All posts in User Experience

Thumbnails, Titles, and URLs: How Users Recognize Representations of Websites

By On July 28, 2011 In Research, Studies, User Experience, User Testing, uxurblog With 11 Comments Permanent Link to Thumbnails, Titles, and URLs: How Users Recognize Representations of WebsitesPermalink

The Mozilla user experience team often designs features that represent sites to users in a variety of ways. For example, Firefox tabs display favicons and page titles, while Panorama displays favicons, titles, and page thumbnails. So, I thought it would be useful to investigate the effectiveness of various ways of representing sites to users.

One interesting piece of research on page representation was published by Shaun Kaasten, Saul Greenberg, and Christopher Edwards at the University of Calgary in their paper How People Recognize Previously Seen Web Pages from Titles, URLs and Thumbnails (download it here). This team conducted a series of studies, most of which involved increasing one variable which represented a site the user had previously visited (such as thumbnail size) until the user recognized it, at which point the user would buzz in to stop the expansion and identify the site.

Here’s some key takeaways from what the Canadians learned:

Running sums of how large a growing thumbnail became before participants recognized it

– The graph above plots the thumbnail sizes at which test participants could recognize a domain (black lines) and a specific page within a domain (blue lines). The dotted lines show all responses, and the solid lines show only correct responses. You can see that by the time a thumbnail was 962 pixels, 60% of test subjects had identified it.  80% of test subjects identified sites by 1442 pixels, and by 3042 pixels everyone had identified the site.



– Users’ guesses about what site a thumbnail was representing were correct about 90% of the time. Not bad, considering on most sites they had no readable text to go by until the thumbnail was over 962 pixels. This shows how effective thumbnails are at identifying sites to users.

– Color and layout in were the most important factors for identifying a site when the thumbnail was 642 pixels and smaller. From 642 to 962 pixels, color, layout, images, and text were equally important. Above 1002 pixels, text was most important.  This is presumably because at that size, sites were not yet identified because they were visually similar to other sites and text was the only effective differentiator.

– Looking at only truncated URLs and page titles, test subjects could correctly identify sites 90% of the time.  The researchers experimented with URL and title representation by showing users right, middle, and left truncated strings and recording when they buzzed in to identify the site correctly.

Running sums of how many characters a page title (top) and URL (bottom) became before participants correctly recognized it

– The graph above shows the running sum of correct answers in identifying sites based on only page title (top graph) and URL (bottom graph).  You can see that right truncation proved the most effective for domain-level site identification.  For titles and URLS that were truncated on the right, sites were correctly identified 15% of the time with 5-6 characters revealed, 30% of the time with 8 characters, 60% of the time with 13-15 characters, and 80% of the time with 25-31 characters. Left truncation was the most effective for identifying a specific site within a domain.  So, if you want users to identify a site based on a string, at least 15ish characters are needed for even a majority.  If you want users to identify a subdomain, clip right left side of the URL.  To idenfiy the domain itself, clip the right.

Firefox Would Love to Read Your Mind

By On July 21, 2011 In Addons, data, Firefox, Research, Studies, Test Pilot, usability, User Experience, User Testing With 11 Comments Permanent Link to Firefox Would Love to Read Your MindPermalink

I’d like to highlight the awesome research project that intern Lilian Weng is leading around Firefox’s new tab page.

While our goal is to make users more efficient at their browsing tasks, what makes them more efficient is a question we keep returning to. Most other browsers display links on new tab pages based on frecency. Frecency is a portmanteau which combines frequency and recency. At Mozilla, we use it to refer to sites that users have been to often, recently, or both. It’s how we calculate what should be the first, second, third, etc site that appears when you type a letter into Firefox’s URL bar.

Using frecency to list links on a new tab page seems an obvious design direction, but we want to truly investigate whether another solution would be best for users. So, Lilian is spinning up a brave new study. Once her test is ready, users of Test Pilot, our platform for collecting structured feedback on Firefox, will be asked if they’d like to participate in a new study. If they say yes, they will be randomly assigned one of six new designs on their new, blank Firefox tabs. One of these six designs will be our control group: a blank white tab, just as Firefox users see currently. The other five will look almost identical to each other. They will display a simple 8×8 grid of favicons set on a button which is colored to highlight them based on a color-matching algorithm designed by Margaret Leibovic:

