MozCamp EU 2012: Mobilize Mozilla

Admittedly, a few days have passed since the September 8-9th 2012 MozCamp EU in Warsaw. But, I wanted to say a few words about the incredible experience.

I was so excited to attend this MozCamp in particular. Eastern Europe, and Poland especially, have some of the oldest and strongest Mozilla communities, in existence for well over a decade.  And, Poland is continually at the top of our browser marketshare charts, with roughly half the population using Firefox. Having never been to Poland, I’ve always seen these numbers and wondered about the people and stories behind them.

I’d met many Mozilla Poland community members over the years and knew they were passionate for the open web – people like Marcin Jagodziński, who first translated Firefox into Polish, and Marek Wawoczny, who maintains Mozilla Poland’s active community site.  But, meeting these contributors together as a vibrant and enthusiastic community sheds light on Eastern Europe’s passion for open source. The communities here are healthy and growing.  They are directly involved in education, many regularly speaking at university campuses to get students excited about innovating in the open.  It was incredible to hear about the specific challenges that each community faces in their regions and the creative ways they step up to meet them, from hacking at meet.js events in Krakow to the Free Hugs from Firefox in Paris.

And, as at all Mozilla events, the talks and demos were incredible. As a gamer, I thought one of the most exciting projects was BananaBread, a fully 3D FPS built using only HTML5 by Anant Narayanan, Alon Zakai, and others.

Wesley Johnston showed off some pretty exciting stuff coming up in Firefox Android, like smooth-as-butter scrolling and reader mode, which turns your ugly mobile site into something that will make typographers cream their pants.

Paul Rouget updated us on the latest developer tools hotness, including including tilt, which lets you visualize a site’s DOM tree in 3D, and the new command line.

Patryk Adamczyk gave a great run-through on the design principles that have guided the creation of the beautiful Firefox OS, including the “personality types” which guided its sound design (good news for anyone who owns a business suit and a skateboard).

Tim Terriberry and Anant Naryanana (yes, again!) gave an awesome demo of WebRTC working in the browser – live with a peer-to-peer video call!

I gave a talk on how to user test mobile apps (and other projects). It was a great experience, and people brought some excellent ideas and questions! I’ll blog more about this talk later.

Of course, I could never do justice to all the great talks, collaboration, and hacking that went on over two very short days, but thanks to everyone who made this MozCamp so awesome. Meeting the Mozilla community always leaves me feeling humbled to work on the Project, inspired by what’s coming up, and (in this case) hungover on buffalo vodka.

Advertisement

Update on Firefox 13’s Home and New Tab Redesign

(Note: the following has been cross-posted to Mozilla UX)

Two Firefox features getting a redesign in Firefox 13 (currently in beta) are the Home Tab and New Tab. Home Tab can be viewed by clicking house icon in Firefox or by typing “about:home” into your URL bar. New Tab appears when you click the “+” at the end of your tab strip.

Firefox 13 New Tab Page

Firefox 13 Home Tab Page (launch targets emphasized)

Firefox’s Home Tab and New Tab have, until now, had fairly basic pages. In Firefox 12, Home Tab had a large search bar, a “snippet” which Mozilla uses to display messages to users, and little else. The main reason the search bar is on Home Tab is because many users click the Home button to initiate a search, either unaware of the toolbar search box or preferring not to use it. The snippet allows Mozilla to give a message to users, such as last October when it asked users in the United States to contact their representatives when the anti-internet-freedom bill SOPA was being heard in the House of Representatives. Such messages can be important while not being urgent enough to disrupt users with a notification.

New Tab, for most of Firefox’s history, has been completely blank. This was done deliberately to offer users a clean, fresh “sheet” to begin a new browsing task. However, a blank tab may not be distracting, but it’s also not useful.

Surely, we thought, we can present a more helpful design than a blank page! Using Mozilla Test Pilot, we began to research how Firefox users use New Tabs. What we learned is that each day, the average Firefox user creates 11 New Tabs, loads 7 pages from a New Tab, and visits two unique domains from a New Tab. The average New Tab loads two pages before the user closes or leaves it.

What this tells us is that users create many New Tabs, but they’re very likely from those to return to a limited number of their most-visited websites. So, we began to experiment with giving users quick access on New Tab to the websites they visit most frequently.

