Since their launch last year, users have created more than 56,000 collections of add-ons. Collections and user reviews are the two ways in which everyday users can contribute content to the add-ons site.
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.
continue reading »
history of add-on install buttonsIf 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
continue reading »
With almost 2 billion downloads, add-ons have proven to be a huge part of Firefox’s growth and popularity over the last 5 years. As Firefox continues to be adopted by non-technical, mainstream users, the security and consumer experience of installing third party add-ons becomes increasingly more important. It’s with these users in mind that I propose some major changes to the way add-ons are submitted and distributed through Mozilla’s official add-ons gallery.
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.
om nom nom »
Since the launch of collections last year, one of the most common feature requests AMO gets is the ability to install all or some of the add-ons in a collection at the same time. There’s really only one thing that has held us back from offering this functionality, but unfortunately it’s not something easily overcome: conflicting first-run experiences.
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.
read the rest of this entry »
Developers got their first glimpse at detailed statistics for their add-ons in early 2008 when we launched the Developer Statistics Dashboard for every add-on hosted on AMO. Since then, we’ve made incremental improvements to this tool, such as adding grouping and comparison options, data tables, locale usage stats, contributions, and most recently download sources.
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:
read the rest of this entry »