I’ve been thinking about ways to improve collections since last year, especially as many other sites now support similar groups of content. Facebook has groups of friends, Twitter has lists of followers, Youtube has playlists of videos, and we have collections of add-ons. We’re a bit different though: collections were designed primarily as a sharing vehicle, which is why we have a public directory listing them when other sites don’t.

But one thing I really love about others’ list features is their simplicity of creation and management. We’re well underway in rewriting addons.mozilla.org in Django, so now is the perfect time to make some improvements to the feature as we rewrite it for the new site. With the goals of making collections easier to create and manage, using them to power other features across the site, and making them more personal, here are a few changes in store for collections in the coming months.

Favorite Add-ons and On-the-fly Creation

Probably the most common reason people create collections is to keep track of their favorite add-ons. We’ve discussed the idea of letting users “favorite” add-ons for years and launched the Rock Your Firefox Facebook application in 2007 to let users do just that, though the functionality never made its way to AMO proper. Collections are a great way to keep track of favorites, and we can do a few things to make managing these favorites a lot easier.

Each user with an account will automatically have a Favorites collection created for them, and add-on details and browse pages will have links to quickly add or remove add-ons from that collection.

Next to the new favorites button, the collection selection widget has also been redesigned to easily let you add and remove the add-on from multiple collections at once. As part of this new selection widget, you’ll also be able to create new collections on-the-fly from any page on the site just by entering the bare minimum of information:

Of course, you’ll still be able to create collections the old way and specify additional settings.

Watching Collections

When we launched collections, we also introduced the Add-on Collector extension that lets anyone subscribe to their favorite collections and get notifications in Firefox when new add-ons are added to a collection. It’s about time we brought that functionality to the website itself. Instead of adding a collection to your favorites and then becoming a “subscriber” as currently happens, we want to change the terminology to “watching” a collection. Once you start watching collections, you’ll be able to see any activity on those collections in a central place and can subscribe to updates through an RSS feed.

URLs, Privacy, & Permissions

Less than 0.005% of collections have more than one publisher, indicating that in almost all cases, collections are very closely tied to their creator. With that in mind, I’ve proposed some considerable changes to the way collections are accessed:

• Collections will have a single owner and will be accessed through a URL under that user’s namespace. For example, /collection/myfavoriteaddons12345 can now just be /collections/fligtar/favorites. This also means collection URL slugs can be automatically generated but still editable, like in WordPress.
• Collections can still have contributors that can publish add-ons to a collection.
• Privacy options will be simplified into completely public collections and collections that only the owner can view while logged-in.

These changes should make collections a lot easier to create and understand.

Installing Multiple Add-ons

Less than two months ago, I blogged about why we don’t let multiple add-ons be installed from a collection, even though it’s a very often requested feature. I’ve since convinced myself that it would be okay to cautiously allow users to do this for a few reasons:

• users who want to install more than one add-on will still install more than one add-on, so we’re just making it harder for them
• we can caution the user before they attempt to install a batch of add-ons about the potential confusion after doing so
• Massive Extender has done well allowing add-ons to be batch-installed from the Add-on Collector

Multiple installations will be surfaced through a link at the top of collections that switch into a multi-install mode, where install buttons become checkboxes and a running tally of your selected add-ons appears on the right. We’re also considering the idea of a configurable option that indicates a collection is meant to be installed as a set, such as a collection of add-ons to make your browser look like Firefox 4. Collections that choose this option would have an “Add All to Firefox” button and avoid going through the selection process.

In addition to these new features, all of the collections-related pages will be getting a facelift. You can see all of the new designs by Chris Howse here. For the full list of planned features and changes, read the spec.

What do you think?

If you’ve ever installed an add-on from Mozilla’s add-ons website, you’ve probably clicked on one of the cute, innocent-looking buttons that stand between you and the add-on you want. They’re really important, but also really complicated little devils.

Originally, the job of this button was just to link to the add-on file, and the only complication occurred if the add-on was platform-specific. Things have gotten quite a bit more complex over the years, and the role of the button changed to be a guide as to what the user should and shouldn’t install with the introduction of “smart install buttons” two years ago. Today, buttons are more complicated than ever, taking into account:

• which application’s part of the website you’re browsing in
• which browser you’re using
• whether the browser add-on is incompatible due to not having compatibility bumped after your browser version’s release
• whether the browser add-on is incompatible because your browser is outdated and requires a newer version
• whether the browser add-on is incompatible because it requires an alpha/beta version that has not yet been released
• whether you have JavaScript enabled
• what type of add-on it is
• whether the add-on is compatible with your operating system
• whether the add-on is featured
• whether the add-on has been reviewed
• whether the add-on is self-hosted
• whether the add-on has a EULA
• whether the add-on has a contributions roadblock or post-download page
• whether the button’s context requires it to be large or small
• whether you’re logged in

…and combining all of those factors on the client side (for caching) to produce the button you see. Wil Clouser made a flowchart a few months ago that takes into account many of the current scenarios. We recently worked with Paul Lloyd of Clearleft to redesign some parts of the site for our Django rewrite currently underway, and as part of that, wanted to address a few issues of current install buttons, namely:

• buttons should indicate when they don’t go directly to a file, such as when a EULA or contributions roadblock must be displayed first (bug)
• “recommended” should be changed to “featured” and incompatibility should be moved to avoid confusing wording (bug)
• incompatible buttons should not be green
• add-ons that haven’t been reviewed should have visually distinct buttons and require a click-through warning (bug, blog post)
• make self-hosted add-on buttons and warnings fit more with the current style
• make it easier for advanced users to override the “smart buttons”
• improve the style of the message given to non-Firefox users trying to download a Firefox add-on and make it more obvious how to download anyway (bug)

new button styles

With our flowchart in hand, Paul went to work coming up with a new way of presenting our buttons that’s more consistent and takes into account all of the cases we wanted to address. One of the first suggestions made was to limit our button styles to just a few, rather than coming up with lots of different colors for different types of buttons, as we had started to do with things like collections. The new button styles have only 4 variations: green for add-ons that are reviewed and can be installed, blue for links and generic buttons, yellow with caution bars for add-ons that haven’t been reviewed, and a faded look for incompatible add-ons or buttons that should probably not be clicked.

Looking at some of most common pain points for button clickers, an annoyance often encountered is that in order for advanced users to ignore the version check for incompatible add-ons, they have to be logged in with an AMO account. We decided that the ability for a button to be clicked should not be dependent on whether the user is logged in, as long as proper warning is given. It will now be possible to ignore the warning and install an add-on anyway in every case except when an add-on has been marked as requiring a newer version of Firefox than you currently have.

Here’s a matrix showing almost all of the possible button scenarios with our new buttons:

The buttons in the matrix can currently be previewed on the Button Smorgasbord. Craig Cook and Jeff Balogh created the buttons using CSS3 gradients, even for the cautionary stripes, so only browsers that don’t support them will need to download a background image.

I’m very excited for these buttons to start appearing on site as we roll out Zamboni, our Django rewrite, as I think they provide a much better experience for both novice and advanced add-on users.

First, some background

This month marks the three year anniversary of the “sandbox” review model being introduced on addons.mozilla.org. Veteran Mozilla contributors and add-on fans may remember what the process was like prior to the sandbox: add-ons were inaccessible until they were reviewed, new add-ons and updates were listed together in the same queue, and the quality of some of the reviewed add-ons was questionable.

The current add-on submission and review process was designed to surface unreviewed add-ons in a “sandbox” to testers who wanted to try them out and write reviews, while still keeping them far away from casual Firefox users just looking to customize their browser. We hoped this would alleviate developer frustration over long review times and raise the quality bar, as not every add-on would have to be “public” and reviewed in order to be distributed on the site. In its original incarnation, the sandbox excelled at keeping untested add-ons from everyday users, but was found lacking in usability for advanced users: no one could figure out the process of signing up for an account and then opting in to sandbox access in order to see the unreviewed add-ons.

In the years since there have been two iterations affecting the discoverability of the sandbox: the first removed the opt-in requirement and allowed anyone logged in with an account to see the sandbox. This made the sandbox a bit more usable and easier to understand; however, feedback from developers indicated that more needed to be done. The second iteration, currently in use today, went even further by letting logged-out users browse and install unreviewed add-ons by simply checking a box.

We get a lot of community feedback on our ideas and site features, but almost all of that comes from developers who, of course, want to make their add-ons as easy to get as possible. We rarely hear from the non-technical users installing these add-ons, which can sometimes lead to decisions that are too developer-focused. I think the current state of unreviewed add-ons is an example of one of those decisions, and that we’ve gone too far in making them widely available. Unreviewed add-ons, which are potentially harmful to your computer and your data, are trivial to find and too easy to install without understanding the risk.

Since the inception of the sandbox, we’ve had very few incidents involving unreviewed add-ons, and have been quick to investigate and respond to any reports we’ve received from our users concerning these add-ons. But as we strive to make Firefox add-ons and our website more consumer friendly and encourage the hundred million users already enjoying add-ons to tell their friends about customization, “very few” incidents is a few too many.

What are the issues?

I helped design the original sandbox and had a part in all of its subsequent iterations, and I’ve heard from developers, users, and security experts on it. I’ve agreed with many of the issues brought forward, and we think it’s time to make some big changes. In my opinion, the biggest issues with the current system are:

• We use misleading terminology. Untested, unapproved add-ons are called “experimental”, which hints that the add-on is not ready for prime time, but doesn’t evoke enough (or any) levels of alarm or warning for a casual user. In computer vernacular, when something is in a sandbox, it is trapped in a secure container and can do no harm. This is not the case at all with the addons.mozilla.org sandbox.
• The interface doesn’t say what it means. For logged-in users, unreviewed add-ons have a green install button, the same as reviewed add-ons. People like to click on green, shiny buttons. For logged-out users, the only thing standing in the way is a checkbox that says “Let me install this experimental add-on.” We don’t explain what this actually means (“not reviewed”) or let the user make an informed decision unless they click on “What’s this?”.
• Untested add-ons are too popular. Yesterday there were 40,000 downloads of add-ons in the sandbox. While this makes up less than 3% of all downloads yesterday, I have serious doubts that all 40,000 downloads came from advanced testers who fully understand the risks of installing unreviewed add-ons.

We need to limit the exposure of unreviewed add-ons so that if an incident does occur, only the few people who have have made an educated decision and accepted the risk will be affected.

What can we do to fix this?

Some have proposed removing the sandbox and unreviewed add-ons entirely. It would certainly solve all of the above issues, but would leave us back where we were in 2006 when developers had to wait a week or two before anyone could try out their add-on. As an add-on developer myself, I know that after I finish working on something, I want to let my friends try it out immediately.

Others have proposed spinning off a separate website for add-ons that have not been reviewed, or encouraging a third party not affiliated with Mozilla to create a website for such creations to live. This may address most of the issues listed above, but I don’t think it would be in the best interest of users. If a user arrives at the only add-on they can find that has a certain feature, they’ll probably install it regardless of any warnings the site may have (keeping in mind a third party would not have to have any warnings at all). I think it’s important that Mozilla provide some form of home for these add-ons until they can be reviewed so that we can take the appropriate cautions for users that do wish to try out the add-ons.

I think there’s a middle ground, and that’s what I’m proposing today. There are three main components:

1. Unapproved add-ons will not be shown in the add-ons gallery.

Users can be sure that every add-on they come across browsing around the website has been tested and approved by Mozilla’s editors. This would mainly affect browsing through categories, search results, and collections.

2. Users who are linked directly to an unapproved add-on by its developer can install the add-on.

After submission, developers can send the link to their unapproved add-on to anyone they’d like to try it out. This can be on their blog, website, email, instant message, etc. However, these direct links will be disjointed from the normal add-ons gallery and make it clear that this add-on has not been reviewed, as well as offer the user the option to leave and go to the gallery with only reviewed add-ons.

3. There will be a maximum amount of time an unapproved add-on can be hosted on the site.

There are 7,500 add-ons currently in the sandbox that have never been reviewed by a human because the developers have never nominated them to show up in the “public” site. Some of these add-ons have been there for years, and are usually the source of the problems we do have.

To address this, we think a critical part of fixing the review process is setting the expectation that all add-ons submitted to the site must undergo review and using a time limit to enforce that.

Under this proposal, an add-on’s submission to addons.mozilla.org will begin its 30-day incubation period. As noted above, the add-on will not appear in the gallery but can be accessed through a direct link from the developer during this period.

The add-on must apply to the gallery sometime during this incubation period, whether on day 1 or day 30. Reminder emails will be sent at certain intervals to remind the developer of this timeframe, but if the add-on has not applied to the gallery during the 30-day window, its listing will expire and no longer be available on the website, even with a direct link.

If the developer has allowed an add-on to expire, he or she may still submit a gallery application after the 30-day window, but the add-on will not be re-activated for download until it has been approved.

The add-ons team tried to come up with details that we think are reasonable and not too complicated, yet still address many of the edge-cases we’re sure to encounter. I haven’t included all the details of this part of the propsal here, but those interested should read the full proposal and give feedback in the discussion thread.

Some additional important details that are worth mentioning in this summary are:

• This policy will apply to add-ons currently in the sandbox, and those add-ons will expire 30 days after this new process is implemented on the website, if it is adopted. Those authors will be given months of advanced notice in order to nominate their add-ons for review before the deadline rush.
• Currently, users who install “experimental” add-ons do not automatically update to new versions in order to limit the exposure of unreviewed code. Many users and developers do not realize or expect this, and it’s not adequately explained. Under this proposal, unapproved add-ons already have a limited exposure window, so automatic updates will be turned on for all add-ons, even if unapproved.
• New versions of add-ons will not be available for download until they have been approved. Currently, 95% of add-on updates are reviewed in under 5 days.

If implemented, this new system will make some big changes to the add-ons website, but I think they’re needed. We’re asking for community feedback on all parts of the proposal, although if you’d like to comment, please take the time to read the full proposal and then add your thoughts in the discussion thread.

These days, almost every add-on has some sort of first-run experience, whether it’s a new tab that’s opened, a sidebar, a wizard, or (worst of all) a modal dialog. When several add-ons are installed at the same time, these elements all fight for attention, often in confusing and unexpected ways. I wrote a post on this some time ago that showed an example of what havoc can be wreaked with only 3-4 add-ons, as well as some suggestions on how developers can improve this area.

Earlier this week, Lifehacker featured the new Massive Extender add-on which works with Mozilla’s Add-on Collector to batch install add-ons from a collection. I’m excited to see this add-on and will be watching its reception closely to see what sort of experiences users have batch installing add-ons. From experimenting with it briefly, the add-on seems to be well-made and has a lot of useful features. But, as expected, batch installing add-ons from a collection and then restarting was not such a fun time.

Standardized support for first-run pages should land on Firefox trunk in the next few months, and other work on the Add-ons Manager revamp should help the situation as well. Hopefully we’ll get to a point where we can let users install mutliple add-ons at once as long as those add-ons meet some “good first-run experience” criteria to be determined later.

Until then, Massive Extender is a good way to install an entire collection for those brave enough.

In July, we asked developers to take a survey about how they use the Statistics Dashboard, and as part of our AMO rewrite currently underway, we’ll be revamping the dashboard.

Here’s a mockup from our designer, Chris Howse, of the overview page of the new dashboard:

A few comments on the new design:

• Our main goal was to simplify the dashboard and present the most common things developers are looking for up front, answering questions like “which application versions is my add-on used with?” and “how many people use my add-on on Mac?”
• Each of the breakdown pages will have its own URL and be linked to directly, eliminating the annoying dropdown menu currently used
• We’ll be replacing the Timeplot graphs with nicer, less buggy graphs using Highcharts
• Most of the features of the new dashboard exist in the current dashboard, but this will create a much better platform and layout for us to add additional features after the rewrite. We already have some great ideas to implement at that time.

You can see the rest of the mockups and design discussion in bug 540885 and implementation in bug 543548.

We’ve also added several new codes, such as on mozilla.com’s Firefox Customization page. It’s exciting to see that many add-ons have adopted the external source tracking feature to track downloads from their websites and marketing campaigns, and those downloads now make up 2% of the total.

Here’s an updated pie chart showing the source distribution of the 2.1 million downloads last Friday, the day after Firefox 3.6′s launch.

We decided to break down the sources further into add-ons that are featured on our site-wide recommended list and add-ons that aren’t. Recommended add-ons are featured on the homepage, the recommended page, and in the Firefox and Thunderbird Add-ons Manager dialog.

There are only about 70 recommended add-ons that make up this large chunk of our downloads. The majority of recommended add-on downloads come from the Add-ons Manager (API), and most Add-ons Manager downloads are recommended add-ons (275,000 vs. 155,000).

We’re now watching this download source data closely and factoring it into our product decisions as we’re working on the next version of AMO.

	Category or Add-on Type	Daily Pageviews
Data from January 5, 2010 for en-US only. * 70,136 pageviews in the Bookmarks category come from the default bookmark in Firefox
1	Themes (add-on type landing page)	85,765
2	Bookmarks (extension category)	81,641*
3	Plugins (add-on type landing page)	70,439
4	Appearance (extension category)	37,971
5	Search Tools (add-on type landing page)	30,111
6	Download Management (extension category)	26,566
7	Modern (theme category)	22,240
8	Privacy & Security (extension category)	21,005
9	Extensions (add-on type landing page)	20,692
10	Dictionaries & Language Packs (add-on type landing page)	20,439
11	Photos, Music, & Videos (extension category)	20,320
12	Alerts & Updates (extension category)	18,891
13	Miscellaneous (theme category)	13,826
14	OS Integration (theme category)	12,628
15	Toolbars (extension category)	11,801