What you’ll see on the New Tab page of Firefox 13 are your most-visited sites displayed with large thumbnails, reducing the time it takes to type or navigate to these pages. This data comes directly from your browsing history: it’s the same information that helps Firefox’s Awesome Bar give suggestions when you type. Or, if you want to go somewhere new, the URL bar is still targeted when you type on a New Tab page. If you want to hide your top sites – permanently or temporarily – a grid icon in the top right wipes the new tab screen to blank.

Mozilla Home is getting a redesign, too! While still keeping the prominent search bar and snippet, the graphic style is softer, the text is more readable, and launch targets at the bottom allow you to quickly access areas such as Bookmarks, Applications, and previous Firefox sessions.

Both Home and New Tab are being improved as part of our longterm vision of making Firefox more powerful, engaging, and beautiful. Over the next few releases, more design improvements will be made towards this goal. For now, please try out Firefox’s new Home and New Tab pages in Firefox 13 Beta and tell us that you think!

Enabling Real-Time Communication on the Web Platform

Mozilla’s manifesto describes the internet as an integral part of modern life and a key component in communication. However, communication on the web has far to go before it’s as rich as face-to-face communication. Real-time video communication on the web should be easy, rich, and readily available to developers in a way that proprietary formats can’t be.

That’s why a new project is spinning up at Mozilla called WebRTC (Real-Time Communication). WebRTC will allow developers to use the web platform to include video and audio conferencing as part of their websites and applications, both mobile and on the desktop. In its first phase, WebRTC will make webcam feeds a primary object in the browser, allowing sites to create rich interactions such as video calling and conferencing. In later phases, WebRTC will allow interactions like co-browsing, in which users can share their screen with a friend.

Privacy and Security

Privacy and security are major concern in enabling open video communication on the web. A face and voice are two of the most identifiable kinds of shareable data, and keeping users in absolute control of who has access to them is vital. As the IETF states in its WebRTC draft document, the ability for users to control access to their webcam, be able to cancel communication at any time, and not be eavesdropped upon are essential.

Some of the challenges we’ll face are in giving users the most accurate information possible about the site and caller who are requesting access to their webcam. Most requests for webcam access will simply be from a trusted site itself, but a malicious site could potentially try to gain access by embedding its call request within a trusted site. In this paper, Eric Rescorla outlines how potential “ad-hoc” calling attacks could come from ads in iFrames embedded within trusted sites.  Many other potential attacks need to be dealt with.  For instance, because WebRTC would be controlled by a web server rather than conventional real-time systems, web browsers might expose JavaScript APIs which allow a server to place a call. If access to such an API were unrestricted, sites could “bug” a user’s computer and capture video camera activity (Rescorla).

Even a trusted site could be compromised, both during a call or after. And, since the sites themselves would control and display the UI of the call itself, Firefox needs to give the user both constant indication that they are in a call and the ability to disconnect at any time.

User Interface

However, guarding against threats only goes so far towards keeping users in control of their webcam communication. Clear messaging, useful tools, and sensible defaults need to be in place for video conferencing to safely take root in the browser.

The first phase of enabling WebRTC will allow the most basic use case: giving a site access to a user’s webcam and microphone. The browser already serves as a mediator for other user data, such as location and access to cookies. Firefox usually asks for permissions using a door hanger notification. Door hangers stem from the URL bar to show the site is asking for a permission, and it extends past the content area to show that Firefox is the mediator of the permission request. Using a door hanger notification for WebRTC is both consistent within Firefox and correctly conveys visually that the site has requested access, and Firefox is asking the user for that permission.

Usually, these door hangers simply ask the user for a permission, and in a click the user can give it. However, webcam access requires a secondary stage: showing a preview of the webcam feed. This approach has three benefits:

1. It gives users the ability to make sure their webcam and microphone work correctly
2. If users had casually or accidentally accepted the webcam permission, nothing makes people more aware of what they’re about to transmit like showing them their own grubby mug
3. It gives users the ability to fix their hair/put on a shirt/remove incriminating items from background before beginning call

In some ways, it’s unfortunate to ask users to pass through two dialogs to give webcam feed rather than one. After all, in most cases the site itself will be providing all necessary UI, and perhaps even a video preview before a call is initiated. So, this could all be redundant in many cases.  However, we cannot predict what purpose a site may be requesting webcam feed for, nor what UI will be in place for the user on that page. Even with all our efforts against security threats, any request for webcam access must be treated as potentially malicious.

