Relocating Firefox’s Add-ons Manager
December 3, 2009
In my last post, I described some of the ways that we’d like to improve the add-ons manager. First, we’d like to fix some of the add-ons manager’s usability problems, such as confusing installation processes and distracting notifications. There’s also some new functionality that the add-ons manager needs to provide, such as better information about add-ons and incorporation of newer projects such as personas. It was clear from the feedback that developers as well as users would like to see the maintenance and configuration of add-ons become easier.
The Add-ons Manager as a Tab
The current add-ons manager window sometimes gets in the way (with apologies to Gizmodo)
A few commenters on my last post highlighted problems caused by the add-ons manager being a separate window. It can get lost among other windows, be as distracting as a pop-up ad when giving a notification, and means part of the browser UI being modified is obscured. A potential solution that I think addresses these well is moving the add-ons manger into the content area of the Firefox, so that it runs in a tab. Here’s a few benefits this design provides:
- Gives more screen real estate to the add-ons manager. This would allow enough room for useful add-on information, scanning an entire add-ons inventory, and functionality like add-on preferences.
- Presents a less fragmented browser experience. Firefox’s chrome is basically a frame in which users go about their online life. But to modify that frame, users have to jump outside of it and onto a floating window. Modifying add-ons in the content space means the user never has to leave their tabbed browsing. Also, they can see all changes their add-ons make rather than having those changes obscured by a window.
- Allows for a similar add-ons experience across different devices. Running the add-ons manager in a tab means that an internet-capable device does not need a separate window or menu to modify add-ons – any device which can open a window can use add-ons in the same way as a desktop computer. Add-on management on mobile devices, tablet computers, and fullscreen mode would all provide the same experience. This is a huge win as the web becomes less about the device it runs on and more about the user, who may access the web on multiple devices.
Designing such an add-ons manager is a challenge we’re actively engaged in. The final design must feel like it’s a part of Firefox rather than a website, even if it’s displayed within a tab. It must also be unspoofable. Below is a rough wireframe of the design direction that we are considering.
Jennifer Morrow's Blog 
December 3, 2009 at 12:07 pm
Do you have any data about how many Firefox users actually use AddOns, as a percentage of the whole?
December 3, 2009 at 12:25 pm
@David : see http://blog.mozilla.com/addons/2009/08/11/how-many-firefox-users-use-add-ons/
December 3, 2009 at 12:36 pm
How do you plan to make the add-ons manager “unspoofable”? Your wireframe doesn’t really help on that point. 🙂
December 3, 2009 at 12:54 pm
How is the current window “unspoofable”? I’m not sure that this needs to be a primary concern at this time. Let’s focus on the main interactions for now, I think.
December 3, 2009 at 1:16 pm
Talking about ‘scanning an entire add-ons inventory’, how about allowing instant view of installed addons for a given category ? I mean, for instance, in your wireframe I can see a category named ‘Features’ in the left panel. As a user, I wish I saw a complete view of installed addons within the right panel when I clicked on the category’s name. Meaning thumbnail-style view. And clicking on the thumbnail for ‘StumbleUpon’ would bring the info depicted in your wireframe. Let’s say we could display max 16 thumbnails per page, which should be enough for the big majority of users, I guess (except for power users, I don’t think lots of people would have more than 16 add-ons for a given category, and even if it’s the case, you could probably give them the option to click on a ‘Next page’ link to show another page of addons).
I propose this because i’m not a big fan of drop-down lists, they clutter space IMHO and sometimes force users to scroll down.
December 3, 2009 at 2:57 pm
Very nice! I really like the per Add-on automatic update!!
Now if we can get all the separate windows to open in tabs then I’d be estatic!
December 3, 2009 at 3:39 pm
The design is very nice!
My only suggestion is for the left sidebar. Rather than specify installed addons categorized by root name, “Feature”, categorize ones installed addons by category as seen on AMO, (i.e., Bookmarks, Download Management, Social Communication, Web Development, etc..)
December 3, 2009 at 4:40 pm
Nice Ideas, let me add some comments…
* There are already some Add-ons that enable “showing as a tab” but don’t modify the layout otherwise. So it would be a good “feature” to be able to switch between window/dialog and tabbed mode -> maybe even do a test-pilot-survey about this.
* Please let there be an “Overview”-mode/feature e.g. by selecting the “My Add-ons” in the sidebar shown in your mock-up, for a fast look on what’s there, which one should be updated, which one is installed, but disabled, etc -> maybe even similar to fenec or “Mr.Tech Toolkit” – compact-mode (I’d prefer fenec UI)
* Citing Aaron(Dec 3, 2009 at 3:39 pm): Categories. Different people, different strokes, good idea would be a switch-able sorting: one like AMO, one like where it works (Theming/UI/Content/Extra-functionality), by Date installed, by last update, etc. -> best do a test-pilot-survey on wanted/used functionality
Thanks for work You’ve invested in this. Would it be possible to implement this as an Add-on for Testing it NOW without the need to install a nightly? this would enable the possibility to do Test-Pilot-Survey befor integrating it permantently.
Thanks again, cheers, Yamaban
December 3, 2009 at 4:58 pm
I think your mockup is way to complicated. I definitely like the idea of putting the manager in a tab, but you should not put more information there. Information like Compatibility, “updated” and so on should only be shown if the user explicitly clicks on it.
I would suggest to show a list of all addons with activated/deactivated status by default like in the old dialog.
The rest is not interesting for most of the users and just raises the barrier for users by showing them a clutter interface they have to “learn”
December 3, 2009 at 6:43 pm
Regarding making the Add-ons Manager (and other chrome dialogues) not spoofable, I have a few ideas.
First, tabs that belong to the chrome could be differentiated from web tabs. This could be a different background, different font, different favicon (or none at all), or some other way of differentiating the appearance. If web tabs looked like Stephen Horlander’s ‘Page Integrated Tabs’ mock-up, differentiating between them and the chrome would be even easier, as chrome tabs would retain the look of the rest of the chrome.
Secondly, the location bar could also be differentiated. The identity button could be made to look more chrome-like, or eliminated altogether. The URL could be replaced with a more readable breadcrumb trail (like Alex Faaborg’s ‘Personal URL’). Better yet, when Firefox 4 comes around, the whole Navigation toolbar could be eliminated altogether—a behaviour reserved for the browser and applications that are given permission.
Finally, whatever behaviour you choose in the end for the Add-ons Manager, I hope it will be made consistent with any other chrome dialogues that will be moved into tabs in the future (and the special Home tab).
December 3, 2009 at 9:26 pm
I have to say, I have reservations about this, although I’m not completely closed out to the idea provided there is demonstrably good rationale behind it. But the reasons given here don’t meet that qualification.
Please understand that this is not an “I hate it, here’s a bunch of things I just made up to support my position after-the-fact” comment. It’s not the case that I feel that your reasons don’t provide a strong enough incentive to make this change, which is a measure that will vary for each person, and generally, developers win. It’s that, removing those types of personal opinions from consideration—that is, agree or disagree with the desire for this change—the reasoning is not sound; there are contradictions among the points you present.
However, I will make exactly one personal appeal:
Please don’t assume this. If the add-ons manager is in a tab, I no more want it to require my browser be sized to an inefficient width[1] than for Web pages to require the same, and that assumption is already egregiously present from the latter.
Okay, as for the ojectivity:
I will start again with the above quoted paragraph. The notion of wider screen real estate is incongruous with point 3, the considerations for mobile devices, which I will discuss below.
Given the incongruity I pointed out above, the likely decision would be to tailor the contents of the Add-ons Manager presented by the mobile version to require less screen space, which eliminates the “same experience” benefit. Additionally, a tabbed Add-ons manager fails to satisfy the “same experience” criterion as related to other desktop applications.
Given a sufficiently large canvas available to tab contents, as presumed and required by point 1, the current Add-ons Manager requires obscuring no more of the browser chrome than a tabbed one. However, a tabbed one does require that its tab be focused, which implies that other Web content tabs are not. This presents a problem if the add-on being managed is making alterations in the canvas of Web content, while there exists no benefit of unobscured browser chrome over the current Add-ons Manager. The net effect is an objective loss.
I hope that my comments have stimulated thoughts, and I look forward to a reply.
[1] Columns of text, at font sizes typical for the Web today, and as wide as today’s monitors (or even last decade’s) are objectively worse for reading. See, for example, the bibliography for The effects of multiple column online text on reading speed, reading comprehension, and satisfaction. (That report itself did favor columnation, and therefore narrow line lengths, but you could argue that because the methodology was not designed to specifically study line lengths, the report isn’t sufficient for a mandate on narrow columns, so I refer you to its sources instead.)
December 3, 2009 at 9:31 pm
To point out something in David’s comment, specifying a “different background, different font, different favicon (or none at all)” are all things that are exposed to Web content today.
December 4, 2009 at 1:47 am
Colby: You misunderstood. I was talking about differentiating the appearance of the tab, not the page content. Those things are not exposed to Web content (save for choosing the favicon).
December 5, 2009 at 2:52 am
If part of the problem this approach is trying to solve is so the addons manager does not get ‘lost’ then this seems like jumping out of the frying pan and into the fire.
I keep *many* more tabs open than I do windows. I am much more likely to lose or forget a tab than I am a window. I currently have 4 windows open, but I’d be embarrassed to count how many tabs I have open.
I appreciate the window approach, as much like the options/preferences window, I can focus on it, deal with it and be done with it. It is not content that I want to monitor. I don’t keep it open and I don’t want to manage it on a continual basis. What I don’t need is one more tab to add to my mess.
December 5, 2009 at 6:23 pm
I cannot stop the addon installation process once i’ve clicked Install button. The only way is by quitting firefox. Is there any way to cancel an install midway?
Could you provide specs on the add-on(size, updatehistory, etc). Yeah i know add on files are small, but i’d still prefer watching their weight.
December 7, 2009 at 4:01 am
Rasmussen –
There should definitely be a way to cancel mid-installation, for add-ons and everything else. Add-on specs would also be awesome, if not in this release in the future. Being able to catch when an add-on is getting out of control or hogging memory – even seeing what resources are allocated to what add-ons – I think would be very useful.
December 7, 2009 at 5:26 am
Mark –
The other nice thing about rendering controls like the add-ons manager in content is that the window could be detached.
December 7, 2009 at 5:48 am
Colby Russell –
On point 1 – Because tabs tear off, the currently present option to detach and resize the add-ons manager would still be available.
On point 2 – Yes, different devices would have different sizes, but the main interactions and workflow in the add-ons manager would remain the same. For instance, right now mobile Fennec and desktop Firefox have completely different add-on manager experiences which are displayed in different ways. If these two designs became more closely aligned, users would not have to relearn add-on usage.
On point 3 – This is a good point – it’s true that the add-ons manager would take the place of the contents of a page. To see the effects of add-ons on a particular pages, users would need to detach the add-ons manager or open it in a separate, possible chromeless window.
December 7, 2009 at 5:52 am
David –
Thanks for the great ideas. I do think some chrome modification, such as the ones you proposed, could be a good solution. Re consistency, I think that probably all separate windows could live happily within Firefox’s chrome in the future. If anything, I worry about things moving in slowly, leading to some panels being separate windows and others not.
December 7, 2009 at 5:55 am
Thomas –
I think you raise some valid points. What I wanted to explore in the mockup was a layout much like the current addons.mozilla.org, but as you note only users very interested in this information would go to that website. A simpler version, perhaps with other information available via progressive disclosure, would be well worth exploring
December 7, 2009 at 6:02 am
Yamaban:
– On bullet 1: as tabs tear off, the add-ons manager would always be separable from a window.
– On bullet 2: Absolutely I would want to make this available. I think clicking on any category heading should show a kind of digest view, with a short entry for each add-on in that category.
– Re testing – I’m afraid you can’t test it *now,* because it’s not written yet. But doing this as an add-on that anyone could try before adding it to trunk would be a great idea. I’ll let you know when that happens. 🙂
December 7, 2009 at 6:11 am
Aaron –
Good point – picking the right categories is a tricky challenge. It’s one I’d love to do some user-testing on. I take it you like what AMO’s done?
December 7, 2009 at 6:11 am
Kurt –
Yikes! I don’t know what to do with positive comments! Thank you! And yes, I think separate windows being integrated into the content space is the Terrible Future that Firefox should move to.
December 7, 2009 at 6:13 am
Mike Beltzner –
Basically I wanted to say I’m not addressing it now, but yes it will be addressed. Seemed like an easy thing for comments to focus on unnecessarily (for now).
December 9, 2009 at 12:01 pm
Looks realy great! I love this idea.
December 9, 2009 at 3:18 pm
1. I fear the way this might look in windows larger than 800×600 (the appx. size of the mockup above). Lots and lots of white space.
2. It seems to take excessive effort to find an item in the list. I’ve got 19 extensions, probably more than most Firefox users. Splitting into categories introduces extra clicks to find them, for what gain? A list of 19 is certainly not too much to scroll through.
3. When I want to find an extension, I have to guess which category it was put in? Some are obvious, some are very non-obvious. What about non-AMO-hosted extensions, what category do they go in? And where does the screenshot come from?
4. How extensible is this? Stylish already adds itself to Add-Ons, and Greasemonkey is working on it (I am! see: http://bit.ly/8h3SRe http://bit.ly/5tgmkj) This layout doesn’t seem to work well for either of those uses. At the very least, I’d like to see extensibility taken into account in whatever add-ons revamp might happen. Doing it now is difficult, and (at least my current work-in-progress solution) feels hackish.
December 9, 2009 at 8:53 pm
Hey Anthony:
1. We’d definitely take different sized screens into consideration. As for me – I’d prefer whitespace to not enough screen real estate for relevant data.
2. I would like to make a category level “digest view,” similar to the add-ons manager now. What this would provide is a quick overview of all the add-ons in that section with a brief description, allowing for more detailed view from this screen.
3. Rather than guess which category, you could use the search box in the upper right of the mockup to locate a particular add-ons. I’d like to implement madhava’s idea of having your own add-ons appear first in the search results, and AMO add-ons listed after that. Non-AMO-hosted extensions would probably predominantly be listed as features.
4. Greasemonkey scripts I’d like to be incorporated with this as all – perhaps even listed under a Greasemonkey category. I could see jetpacks working similarly.
December 10, 2009 at 12:56 am
Yes! Moving it to a tab makes a lot more sense! nicely done 😀
December 22, 2009 at 2:11 am
Boriss:
I absolutely love this idea, great job!
One thing I would like to see however is better discovery functionality. What about showing a list of the most popular, highly rated, or most shared addon like the front-page of AMO? Also, I think a button for sharing on Facebook, Twitter, etc, would be great. Users prefer to install addons from within their browser instead of visiting a web page, so I think it would be great if more features from AMO were added.
January 19, 2010 at 11:22 am
I have concerns with this approach. It’s absolutely correct for the Add-Ons Manager to be a separate window, for the following reasons:
– It’s related to configuration of the browser, not browsing web content. You shouldn’t mix these concerns. The whole issue of spoofability is a massive can of worms if you go down this avenue. (There are quite a few Add-Ons which collect personal login info, like email checkers and the like.)
– Having it as a tab will mean that it is quickly lost for those of us who keep dozens of tabs open at a time when we’re researching topics.
– We don’t interact with the Add-On Manager every day, like we do with tabs. If something is a rare occurrence, it’s far that it is treated differently, and that includes its UI. It doesn’t matter if the manager is a separate window if all I’m doing is acknowledging the installation of updates or browsing/downloading new Add-Ons when I’ve just installed Firefox on a new machine.
– You won’t be able to see the effects of changing Add-On settings on web pages without detaching the tab from the strip. This is an action which is alien to the majority of Firefox users.
As others have said, the mock-up is too complex. The current list is fine, possibly with some additional information when you click on an item. The majority of users only have a handful of Add-Ons installed, if any, so a simple list is the most logical, easiest to digest solution. Please don’t complicate matters.
I’d suggest research into installing Add-Ons without having to restart the browser instead 🙂
Sorry for the negativity, but this seems to be a change made for the sake of change, and would be a backwards step in terms of usability.
January 28, 2010 at 2:02 pm
[…] redesign, with the eventual goal of integrating it with Preferences. I’ve described in a previous post that it makes sense for the Add-ons Manager to display in the content area of Firefox: I think the […]
March 25, 2010 at 2:32 am
[…] 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 […]
April 1, 2010 at 7:14 am
[…] in Firefox’s interaction model. You can read more about the reasons for in-content display here, but the summary is that displaying in […]