As the Mozilla Marketplace project has begun to take off, we want to make sure there’s a dedicated place for discussion of planning, features, policies, and other topics. mozilla.dev.marketplace has been around for a couple months, but due to a bug with content not being synced to Google Groups, we were holding off using it. We can’t wait any longer, and this week I’ll be starting a bunch of discussions there about our roadmap, payments, and other topics as we start to build and launch our Marketplace.
So, I invite you to subscribe through either the mailing list or in your email client if you’d like to participate. (Note that this newsgroup is specific to the Marketplace, and that discussions of our web apps platform go to mozilla.dev.webapps instead.)
This weekend we said goodbye to an action-packed year, and I thought it’d be fun to think back on all we accomplished in Add-ons in 2011.
Firefox 4 Shipped
A critical release for many reasons, Firefox 4 introduced a completely rewritten and redesigned Add-ons Manager, including the interactive discovery pane (“Get Add-ons”), automatic add-on updates, and addressed the single biggest complaint for years with add-ons: installation without restarting. Firefox 4 also allowed us to see how many users actually use add-ons, how many non-hosted add-ons are out there, and gather real-world performance data — all things for which we had no insights before Firefox 4.
The discovery pane was viewed more than 5 million times in the 24 hours after release, and is currently viewed between 2.7 and 2.9 million times each day. It’s responsible for 40,000 add-on downloads every day, plus the 300,000 downloads that come from the Add-ons Manager search. 33% of new add-ons submitted to AMO each month are restartless.
New Developer Tools, Editor Tools, and Review Process
It seems like this happened much more than a year ago, but it was in early 2011 that we launched our brand new Developer Tools on AMO — in my opinion, the best management tools for add-ons, apps, or anything like it on the web. In 2010 we made the decision to rearchitect our review process to require all add-ons to be reviewed and get rid of the sandbox with 7,000 unreviewed add-ons in it. We launched that new process in 2011 by introducing preliminary reviews and direct links while waiting for review. And we made a number of awesome improvements to our Editor tools and statistics dashboard.
continue reading »
It’s beginning to look a lot like a new blog theme.
I have a good feeling about this theme and hope it will last at least a year before I start to dislike it
— me, less than a year ago
Actually, it only lasted a few days before I started to dislike my previous gradient-tastic theme. 8 posts and 11 months later, I’ve finally replaced it with something very different.
I wanted to step out of my comfort zone with this one, so I did two things I never do: you won’t find a single rounded corner, and I used a background pattern — a realistic one at that.
I also got rid of my About page in favor of an about.me profile and threw in a subtle CSS animation because I’m hip like that.
What do you think?
Towards the end of last year, the need for a faster Firefox release cycle was apparent, and nearly every team at Mozilla began preparing for the major changes afoot. Add-on compatibility has always been a huge barrier to releasing more often, so it was critical we have a plan that wouldn’t leave add-ons or users behind. With previous releases usually a year or more apart, we could begin compatibility outreach to developers 3 months in advance of the release, and were able to get at least 80% of the most-used Mozilla-hosted add-ons compatible with the new version. For this new system to work, we wanted a compatibility process that didn’t require developers to lift a finger unless their add-on was one of the few broken.
Firefox assumes that add-ons are incompatible from one version to the next because, in previous versions, they often were. This becomes a big problem when nearly all add-ons actually are compatible in our shorter release cycles. We devised a plan to work around the assumed incompatibility that had three parts:
- Firefox developers should consider the add-on compatibility impact of every change they make
- Firefox developers should follow a compatibility notification process to ensure we communicate changes to add-on developers
- AMO (addons.mozilla.org) will scan hosted add-ons for issues with the new Firefox version and automatically bump their compatibility if none are found
Longer term, the Add-on SDK lets developers build restartless add-ons without worrying about compatibility hassles.
continue reading »
AMO has made huge improvements in nearly every way since I started working on it in 2006 — design, scalability, performance, user experience, content, quality. Back then, we had a whopping 6 listed add-ons on our homepage: one featured promo block and a list of the top 5 downloads that week. None could be installed without going to the add-on’s details page first.
In contrast, today there are dozens of add-ons on the homepage and most can be installed without leaving the page. When we set out to design the new homepage, we wanted to surface more add-ons in such a way that every user would be able to see something interesting, read the details, and grab it without leaving the page. We wanted it to be easy to scan through the page and if you weren’t interested in a particular add-on, it wouldn’t take any time to skim right over it.
We knew we’d probably use a hover effect to expose the additional details, but wanted to steer clear of the bad hover interactions used on many popular websites and similar galleries today. Chris Howse and I whiteboarded some mocks of an early hover interaction of a card, and began examining the ways it was insufficient. Most hover designs block scanning in one of the directions you’re trying to go (down or to the right) or, in order to avoid that, display content above and break your downward focus.
continue reading »