Ways to Improve Mozilla’s Extension Pages

I’ve been recently paying more attention to the extensions-side of the Firefox project. Mozilla.org does not maintain a website for extensions, as most are third-party developed. A lot of extensions are mozdev.org projects, and the MozillaZine forums provide some user-to-user support for help and troubleshooting. There are two sources that are trusted, in general for Extensions; they are Firefox Help’s Extensions page and The Extension Room. Both sites use the same database of extensions maintained by the MozDev database project. During the release, and even before that, stuff that needed improving had been coming to me, with the way that Extension Room itself is laid out and works. I pick Extension Room to discuss specifically here, because it hosts extensions for all Mozilla products that support them (Mozilla Suite, Firefox and Thunderbird). It’s a good concept, but it really needs a lot of changes to make it more usable for visitors.
The most critical of which is that neither site seems to be truly reliable. Especially during releases, when the servers they’re on get loaded with traffic, and become unavailable. This is to be expected to a point given the increasing popularity of the releases, but is not really acceptable when it comes to trying to serve people with add-ons to the new product. It passes a feeling of unreliability on the availability of extensions to the user. Both Firefox Help and Extension Room both have been down a lot, during the release. Though, Firefox help is down by choice, as far as hosting extensions go, to focus on the help content and keep the server, which is private, and has a corporate website also hosted on it, operational. One problem which has been an issue with the Firefox Help Extensions page in the last month was a problem with syndicating the database to texturizer.net for Firefox extensions. The database would be incompletely transferred, breaking it entirely, or listing only half of the extensions. Though, this has not occurred in the last couple of weeks. Extension Room has also had some database-related downtime, because of errors with human-error in entry to the database.
The other issues I’ve found are usability issues, with the sites. Starting with the most serious, and more or less going to least important’
Extensions Listed on Extension Room are not really marked as being compatible with a new version of Firefox. This has created problems and some confusion for new Firefox 0.8 users recently, who expected any of the extensions on the list to be 0.8 compatible, because nothing said otherwise. The site assumes that the listed extensions are current, and does not have a maximum version they’re verified as being compatible with listed. They list the fact that the extension is for Firefox, and in some cases starting and ending dates for which builds it works with, but those cases are few. This is misleading, users assume that because the site says it works with Firefox that it works with all versions, and most are quite surprised when they have problems. Rather than assuming the max version, it should be defined, the current version it works with when the extension was added, as it’s better to assume it may break in the next release than to assume it works. Testing the extension with the newer release, once the code freezes for the release, would enable someone to update the information for the extensions with either a works (Verified) or a doesn’t work (Incompatible), for the newest release prior to it’s release date. Any extensions that remain untested should show that state (Untested). and not be listed by default, but it should be possible to find a list of such extensions, fairly easily, since they do need testing by more experienced end-users, who are capable of dealing with problems if they’re incompatible, and reporting back that information, and to bury them would create a wasteland of lost extensions, after each release. The default state for a new release for all existing extensions should be Untested, unless otherwise noted, as it’s possible for nobody to have time to do such testing, and defaulting to incompatible make that state more ambiguous by creating a degree of doubt, is this extension actually in incompatible, or just untested? This three-state system makes it very obvious to the end-user if an extension is or isn’t going to work. Though the middle state, untested, is still ambiguous, and encourages testing prior to a release. It also allows for expandability, for other states, such as certified extensions, in the future. As for the UI for the website for a list broken down like this, the page should auto-determine the version the visitor is visiting with, and present them with the list of verified extensions for that version of that product. With links to also view the other states for that version of the product, keeping a clean layout, so that the extensions on the page, are what’s emphasized, and not the links.
The next problem, which has been recently improved, with Extension Room specifically, is by being verbose and trying to give as much information about the extensions as possible, the page is way too large, and took too long to load especially on dial-up connections, as the page was 250k to load, before images. Now the page is not verbose enough, furthering the problems with point 1 above and gives a short description and extension title only, though it is grouped by category. In order to get any more detail you have to click the name of the extension and go on to the ‘more-info’ page. One extreme is as bad as the other. In theory, at a glance you should be able to see the Extensions Title, Date, Version, and Compatibility info (or at least the simple version of it for the version of whatever product you’re viewing), more info and download/install links. The other flaw with page size is the fact that the page attempted to show the entire list on one page, which is not feasible by any means, once the list gets above a certain size. To make such a list viewable by the most clients, is has to support the ability to customize the number of extensions per page, depending on the total number, anywhere from 5 to 20 per page should do it, to allow sufficient customization for dial-up to broadband users.
The last point is subject to debate, though some users might find it useable, and that would be the ability to sort the extensions in multiple methods, specifically by name, category, and date (newest to oldest), with the default being by name, as people looking for a specific extension are most likely to find what they want quickly, and those casually browsing won’t be hindered by the organization. Given a good placement, such options should not over-complicate the interface and make it cumbersome, in my opinion. Though if such options aren’t feasible while maintaining a clean user-interface, then they should be dropped in favor of the default alpha order.
Overall, the user-interface of the site should be clean, with good graphics and an emphasis on the content, while not being hard to use, the placement of links being where they’re easily accessible from a usability standpoint.
A point that may be a problem with the first point above, that I’m thinking now, the auto-detection of the browser that’s being used, may create problems for people hoping to just download the extensions in one place and install them on another machine. Particularly if that machine is running a different version of the product. Also, this would apply to Thunderbird users, who don’t qualify under auto-detection, for obvious reasons, therefore, there’d have to be some way to be able to generate such a list from user-selected product/version values as well. Such items may be more likely to complicate the interface, but unfortunately, are most likely required.
My last idea for how to improve the way extensions are handled from the website is a feature similar to the PHP project’s my php.net page, where most of UE settings are storable as cookies in the browser. That way a user could customize their view of the extensions pages to suit their preferences and store them. So they don’t have to customize that view every visit like with some sites of a similar nature. Options such as sort order, extensions per page, and other customizable options in the final layout, should have an option to be set permanently, to make it useable quickly. For those cases where the defaults don’t work for the user, such as a broadband user who prefers more than 5 extensions per page, while the default shouldn’t be higher than say 10, else making it difficult for dial-up users, such a page would solve the problem.
With these issues addressed, I’d say that an Extension website would be much more useful to the new and current users of Mozilla products, and considering the growing emphasis on extensions with Mozilla Firefox and Thunderbird over the Mozilla Suite, the issue of lacking a good usable site grows.