Minimal 8x8 Grid Layout of Site Links

The only variable that will be changing among the five designs is which sites are displayed in this grid. Here’s the five variations we’re testing:

  1. Frecency. A combination of a user’s most frequently and most recently visited sites.
  2. Most recently bookmarked sites. By displaying prominently what a user has recently starred, we effectively turn the new tab page into a read it later list.
  3. Most recently closed sites. This could lead users to treat new tab page as an undo feature, or close tabs in order to temporarily store them in the new tab page as a short-term read it later list.
  4. Sites based on content similarity. Intern Abhinav Sharma is trying out his project, called Predictive Newtabs, which displays sites based on where the user has opened a new tab from. For instance, if the user has been browsing a news site, a new tab would offer other news sites the user has been to.
  5. Sites based on groups of sites frequently visited together. In another part of Abhinav’s Predictive Newtabs experiments, he has designed an algorithm to predict sites to show based on sites users visit in groups. For instance, if every time you get to work you first check the weather and then check stock prices, this new tab would offer you a stock page on a new tab after you checked the weather. If you want to try this experiment out yourself, you can download the Jetpack here.

The above study is still in preparation, and once it goes live I predict that we’ll learn tons of valuable information about how new tab suggestions can positively impact users. Lilian will be collecting data on many aspects of users’ responses to these designs, such as how they effect the breadth of sites users visit, how likely they are to click on each item in the grid, and how long they spend deciding where to navigate. I can’t wait to start pouring over the data that comes back: it’s very new research in an area that has a profound impact on how we use the web.

User Testing in the Wild: Joe’s First Computer Encounter

By On July 6, 2011 In Cafe Testing, data, New Users, Research, User Experience, User Testing With 190 Comments Permanent Link to User Testing in the Wild: Joe’s First Computer EncounterPermalink

This past Friday, I went to Westfield Mall in San Francisco to conduct user tests on how people browse the web, and especially how (or if) they use tabs. This was part of a larger investigation some Mozillians are doing to learn about users’ tab behavior.

The mall is a fantastic place to find user test participants, because the range of technical expertise varies widely. Also, the people I encountered tended to be bored out of their minds, impatiently waiting for their partners to shop or friends to meet them. However, rather than completing all 20 tests I was hoping to, I ended up spending three hours testing a man I’ll call Joe.

I find Joe, a 60-year-old hospital cafeteria employee, in the food court looking suitably bored out of his mind. Joe agrees to do a user test, so I begin by asking my standard demographics questions about his experience with the internet. Joe tells me he’s never used a computer, and my eyes light up. It’s very rare in San Francisco to meet a person who’s not used a computer even once, but such people are amazingly useful. It’s a unique opportunity to see what someone who hasn’t been biased by any prior usage reacts. I ask Joe if I could interview him more extensively, and he agrees.

I decide to first expose Joe to the three major browsers. I begin by pulling up Internet Explorer.

Internet Explorer (as Joe encountered it)

Me: “Joe, let’s pretend you’ve sat down at this computer, and your goal is finding a local restaurant to eat at.”

Joe: “But I don’t know what to do.”

Me: “I know, but I want you to approach this computer like you approach a city you’re not familiar with. I want you to investigate and look around try and figure out how it works. And I want you to talk out loud about what you’re thinking and what you’re trying.”

(I show Joe how to use a mouse. He looks skeptical, but takes it in his hand and stares at the screen.)

Joe: “I don’t know what anything means.”

(Joe reads the text on IE and clicks on “Suggested Sites”)

Me: “Why did you click on that?”

Joe: “I don’t really know what to do, so I thought this would suggest something to me.”

(Joe reads a notification that there are no suggestions because the current site is private)

Joe: “I guess not.”

Joe looks around a bit more, but he’s getting visibly frustrated with IE, so I move on to Firefox.

Firefox (as Joe encountered it)

I give him the same task: find a local restaurant. He stares at the screen for awhile with his hand off the mouse, looking confused. I ask what he’s looking for. “I don’t know, anything that looks like it will help!” he says.  Finally, he reads the Apple context menu at the top of the screen, and his gaze falls on the word Help.

