has an undiagnosed addiction to steamed pork buns
and works on webby stuff at Mozilla. more »

posts categorized as “planet.mozilla.org”

Mobile World Congress 2012

Last week I went to Barcelona to attend Mobile World Congress for the first time. It was incredible for several reasons, most importantly how all of our products came together to tell one unified story: the Web is the platform. You can’t talk about one of the products without it leading directly to the others: Boot2Gecko and Open Web Devices, Marketplace and apps, Persona, and Firefox. I’m excited about it, the conference was excited about it, the industry is excited about it, and Mozilla rocked the show despite it being our first time there.

MWC photos: mine | Mozilla’s

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:

continue reading »

mozilla.dev.marketplace

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

Add-ons in 2011

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 »

Add-on Compatibility Progress & Plans

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 »

Hover Crafting: a look at AMO’s new add-on grids

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 »