Looking into this data also revealed a few pages that have hideous bounce rates that we should be able to improve with a few tweaks. I’ve started Operation: Gravity to try to reduce these bounces as part of Zamboni.

If you have suggestions for improvements to category pages or notice other gaping holes in AMO metrics we’ve talked about, please feel free to let us know.

Our development team has been hard at work building up the Django framework to be able to interact with the existing database and read CakePHP’s sessions so that we can have both sites up in production at the same time. Once this is finished, they’ll begin porting over sections of the site to the new codebase, and ideally users won’t even realize that some parts of the site they’re using are powered by the new system.

This process will take several months, and although we’re still fixing important bugs in the existing site, we’re focusing on this new AMO 4.0 framework, codenamed “zamboni”. Since we’ll be porting over every page on the site, I’m seizing the opportunity to throw in some often requested changes and cool new features to be implemented as we move each page. We’re still working on this product plan and I hope to post it shortly for everyone to give feedback on, but I wanted to highlight a couple planned changes to some longstanding practices on AMO that might be unexpected.

“Recommended” add-ons will become “featured” add-ons

What’s the difference, and why bother? In English, there’s a slight difference between the two words. Recommendations are usually when someone suggests that you try something based on what they know about you, or when they give reasons for why someone would be interested in the recommended person, place, or thing. On the other hand, things that are featured are promoted to everyone, regardless of who they are or their interests, and often come with no explanation.

We’ve been content with keeping highly promoted add-ons labeled as “recommended” across the site, but this year we plan to add support for personal recommendations — if you tell us what add-ons you use, we’ll tell you what new add-ons to try based on collections data and what we know about add-on usage from others who have opted in. In order to differentiate between these tailored recommendations and the site-wide list of promoted add-ons, we plan to change the nomenclature to “featured” add-ons.

Daily Users will become public for every add-on

We first introduced active daily user counts for add-ons in 2008 with the Statistics Dashboard for developers. With the exception of total and weekly downloads, this data has been private by default. It was an arbitrary decision at the time, but since then, a few things have happened:

• Daily user counts will be a lot more reliable soon. Firefox 3.6 specifies the type of update check it’s doing for add-ons, and AMO will soon only count the daily background checks, which should stop the slight daily inflation and the huge release-time inflation.
• Other platforms like Facebook and Chrome Extensions have started displaying user counts publicly, so it’s a much more common practice now.
• There are several lists of add-ons ordered by their number of users on the web, so it’s not difficult to estimate the number of users of an add-on in between two other add-ons that have made their stats public.
• In a Stats Dashboard survey from July, developers overwhelming said they would be fine with this number being public:

  

Weekly downloads are good at telling users what add-ons are recently popular, but they don’t do a good job of indicating which add-ons are actually holding on to all of those new users. So, with zamboni, we’ll probably make the latest day’s daily user count public for all add-ons on their display pages. There would also be a new sort option for this data in search and browse listings.

These changes are still a couple months away, and much more detail on all of the zamboni product plans will be available here and on the Add-ons Blog.

Last year I blogged that we were no longer actively developing or fixing bugs with the application behind Rock Your Firefox, a part of AMO’s codebase. Sadly, we’ll be ending support and disabling Rock Your Firefox this Friday. We may re-launch again in the future when we can rewrite the application to fix numerous bugs and make use of many new features on both AMO and the Facebook Platform.

As a way to remember the good times you had with Rock Your Firefox, make sure to grab a Rock Your Firefox Wallpaper before it’s too late.

addons.mozilla.org (AMO) is a huge site, and it’s quite possible you’ve found a minor glitch or more serious bug that we haven’t heard about yet.

Bugzilla can be complicated to a new user, so here’s a step-by-step guide to letting us know about a problem with AMO:

1. Create a Bugzilla account. (NOTE: If you’re a longstanding Mozilla community member, you may already have one. Check first to make sure you aren’t already logged in when you visit the site.)
2. Search for existing bugs. Looking for an existing bug is helpful to both you and us, because you’ll see any progress that’s been made in resolving your issue, and we won’t have to close your bug as a duplicate.
3. File the bug. Select the best component, enter a brief summary, and describe the problem you’re having.

That’s it! Your new bug will be emailed to everyone that is interested in AMO development, and we’ll triage the bug and help sort it out.

Happy bug filing!