Friday and Saturday, I and a few others were at the BlogHer ’10 conference in New York to promote Firefox Add-ons to more than a thousand bloggers in attendance. I had a great time and think our presence there was very effective.

This is the second event I’ve been to where we’ve focused on getting the word out about add-ons to consumers, the first being last year’s Renegade Craft Fair in San Francisco. Almost all of my time is spent talking with developers and other technical people, so getting the chance to talk to real people who use Firefox and add-ons is fun and educational. I get to learn about things that aren’t obvious to normal users and the problems they encounter.

I spent both days of the conference in our hospitality suite answering questions, telling people about Firefox, add-ons, and Personas, promoting the new BlogHer Toolbar, and showing off Firefox 4 features. Our suite was packed with bloggers all day both days; I’d estimate we saw at least 600 people come through, most of whom we had personal conversations with.

We were heavily promoting Rock Your Firefox, so sticking with its retro theme, we had lava lamps, disco lights, retro candy, 80s music, and cupcakes. Many attendees came back the second day and told us we had the best suite at the conference.

While talking with visitors to our suite, I was pleased to hear that the vast majority said they exclusively use Firefox, and many even said they use add-ons. Those who filled out our survey confirmed this, with 90% of participants saying they use Firefox and 65% of those people using add-ons. For folks who said they didn’t use add-ons, I demoed a few blogger-friendly add-ons from the BlogHer Collection and many people said they’d check them out as soon as they got home.

I answered a number of interesting questions from current Firefox users — everything from choosing where downloads are saved to managing 50 tabs (answer: Tab Candy demo) to what red pandas have to do with Firefox. Despite the good vibe in the room, one of the most common questions I heard was “why does Firefox crash so much?” from users who said they were on the latest version. We tried to give these users tips on debugging and reporting crashes, but it was disappointing to hear firsthand about the frequent crashes that some people experience. I’m hopeful that our continued efforts at reducing crashes will have a noticeable impact on these users soon.

Nick and Julie suggested the topic for my talk a couple months ago and I knew I’d have fun working on it, as it’s really important to me that the add-ons people make are enjoyable. A single bad experience with an add-on can turn someone off to the idea of customizing their browser for a long time, but a great experience with an add-on can have the opposite effect.

I came up with a series of tips and guidelines broken into 3 areas for this talk:

Building – creating an add-on with a great user experience

1. Clean first-run experience
2. Don’t clutter the UI
3. Earn and keep your users’ trust
4. Stay current with the platform
5. Smooth performance
6. Be delightful!

Marketing – getting people to download your add-on once it’s made

1. Choose a descriptive name
2. Have a relevant (and pretty!) icon
3. Upload and update screenshots
4. Avoid EULAs

Listening – communicating with your users and incorporating their feedback

1. Provide support
2. Monitor user reviews
3. Utilize tools provided

The full video of my 30 minute talk is below in Ogg format, or you can view it on Vimeo. You can also view my slides on SlideShare or download the .pdf or the .pdf with my notes.

Let me know what you think!

And thanks to Alex Woodbury for the illustrations used in my presentation.

This is a live-updating dashboard that shows real-time Firefox 3.6 download counts, Tweets about Firefox and Mozilla, local transportation information, upcoming events, local times at our worldwide offices, and a rotating module of various project information. Conveniently, we’d recently installed 4 huge displays throughout the office with built-in computers waiting for such a use, so I put up the first prototype on the screen nearest to me one day. It caused traffic jams all day as crowds of people stopped to read the tweets and comment on them.

One problem I noticed immediately was that the interest in the displays could change dramatically from one minute to the next depending on the tweets shown at the time. If you walk past and only see retweets of a TechCrunch article about Firefox or tweets in a language you don’t understand, it’s not very interesting.

I addressed this by adding an interactive element to the displays: letting users “favorite” interesting tweets, which would then be stuck on the display for much longer. As shown above, there are two Twitter columns: the one on the left is the live stream of tweets involving Firefox and Mozilla, each with a unique number 0 – 9. If one of those tweets is noteworthy, its number can be pressed on the numeric keypad attached to the display and it will move to the right column of Favorite Tweets. Favorite tweets are retweeted by the @mozillafavs account so that anyone can follow along, which also means the tweet author will see that we noticed it. We favorite everything from favorable and insightful tweets to unfavorable and very unfavorable tweets.

