From Amazon’s Cloud Reader Installation:

From the University of Virigina’s guide to setting proxy settings in Firefox:

From HootSuite’s TwitterBar acquisition announcement:

From Tecca’s Guide to Internet Explorer:

That’s right: they all include portions of browser chrome. (Chrome 13, Firefox 3, Firefox 4 for Windows, and Internet Explorer 9, I believe.)

What else do these screenshots have in common? They will all one day be out of date (if they aren’t already). As soon as Google modifies their extension installation dialog, or Mozilla changes their proxy settings tab, or the Firefox address bar gets a new background color, these screenshots will no longer accurately represent the interaction through which they’re meant to guide the user.

A Modest Proposal

I propose that this problem of stale browser screenshots could be alleviated by the creation of a Web service that exists solely to serve semi-dynamic screenshots of browser chrome. Allow me to explain with examples.

The Amazon screenshot above could be replaced with a call like this:

<img src="http://browsers.foo/addons/installation?highlight=confirm&w=460&h=60" />

Or the TwitterBar image could use this URL instead:

<img src="http://browsers.foo/toolbar/?include=url-bar,icon&icon=http://foo.com/hoot.png&highlight=icon" />

(Note the idea of being able to merge existing images into the screenshots.)

The IE add-ons dialog screenshot could just as easily call this URL:

<img src="http://browsers.foo/addons/tracking-protection?browser=ie&version=9&highlight=easy-list" />

The API would automatically use the user’s user-agent to determine what browser, version, and platform to show in the screenshot (although these could also be specified manually, as seen in the IE example). If images from the exact current version aren’t available, the most recent version could be used instead.

I think that with a couple dozen high-resolution, high-quality screenshots of the various windows and dialogs in each major browser version on each major platform combined with metadata defining the position of key elements in those screenshots (e.g., the home button, the address bar, the History menu), 90%+ of the browser-specific screenshots on the Web could be replaced by calls to this service.

What do you think?

Is this a solution in search of a problem, or is it a legitimately useful idea? I think it would be worth its development costs just for organizations like Mozilla or Google to use in order to populate their help documents with screenshots that would always be up to date. Tell me what you think in the comments below.

That being said, FireFound will be shutting down on June 1, 2012. I don’t have the time to keep it compatible with the newest Firefox and Firefox Mobile releases, nor can I keep up with the feature requests and bug reports.

FireFound users who would like to save a copy of their location data can, as always, export their data by logging in and clicking the “Download” button on the “My Data” page. Any users who have pre-paid for a Premium account past June 1 will be given a prorated refund.

For those looking for a suitable replacement, I recommend Prey. It’s an open-source implementation of a similar idea, but it runs at the operating system level rather than inside the browser, so it’s always on.

(If you’re interested in taking over FireFound, e-mail me at cfinke@gmail.com. If you’d just like to run your own instance of FireFound, all of the code is open-source.)

I now have six months of data, and I’ve run some statistical analysis on it in order to share some interesting stats with you. (If I were more creative, I would make an infographic out of this information.) Note that this data does not include bookmarked links or links that users click on in websites. It is strictly domains that have been typed directly into the address bar.

View the code at GitHub.

Usage

The new usage rules are as follows:

• Replace MY_EXTENSION_NAMESPACE with the namespace of your extension’s files. e.g., if your files are at chrome://abcdefg/content/, then replace MY_EXTENSION_NAMESPACE with abcdefg.
• Rename MY_EXTENSION_STRINGS to something that won’t interfere with another extension.
• The _locales directory from your Chrome extension should be in the chrome/content/ directory of your Firefox extension (or update my code to point to wherever you put it).

Advantages

This code has four advantages over the previous versions:

1. It’s a single code block that works with all recent versions of Firefox.
2. You don’t need to include an additional library for file I/O.
3. It fixes a bug in retrieving the proper locale code in Firefox on Linux.
4. You don’t have to specify <em:unpack>true</em:unpack> in your install.rdf in Firefox 4.

Thanks Wladimir for your input; this version is undoubtedly better than both previous versions. I can’t ensure that it’s the best possible solution, but it’s the best one that I’ve found so far.

A few months ago, I posted a snippet of code that provides an API for using locale files from Google Chrome extensions in extensions for Firefox 3.6 and older. I’ve now added support for Firefox 4, and the updated code is shown below:

