Archive - January, 2007

Parsing microformats

Update: This code is now contained in Microformats.js.

One of the things I’ve run into with Operator is learning how to parse microformats correctly. Instead of keeping the knowledge I’ve found to myself, I’ve decided to work with Andy Mitchell and create a generic cross browser microformat parser in JavaScript, tentatively called ufParser. That’s the reason I’ve been so quiet.

The parser allows for the creation of definition files for microformats, so that new microformats can be added to the parser easily. So far I have all of the Operator microformats done (hCard, hCalendar, hReview, hResume, geo, xFolk, rel-tag) and I have done XFN.

We’re also investigating the potential to create more generic actions as well (but I’ll maintain compatibility with old style Operator actions).

The next version of Operator will definitely use the new parser, so there might be some regressions here and there. Hopefully we’ll get them solved quickly

Stay tuned. I’m hoping to have something in the next week or so.

Operator 0.6.2 is available

The official release of Operator 0.6.2 is available.

Here’s a full list of new features:

  • Multiple languages available thanks mainly to babelzilla.
  • Fix for the tabbing interaction bugs
  • Options menu added to statusbar and toolbar button menu
  • xFolk support (needs to be added explicitly in Options if you are not a new install)
  • tag support for ma.gnolia.com
  • Improvements to adding calendar entries
  • include-pattern support for hCard and hCalendar
  • Implied “n” optimization for hCards
  • Improved debugging dialogs to use text area instead of alerts so they can handle large data and can be copied
  • When debug mode is on, microformats with invalid items are bolded
  • When debug mode is off, invalid microformat errors are placed in the Error console
  • When you are in microformats mode with all handlers and have debug mode on, you get an additional menutem called “Debug” that displays the source and internal representation of the microformat (no more keystrokes)
  • Selecting an invalid microformat displays error and source in the same window
  • Operator now follows the bookmarks toolbar conventions for opening new windows and tabs. This includes:
    • Opening links in the current window by default
    • Middle click opens in a background tab
    • Shift+click opens in a new window
    • Ctrl/Ctrl+Shift open in a new tab based on the hidden preference browser.tabs.loadBookmarksInBackground (which is the opposite of Select new tabs opened from links – see my previous post)
  • If you right click on a microformat, the microformat handlers show up on the context menu
  • I have added an experimental feature for highlighting microformats that can be turned on in preferences. Not only does it highlight microformats when you hover over them, when you select microformats in any Operator menu, they are highlighted on the page. Please give me feedback on this item.

Here’s my social contract status for this release:

  1. All code was run through JSLint
  2. All handlers were tested
  3. All migrations were tested
  4. This release contains safeguards against leaving in debug messages in
  5. I learned more XPath and was able to use it in more places to improve performance
  6. I made multiple beta versions available before the official release
  7. I fixed every bug that was reported so far

Note the “Extra Extra” tab in Debug is there for a reason – I’ll be posting about that soon.

Thanks for your support!

One More Operator 0.6.2 beta

http://www.kaply.com/operator/operator.xpi

I added a few more features, so I need more testing. After this, I am totally feature frozen for the 0.6.2 release.

New features include:

  • Operator now follows the bookmarks toolbar conventions for opening new windows and tabs. This includes:
    • Opening links in the current window by default
    • Middle click opens in a background tab
    • Shift+click opens in a new window
    • Ctrl/Ctrl+Shift open in a new tab based on the hidden preference browser.tabs.loadBookmarksInBackground (which is the opposite of Select new tabs opened from links – see my previous post)
  • When you are in microformats mode with all handlers and have debug mode on, you get an additional menutem called “Debug” that displays the source and internal representation of the microformat (no more keystrokes)
  • Selecting an invalid microformat displays error and source in the same window
  • If you right click on a microformat, the microformat handlers show up on the context menu
  • I have added an experimental feature for highlighting microformats that can be turned on in preferences. Not only does it highlight microformats when you hover over them, when you select microformats in any Operator menu, they are highlighted on the page. Please give me feedback on this item.

Thanks again for your support!

Operator Usability Continued

OK, after opinions and debate, here’s what I’ve come up with.

I’ve combined the source view and the internal representation into one tabbed window so I only need one action to display it.

For now, that action will only be available when you are in microformats mode with all handlers displayed AND debug mode. When that is done, you will have a new menu in the handlers that says “Debug” that displays the information. I might add a keystroke/mouse action later.

When a microformat is invalid, clicking on it will display the same window (again, debug mode only)