“Help, that’s what I need!” says Joe. He clicks on Help, but looks disappointed at what he sees in the menu.

“None of these can help me,” he says.

Joe is getting frustrated again, so I move on to Chrome and give him the same task.

Chrome (as Joe encountered it)

He proceeds to read all of the words on Chrome’s new tab page, looking for any that may offer guidance. Luckily for Joe, he spies a link to Yelp which is marked San Francisco in Chrome’s new tab page. He clicks it, and, seeing restaurants, declares he’s won.

I want to put Joe through other experiments at this point, but the tests are clearly taxing him. He looks very agitated, and has frequently in the tests declared that he “just doesn’t know,” “should have learned this by now,” and “has no excuse for not taking a class on computers.” No amount of assurance that I was testing software, not him, was calming him down. So, I decide to cut Joe a break. “Alright Joe, you’ve helped me, maybe I can help you.”

Because Joe has mentioned a few times he wants email, I get him a gmail.com email address and show him how to access it at a public computer. We practice logging into Gmail several times, and I end up writing a very explicit list of steps for Joe which includes items like “move mouse cursor to white box.” One of the hardest things to relate to Joe is the idea that you must first click in a text field in order to type.

When I am convinced that Joe understands how to check his email, I want to show him how he can use his new email address. So, I ask him why he had asked for an email address in the first place. I imagine he’ll say he wants to communicate with friends and relatives.

Joe: “I want discounts at Boudin Bakery.”

Me: “Sorry, what?”

Joe: “I want Boudin discounts, but they keep telling me I need email.”

(Joe takes his Boudin Bakery customer appreciation card out of his wallet and shows it to me)

I’m a little confused, but go ahead and register Joe’s Boudin Bakery card with his new email address. I show him the web summary of all the bread he’s bought lately. “Woah!” says Joe.

So, what did I learn from Joe?

  • There is little modern applications do to guide people who have never used a computer. Even when focusing on new users, designers tend to take for granted that users understand basic concepts such as cursors, text boxes, and buttons. And, perhaps, rightfully so – if all software could accommodate people like Joe, it would be little but instructions on how to do each new task. But, Joe was looking for a single point of help in an unfamiliar environment, and he never truly got it – not even in a Help menu
  • No matter their skill level, users will try to make sense of a new situation by leveraging what they know about previous situations. Joe knew nothing about computers, so he focused on the only item he recognized: text.  Icons, buttons, and interface elements Joe ignored completely
  • We shouldn’t assume that new users will inquisitively try and discover how new software works by clicking buttons and trying things out. Joe found using software for the first time to be frightening and only continued at my reassurance and (sometimes) insistence. If he was on his own in an internet cafe, I think he would have given up and left after a minute or so.  Giving visual feedback and help if someone is lost may help people like Joe feel they’re getting somewhere
  • Don’t make too many assumptions about how users will benefit from your technology – they may surprise you!

Research Spinning Up on New Tab Page

By On June 15, 2011 In Customization, Features, Firefox, Mozilla, Next Version, Research, usability, User Experience With 19 Comments Permanent Link to Research Spinning Up on New Tab PagePermalink

Whenever you open a new tab in Firefox, your goal is to navigate somewhere.  To aid your navigation, on this new tab Firefox currently offers you… nothing.  Just a blank page.  100% white, and 100% not useful.

Firefox has been displaying this blank page when users open a new tab for as long as there’s been a new tab.  And, partially, it’s deliberate.  After all, a blank page is guaranteed not to distract you from your current task.  It’s just clean and white, like a canvas, offering no suggestions for the next move and no distractions from it.  Alex Faaborg explains very well in his recent blog post the concerns we have with distracting users and the ways that data overload on a new tab page can be harmful.

This isn’t the case when you open a new tab in other browsers.  Opera was the first to offer a “Speed Dial” with giant thumbnails linking users to their most frequented sites.  Safari’s giant wall-o-televisions offers much the same.  Chrome has played around with different designs, first trying a speed dial like Opera’s and later integrating other content, such as apps.  Internet Explorer, the most unusual of the designs, offers you some options: reopen closed tabs and sessions, start private browsing, or use an “Accelerator,” which usually means do “something with Bing.”

