Last week I blogged Part 1 of the previews of upcoming changes to the Developer Tools area of This week we’ll look at another new page in the revamp, now known as AMO milestone 3.5.

One UI element present on a number of pages in the Developer Tools area is the Translation Box. Anytime there’s a field that can be localized, this box appears to allow developers to switch text fields between locales. This is what the Translation Box currently looks like on the Edit Add-on page:

As I neglected to announce 2 weeks ago, AMO 3.2 launched very smoothly (technically anyway – the cluster stayed up this time!)

For a few weeks before 3.2 launched, I’ve been working on a big project for an upcoming release of AMO: a rewrite of the Developer Tools area to make the user interface more intuitive and provide a number of new features to give developers greater control over many aspects of their add-on listings. I don’t have the work done so far on a staging server, but I’ll be blogging with screenshots as I finish various sections and asking for community feedback.

There are a number of big changes to the overall structure of how add-ons will be submitted, updated, and modified. The first few posts will focus on the new editing tools. Managing add-ons will be really simple and easy to figure out in the new design because the tools have been separated out into 6 different sections rather than one long, confusing page.

Yesterday, Mike announced the public preview of the upcoming changes to (AMO). One of the new features that has been long-requested is the ability for developers to see how many update pings, or Active Daily Users, their add-ons have. Just like Firefox, extensions check for updates once a day, and we count how many times this happens for each extension. While the total number of downloads tells add-on authors about how many people have tried out their extension, the active daily user count tells them about how many people used it on a given day, although it’s not perfect.

There’s a bit of fine print regarding active daily usage, but some of the more important points are:

  • Only add-ons that do not have an updateURL specified are counted. All add-ons are required to have an empty updateURL when submitted to AMO. If an add-on is distributed from another website with an updateURL, those pings are not counted by us.
  • Active Daily Users is not the same as saying “this many people use my extension”. Not all extension users use Firefox every day of the week, users can manually check for updates which will count false active users, etc.
  • Many people keep extensions installed but disabled. The stats dashboard allows you to see the various statuses, such as enabled, disabled, incompatible, etc.

Now that some background information is out of the way, on to the features!

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.

Someone asked me how I was searching Bugzilla from my location bar last week, so I figured there are probably a few others who aren’t familiar with QuickSearch + SearchWords and would benefit greatly from finding out about it, so here’s a post!

The little search box on every page of Bugzilla is useful for more than just typing in bug numbers – it actually has a pretty detailed syntax that can be used to narrow down bug queries faster than using advanced search in many cases. Jesse has a page listing all of the tricks, but I’ll mention a few of the ones I use.

Using a colon in QuickSearch specifies the product or component to search in. For example, :firefox would search bugs in the Firefox product and searches,, and a number of components in Websites.

QuickSearch defaults to searching only open bugs, but adding “ALL” as the first word of your search will make it search both open and closed bugs. @ will search for bugs assigned to that user. So, “ALL :addons @fligtar” returns all bugs I’ve fixed or am currently assigned to in product.

QuickSearch is great in itself, but combined with SearchWords, it’s even better. (SearchWords is part of Firefox 3, so you only need to install it in Firefox 2.) I have the “bug” keyword associated with the Bugzilla@Mozilla search engine, so typing in “bug :cvs” in the location bar will return all of the open CVS Account requests.

I never bookmark bugs because of this method, even if it means once a day doing Command + T, Command + L, “bug :addons statistics” to find the same bug over and over.