Improving the add-on install experience

Add-on developers face a bit of a challenge when it comes to helping users get the most out of their add-ons. Even once you are past the first hurdle and have got a user to install the add-on, you then need to help them get up and running quickly after Firefox has restarted. Presented with just the blank Firefox window it can be difficult for a user to know where to go next. Many add-on developers have taken to including a first-run experience to give the user some help. Display a webpage with some instructions or open a wizard to start setting up. As this practice started it was generally acceptable. Few add-ons actually did anything so it was helpful. These days though many add-ons are doing it, no doubt with more to come. It is starting to be an annoyance in some cases. Others have already been discussing ways that we can improve this.

In Firefox 3.0 we introduced a small feature to try to alleviate a little of this. After restarting Firefox the user would be shown new add-ons that had been installed so they could configure them. It also provided a little consistency across the restart which was normally done from the add-ons manager.

The current post-install display

The current post-install display

This UI had the additional small benefit that it would also display when other applications installed extensions into Firefox without the user’s knowledge. However as a post-install experience it really hasn’t worked out all that well for a few reasons:

  • It’s invasive. It pops up in front of the user after the restart and they feel the need to close it before doing anything else. This makes it almost as bad as some of the first run experiences provided by extensions.
  • It’s confusing. It can be pretty difficult to identify just what add-ons have been installed especially when the list is long.
  • It provides no next steps. Although if you click on the new add-ons you might get a chance to configure it, it doesn’t actually help push the user in any direction.

We’ve been thinking about ways to improve this for a while and there are a few different ideas floating around. I’d like to float one of them here and see what people think. The goal is both to let users know that new add-ons have been installed and let the add-on help the user move forward without needing to show popup dialogs or inundate the user with a webpage per add-on. It also needs to work in applications that aren’t Firefox. Excuse the poor mock-up, my UI skills aren’t all that hot.

Proposed first run experience

Proposed first run experience

The idea is that in Firefox this would display in the webpage content area. It might display immediately after startup, or it might be better to use an alert to tell the user new add-ons are there and then display it when they click on the alert. Other applications can open this in a new window or wherever they wish.

It’s designed to be clear exactly what has been installed and give the user things to do with those items. Preferences at a bare minimum, but the yellow highlighted areas are the interesting bit. Those represent overlay points where the add-on can put whatever UI it likes. This might be a simple message to tell the user how to get started. It might be a few of the most common settings, maybe a login box. It might be a button to launch further UI like a wizard.

I think, even if this were to open immediately in Firefox, this addresses the main deficiencies of what we currently do. I’d hope that many add-on developers could then stop their custom first-run stuff and instead just use this, but I know there are lots of different needs out there so I’d like to hear where this doesn’t work to see if we can accommodate.