What happens when you open a new tab in different browsers

So, which approach is best for our users?  Would presenting large thumbnail targets to direct people to sites they frequently visit save them time?  Could we present information to make it easier for users to navigate to their next destination?  Can we do so without being distracting and leading users away from the task they had in mind?

We realized that we couldn’t answer these questions without finding out more about our users.  So, a few people at Mozilla are heading up studies to find out how people use tabs and how different designs of new tab page effect how they browse and user the web.

Here’s what’s going down:

1. Quantitative study through Test Pilot on what users do after opening a new tab

Intern Lilian Weng is currently working on a quantitative study within Test Pilot to capture data on what users do after they open a new tab.  This should answer questions surrounding user intention when opening a new tab, and possibly how long users take to perform actions after opening a new tab.

2. A/B test of a new tab page vs. blank new tab

Interns Diyang Tang and Lilian Weng are preparing to do an A/B test using Test Pilot to determine how user behavior differs when presented with a new tab page vs. none.  They are attempting to answer questions such as:

– Does a new tab page slow users down (e.g., by distracting them), or speed them up (e.g., help them find the target site faster)?
– Does a new tab page discourage breadth in visited sites?
– How do users navigate to a website after they open a new tab in each scenario? (location bar, search bar, top sites, bookmarks, history, etc.)
– Are there users who are more mouse-based and some who are more keyboard-based? How does a new tab page affect them?

3. Cafe testing for current Firefox

Diane Loviglio and myself are preparing more qualitative “cafe” tests to gain insight into how people use tabs currently.  We’d like to know why and when users open new tabs in a more contextual perspective than Test Pilot data provides.  Our goal is to find a wide enough range of users that the most common new tab behaviors can be grouped and discussed in a more tractable framework.

4. Testing multiple new tab page designs

Once the research from tests 1-3 is available, variations on new tab pages will be implemented and tried out with real users.  There are multiple testing methods that could be useful here, such as a multivariate testing or even journaling to gain insight into how new tab pages effect behavior of a user over time.

5. Creating a contextual speel dial implementation

Not quite a research project, but intern Abhinav Sharma is designing and implementing an experimental new tab page which uses contextual information about a user’s current browsing session to offer suggestions.  His page makes intelligent recommendations about where you’re likely to go next based on where you’ve been.  The project’s still in alpha, but you can see the code he’s done already for a basic speed dial implementation on his github.

You’ll notice that a lot of this work is being done by our awesome new Summer 2011 interns!  It’s only early June and they’re already rocking hard.

I’ll post what we learn from these studies as results come in.  I predict we’ll gain some insight into user behavior that will inform not only Firefox’s new tab design, but many other features besides!

Making Add-on Updating not Suck

By On February 14, 2011 In Addons, Customization, Firefox, Firefox 4.0, Manager, Mozilla, Next Version, User Experience With 10 Comments Permanent Link to Making Add-on Updating not SuckPermalink

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:

Simplifying and Polishing the Add-ons Manager’s List View

By On January 26, 2011 In Addons, Features, Firefox, Manager, Mozilla, Next Version, Performance, User Experience With 12 Comments Permanent Link to Simplifying and Polishing the Add-ons Manager’s List ViewPermalink

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.

Old vs New Add-ons Manager: Removal of Sorting Bar and 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!

Do you know CSS? Make a Huge Difference in Firefox 4’s Add-ons Manager

By On January 20, 2011 In Add-ons, CSS, Firefox, Mozilla, Next Version, Technologies, usability, User Experience With 14 Comments Permanent Link to Do you know CSS? Make a Huge Difference in Firefox 4’s Add-ons ManagerPermalink

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:

www.donotlick.com

If you need any information or help, comment I’ll get in touch with you!

What’s New in Firefox’s Add-ons Manager

By On December 5, 2010 In Add-ons, Features, Firefox, Firefox 4.0, Mozilla, Next Version, User Experience With 21 Comments Permanent Link to What’s New in Firefox’s Add-ons ManagerPermalink

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!

