My 2008 Add-on Developer Tools Wishlist

Statistics Dashboard

A statistics dashboard for add-on developers that shows historical graphs of downloads and active users based on update pings. The active user data should include breakdowns for the add-on version in use, the application and version, operating system, and add-on status (enabled, disabled, incompatible, etc). This is already being implemented and, if all goes according to plan, will launch (at least on a preview site) by the end of 2007 populated with data from the last 6 months.

Developer Control Panel Revamp

AMO has a lot of new ideas and a lot of new users. The Dev CP is better than it was pre-Remora, but can still come a long way in user experience and discoverability. The public side of AMO will be getting a makeover soon, and following that I’d like to redo the Developer side to support many of the new principles we’re trying to implement.

Localization of Extensions

Although the AMO site itself is available in 20 languages and more every few months, many of the extensions hosted on the site are only available in one. The site is translated, but does not have a truly localized feel to users in other locales. Wil Clouser has been working with the L10n drivers and I think AMO will have a plan soon for how we’ll facilitate the localization of more extensions so that when someone visits the site from Japan, they see featured add-ons that are popular in Japan and have Japanese descriptions and language packs.

Taggable Extension Code Repository

The Mozilla Security group has long wanted a searchable repository of extension code to look for vulnerabilities and also to know if extensions will break if a certain part of Firefox is changed. These searches are currently done manually by AMO admins. A taggable extension code repository would support that, as well as provide extension developers with a large pool of example source code.

When uploading an add-on to AMO, developers would be asked if they’d like their extension to be listed in the extension code repository. The repository would have a wiki-style tagging system, in which anyone could select specific lines of an extension’s file(s) and tag them as “opening a new tab” or “creating a new about: page”. (I volunteer Mark Finkle to be the wiki gardener!)

A simpler version of this that schrep suggested is checking extension source into a CVS repository and using existing tools like LXR/MXR.

Add-on skeletons

A few weeks ago I noticed that Facebook has made it ridiculously easy to create an application. There’s now a “Check out example code for this application” link under each of your applications that pops up a dialog with 3 easy steps to create a working application, two of which are copy and paste and the third is clicking a link.

I was trying to think of ways that we could do the same for add-ons. I know there are already various tools available for creating basic structure for install.rdf and such. Chris Beard suggested creating skeleton extensions for each of the major types of extensions, such as a statusbar extension, sidebar extension, toolbar, theme, etc. This would make it very easy for new developers to dive right into working code and not spend time trying to figure out the directory structure of an extension.

Along with the basic skeletons, we may want to provide “tutorial” skeletons that are extensively documented. For example, where we include a JavaScript file in XUL, we have a comment that explains why you should never include a remote JavaScript file in an extension.

I don’t expect all of these things to happen in 2008, but it’d be cool to see a few of them.