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!

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.

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.

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!

Moving right along...

One of the ways that I verify that Operator is working correctly is by comparing against other sites that do similar functions. For instance, I might go to eventful.com or upcoming.org and compare their Yahoo! or Google calendar to mine.

One of the things I have discovered is that upcoming.org's use of microformats needs some serious help. Let's use this event to demonstrate the various problems.

Problem 1 - Missing information in the microformat

Notice that on the page it indicates the event is from 11AM to 5PM. If you add this event to Yahoo! with Operator, you won't get an end date. If you use the Yahoo! calendar functionality built in to upcoming.org, you will. The end date (dtend) is not specified in the microformat so I can't get it. Here's another one. Notice that there is no phone number on this page at all. But if you add it to your Yahoo! calendar, you'll see a phone number. Also, country information is missing from all pages, even though it is used by upcoming.org's Outlook export feature.

Problem 2 - Extra information in the description

You might have noticed when you added that event via Yahoo! calendar, that the word "Description" appeared at the top of the description. This doesn't happen when you add the event using upcoming.org's Yahoo! functionality. This is because upcoming.org has tagged their description incorrectly. Here's how they tag them:

<div class="description">
<div class="small">Description</div>
Text of the description
</div>

The problem here is that the word "Description" is contained in the description. The correct tagging shold be:

<div class="small">Description</div>
<div class="description">
Text of the description
</div>

Or something similar. They also do this with category. While this might not seem like a big problem, wait until you see what it does with url...

Problem 3 - URLs are tagged completely wrong

On that upcoming.org page, you might try selecting the Web Page option from the event in Operator and see what happens (assuming you are in microformats mode and not action mode). Notice you'll get an error that the URL can't be loaded. This is because the URLs are tagged completely wrong. Here's the URL for that page:

<div class="url">
<div class="small">Homepage<div> <a href="http://blog.coworking.info">http://blog.coworking.info</a>
</div>

At first glance, this just looks like the problem 2, but it turns out to be much worse in this case. If the url class is not specified explicitly on an anchor tag (which it isn't in this case), the specification says to use the entire text content of the url class as the URL. In this case, that would be Homepagehttp://blog.coworking.info. So this turns out to actually break functionality in operator.

So please upcoming.org, fix your bugs. You're making Operator look bad

OK, so if you were one of the unlucky people that got 0.6 with the migration problem, you probably have nothing on your Operator toolbar.

The problem is that it got half migrated, so because we see some preferences, we don't recreate the default set.

Here's how to fix it:

Type about:config in the URL bar and press enter.

Type operator in the filter at the top.

Delete (right click and select reset) ALL preferences that start with extensions.operator.

Once you've done this, close and restart the browser and you should get the default set.

Again, my apologies.

Let's try this again without the migration bug...

Operator 0.6.1 is available from addons.mozilla.org.

Here's what's new in this release:

• Performance Improvements - I've done a few things here. The main thing is that I was going through the document's DOM one time for each microformat. I've reduced that to one time for all microformats, and I also cache the list of microformats as best I can (there's more work to be done here. I've also modified it so that I don't build any menus until the icons are actually clicked. In addition, I removed the code tehat did a reverse lookup on geos to get the address. This was causing a MAJOR performance problem on pages with geo tags. I think this is a deficiency in the geo spec - I wish they had a way to specify a name for the geo on the geo tag.
• User Interface - I've added both a toolbar button and a status bar icon that contain all the Operator functionality.
• Handlers - I've made it so that handlers can indicate that they require data in a microformat. If that data is not there, the handler won't appear. In addition I've added basic support for 30 Boxes. If any 30 Boxes developers are out there, please feel free to contact me so we can discuss why I can't make 30 Boxes work as good as Yahoo or Google Calendar. I've also added support for Yedda.
• Microformats - I've added support for hResume. It's not there by default, so if you want to see it, you'll have to add it using the Microformats tab in Options.
• Debug - I've modified the debug dialogs so that they now display in a readonly text area that can be copied to the clipboard. They are also formatted better.
• Tags - I've improved the parsing to be more compliant with the spec for valid/invalid tags. You'll notice the tags on my blog don't display because they are invalid. (Thanks blogger!)
• Browsers - I've verified that Operator works on Flock and modified the install.rdf to support Flock
• hCard - I've added support for the "hCard reference via object."

I hope this version addresses some of the concerns people had about the Operator UI as well as performance. Please give me any feedback you have!

FYI, for the next release I'll be working on:

• Script management
• Missing elements in certain microformats
• Customizing how URLs are opened
• Ability to save vcards and icals, not just export them

Enjoy!