I am going to honor the browser settings for Ctrl/Shift behavior for opening new windows. This however has me in a new quandry.

Here’s the note I sent to the Mozilla usability folk (Mike Beltzner):

I’m looking into making operator honor the browser preferences related to opening links (in tab, in tab background, in new window, etc.)

On investigating this problem, I found that there are two prefs that control this functionality;

browser.tabs.loadBookmarksInBackground

and

browser.tabs.loadInBackground

browser.tabs.loadInBackground is used for content, and browser.tabs.loadBookmarksInBackground is used for chrome (I’m guessing mainly bookmarks)

The user can’t change browser.tabs.loadBookmarksInBackground easily – the pref UI only changes browser.tabs.loadInBackground.

So my question is, which preference should Operator use for opening links (what would a user expect)

Would they expect it to behave similar to content or similar to bookmarks (chrome)

Note the biggest difference here is what happens when Ctrl and Ctrl+Shift are pressed when opening a link.

Incidentally, by default these preferences are opposite which makes for a horrid user experience.

Create a new profile in Firefox 2.

Hold Ctrl key. Click on a link in content. Then hold Ctrl and click on Getting started in the toolbar – two different results. That sucks.

Thanks for your input.

More opinions welcome

Need Operator Usability Opinion

I need to make a change to how Ctrl (and maybe Shift) key works in Operator and I need some opinions.

Currently, holding down the Ctrl Key when clicking on an entry in
Operator displays the HTML source and holding down the shift key when
clicking displays the content as I store it in an internal structure.

Unfortunately, my choice of the Ctrl key was a bad one, since the Ctrl
key is used to affect tabbed browser behavior. I’d like to change
Operator so that when the Ctrl key is held down when clicking, it
opens the web page specific to the operator action in a background
tab.

My choice of Shift was also bad, since Shift forces links to open in new windows.

The only keyboard action I’m left with using is Ctrl+Shift at the same
time (alt isn’t available).

So, here’s the question.

Of the two actions I provide, which is the most useful to microformat
developers, seeing the source of the microformat or how I interpret
it?

Should I assign the Shift key to displaying the microformat and
Ctrl+Shift to displaying my internal representation (since I may be
the only one that uses it). This would mean I couldn’t use the Shift
key to open a new window.

Alternatively, should I simply add menu items that correspond to these
two actions when Operator is in debug mode and get rid of the
keystrokes completely.

Or perhaps a menuitem to display the HTML, and the hidden action (Ctrl
key) displays the internal representation.

Or maybe have Ctrl and Shift do exactly what they do today only in debug mode?

Thanks in advance for offering your advice.

Operator 0.6.2 beta Available

Per my social contract, I am making 0.6.2 beta available before placing it on addons.mozilla.org.

It’s available at http://www.kaply.com/operator/operator.xpi