21 thoughts on “Improving the add-on install experience

  1. I propose having a persistent alert bar above content, instead of loading the page immediately. The reason is that the page can lose focus to other tabs easily. e.g. when pages on startup have authentication dialogs pop up.

    It might also be wise to support firstrunUrl (or similar) in install.rdf (there is a bug somewhere on that), but instead of auto-launching it, it could be exposed in your proposed UI as a link.

  2. The main issue I have with the notification bar is that it is intended to be for page specific information, though we have already broken that rule on occasion. It is also something that is easily hidden if something else needs to display a notification.

  3. Consider having another button: “Teach me how to use this Extension” or something along that lines. In our experience people install random extensions and would benefit from ability to learn how to use it.

  4. Make it an about:newextensions (or about:extensions?new) page where any extensions that have been installed since the last visit to this page is displayed.
    An about:extensions page could also be nice to have, sort of like about:plugins except you have the boxes illustrated in the article instead.

  5. The mock-up looks good and is nice and clear, however, please remember Thunderbird and other Mozilla-based applications here, we want to improve as well ;-) With its tabs Thunderbird can now display content as well, so make the code globally accessible within gecko/toolkit and we can use it as well.

  6. Yes, this would certainly be an improvement. I guess with some effort I could shoehorn my first-run page into the tiny space – and even add a “Learn what’s new” link. I just hope that it will still work properly with applications like Prism that don’t have a tabbrowser.

    @Brian: Requiring the user to click a link to configure the extension strongly reduces the probability that the user will leave that page having configured the extension. My experience is that the overwhelming majority of users don’t read any text and consequently don’t click any links. They will only do something if the page clearly demands a decision.

    An alert bar is not a good solution for the same reason, it requires the user to take an action before he knows that he needs to configure something.

  7. Kim, that is entirely the point. It only displays newly installed extensions.

    Standard8, the idea is that applications can choose where/how to display this in whatever way fits to them. At the minimum it would support being opened as a window in its own right which would work in most applications. Firefox would use the webpage area, Thunderbird could open it in a tab, whatever they like.

  8. I like the idea, but isn’t it asking for spoofing attacks? People may find themselves installing unwanted add-ons if they see a similar-looking page that asks to “click here to complete your installation” (even if they haven’t installed anything). They’ll click just because they’ll be used to this page and to trusting it.

  9. Something that might be an issue: what if the extension is disabled when it is installed, e.g. because it has dependencies on other add-ons or is incompatible with the application version? This page would show up for an extension that is disabled and cannot be configured. And when the extension actually becomes enabled the opportunity to configure it is already gone.

  10. How about adding another Pane to the Addons window, titled ‘First Run’,
    that lists only the new extensions, with the information displayed in your mockup,
    but formatted to the default look & feel of the Addons window.
    Key buttons to show for First Run extensions could be: Options (or Pref’s for Mac), Homepage and About.

  11. Maintaining and testing this extra XUL content is tedious. Please no preference button, and allow the install.rdf to just have an optional link we can use to point to HTML content.

  12. I like the idea, it would certainly solve the first-run issues and being a constant, uniform reaction to installing new add-ons. I particularly like the idea of a box where the add-on can feature its own first-run introduction/requirements/options.

  13. Has anybody discussed or considered the annoyance of making Firefox restart to install addons in the first place? I think Mozilla should be looking at ways to install addons without a restart. I realize that is probably a huge change (coding wise), but I know of other applications I use that support addons but do not require a restart. Especially if the user has multiple tabs and/or website sessions open, it’s very inconvenient to have to restart.

  14. Yes Jake, that is the source of many discussions, even some on this very blog. It’s a pretty big change to do well (particularly when you consider complex add-ons and allowing for updates). For the time being have you seen the new Jetpack concept? It allows for simple add-ons to be installed and uninstalled without any restarts.

  15. Yes, I’ve seen JetPack, and I like the idea. Do you know if Mozilla has long term plans to remove the restart requirement? Sometimes even big changes are ultimately necessary, and I hope Mozilla is not avoiding this problem just because it’s a big change.

    • Right now it is likely that Jetpack is going to be the solution for the restart requirement for those add-ons that can run there. The problem is that there is no way remove all running code from the runtime that isn’t in some kind of sandbox which makes upgrades or uninstalls without restarts effectively impossible. Allowing installs without restart is easier, but it is barely half a solution and when we have session restore to solve much of the burden of restart there are more pressing matters to work on.

      • The real problem with session restore is that firefox still does not allow delays tab opening. Currently if one is researchign somethign and has say 3 dozen tabs open, with maybe 10 or so to a single site this will cause a problem. Example just now I was researching somethign with about 46 tabs open. I found an addon to firefox that would make my life easier in this research. However I am loathe to restart right now as 14 tabs go to a single site. After a restart because FF chooses to open all tabs at once this causes undue processing problems, and in some cases can be seen by automated protections as an attack on a site. I have on some occasions been blocked from a site due to this very failing.

  16. is there a way to remove this dialog completely? i’m not your average user; i know my add-ons, and having this extra window appear all the time is annoying at best… if i had a config switch/value whereby i could bypass this dialog, i’d use it in a heartbeat :)


  17. Pingback: Silent Install Firefox Plugin Backfires on Microsoft « Aftirmative

  18. Pingback: Oxymoronical » Blog Archive » Progress on notifying users about third-party add-ons

Comments are closed.