View the code at GitHub.

The same usage rules still apply:

• Replace “MY_EXTENSION_ID” with the ID of your extension.
• Rename “MY_EXTENSION_STRINGS” to something that won’t interfere with another extension.
• The _locales directory from your Chrome extension should be in the chrome/content/ directory of your Firefox extension (or update my code to point to wherever you put it).
• Include the excellent io.js library in your extension.
• NEW: For Firefox 4, you’ll need to specify <em:unpack>true</em:unpack> in your install.rdf.

I’ve been using this solution in ScribeFire in Firefox 3.5, 3.6, and 4.0 (and 5 and 6) for a while now with no complaints. Let me know if you implement this in your extension, and I’d love any feedback you have on the code or its performance.

If you’d like to take over development, let me know, and I’ll transfer the Slashdotter add-on to you on AMO; if nobody volunteers, I’ll be removing the add-on from AMO in a couple of weeks. (Like all of my browser extensions, Slashdotter’s source code is open source, so you could still develop your own version if you want.)

My Firefox add-on TwitterBar, the world’s most popular Twitter client for Firefox’s URL bar, has been acquired by HootSuite and has been renamed “HootBar.”

HootBar users now have access to great HootSuite features like the Hootlet: instead of typing “–post” at the end of your tweet, if you type “–hoot”, you can schedule your tweet for later, send your message to networks besides Twitter (like Facebook or LinkedIn), and track stats for link clicks.

The rebranded version of TwitterBar is still awaiting approval by Mozilla, but you can install it manually here. More information on the TwitterBar-to-HootBar change is available at HootSuite’s “TwitterBar to HootBar” transition page.

I’ve finished work on the first version of a client-side spellchecker written entirely in JavaScript, and I’m calling it Typo.js. Its express purpose is to allow Chrome extensions to perform spellchecking, although there’s no reason it wouldn’t work in other JavaScript environments. (Don’t use it for Firefox extensions though; use Firefox’s native spellchecking API.)

How does it work?

Typo.js uses Hunspell-style dictionaries – the same ones used in the spellcheckers of OpenOffice.org and Firefox. (Typo.js ships with the latest American English dictionary, but you could add any number of other dictionary files to it yourself.) You initialize a Typo.js instance in one of two ways:

Method #1

var dictionary = new Typo("en_US");

This tells Typo.js to load the dictionary represented by two files in the dictionaries/en_US/ directory: en_US.aff and en_US.dic. The .aff file is an affix file: a list of rules for creating multiple forms of a word by adding prefixes and suffixes. The .dic file is the dictionary file: a list of root words and the affix rules that apply to them. Typo parses these files and generates a complete dictionary by applying the applicable affix rules to the list of root words.

Method #2

var dictionary = new Typo("en_US", affData, dicData);

With this initialization method, you supply the data from the affix and dictionary files. This method is preferable if you wish to change the location of the affix and dictionary files or if you are using Typo.js in an environment other than a Chrome extension, such as in a webpage or in a server-side JavaScript environment.

Once you’ve initialized a Typo instance, you can use it to check whether a word is misspelled:

var is_correct_spelling = dictionary.check("mispelled");

Customization

Depending on your needs, you can configure Typo.js to perform word lookups in one of two ways:

1. hash: Stores the dictionary words as the keys of a hash and does a key existence check to determine whether a word is spelled correctly. Lookups are very fast, but this method uses more memory.
2. binary search: Concatenates dictionary words of identical length into sets of long strings and uses binary search in these strings to check whether a word exists in the dictionary. It uses less memory than the hash implementation, but lookups are slower.

See this blog post by John Resig for a more detailed exploration of possible dictionary representations in JavaScript.

Practice vs. Theory

Typo.js is already in use in my Comment Snob extension. You can install it today to experience Typo.js in action, filtering comments on YouTube based on the number of spelling mistakes in each one.

What’s next for Typo.js?

The next step is adding support for returning spelling suggestions; right now, all Typo.js can do is tell you whether a word is spelled correctly or not. It also needs to support Hunspell’s compound word rules. These are the rules that a spellchecker uses to determine whether words like “100th”, “101st”, “102th” are correct spellings (yes, yes, and no, for those of you keeping track) since it would be impossible to precompute a list of all possible words of these forms.

The Typo.js code is available on GitHub. I welcome any and all suggestions or code contributions.