For me, monitoring the mood of Twitter users has been very helpful in understanding what users don’t like about Firefox and what our pain points are, at least from that group. And I (and others) have responded to frustrated users we’ve noticed on the displays who needed support.

This was a spare time project, so I haven’t been able to work on it as much as I’d like, but I’m still slowly making improvements. With help from our metrics team, we plan to add much more interesting stats that give a more up-to-date view of how Firefox is doing than overall downloads. Client-side graphing may not be possible due to the very very weak Windows XP Embedded computers built into the displays (even CSS transitions were too taxing). I also want to add more rotating projects besides the add-ons module, likely to include SUMO information, arewefastyet.com, and shaverfacts.com.

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?

It turns out this is a “social plugin” from Facebook embedded in an iframe. As a (mostly former) web developer, I know that means CNN.com doesn’t actually know who I am; rather, that content is hosted on Facebook but embedded on CNN’s website in a way that CNN can’t access. But it’s ridiculous that I have to look at the source of a website and understand the DOM security model to know that. People see their friends’ activity on CNN.com and think the website knows who they are, and there’s no Facebook preference to turn that off.

Just to reiterate that, Facebook wants websites to embed iframes that can look just like their surroundings on the page and trick the user into thinking that website knows them and their friends, and didn’t bother including a way to turn that off. Maybe this iframe thing will catch on and my bank will start letting me log in from other websites too!

I considered these things and tried to think of any benefit of the Facebook service that came to close to outweighing its clear violation of my privacy. And then I deactivated my account. The answer was a definitive “no, I don’t even use the site that much anymore and don’t want to be involved if this is the direction they’re going”.

The first two days were rough; I had formed such a Facebook habit that I would go to click where my bookmark used to be and briefly hunt for it before remembering why it’s gone. But after that it got a lot easier, and today I didn’t really miss it or even think about it at all.

I’m not writing this post to try to convince anyone else to deactivate their accounts, though I know others who have for the same reasons. I understand that everyone values privacy differently (especially Facebook, apparently) and for some people the value provided really is worth the cost. I’m mainly writing it so that it’s public and I’ll be more likely to stick to my deactivation in case it gets more difficult to stay away. (ex-Facebook group therapy meetup, anyone?) Although, now that I’ve disabled third-party cookies in my browser, effectively turning off the “social plugins”, I might even consider reactivating my account down the road if they abandon this scary, scary direction they’re headed. But that seems pretty unlikely.

As the product manager of a website full of user-generated content, I try to keep up with what others solving some of the same problems are doing, and Facebook is certainly a leader in this space. That’s partly why I’m so disappointed that someone in a similar position made a conscious decision to make these new features opt-out and some parts not have an “off” switch at all. This is where I am reminded how awesome it is to work for a company that puts the user above everything else.

I guess Facebook and I will just have to agree to disagree on my privacy.

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.

It’s where add-ons can be installed, disabled, removed, searched, and oftentimes tweaked. It’s used quite a lot, and is how many Firefox users discover the existence of add-ons. It has largely remained the same for a number of years, with the addition of the “Get Add-ons” pane in Firefox 3 that shows several recommended add-ons and allows for searching the Firefox Add-ons gallery for new add-ons. Approximately 20% of add-on downloads come directly from the Add-ons Manager, mostly from the recommended add-ons.

A number of folks on the add-ons and Firefox teams have been working the past few months on how to improve the way add-ons are managed in the browser in hopes of revamping this dialog in time for the next big release of Firefox.

Jennifer Boriss has led the user experience efforts of this project and has made several blog posts on this topic, including some huge plans to move the Add-ons Manager into a tab. This will give us much more room to expose additional data about add-ons and provide new functionality like letting add-ons place preferences right in their details view.

I started to think about how we could improve the “Get Add-ons” pane of this new Add-ons Manager design and provide much more useful content than a random selection of 5 featured add-ons. Content that is updated regularly, localized for the user’s country and language, and most importantly, useful.

