February 14, 2011
Updating software sucks. For most of your software, you’d probably prefer to never think about updating. Ideally, your applications would stay current and fast on their own without ever requiring your input.
That’s why one of the important changes in Firefox 4′s add-ons manager is keeping add-ons up-to-date automatically. This happens in the background without you even noticing.
Automatically updating add-ons does exactly what users have been telling us they’d like for a long time. However, some users will want to manually update their add-ons, as they did before Firefox 4. Other users will want to automatically update some add-ons but not others.
Hard as it is to cater to many use cases, we felt it was important to allow users to manually update add-ons if they prefer. Add-on updates are essentially new software, and users should always have the ability to opt out of them.
Below is the basic use case of managing add-on updates I’m proposing for Firefox 5 (which is only a few weeks after the release of Firefox 4 thanks to our new shorter release cycles). The user begins with completely automatic updates on by default. By switching to manual updates in the advanced menu, the user can go back to installing updates themselves. Each add-on shows, in its detailed pane, whether it receives updates automatically or manually.
However, there’s another kind of usage that needs to be supported. What if a user wants all but a few add-ons updated automatically? Or, all but a few add-ons updated manually? Allowing users to switch any particular add-on between manual and automatic updating allows users to make one-off exceptions.
If a user goes to the detailed pane of add-on, they can see how an add-on is currently updating and switch it to the other method. To change <i>all</i> add-ons to the other method, the user needs to select that option in the advanced panel. This way, we allow users to make both blanket rules and exceptions as they go. Here’s a more complete diagram showing updating preferences, with one-off exceptions included:
January 26, 2011
As we approach the release of Firefox 4, the last few polish and stylistic changes are happening in the add-ons manager. Some are simply graphic cleanup, while others are the result of beta testing the new manager for the past several months.
I wanted to highlight one change in particular that you’ll be seeing in the Firefox nightlies soon. The date an add-on was last updated, rather than being displayed in list view, will now only appear in the detailed view of an add-on. This also means that installed add-ons can no longer be sorted by last updated date.
For some users, this change is substantive and will feel disruptive. So, I wanted to give the rationale behind this design decision.
1. Providing a simplified overview
The intended purpose of the add-on manager’s list view is to give a brief overview of the users’ add-ons and to provide only the minimal, most used information and functionality. This minimal information is the name of an add-on, its icon, and a short description. The minimal functionality is the ability to disable and remove an add-on. Even the author name we’ve removed to provide the simplest, most visually scannable design. By removing the last updated date, we not only visually clean an add-on’s list entry, but also eliminate the need for a sorting bar at the top of list view. This gives back both whitespace and a cleaner appearance at the top of the list.
2. Updated date does not provide important functionality for most users
For most users, the last updated date does not give information meaningful enough to justify its placement in list view. It allows users to see which add-ons have been updated automatically most recently, but does not give any details about the updates nor provide tools to interpret the information.
Some advanced users use the last updated date as a diagnostic tool to identify which add-on updates may be causing a recent problem in Firefox. However, the date makes a very poor diagnostic tool. One reason is that the date does not give any information about the size nor scope of the update, and thus can only be used for diagnosis by disabling one add-on at a time to isolate a problem. In many cases, a problem in Firefox caused by an add-on are instantly identifiable as being caused by a particular add-on. Even in the rare case where a problem suddenly appears in Firefox, the chances of it being from an add-on update are not large. A problem could be caused by any number of online events, which is why Firefox provides tools such as the Error Console and about:crashes to help diagnose them. And, even if we were to give fuller information about updates in the add-ons manager and make it into a better diagnostic tool, why should this tool be so far removed from other diagnostic tools? How could a new user figure out that, to access diagnostic tools related to add-ons, they should go to the add-ons manager rather than a more comprehensive diagnostic tool? It would be wildly inefficient to apply this elsewhere in Firefox by placing diagnostic tools only on the interface elements they relate to.
What we should do is add diagnostic tools about add-ons to comprehensive tools such as about:support. Then, we could provide expert users the information they want in a better format while keeping one-off diagnosis away from list view in the add-ons manager.
3. The goal of removing updating entirely for most users
The intended purpose of automatic updates is to remove updating from the list of items the user has to care about and remember. By exposing the updated date in list view, Firefox insinuates both that the updated date is very important that this is a process the user should manage.
Actually, the actual reason sorting and the last updated date were initially proposed in the add-ons manager design was to give users the ability to sort their add-ons by performance, not updated date. Sorting by performance would allow users to find out how their add-ons effect Firefox on metrics such as startup time and memory. However, the ability to rank an add-on’s performance is going to be a part of FIrefox after the 4.0 release, making the remaining sorting categories (alphabetic and updated date) much less useful.
By the way, Firefox 4 beta 10 is out, so please try it out and tell us what you think!
Firefox 4 is right around the corner, and the Firefox’s community and team are working their butts off to make it as awesome as possible. The blocker list is going down every day, and the browser’s looking better than ever.
However, with everyone putting so much effort towards blockers, there are less people available to help with polish bugs for the add-ons manager. In particular, there’s a handful of bugs – mostly in CSS – that would take the add-ons manager from good to awesome. If you know CSS and are interested in helping with a feature used by millions, please consider taking a look at one of the remaining bugs. Not only will you be hailed as the people’s hero (by me anyway), but you’ll be helping millions of people customize their browsing experience.
Here’s a diagram of the remaining add-ons manager polish bugs:
If you need any information or help, comment I’ll get in touch with you!
December 5, 2010
One of the best reasons to use Firefox is with thousands of add-ons available to customize it, you can turn it into exactly the browser you want. To make it easier for you to find and use add-ons, members of the Firefox team and community have been working to redesign the add-ons manager for Firefox 4.0. The new add-ons manager will be easier to use, sleeker, and faster than ever before.
Here are a few highlights of the new design:
Add-ons update automatically
No more warnings when your add-ons are out of date; Firefox will now update them automatically. This should happen without you even noticing, keeping add-ons safe and fast while eliminating the hassle of updating.
Make changes to add-ons without restarting
Restarting your browser is a pain. Developers can now build their add-ons for Firefox 4 such that no restart is required; add-ons built using the Add-on SDK get this for free. Restartless add-ons can be installed, modified, and removed without a single restart needed! More and more restartless add-ons are being created and made available on addons.mozilla.org every day.
Add-on manager in a tab, not a window
Instead of managing your add-ons in a small, separate window, the add-ons manager now loads in a tab. This means it won’t be so small and easily lost among other windows, and you can interact with it identically to other tabs, including resizing and moving.
New Get Add-ons pane
Justin Scott has been leading a project to create a new section in the add-ons manager we call the Get Add-ons pane. In the old add-ons manager, we displayed five featured add-ons that could be installed. This was done to show you some examples of add-ons – much like buying a picture frame with a stock photo already inside. Justin’s done a thorough revamp of Get Add-ons, building a page which introduces you to the concept of add-ons, highlights particular add-ons that are editorially selected, and helps you explore and discover other add-ons that match your interests. Justin’s currently working on a new feature for this pane which makes personal recommendations of add-ons you might enjoy based on which add-ons you already have installed.
Quickly find any add-on
If you want to make a change to an add-on but don’t know which category it’s in, you can now simply search for it in the new global search box. The add-ons manager can quickly locate an installed add-on or find you some matching add-ons that are available to install.
If you’re using Firefox’s nightly builds, you can already see many of the above changes in action. Blair McBride has recently put a lot of work into the new theme change, so now we’re working on the final few bugs and polish. If you’ve already used the new add-on manager, please share your thoughts by commenting or leaving a message on Firefox 4.0′s feedback page!
November 4, 2010
I’d like to give a few updates on the continued implementation of Firefox 4′s new add-ons manager. As development work continues, some parts of the manager’s functionality have been adjusted and updated since I last posted mockups. Here are a few highlights of what’s been going on.
Add-on Specific Notifications
Each add-on in the manager could have one of several notifications that only pertain to itself. How can it be made clear when an add-on needs attention or action? Stephen Horlander first experimented with adding subtle coloring and diagonal stripes to each add-on. In the latest nightlies, this method is expanded to give the full range of add-on notifications. Red and yellow signify different levels of potential problems, while grey and green signify when an add-on requires attention or action.
Here’s a mockup of what these notifications would look like in the manager:
In Detail View, where only one add-on is visible, notifications appear at the top of the pane.
Global Add-on Notifications
Notifications that relate to all add-ons now display in the scope bar (bug 566194). The color of global notifications follows the same scheme as notifications for individual add-ons.
Hiding Browser Navigation Widgets
The design of the add-ons manager is enhanced by displaying only relevant parts of the browser chrome and hiding those that don’t relate to the page (such as the URL bar and reload button). Some benefits of doing this include:
- Presenting a minimal, clean UI
- Creating a distinctive in-content page that no other site can mimic – vital because of the far-reaching changes which can be made within in-content pages
- The user only sees actions that they can take. Reload, for instance, is needless on a page that’s locally hosted
- Space in the navigation bar normally used for browsing buttons can be repurposed for widgets useful for in-page content. For instance, the URL bar space can be used in future Firefox versions to present breadcrumb navigation for in-page content.
Progress towards removing browser navigation widgets is being tracked in bug 571970. Unfortunately, this will only work when Firefox is in its default tabs-on-top mode. Removing elements for tabs-on-bottom configurations involves changing the entire theme of Firefox substantially. In order for fast tab switching to remain possible, tabs would need to remained aligned in tabs-on-bottom mode while still preserving the minimal style of in-content pages. This will be the goal for a future version of Firefox.
Downloading Add-ons within the Manager
If you run Firefox nightlies, you may have noticed that if you install an add-on from within the add-ons manager, the installation process happens fully within the manager. By turning the download button into a progress bar, the user’s focus need not move; the relevant information for the download is where the user was looking in order to prompt the download. After the add-on is downloaded, a notification will display on its entry alerting the user that either the installation is complete or that a restart is needed.
A notification will appear over themes and backgrounds when they are fully implemented in the manager. These and other changes that only effect the style of themes and backgrounds will be implemented in future versions of Firefox after 4.
Add-on Installation Process
We’ve also streamlined the process of installing an add-on from a website for Firefox 4. The new design uses Firefox 4′s new arrow notification panels to minimize the number of steps required. When the user begins an add-on installation, the download now begins automatically. For most users, this should only take a second or two. The user then sees the name, author, and source of the add-on, and has the option of allowing the installation of the downloaded add-on. Firefox only obtains this information about add-ons once they have partially downloaded, which is why the full information is presented after the download completes. Though the add-on file has already downloaded at this point, the file is not accessed unless the user allows it to be.
If the add-on does not require Firefox to be restarted, that’s it: the add-on is activated as soon as the user clicks “Allow”. If it requires a restart, the user is notified that a restart is needed and the add-on is activated after the next restart.
If you’d like to try out the new add-ons manager, try running the latest Firefox nightlies. Some of the smaller style changes have not yet landed, but the behavior described here is ready for testing (and bug reports where needed!)
September 22, 2010
The basic redesigned add-ons manager functionality is running in Minefield nightly builds. Many smaller parts of the functionality, and especially edge cases, have open bugs and are being actively designed and fixed. API changes are being made majoritively by David Townsend, and final CSS visual polish is being done majoritively by Blair McBride. Majoritively is actually not a word. Individual bugs are not being filed for most of the small steps required to visually style the manager to match the current mockups.
The add-ons manager consists of a separate panel for each category of add-ons, called List View (☑ bug 585950). Individual add-ons’ details can be viewed in Detail View (☑ bug 562902). The other main parts of the add-ons manager are search, a client-side “Get Add-ons” pane (bug 558158, spec), and the Update Pane (bug 598738).
- Extension manager API rewrite (bug 461973, wiki, documentation). Dave Townsend is making API improvements clean up a number of issues, including to allow the main UI to operate without having to speak RDF. This bug currently has 52 dependencies, including some user experience issues:
- Having extension compatibility controlled on a per-addons basis (bug 527861)
- Controlling order of add-ons in manager (bug 595847) and adding a search plugin provider (bug 552747)
- Installing and upgrading add-ons in the add-ons manager:
- Viewing add-ons in the add-ons manager:
- UX-centric functionality bugs for viewing add-on information:
- UX-centric functionality bugs for installing and updating add-ons:
- UX-centric functionality bugs for using add-ons:
- In-content UI work needed
- The add-ons manager currently does not visually incorporate the navigation bar. Incorporating the navigation and (if applicable) bookmarks bar, as in the mockups, distinguishes in-content pages as a part of the browser, not a part of the web. It presents a steamlined, simple interface for dealing with what is essentially a panel of Firefox itself. It also makes such pages distinct and unspoofable. Bug 571970 is tracking progress on this change. An added challenge of this change is making in-content UI work when the user has set tabs to display on bottom (see comment 23). While a decent design solution could be found, this may not be worth the work and time before Firefox 4, and fixing the multiple back forward buttons present with tabs on bottom (bug 597178) is likely a better temporary solution
- Unresolved issues
- Giving a better experience for third-party installed extensions. Namely, to outright disable them on upgrade or not? (bug 596343)
- Gradients and texture files needed for background of all in-content pages. This could get slightly tricky with window resizing, anchored images
- Concept and icon for what we’ve been calling the “gear” menu. Gear works fine for OSX, not so much for Windows and Linux. Even current placeholder gear is too close to native OSX window “tasks” menu
- Final images and colors on sorter bar and search header
- Final mockup for Update panel and in-line updates
August 29, 2010
I’ve posted quite a few mockups on this blog of Firefox’s redesigned add-ons manager’s features and interactions. What I haven’t shown are screenshots of how the manager will actually look in Firefox 4.0. The following are designs, based on Stephen Horlander’s work on the new Firefox theme, of the add-ons manager in OSX and Windows 7. The icons are still placeholders, but the rest of the design is pretty near finalized.
In the image below, you’ll see three windows for each operating system. The first row shows list view, where a short summary of each add-on and its description are shown. Buttons allow the user to disable an add-on or launch its preferences. Clicking “More” takes the user to detail view.
The second row shows detail view, where the user sees more information about a single add-on. The full description is displayed as well as a contribution box if the add-on’s author chooses.
Finally, appearance view shows installed themes and backgrounds (previously personas). Since these add-ons are primarily visual, the interface gives a large preview of each item and does not display a description.
Dave Townsend and Blair McBride have been working hard on implementing these visual changes as well as the slew of under-the-hood improvements that are making the add-ons manager faster and more stable. To see how it’s coming along, try running a nightly build in your operating system of choice. Hope you like it!
April 1, 2010
Greetings! I want to tell you about some changes to the add-ons manager you’ll be seeing in Firefox’s trunk release very soon.
Add-ons in the Content Area, Oh my!
The biggest change you’ll see is that the add-ons manager will no longer appear in a separate window, but in a tab in Firefox’s content space. This represents a big shift in Firefox’s interaction model. You can read more about the reasons for in-content display here, but the summary is that displaying in content:
- Allows for similar display across devices
- Allows for quick updates from external sites, like Mozilla Add-ons (AMO)
- Gives more screen real estate to tasks, allowing for less constrained interaction
- Eliminates the need to manage small, easily-hidden windows
Eventually, we’d like to move many of Firefox’s various “extra” windows (Download Manager, Bookmarks Library, etc) into the content area. The add-ons manager, by being the first, will hopefully provide a solid working model that will guide the redesign and improvement of Firefox’s other windows.
So, what will you see when this thing lands in trunk? Something like this:
Ugh, These Icons Aren’t Final, Are they?
No, they’re not. Can you not read giant ridiculous gradient-heavy starbursts?! These are not the final graphics nor colors; they’re placeholders for now. In redesigning the add-ons manager, interaction design and visual design were kept deliberately separate. What you’ll see in trunk is a reflection of the new interactions in the add-ons manager – viewing in a tab, configuring and installing add-ons, etc. The final visual look will come later. This is partially because there’s still kinks to work out before the final graphics are created, and we’d like the community to try out the manager before it’s 100% done.
A Model for Firefox’s “Extra” Windows
There’s another reason the graphics aren’t final. If Firefox’s extra windows are going to move into the content area, they have to feel very different from the rest of the web. They need to feel fundamentally a part of the browser itself. They also need to feel like a part of Firefox and the operating system. Additionally, they need to feel like each other. One of the goals here is to make Firefox’s look and feel more cohesive. The browser is the one stable part of the browsing experience. The web is a dizzying array of different content, and the browser should provide a dependable framework for exploring it. Right now, Firefox’s style is inconsistent in many places, both in design and interaction.
It looks like different parts of Firefox were made by different people at different times because, well, they were. Compare that to a product with fewer people working on each feature’s interface and a much shorter turnaround cycle.
Incongruous design is often a result of software having an organic development cycle over a long period of time; different parts begin to look and feel very different to each other.
One way to mitigate against organic growth creating dissimilar design is to make and use style guides. Firefox follows them for code and terminology, but we don’t have much for interaction and interface design. So, before we can really bring all these extra windows to content, we need a clear picture of the interactions and style that we’re following. Starting this process has been contingent on the new Firefox theme becoming solidified. Stephen Horlander‘s done incredible work here, and we can feel confident moving forward with a plan for these other windows. This is a separate project that I’m starting up and will be blogging about in the future.
Even though the graphics and style are not yet final, I wanted to point out some of the projects that influenced the interaction of the add-ons manager redesign. Nothing is ground-breakingly new in the manager, and this is deliberate; I was trying to find the simplest interactions that would work for a wide variety of content and users.
One simple interaction being used is the two-panel design itself. “Zooming in” to information by moving right has become a standard of application design. All major operating systems have a similar interaction here: selecting an item on the left shows its contents and/or details on the right (the opposite is true for right-to-left language readers). This design is already being used in Firefox for the History sidebar, Bookmarks Sidebar, and Library.
The basic layout of the addon manager’s “digest” and “detailed” view are similar to the layout of addons on addons.mozilla.org (AMO). Luckily for us, AMO had a recent redesign and solved many of the problems of displaying add-on information. Giving summary information in a list helps find an add-on of interest, and more information is available on click. Using a similar style to AMO was also important because of how intrinsically the add-ons manager and AMO are related. Treating add-ons differently within Firefox would mean that add-ons users would have to learn two systems rather than one.
Other bits of the design are inspired by small interactions I’ve seen other applications get right. For instance, add-ons in the manager can be downloaded from within the manager. But, popping open the Downloads Manager to show a progress bar would clutter the interaction. I looked around for an elegant way to do in-content downloads, and found it in the video player Miro. Miro elegantly turns the download button for a video into a progress bar, meaning the user does not need to look away from the target they clicked on. They also incorporated pause and stop button beautifully into the bar itself. The new add-ons manager handles the progress bar very similarly.
Another element of Miro I thought was a good idea was the very subtle “Show More” button, which gives an expanded view of the selected item. This works well for add-ons as well as videos, and thus the redesign has a similar link.
The view of multiple add-ons was also inspired by task-management application Things, which also groups right-paneled items into expandable boxes.
Better close out before this gets too much longer. Tune in next time for: why themes are hard. Hopefully I’ll have a better title by then.
January 28, 2010
Big day, right? iPad, Prop 8 Trial’s Witness Testimony concludes, Obama’s first State of the Union, Ted Haggard was cured of being gay (again). But you found the time to stop by my blog anyway. That warms my heart. So have a seat, and let’s talk about the add-ons manager.
Oxygen or Bling?
First, humor me a second, because I want to back out a little. Lately I’ve noticed that we talk about add-ons in very different ways. Add-ons developers and community sometimes talk about add-ons as something “everyone” should install. I’ve heard some say that there’s an add-on for everyone, or that everyone should install a few that help their browsing experience. This is the “add-ons are oxygen” view. And heck, it’s been said plenty that add-ons are one of the main things that make Firefox great, and they are certainly what differentiates Firefox from other browsers.
But hold on. Isn’t Firefox sexy and beautiful right out of the box? Don’t about half of Firefox users have no add-ons installed? And when users have problems with Firefox, aren’t “weird add-ons” the first thing we blame and disable? This is the “add-ons are bling” view.
So, should we encourage users who don’t use add-ons to install them? Are they oxygen or bling? Like about everything, they’re probably in between.
A Browser with a Bike Rack
The purpose of a car is to drive places. That’s why you’d buy one, and you’d expect it to do that perfectly as soon you buy it. There are some car nuts (I know quite a few) who care deeply about a car’s engine, performance, style, etc. They will make incredibly deliberate decisions about the car they buy, and even make modifications to get it to behave differently. Some of these modifications will be purely functional (e.g. tires with better traction), others are stylistic (e.g. racing stripes), and some help them perform other activities (e.g. a bike rack).
But the majority of car drivers won’t look for modifications and will be content as long as their car looks good, drives well, and get them from A to B safely. If they’re driving a good car, it’s probably because one of their car-head friends told them it was a good model (explains my Civic). Should these users be encouraged to modify their car? If so, how?
While the casual car drivers may not understand much about the workings of their car and may be bored at what car-heads find interesting, many could have a better car experience if some modifications were easy to understand and easy to install. If I could change the color of my car every day with a click, I would. Ditto if I could add a laser gun to the front. If putting a red stop-sign sticker on my windshield protected it from bird droppings, I’d stick it on.
So if you were a car manufacturer of free cars and free car modifications, and your goal was happy users, what would you do? First, for those car-heads, you’d want modifications to be easy to develop and share. For those casual drivers, you’d want the free modifications to be simple to find, install, remove, and understand. You’d want it to be clear how a modification would change the driving experience. And if one of those casual users wanted to become more of a car-head, you’d pave the path for them. These are roughly the goals of the add-ons manager redesign.
Add-ons as Preferences
There’s something else to keep in mind with the add-ons manager. Add-ons are essentially choices the user has made about how to tailor their browsing experience in a way that reflects their preferences. Uhoh, preferences? You bet – installing and configuring add-ons is a small part of a user’s browser preferences, and as such should probably not be separate from the Preferences menu. I constantly see users go to the Add-ons Manager when they want their Preferences, and vice versa. So in a future Firefox, it makes sense to combine these. But, because there are many separate challenges involved, for now we are focusing only on the add-on manager’s 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 same can be said for the Preferences menu.
The Preferences project is still in its infancy, but keeping in mind that the add-ons manager will probably exist within the context of the user’s Preferences is important both in design and implementation.
The design currently being considered for the add-ons manager is a two-panel basic hierarchy view within the content area of the browser. Add-on categories would display in the left panel, with an expanded on the right. This gives the user an overall view of that the add-ons manager entails, as well as enough room to individually configure items.
One of the benefits of having this two-panel design is that it allows scanning the contents of a category. The current add-on manager currently employs a sort of “digest-style” summary for each add-on, and with category view this sort of functionality can be improved with better information.
If a user selected a particular add-on from their manager, the right panel would show a detailed view of that add-on. This is something the current add-ons manager lacks: enough space to find out more about an add-on and configure it. Below an add-on’s information, the developer could add preferences for that add-on. The current manager pops preferences out in a separate window, launched from a button. This is essentially a pop-up window within a pop-up window. A two-panel in-content layout allows all of this functionality to be integrated.
This post is getting long pretty fast, so I’ll close here for now. Next up – how some of the interactions for maintaining, configuring, and installing add-ons could work within such a design.
As usual, these designs are not final and feedback (especially from add-on developers) is absolutely welcomed..
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
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.