Significant items in this release include:

  • Fix for the tabbing interaction bugs
  • Options menu added to statusbar and toolbar button menu
  • xFolk support (needs to be added explicitly in Options if you are not a new install)
  • tag support for ma.gnolia.com
  • Improvements to adding calendar entries
  • include-pattern support for hCard and hCalendar
  • Implied “n” optimization for hCards
  • Improved debugging dialogs to use text area instead of alerts so they can handle large data and can be copied
  • When debug mode is on, microformats with invalid items are bolded
  • When debug mode is off, invalid microformat errors are placed in the Error console
  • I have tested this release significantly, including running JSLint against all code, testing migration from Operator 0.5 and 0.6.1, as well as starting a test suite. If you find problematic pages, please add them to the test suite.

    Please report bugs here.

    Thanks!

    Essential Extension Development Preferences

    Jonathan Watt pointed out some preferences you can set to ensure that the JavaScript code in your extension is “clean.”

    javascript.options.showInConsole set to true causes chrome JavaScript errors to be displayed in the JavaScript console. This preference is essential when you are writing/debugging your extension. If you don’t have it set, your extension will simply not work and you won’t know why.

    javascript.options.strict set to true causes JavaScript to parsed in such a way such that you will see errors about bad code on the console. If I had set this preference, I would have found my problem.

    Why Use JSLint?

    In my social contract, I taked about using JSLint.

    There were two problems reported with the current release of Operator that were very strange when I heard about them. One was that Firefox didn’t honor the “Show the tab bar when only one tab is open” preference anymore and the other was that external links opened in new windows. I spent a bit of time debugging the problem and tracked it down to this code:

      disable: function()
      {
        toolbar = document.getElementById("operator-toolbar");
        toolbarbuttons = toolbar.getElementsByTagName("toolbarbutton")
        for(var i=toolbarbuttons.length - 1; i>=0; i--) {
          if (toolbarbuttons[i].id != "operator-options") {
            toolbarbuttons[i].setAttribute("disabled", "true");
            toolbarbuttons[i].label = toolbarbuttons[i].getAttribute("origlabel");
            toolbarbuttons[i].setAttribute("label", toolbarbuttons[i].label);
          }
        }
      },
    

    Do you see the problem there? Because I didn’t have “var” in front of toolbar, I was affecting the global variable toolbar which was causing all the problems that people were seeing. Anytime an extension uses a variable with a common name without putting “var” in front of it, it risks overwriting other global variables in the browser.

    Running JSLint through my code with the “Detect undefined variables” option would have found this problem and other problems as well. When I used JSLint, I found many cases where I had done this and I was able to easily find and fix them all.

    Some of the other things I was able to fix as a result of JSLint included missing semicolons, unnecessary global variables, using == where I should use ===, as well as general cleanup. One error in particular (Weird construction. Delete ‘new’.) encouraged me to reevaluate some code I had written and I was able to clean it up considerably.

    So I would encourage you to at least attempt to run JSLint against your extension to make sure you aren’t creating any side effects you don’t intend.

    Note that there is one construct that JSLint complains about that is very common in Mozillla/Firefox source code:

    Components.classes["@mozilla.org/embedcomp/prompt-service;1"]
                               .getService(Components.interfaces.nsIPromptService);
    

    JSLint would prefer you wrote it like this (note the location of the period)

    Components.classes["@mozilla.org/embedcomp/prompt-service;1"].
                                getService(Components.interfaces.nsIPromptService);
    

    I went ahead and made this change in my code to avoid seeing the JSLint errors, but your mileage may very.

    Extension Development and Social Contracts

    In most software installations, the user (you) agrees to a EULA where limitations and restrictions are spelled out. By reading the EULA, you can make a decision as to whether or not you want to install the software. The EULA in a sense gives you the developer’s side of a contract, and by agreeing to the EULA, you are deciding to accept that contract. A EULA could have a statement like “this software will slow down your machine” or “this software will cause all other applications to break,” but you have the opportunity to read these statements in the EULA (usually) and decide whether or not to install the software.

    Extension development, however, involves an implied social contract, because in most scenarios, a user is not presented with a license agreement before installing the extension. Here are a few examples the developer’s responsibilities in that contract:

    • Not slowing down the browser
    • Not breaking existing extensions
    • Not breaking browser functionality
    • Not losing any of the user’s data
    • Not stealing/misusing the user’s personal information
    • Not formatting the user’s hard drive :)

    With previous versions of Operator, I was not proactive enough in making sure I didn’t break the contract. (Part of this was related to the fact that I committed to a specific release date, so I rushed things a little bit.) So the goal of this post is to outline for you (and for me) a basic social contract to make sure that what happened with Operator in the past does not happen in the future.

    The Operator Social Contract

    1. I will run all of my JavaScript code through JSLint or something similar to ensure I am not making mistakes in my JavaScript that can break browser functionality or other extensions before every release.
    2. I will test ALL handlers for ALL microformats before making any build of Operator available.
    3. I will test migration from one release back as well as Operator 0.5 for every release.
    4. I will modify the method I use to debug Operator to ensure that I do not accidentally leave debug messages in the extension when I ship.
    5. I will continue to educate myself on JavaScript and extension development so that I can find ways to improve the performance of Operator.
    6. I will not commit to any specific day to release an update to Operator.
    7. I will not make any Operator build available on Firefox Add-ons before it has been made available on my personal website for testing by the community.
    8. I will take all bug reports seriously and attempt to solve them.

    So there you have it. The beginnings of a developer’s social contract. So where am I in meeting this contract?

    1. I have fixed the specific bugs relating to migration and Operator interfering with tabbed browsing.
    2. I have run all of the Operator code through JSLint and found a number of issues which I have fixed.
    3. I have created an API I use for debugging that is automatically disabled in release builds.
    4. I have found some new ways to do some JavsScript that increase the performance of Operator substantially.

    Per my contract, I am not committing to a specific day for the next release, but I am hoping to have something available this week (the week of Jan 7, 2007).

    Thanks for your support!

    upcoming.org microformats got some loving

    Thanks to the great work of the upcoming.org team, the major issues with upcoming.org and Operator are already fixed.

    Thanks y’all!

    Page 1 of 212»