Operator 0.7a is available. This is an alpha release. Really.

You probably won’t notice anything obvious that has changed, but under the covers, things are very different. Here’s a list of some of the changes:

• Complete rewrite of parser and actions system
• Experimental support for species and XFN (These probably won’t be in the official release)
• More complete support for hCard and hCalendar
• Exporting a contact or event now gives you the option to save it to disk
• You can choose to not remove duplicate microformats
• Various bug fixes
• Ability to drop in Brian Suda’s X2V transforms to compare results (More info on that later)
• REMOVED: Ability to have default handlers for a given microformats

The new actions system is in flux right now, so I’m not giving any detail on how to write to it yet. Old handlers will still work, so if you have those, just drop them in.

If you find bugs, please report them as comments to this post.

As per my social contract, all code has been run through JSLint and migration from three versions of Operator have been tested.

Enjoy.

Why does it seem that every piece of software needs to be rearchitected at least once or twice?

So after chatting with Andy Mitchell about his Webcards work we decided to collaborate to try to avoid duplicating effort. I’m just about done with phase one of that effort.

The results of this effort include:

• Moving to a unified non Operator specific, non browser specific microformats parser.
• Moving to a unified actions architecture (Extension specific right now, but we’re working on that.)
• Nearly complete support for all included microformats.
• Ability to use legacy handlers.
• Ease of adding new microformats (I’ve added XFN and species just for fun).

After much internal struggle, I decided to actually remove one of Operator’s options because I think I was trying to hard. Operator has two modes, Actions and Microformats, and within Microformats, you could choose to have a “default handler” or display all handlers. If you chose not to display all handlers, you would get a similar UI (toolbar buttons), but they would only invoke the default handler. It seemed logical when I wrote it, but this function (if needed) can be emulated by actions. I hope no one complains about my removing this.

Visually, everything else remains the same, except I cleaned up the names of some of the actions. It’s really only the guts that have changed. Obviously there’s the potential for new bugs in this implementation, so I’m trying to get something out this week to start some testing.

If you have written handlers for Operator, please let me know so that I can make sure my legacy code is working. I’m not going to explain how to write to the new action API yet since it is not baked.

Thanks!

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.

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!

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!

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

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.

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:

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!

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!

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

Thanks y’all!