Once a user has given a site access to their webcam and is likely engaging in face-to-face communication, that interaction should be given a heightened level of priority within the browser. For a user to lose that tab or forget they are broadcasting could range from mildly embarrassing to, well, use your imagination. If a user is actively sharing their webcam feed, they should be able to jump to the tab where data’s being shared or simply cut their webcam feed from anywhere within Firefox. This will require at the very least a toolbar-level Firefox control that appears once a user’s actively sharing.

Designing and implementing a new API is always a complex process.  If you’re interested in reading more or contributing to this project, here are some resources:

• Mozilla WebRTC feature page
• Mozilla notes on first WebRTC security discussion
• The IETF’s draft document on WebRTC Use-cases and Requirements
• Robert O’Callahan MediaStream Processing API Proposal
• Mozilla’s RTC API Proposal on GitHub and on Web Activities, a service discovery mechanism and light-weight RPC system between web apps and browsers
• Eric Rescorla’s paper on WebRTC Security Considerations, and his corresponding presentation slides (PDF)
• Cullen Jennings’s PDF slides on WebRTC API Design Questions
• W3C WebRTC meeting notes, including a PDF of Mozilla’s implementation status

On Life

“No one wants to die. Even people who want to go to heaven don’t want to die to get there. And yet death is the destination we all share. No one has ever escaped it. And that is as it should be, because Death is very likely the single best invention of Life. It is Life’s change agent. It clears out the old to make way for the new. Right now the new is you, but someday not too long from now, you will gradually become the old and be cleared away. Sorry to be so dramatic, but it is quite true.

Your time is limited, so don’t waste it living someone else’s life. Don’t be trapped by dogma — which is living with the results of other people’s thinking. Don’t let the noise of others’ opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary.”

Steve Jobs
February 24, 1955 – October 5, 2011

How People Use New Tabs

As the web evolves, so does the way people interact with the web. Firefox’s user experience and research teams have been eager to learn about our users’ browsing habits so that we can better design for our users.  Lately, Mozillians like Lilian Weng and Jono X have been running some fascinating studies using Test Pilot to determine how, when, and why Firefox users open new tabs.  I wanted to note a few key takeaways from their recent study that give us a glimpse into how our users browse (full studies are linked at the bottom of this post).

A caveat is that these results – as with all Test Pilot studies – are gathered using anonymized data submitted by users who have signed up to participate in Test Pilot. Thus, the Test Pilot users data tends to skew slightly towards the technical and early-adopter crowd.

How are people currently using new tabs?

Each day, the average Firefox user creates 11 new tabs, loads 7 pages from a new tab, and visits 2 unique domains from a new tab.^[1] The average new tab loads two pages before the user closes or leaves it.^[2]

Once users have a new tab page open, about half of the time (53%) they navigate to a new page using their mouse, and about half of the time (47%) they use the keyboard.^[1]

Here’s a breakdown of what actions users take once they’ve opened a new tab:

As you can see above, the URL bar was the most-used item on a new tab page, with 53% of use actions originating there. The search bar only accounted for 27% of user actions. Even though by default it’s not even enabled in Firefox, 16% of new tab page actions were clicking on a URL in the bookmark bar. History and bookmarks menus were both used less than 5% of the time.

In this study, 17.4% of the domains recorded accounted for 80% of the page views for all participants. You might think that the more active a user is, the number of unique domains they’d visit would follow the same ratio. However, this study found that the more sites a user visited online, they more often they would visit the same 20% of domains. Turns out, the most active internet users are even more loyal to a few choice domains than their less active counterparts.^[2]

^[1]Quick report on new tab study, by Lilian Weng

^[2]Test Pilot New Tab Study Results, by Mozilla Research Team

Name Change (to Protect the Innocent)

Just some housekeeping: My name’s changed from Jennifer Lynn Boriss to Jennifer Lynn Morrow. I’ll still be using “Boriss” as a nickname, but only to friends rather than to everyone.

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

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 96² pixels, 60% of test subjects had identified it.  80% of test subjects identified sites by 144² pixels, and by 304² 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 96² 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 64² pixels and smaller. From 64² to 96² pixels, color, layout, images, and text were equally important. Above 100² 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

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

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’a 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

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:

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!