I created a rough mock-up of what I thought this could look like, and Sean Martell turned it what we’ve nicknamed the Discovery Pane:

The content area is dynamic and loaded from a remote source, so it can be updated anytime and easily localized. A few of the sections shown above include:

• What are add-ons? – it turns out that right now we don’t really tell users what an add-on is before we show them 5 and suggest that they install them. This section fixes that, and will disappear after a user has installed a few add-ons.
• Rock Your Firefox featured add-on – we recently launched Rock Your Firefox to showcase a new consumer-friendly add-on three times a week, and could show the currently featured add-on in this panel.
• Top Add-ons – This is just a list of some of the most popular add-ons that are compatible with your version of Firefox and your platform
• Links to view all Personas, themes, and add-ons – the links at the bottom will always be there and open the appropriate landing pages of the add-ons gallery in a new tab.

The panels that are shown will differ depending on what content we want to show at a given time, and in some cases we may have panels that rotate between several views. One of the new features I hope we’ll be able launch with this is Personal Recommendations, where users can opt-in to telling us what add-ons they have installed in exchange for recommendations of what add-ons they might like, based on what we know about other users who use the same add-ons and have opted-in to telling us.

I’m very excited about the potential for this new Discovery Pane and the new Add-ons Manager in general, as I think it will make a huge difference in how people find cool new add-ons to try out, and especially for new users who haven’t customized their browser yet. What do you think?

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.

Times have changed, and last April, the add-ons team came up with a policy statement about respecting the choices a user has made, not changing defaults unless the user would expect that change, and not interfering with other add-ons. We hadn’t named the policy, so when it came time to blog about it, I read through it trying to think of a name that summarized our position. The result was the oft-cited “No Surprises” policy, now officially adopted after some slight modifications.

Frankly, I am still surprised on a weekly basis by the behavior of some add-ons and companies targeting add-ons. This recent flurry of issues we’re dealing with has left me wondering, “what’s so different between add-ons just a few years ago and now?” Money, of course.

In 2005, almost all add-ons were built as spare-time projects by students and people who had other full-time jobs. Now, many of the more popular add-ons are created by companies and add-on startups who need to find a way to make a money from their work.

To be clear, I’m not against add-ons making money. In fact, I very much support it when it’s done tactfully. Some of my favorite add-ons have figured out business models that work for them and still respect their users’ privacy and expectations.

The problem comes when add-ons want to:

• change the user’s default search provider without asking
• replace ads on websites with their own ads
• send all of the user’s search queries to a third party when the add-on isn’t related to searching
• bundle other add-ons or software the user didn’t ask for

There are add-ons that do all of these things, and there are companies actively soliciting add-on developers to adopt these practices in their add-ons. Some add-on developers are even approached about selling their add-on and all of its users so that the new owner can implement a monetization strategy above.

These are the sorts of issues that the AMO admin and editor teams deal with regularly now, and it shows how important it is that we continue to review add-ons to keep users safe. One bad add-on can easily stop someone from ever trying them again.

If you’re an add-on developer and you’re considering a partnership that would involve tampering with a user’s choices or privacy, make sure you’ve read our policy on the subject and are comfortable with the likely ramifications (bad ratings and reviews, loss of featured status, users switching to a competing add-on, etc.). If you have any questions about whether something is allowed, please contact the editor team for clarification. Keep in mind some companies that approach developers say their methods are approved by Mozilla, when in fact they aren’t.

If you’re an add-on user, always read an add-on’s description and privacy policy to make sure you understand what the add-on does. If you notice an add-on changes your defaults in an update without asking or makes another change that isn’t disclosed, please report it.

During the keynote of Add-on-Con 2009, I announced that Mozilla is planning to launch a marketplace pilot this year. That’s still the case, and in my opinion, it can’t come soon enough. There are many reasons I think we need to give developers a way to earn a living off of their hard work creating add-ons: it will increase the number of add-ons, the number of developers, and the quality of add-ons. But right now, the reason I most want an add-ons marketplace is to give developers an easy way to profit from their work so they don’t even have to think about going down the road of surprises.

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.