When I first began contributing to Mozilla as a volunteer add-on reviewer, I had no idea I was joining a community I’d call home for so long. Working on AMO and the Firefox Add-ons ecosystem the past 6.5 years has been an amazing experience that I’ll never forget. Leading the add-ons team/product the past couple years and helping lay the foundation of the Firefox Marketplace more recently has been a unique experience in which I’ve met many great people, learned a ton, and had lots of fun.

I’m looking forward to what’s sure to be a very exciting year for Mozilla and the web.

The best photo of me running that has ever been or will ever be taken.

Two weeks ago I flew across the country to run my first half marathon at Walt Disney World. After 6 months of excitement leading up to the race and many weeks of seemingly constant training runs, I crossed the finish line with a better time than expected and felt great doing it.

As a big fan of Disney Parks, I knew this was the perfect first race to keep me alert and motivated through 13.1 miles, with entertainment every mile and 2 big milestones to look forward to: running through Magic Kingdom around the halfway point, and finishing at EPCOT. I was a bit nervous in the weeks leading up to the race because of a knee injury, but it turned out to not be a problem at all when race day came.

I was really surprised at the end that everything had gone so well, and then I realized that’s what all the training was for. It’s not like I decided to take a shot in the dark and find out if I could run a half; I had already pretty much done it in training. The more impressive thing was waking up at 3am Eastern (earlier than I usually go to bed Pacific time) two mornings in a row for this madness.

Speaking of which, the scale of runDisney races is impressive, with 25,000 runners in both the half and full marathon, and an additional 10,000 in the Family 5K (which I also did to run even more in the parks).

I’m already registered or hoping to register for a number of other races this year, including the Inaugural Rock ‘n’ Roll SF Half, Bay to Breakers, WIPRO SF Half, Big Sur Half, and of course the Disneyland Half (and inaugural 10K, together making the Dumbo Double Dare). But it’s not all coasting for those, as I have 3 more goals in mind for this year: learn to toe strike, be able to tackle hills without total exhaustion (SF Halves, I’m looking at you), and improve my time. As I ran this half with 1 minute of walking for every 4 or so minutes of running, most of my time improvement will probably come from attempting to run continuously for longer periods of time.

The big question I’ve been asking myself is whether I want to try a full marathon at WDW next year, or even the Goofy Challenge (half marathon and full marathon in 2 days). It was certainly on my mind a lot after seeing so many people walking around with their fancy Marathon and Goofy medals. For now I’m planning to focus on improving my half marathon abilities, which should keep me well-occupied.

In May of this year, I decided to try out Bay to Breakers, just to see what would happen. If tens of thousands of drunk people can finish a 12K, why can’t I? Wait, how far is a 12K? Things went well the first 5 miles, but the second half was really rough. I injured my knees and ended up walking most of the last few miles and sitting in excruciating pain for days afterward. I hadn’t trained at all even though it was certainly the farthest I’d ever run.

But despite the physical pain, it felt great that I’d set out to cross the finish line and did. I decided I wanted to train for something real that would challenge me both physically and mentally, to see if I could do it: running a half marathon. Too often in the last few years I’ve started projects or goals and haven’t finished them, and having the experience of training for and finishing a half marathon would give me confidence in my ability to follow through, as well as help me get in better shape.

Within a few days, I knew what my target half marathon would be: the Walt Disney World Half Marathon. As a huge fan of Disney parks, it’s the perfect race: an excuse to go to Disney World, lots of Disney entertainment along the course, and lenient pacing requirements. And of course getting to run through the parks, including some backstage areas. Held every January, I’d have plenty of time to get ready.

I knew I’d be doing a run/walk program in order to build up the endurance necessary to go 13.1 miles. For this first half, my goal is just to finish, regardless of time. I looked at Jeff Galloway’s training plans on runDisney, but ended up going with the Marathoning for Mortals plans after someone suggested reading the book. I’ll talk more about run/walk training in a separate post.

