June 15, 2011
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.”
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:
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.
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 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?
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.
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.
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!
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: