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.

  • Ray Kiddy

    I am glad to see your suggestions. They are all good things to do. I think that if MoCo helped extension developers, and gave them a place to manage their code from, and this provided tools that would help MoCo help them, this would all be good.

    Can I suggest, too, that there be assistance for testing extensions as well. For example, if an extension’s source is up, it can be part of the tinderbox tests. This would help motivate people and we would all be able to see whose code is working.

  • kiroset

    I would like to have better support for multiple versions of an extension targeted to different versions of firefox.

    I have an extension on AMO for firefox 2 – that version won’t work in the firefox 3 betas.

    I have a (extensively) changed version that works with firefox 3, and it just not feasible to combine the two into one.

    I can’t put the new version on AMO for firefox 3 beta testers because then all the regular people on firefox 2 wouldn’t get a version that works right now (I know about “previous versions” link – not good enough, people won’t find it)

    So AMO should be smart enough to serve ff3 targeted version to ff3 users and ff2 targeted version to ff2 users.

  • Nickolay Ponomarev
  • fligtar

    I’m encountering a similar problem myself at the moment. I’m going to look into what we can do about that soon.

    Yeah, that’s one of the existing tools along with XULExlorer that are helpful. Rather than a generator, I’d rather have a zip file that the user just downloads, extracts, and copies the id file to their profile extensions directory.

    They can then play around with the extension without having to know what all of the options on the extension generator page mean. Then, if they actually want to distribute the extension, it’s very easy to change the default values in install.rdf.

  • Dwayne Bailey

    I was about to report a bug for the statistics on AMO. But then found the bug that you are working on.

    The screenshots look lovely. All I can say is thanks! We have about 11 languages and a growing number of dictionaries on AMO. But seeing those number as they currently are give me no idea if our latest PR worked. And I can’t stand up and say X people use our Afrikaans spell checker and Y download it every week.

    Can’t wait for this to land, count me in if you need beta testers.