It’s now 2 weeks away from the race and I’m as ready as I’m going to be, and getting really excited about the trip. I feel pretty confident I’ll be able to finish even though the farthest I’ve gone in training is 10 miles. But I’m still starting to get nervous and thinking about what to pack/wear, making sure I don’t get injured before the race, and other miscellaneous preparations.

If all goes well, I have several other half marathons lined up next year that I’m excited about, and will give me an opportunity to start working on my speed once I know I can finish.

Mozilla’s booths were in the App Planet exhibition hall along with many platform, commerce, and other software companies. There was a good vibe, especially compared to some of the other halls entirely dominated by hardware giants with multi-million dollar booths the size of a city block. I spent most of my time in Mozilla’s main booth giving demos of our HTML5 apps platform and answering questions about the Mozilla Marketplace.

At first, I wasn’t sure what to expect from 6-8 hours a day of talking and demoing, and was concerned that I wouldn’t have time to visit other booths I was interested in to learn about their products and how they might help our Marketplace. Booth duty turned out to be the best use of my time, as I learned a lot about the crowd’s perception of Mozilla’s offerings and HTML5 apps, and got to meet so many people with relevant ideas. By the time the last day rolled around and I had some time to stop and talk to other booths, all the companies I was interested in had already come to see me. (Though there was still reason to visit one.)

Here’s some of what I learned from my own observations and from talking with hundreds of people:

• People love Mozilla and were very excited to see us there with cool new products. I think for many people, this is the first time they considered Mozilla as more than just Firefox. I think this gave our booth a lot of energy throughout the day, and isn’t something I saw at any other booths I visited. It felt great.
• Nearly everyone had heard of our announcement with Telefónica after Monday morning and asked for a demo of it by name. From then on, B2G always had a line waiting for a demo, and I even saw some people come back with their friends for another look. (Erin is a hero for how many 5 minute demos she did back to back every day while keeping a smile)
• Almost no one knew that HTML5 device APIs that we demoed in Firefox for Android existed, such as vibration, notifications, camera access, accelerometer, battery status, and full screen mode. Any time someone came to me doubting HTML5′s power, Paul‘s demo page really shocked them and many were eager to learn more.
• Even so, quite a few people (usually journalists and analysts, but sometimes developers) commented to me after demos that they think “this (HTML5 apps) is the way things are headed”.
• Many people equate HTML5 to “online and remotely hosted”. Coming from many years of web and add-on development, the idea of locally hosted HTML isn’t anything out of the ordinary for me, but to everyone else HTML5 means “website”. I did a few Boot2Gecko device demos, and several people asked what happens to the homescreen and dialer when the phone is offline. As part of my apps demo, I always talked about offline support in HTML5 which we encourage app developers to take advantage of, but I think this is an important component of our HTML5 messaging we should work on.
• When you announce you’re opening an apps marketplace, LOTS of people want to talk with you about how their product or service can integrate with it. I have a lot of research and follow-ups to do.
• Everyone (myself included) was floored by the B2G device’s shutdown and startup time. Mapping the phone’s menu button to View Source was also a hit.
• The new Firefox for Android builds have a gorgeous UI and are extremely snappy. I can’t wait for them to ship, and neither can the folks I showed them to.
• When you bring in the best baristas to serve coffee at your booth, the huge line that forms is not necessarily due to someone raving about your killer cross-platform apps demo, so be careful before assuming. (Just kidding, but not about the awesome baristas or the huge line.)

I know many people worked very hard to get the products ready in time for the event, and having them there telling the same story is why they were so well received. Thank you for making that happen. Now that we’ve shown the mobile world how we’re going to change it, let’s do it!

After a few flights like this, I decided that it was something I should be able to overcome mentally. I knew I was flying 600 miles an hour 30,000 feet in the air, but if I felt the same bumps riding in a car, I wouldn’t even think about them.

The trick I came up with was to pretend I was on a roller coaster or another ride at a theme park. At first, this was a very conscious and literal process, where I’d actually picture different Disney World rides in my head. Sometimes, the turbulence would even turn fun. Gradually, I was able to calm myself with just the reminder of a roller coaster.

The last couple years, I’ve apparently convinced myself that planes are so safe that turbulence no longer bothers me at all, even when it gets pretty bad. I don’t even have to think of roller coasters any more; I just continue doing things as if nothing’s happening.

We’re going to have to do our pre-landing safety check on the honor system, so look at your neighbors and if their seatbacks and tray tables aren’t up, give them the stink eye.— Flight attendant on a very turbulent flight last week

I’ve mentioned method this to a few people and it seems to have helped them as well, so if you have issues with turbulence, you might try thinking of theme park rides and realizing it’s something you can get over mentally.

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.)

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.

In 2011, AMO Editors granted 9,731 full reviews, 7,468 preliminary reviews, and rejected 2,616 versions.

BrowserID, Apps, and Marketplace Integration

When people joke about buzzwords, “synergy” often tops the list. But it’s a really awesome feeling seeing so many pieces of different projects falling into place to create a single experience. A year ago, users purchasing apps from AMO with their BrowserID account and running them on top of Boot2Gecko would have seemed crazy. Actually, it still seems crazy, but it’s happening.

We made great progress on our apps and marketplace integration in 2011 while still moving Add-ons forward. I’m really excited about building out the rest of the marketplace over the next few months and jumping into the app store battle with something to fight for.

Rethinking Compatibility

Around this time last year, everyone in the Project was trying to figure out how their piece of the puzzle would work in a 6 week development cycle. We had tens of thousands of puzzle pieces to figure out, and we came up with a plan to automatically bump compatibility for AMO-hosted add-ons and quickly built out the tools necessary to pull that off. That process worked really well for our hosted add-ons, but we still heard many complaints from users. Thanks to data we got from Firefox 4, we were able to quickly identify the problem: there were far more non-hosted add-ons out there than we imagined.

We regrouped and brainstormed solutions that would also address the hundreds of millions of add-ons we had no control over. We came up with our plan and engineered the solutions on both client and server side to make Default to Compatible a reality — changing a fundamental piece of the Mozilla platform that had been in place for many years.

New Design

It’s hard to remember what AMO looked like before we rolled out our new design to nearly all of our trafficked pages. The new design is a simpler, cleaner look that’s consistent with other Mozilla sites. We restructured the details page to place items from most important to least important, and introduced hovercards, allowing users to quickly scan through more add-ons while still viewing extended details of those they’re interested in.

Search Improvements

This year we upgraded our search backend to a better engine for improved performance, result quality, and facets. And we launched search suggestions and AJAX search results, which were a huge usability win for users.

30,000 add-on downloads a day come via search suggestions.

Add-on SDK Launched

It was in 2011 that the Add-on SDK officially launched along with Add-on Builder to open up add-on development to many more people. The SDK team has also accomplished a lot this year, and we helped support them in a number of ways, including repacking SDK-based add-ons when updates are issued and introducing a review incentive for SDK-based add-ons.

27% of new add-ons submitted to AMO each month use the SDK.

Contributions Flow

In March of last year we switched our Contributions flow to use PayPal’s in-context payments so that users can thank their favorite add-on authors without leaving AMO. We also added a Contributions notice in the Add-ons Manager of Firefox 4, and allowed developers to direct their contributions to the Mozilla Foundation or a third party.

This increased the number of contributions from 1,390 per month to 2,500. In 2011, add-on developers received $150,000 from 25,000 contributions. In total since its launch in mid-2009, our users have given $282,000 to developers in 48,680 transactions.

Opt in to Third-party-installed Add-ons

Add-ons dropped into Firefox without user consent have always been a problem, but we had no idea the extent until this year (thanks to Firefox 4). In addition to the security, performance, and usability issues that often come with these add-ons, their presence made compatibility between releases a nightmare for many users. We designed and implemented a solution that helps users stay in control of what’s installed in their Firefox going forward and also allowed them to correct past intrusions.

Performance Work

We kicked off our performance initiative this year and worked with many add-ons to improve their start-up delays. We made significant progress on tools that will allow add-on developers to test and improve performance on their own. And we presented the first look into what real-world start-up time looks like for Firefox users and how add-ons can impact that.

And more…

Among all of the huge projects we tackled this year, we worked on many smaller projects and features that made a huge improvement for users. Some that come to mind:

• Mobile AMO — Although we’ve supported the Fennec application on AMO for some time, it wasn’t until 2011 that we launched a mobile-optimized version of the site.
• Featured Add-on Selection — Nearly every add-on wants to be featured, and in 2011 we started the Featured Advisory Board so that community members who love using and creating add-ons are the ones who choose which add-ons are featured each month.
• Blocklist Experience — Clicking “Learn more” when something you had installed was blocked previously took take you to a giant listing of everything we’d ever blocked with a few words of description. Now, clicking “Learn more” takes you to a page that explains why that specific item was blocked, who is affected, and what this all actually means.
• Add-ons Blog — We redesigned and customized the Add-ons Blog, which gets 200,000 pageviews a month.
• Intro Video — We finally have a great introduction video to add-ons that actually shows what they can do, complete with an interactive version.
• Email opt out — We revamped our email notifications and added one-click unsubscribe.
• Add-on slugs — Our URLs became much prettier when we replaced addons.mozilla.org/en-US/firefox/addon/1865 with addons.mozilla.org/en-US/firefox/addon/adblock-plus
• Switching to ADU — We switched our primary popularity metric from downloads to active users to ensure the most popular add-ons are those people actually use instead of just try.
• Up & Coming — We introduced the Up & Coming sort, which surfaces new add-ons that are becoming popular.
• Better Compatibility — We hide incompatible add-ons by default in many places, and always make it clear when something won’t work with your device. We also integrated more tightly with the Add-on Compatibility Reporter so pre-release testers can still get to incompatible add-ons.

Thanks to everyone who made these things possible in 2011, and let’s get ready for a whirlwind 2012!

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?

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.

How’s it working out?

Compatibility-breaking changes in Firefox have been minimal in the first four 6-week development cycles, with the exception of two larger changes that were reverted because of their larger impact. Jorge has posted detailed guides to changes that affect add-on developers for each of those releases (5 & 6, 7, 8), and Firefox developers are often coming to us to discuss the impact of their changes on add-ons.

We’ve automatically bumped thousands of add-ons for each Aurora version and emailed developers with the results of our compatibility scanning. When Firefox 6 launched, 97% of add-ons compatible with Firefox 5 were still compatible with 6. And we’re on track to launch Firefox 7 tomorrow with 99% compatibility from 6.

But with all of that, why do we still see users reporting that their add-ons aren’t compatible?

Our compatibility plan has two notable shortcomings: it doesn’t work for add-ons with binary components and it doesn’t work for add-ons not hosted on AMO. The vast majority of add-ons don’t contain binary components, which must be recompiled with every version of Firefox in order to continue working. And while we know a lot about add-ons that are hosted on AMO, we didn’t know much about the other add-ons in Firefox’s ecosystem.

In Firefox 4, as a result of enriched metadata in the Add-ons Manager, we have a much better idea of what add-ons are out there in the wild. And it was quite eye-opening when I learned that only 25% of the 600 million add-ons in use every day in Firefox 4 and later are active on AMO. That means at least 75% of add-ons aren’t getting the benefits of the automatic compatibility system we created, as well as the security and quality reviews that hosted add-ons receive. When we created the compatibility plan for the new development cycles, we weren’t aware that so many add-ons wouldn’t even be affected by it.