Changes for Firefox Mobile’s Add-on Manager

By On November 11, 2010 In Firefox, Mobile, Mozilla, Next Version, usability, User Experience With 2 Comments Permanent Link to Changes for Firefox Mobile’s Add-on ManagerPermalink

I’ve been blogging about Firefox’s add-ons manager lately. But what does the add-ons manager look like on Firefox Mobile?

Current Add-ons Manager on Mobile Firefox

Currently, the Android/Maemo add-ons manager in Firefox looks like the image below. At the top are the user’s installed add-ons. Below them, a “Get add-ons” section includes add-on catalog search and five recommended add-ons. Below these is a “Browse all add-ons” button which links to Mozilla’s Mobile Add-on page.

Current Add-on Manager in Firefox Mobile

How Should Mobile Users Learn More About Add-ons?

Giving users information about add-ons has been a continual focus in the non-mobile Firefox add-ons manager redesign. Justin Scott has been leading the design of Firefox’s “Get Add-ons” pane. This pane, which loads within the manager itself, introduces users to add-ons by recommending popular add-ons and promoting the community behind them. The pane also includes a “Learn More” button, which will eventually link to a site which provides add-ons help, information, and even videos about add-ons.

This solution works well on the desktop because of the space available in the add-ons manager and the ease of loading content within Firefox. But would should the mobile solution to add-on information be? And where should that pesky “Learn More” link lead on mobile?

The first option is for “Learn More” to go straight to Mozilla’s page for Mobile Add-ons. However, this site is a portal to our huge catalog of add-ons: it doesn’t provide the simple explanation that “Learn More” implies. Also, it forces the user to leave the add-ons manager and load a media-dense page. Both of these could negatively surprise users.

A second option is for “Learn More” to expand the current “What are add-ons” section within the column to provide more detailed information within the add-ons manager. This has the benefit of consistency with the current mobile UI, where some sections already expand to show more information. It also doesn’t require users to leave the add-ons manager. However, this design also has a few drawbacks. The page height becomes much taller, requiring more scrolling to go between the user’s add-ons and the recommended add-ons. Also, considering the “What are add-ons?” section already expands with a click, now there would either be three levels of zoom or a large surprise the first click.

A third option would be to create another page, within Mobile Firefox’s preferences, that provides an explanation of add-ons. This is better than an external page, because it would not require a lengthy load time while presenting the most relevant information. It also may provide less of a surprise than the expanding in line option. But, it would require users to leave the screen they are on, and would be inconsistent with how the UI works now.

Three Possibilities for Where "Learn More" Link could lead

A Simpler Design

After considering these options and their drawbacks, I went back and thought about exactly what purpose the explanation of add-ons is meant to provide. In Firefox, this section’s purpose is to tell users who have never encountered add-ons what they are and why they are useful. In fact, as soon as the user installs a few add-ons in Firefox, they never see that explanation again. There’s no need for the message to be persistent, as it is currently in Mobile Firefox. In fact, as soon as a user installs an add-on, they no longer need the explanation. Making the message dismissible is the first step towards a better Mobile Design.

So, how can users gain more information about add-ons? And what information would they want?

Assuming that the “What are add-ons” snippet gives a good summary of what add-ons are, and add-ons themselves explain what they do in their descriptions, there simply isn’t enough information left to tell mobile users that justifies a separate explanation link. Additionally, on Mobile Firefox, there are less than 100 add-ons currently available. I simply can’t think of information about these add-ons that would be important enough to users to include a link and a separate page about what add-ons are.

So, the design I’m recommending keeps the explanation of add-ons short but prominent in the add-ons manager. It’s dismissible, but also disappears automatically once the user installs one or more add-ons. If the user wants to browse Mozilla’s Mobile site, the “Browse all add-ons” link at the bottom of the list will direct them there. With such limited screen space, keeping the interface simple should provide the best experience.

Proposed Design for Mobile Firefox's Add-ons Manager

Add-ons Manager Design Update

By On November 4, 2010 In Add-ons, Bugzilla, Firefox, Next Version, usability, User Experience With 15 Comments Permanent Link to Add-ons Manager Design UpdatePermalink

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

← Older Entries
Newer Entries →