So, how do 450 million add-ons get installed if not from AMO? Third-party bundling. More and more software tries to plop a toolbar into Firefox when you install it, often without asking you. Java Console alone has more than 100 million installations among Firefox users on Windows, and it doesn’t even do anything. While some of these add-ons are keeping up with our release compatibility, many use their own update mechanisms instead of the built-in update service that works with Firefox’s compatibility checking, so in order to get a compatible add-on, you must update the third party software separately.

When these add-ons aren’t compatible with a new version of Firefox, it’s an even bigger problem because it’s often confusing to users as to what functionality they provide. When they’re told that Skype or their antivirus toolbar isn’t compatible with the new version, they may think upgrading means they can’t use Skype at all or that their computer will be more susceptible to viruses.

Firefox 8 (in beta later this week) tries to curb some of this behavior by requiring users to opt in to new add-ons and letting users disable add-ons they’ve already acquired.

Help is on the way

We’ve been working on a plan for fixing add-on compatibility that also takes non-hosted add-ons into account. Instead of working around Firefox’s assumption that add-ons are incompatible between versions, we’re going to teach Firefox to be a bit more trusting of add-on compatibility with new versions. You can read more about the idea on its feature page, and I’ll post more about this change on the Add-ons Blog when it’s underway.

In the meantime, if you find that your add-ons aren’t compatible, install the Add-on Compatibility Reporter and try ‘em out — there’s a good chance they work fine.

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.

We wanted a way for users to be able to scan across a grid of add-ons any way they wanted without getting frustrated. Greg Koberger had an idea: trim the width of the card such that you can still see the add-on icons, allowing users to easily scan down a column of add-ons.

We went to dinner at New Mongolian BBQ to noodle over whether this new design would work, and potch began planning how he would achieve the CSS box shadow effect with the tricky border structure. A few minutes after we got back from dinner, we had a working prototype, and were excited to see that it had the effect we wanted. This design would also let us place install buttons right below the hover area, ensuring that no one would have to play some kind of mouse game to get to the download button while the hover was still in effect.

The hovercards, as they are lovingly known, went live with our new design several weeks ago. They’re certainly not perfect, but I think they’re a big improvement over other hover methods.

Great, you redefined hovering as we know it. How are they actually performing?

Interestingly, the answer depends on the page. On the homepage, where we utilize hovercards for the Featured and Up & Coming carousels, two thirds of downloads from each section come from the hover card, while only one third come from a user clicking through to the details page and installing the add-on there.

However, on the category landing pages, where we employ hovercards in every section and carousel, closer to only one third of users install from the card and the rest journey through the tubes to install from the details page. Even more interestingly, each section has different results: Recently Added has the most hovercard downloads by far, with 46%, while the Featured hovercards only account for 30% of their downloads.

Why is hovercard usage so inconsistent? One theory is that it all depends on the add-on. Some add-ons are self-explanatory: you know exactly what they do from the name or summary, and you immediately want to have them. Others are quite a bit harder to figure out: what does this functionality even mean? is this a reputable author? what’s their privacy policy? what do the reviews say? screenshots please!

To test this, I looked at a few individual add-ons and compared them to the site-wide average for hovercard use in the Most Popular carousel on the category landing page.

• All add-ons: 36% from hovercard
• Adblock Plus: 25% from hovercard
• Firebug: 38% from hovercard
• Download Statusbar: 43% from hovercard

That shows the individual add-ons have an impact, but nothing too substantial. Let’s look at the the Featured block on the homepage for those same add-ons:

• All add-ons: 61% from hovercard
• Adblock Plus: 34% from hovercard
• Download Statusbar: 76% from hovercard

Well, that rules out that it’s entirely the individual add-ons, since Download Statusbar nearly doubled the percentage of downloads coming from the hovercard. It looks as though the location and context of the hovercard really does make big a difference in how many people use it, but that the individual add-ons play a decent role as well.

I’m very interested in what AMO visitors think of the hovercards, and am looking forward to digging into the data we have on other parts of the new design as we continue to roll it out.