If you’re interested in web browser user experience, take a look at Browser Bits, my little tumblelog/mini-blog thingy all about browser UX.

If you want a Cole’s Notes version, just check out the summary.

I have a problem with tabs. On one hand, I find them amazingly useful, and don’t think I could ever go back to using a browser that doesn’t support tabs. But on the other hand, my browser usually looks like the one above. I have so many tabs open that the tab bar is scrolling. The tab titles are too small to read. I have some pages open in duplicate tabs. It’s generally just a big mess.

When I spoke to my friends and colleagues, I realized that I wasn’t the only one who has this problem. In order to fix the problem, I think it’s important that we understand how and why people use tabs today.

I did some research, and although I could find several studies that had looked at web browsing behaviour (e.g., Catledge & Pitkow, Cockburn et al., and Obendorf et al.), I couldn’t find very much data about how people use tabs. So I decided to do a study myself.

Study Details

The study was conducted with 21 participants over the course of approximately two weeks each. In our call for participation, we asked for “Mozilla Firefox users who often use multiple tabs or windows.” You’ll notice that I said “tabs OR windows”, and up to this point I haven’t mentioned anything about windows.

In many ways, tabs and windows serve the same purposes. You can open up links in multiple windows, and switch between them in any order, just like you can with tabs. Although we were most interested in how people use tabs, we felt that there was also a benefit to studying people who use multiple windows. However, all but one of our participants showed a strong preference for tabs.

In this study, we gathered both quantitative as well as qualitative data. The quantitative data was gathered through a Firefox extension I wrote called tlogger. Tlogger records click-stream logs–essentially, all network events, along with everything interesting the user does: clicking links, using the back button, opening, closing, and switching tabs, etc. In order to get a natural representation of their browsing behaviour, we felt that it was important that the actual URLs they visited were not visible to us. They were anonymized so that we could tell whether two URLs were from the same site or different sites, but we couldn’t see what the sites were.

The qualitative data was gathered in two ways. First, tlogger would periodically prompt the participants to record a short diary entry, explaining what they are doing, what tabs they have open, and why they have them open. Second, we interviewed each participant 2-4 times over the course of the study. In these interviews, we asked some prepared questions, and also just generally talked to the participants about how they use tabs. Also, if we noticed any interesting comments in their diary entries, we also asked them for further detail on those.

Results

Rather than presenting the quantitative and qualitative results separately, we’ll take a more holistic approach, and look at the results from three angles. First, we’ll compare our participants’ usage of tabs to their usage of windows, and show that all but one of them showed a strong preference for tabs. We’ll also discuss why they preferred tabs. Second, we’ll take a closer look at the tab usage of our participants, and talk about a subset who used tabs much more frequently than the others–the so-called “tab power users.” We’ll talk about the reasons our participants gave us for using tabs, and talk about one key difference between the tab power users and the other participants. Finally, we’ll take a look at the use of tabs as a revisitation mechanism–as a way of getting back to pages that have previously been seen. Tabs offer a kind of revisitation that is similar to, but different from, the browser’s conventional revisitation mechanisms (the back button, bookmarks, and the history).

Before we get into the results, let’s talk about how we measured tab and window usage. We could take a time-based approach, and look at the number of tabs created per hour. The problem with this is that it’s difficult to tell exactly when a person is using their browser, versus when it is just sitting idle.

Instead, our unit of measure is a navigation action. A navigation action is considered to be any time the URL changes. We measure the tab creation rate as the number of tabs created per navigation action. The window creation rate is defined similarly. I should note that we only count additional tabs and windows that are created. We don’t count the first window that is opened when the browser starts up, nor the first tab that is created in a window.

Ok, with that out of the way–let’s take a look at tab and window usage.

As you can see, most participants used tabs a lot more than they used windows. Only one participant–Participant 10–used windows more than tabs. But let’s take a closer look at the window usage.

There are several ways that a window can be created. Sometimes, it’s purposely by the user, such as by hitting Ctrl-N or right-clicking on a link and selecting “Open Link in New Window”. Other times, the web site itself causes the new window to be opened.

So what if we only look at windows that were created intentionally by the user?

When we do that, window usage drops off pretty dramatically–only three participants show any real window usage to speak of. Now, to be fair, let’s do the same with tab usage.

We see a pretty substantial drop-off for some users, but overall, there’s still a lot of intentional tab usage. Participant 10 still used more windows than tabs, but only slightly. Everyone else used a lot more tabs than windows. *Despite the fact that our call for participation asked for people who either used multiple tabs or multiple windows, what we got was mostly people who preferred to use tabs.

Advantages of Tabs Over Windows

We asked our participants why they preferred to use tabs instead of windows. The most commonly cited reasons were that tabs are cleaner, less cluttered, or more organized than using multiple windows (cited by 10/21 participants) and that tabs are easier to access and switch between (mentioned by 7 participants).

Some other reasons that were only mentioned by a few participants:

Tab Usage

Now that we’ve established that our participants used tabs much more than they used windows, the rest of our results will focus on their tab usage. In the following chart, the tab creation rates of our participants are plotted as a histogram:

You can see that we have a bi-modal distribution. We’ve got 13 participants clustered around the 0.04 mark, i.e. four tabs created per 100 navigation actions. And then we’ve got another 8 participants loosely clustered around 0.14, or 14 tabs per 100 navigation actions. We called this second group of people the “tab power users”. They created about 3 times as many tabs as the others.

Although I didn’t mention it in my talk, if you’re interested in a closer look at how many tabs people used, you should take my earlier post: How many tabs do people use? (Now with real data!).

Why Use Tabs?

In the interviews, we asked our participants why they used tabs. In what situations are they useful? What are the advantages of using tabs?

The most commonly cited reason (by 17/21 participants) was reminding:

The second most commonly cited reason (by 14/21 participants) was the ability to open links in the background.

For example, 10 participants mentioned that on a search results page, they like to open several of the results in new tabs, and then go look at them. Some people mentioned doing something similar on news sites like Google News or Digg–they’d scan through the list of articles, open any interesting articles in new tabs, and then go and read the articles.

One interesting thing that we noticed was that several people mentioned that opening links in a new tab had become habitual:

In fact, it turned out that every single one of the tab power users, and none of the other users, reported that opening links in a new tab had become habitual. And this was something that we learned after we identified the tab power users. So this is likely a key difference between the tab power users and the other participants.

Why else did people use tabs? Here are some of the other reasons people mentioned:

There’s one thing that all of these reasons have in common: they are all about revisitation.

Tabs as Revisitation

Tabs offer a kind of revisitation that is different from the conventional revisitation mechanisms of the browser (the back button, bookmarks, and the history). The main difference is that when you switch back to a tab, the page is not reloaded.

In this chart, we compare our participants’ tab-based revisitation to their use of the conventional revisitation mechanisms:

The green bars represent tab switches (as a percentage of navigation actions). The dark green are tab switch revisitations–switching back to tab that they’ve already been on. The light green bars represent the first time a tab is switched to.

The red and the pink bars represent conventional revisitation, with back button use in red. The reason we’ve focused on back button use is that previous studies (e.g., Catledge & Pitkow, Cockburn et al., and Obendorf et al.) have consistently shown that the back button is the most frequently used revisitation mechanism, and is the second most frequently used navigation mechanism in the browser, after link clicking.

We can see from this chart that 16 of our 21 participants used tabs for revisitation more often than the back button. So, clearly tabs are often used for revisitation reasons. But also, for frequent tabs users, tab switching is the second most frequent thing they do in the browser.

Advantages of Tabs

We asked our participants why they would use tabs for revisitation, instead of using the back button. Here are the top four reasons:

• 7 people said tabs are quicker or more efficient to use than the back button
• 6 people said that tabs are generally better, easier or more convenient
• 6 people said they are more predictable. As one person said: “You might have to click the back button like six times to get back to where you were. Or maybe never even find it again [...] whereas the tab just kind of stays at the originating page.”
• 6 people said they liked that tabs leave the page “as is”. If you’ve typed data into a form, or scrolled to the bottom of the page, it will be exactly as you left it when you switch back. This is not always true with the back button.

Summary

To summarize our results:

• Despite our call for participation asking for Firefox users who either use multiple windows or multiple tabs, 20 of our 21 participants showed a strong preference for tabs.
• We talked about why our participants preferred to use tabs rather than windows. The most cited reasons were:
  • Tabs are cleaner, less cluttered, or more organized than using multiple windows (mentioned by 10/21 participants)
  • Tabs are easier to access and switch between (mentioned by 7/21)
• We took a closer look at the tab usage of our participants, and talked about a subset of participants who used tabs about 3x more than the others. We called these people “tab power users”.
• We explained some of the reasons our participants cited for using tabs:
  • Reminding (mentioned by 17/21). Leaving a tab open serves as a reminder that further action is required.
  • Opening links in new tabs (14/21). This was done in order to open several links at once, or to open a link and continue reading the current page.
  • Switching between several tasks (11/21)
  • Going back and forth between two pages (10/21)
  • Short-term bookmarks (4/21)
  • Frequently-used pages (4/21)
• We identified one key difference that separated the tab power users from the others–the tab power users habitually opened links in new tabs.
• We showed that tabs are often used for revisitation, and that, for ¾ of our participants, tab-based revisitation was used more often than the back button, making tab switching the second most frequent thing they do in the browser.
• Finally, we talked about the reasons our participants said they preferred to use tabs rather than the back button. They were:
  • Tabs are quicker or more efficient (7/21)
  • Tabs are better, easier, or more convenient (6/21)
  • Tabs are more predictable than the back button (6/21), because you don’t always know how many times you’ll have to hit the back button to get back to your page.
  • Tabs leave the page “as is” (6/21), including any data entered into a form, and the scroll state of the page. This is not always true with the back button.

Implications for Design

Now that we have this data, what can the browser designers take away from it? How can Mozilla (as well as Microsoft, Google, and Apple) use this to improve their browsers?

• We identified several common usage patterns for tabs, and it would be interesting for browsers to include explicit support for these. It would be great if I didn’t have to keep 10 tabs open to remind me of various things.
• We showed that for people who often use tabs, tab switching is a very important activity, and I’d love to see some thought put into how we could optimize for that.
• Since tabs are often used for revisitation, it would be nice to add better support for tab-based revisitation, and better integration with the conventional revisitation mechanisms of the browser. For example, when I open a link in a new tab, the back button is disabled in the new tab. Why not inherit the back button stack from the previous tab, or maybe even just close the new tab and take me back to my old one?
• We mentioned several advantages of tab-based revisitation over using the back button. These point to ways that the back button could be improved, possibly allowing us to use fewer tabs. For example, I’d love it if I could feel confident that the back button would always save form data and the scroll position of the page.

If you’d like more detail on this study, please take a look at the full paper from CHI 2010. If you have any questions, feel free to send an email to pat at the domain dubroy.com.

Also, if you’re interested in doing research with Firefox, I’d encourage you to take a look at tlogger, the extension I wrote for this study. It’s already been used in two other projects: the TabViz project, and the Multitasking bar paper presented at CHI 2010. I’m happy to answer any questions about the code and how the extension works.

Of course, the iPad browser is Safari. And from what I’ve seen and heard, it’s more like the iPhone than the desktop version. John Gruber reported that “even though the screen offers the same pixel count as what was once the standard size for a laptop display, iPad Safari renders pages like iPhone Safari. The web surfing experience is all about zooming and panning.”

I’ve had an iPhone for a while now, and done my fair share of browsing in Safari. Since I’m interested in web browser user interfaces (c.f. Browser Bits, my blog on web browser UX), I thought it would be interesting to take a closer look at the little details that make for such a great browsing experience on the iPhone. By examining the most widely-used (and arguably best) mobile web browser, we can better understand what it takes to make a great mobile web browsing experience, and how we might do even better. But also, looking at the design choices made under the iPhone’s contraints can help us break free from our assumptions of what a browser interfaces should be.

Browser Controls

The first thing I noticed is that despite the restricted screen resolution of the iPhone (320×480) they’ve still managed to fit in most of the browser controls that we’re used to seeing.

Along the top, we’ve got the page title, the URL bar, and the search bar. It’s interesting that they chose to keep the two bars separate, rather than combine them into one as Google Chrome does. They probably made this choice in order to stay consistent with the desktop version of Safari.

In fact, almost everything about iPhone Safari is strongly consistent with the desktop version. Page loading progress is shown in the URL bar, and the refresh and stop buttons appear at the far right of it. The controls along the bottom — the back and forward buttons, the bookmark button, and the “+” button — all work almost exactly the same. One small difference is that the “+” button, instead than just being used to add a bookmark, serves three purposes: “Add Bookmark”, “Add to Home Screen”, and (somewhat oddly) “Mail Link to this Page”. The last function seems a bit out of place on this menu, but without adding a button, I’m not sure where it would make more sense.

One of the clever design choices Apple made is that top control bar is actually positioned inside the scrollable content area, so that when you scroll down, it disappears off the screen. The initial content area is 356px high, and the control bar takes up another 60px, so the result is 17% more vertical pixels for the page contents.

The bottom control bar, on the other hand, is static. I’m curious to know if the choice to put those controls on the bottom was based on any empirical usage data, because it’s not obvious that they would be used more often than the controls on the top [1].

Another thing to note is how small the URL bar actually is. In most desktop browsers, the URL bar is massive, taking up most of the window width. The iPhone browser proves that’s mostly unnecessary — I’ve rarely needed to see more than the ~20 characters it shows by default. However, the URL bar and the search bar are only that size when they don’t have focus. When you tap on one of them, it expands to fill the full width of the screen.

One weakness of the smaller URL bar is that it makes it much harder for the user to detect a phishing attempt: on many sites, the entire domain isn’t visible. Tapping on the URL bar is useless because it shows the end of the URL, and scrolling it to the beginning is complex and slow.

The extra width afforded when typing into the URL and search bars is nice, but I’ve found that it can lead to mode errors. When I want to go to a new page, sometimes I tap on the wrong box, and quickly hit the “X” to clear its contents. Once the box fills the screen, there is little indication which box you are typing in. The differences are very subtle: the search bar has fully semi-circular ends, whereas the URL bar is a rectangle with rounded corners. But what usually happens to me is that I type the first word of a search query, and then freeze when I realize that there’s no space bar on the keyboard.

If you’ve never used on iPhone, that probably requires a bit of explanation. On the iPhone, the on-screen keyboard changes depending on what kind of text field you are typing in. I’ll explain more in the next section.

Typing

Text entry on an iPhone is done using a soft keyboard that takes up the lower half of the screen. In most apps, the keyboard is in the configuration shown below left (notice the space bar). Symbols (like the ones you’d need when typing a URL) can be accessed by tapping the button in the bottom left corner. This is the same configuration used when you’re typing in the search bar. But when you’re typing in the URL bar, the keyboard is different, as shown on the right. The space bar is replaced with keys you’re more likely to need when typing a URL.

An additional hidden feature is that you can hold down the “.com” key to access “.net”, “.edu”, and “.org”. Very handy indeed.

One of the coolest things about this feature is that it doesn’t just work this way in the URL bar and the search bar. The keyboard will also reconfigure on any web page that uses one of the new HTML5 input types (like “url” or “email”). In “email” configuration, for example, the space bar is extra small, and buttons are added for “@” and “.com”. (For more information on this, see Mark Pilgrim’s very informative article on forms in HTML5.)

Ok, so most people probably don’t spend that much time thinking about the keyboard. The actual browsing experience in iPhone Safari consists of three main things: tapping on links, scrolling around the page, and zooming in to content.

Zooming

Before the iPhone, it was hard to use a mobile browser to view a site that wasn’t specially designed for a smaller screen. iPhone Safari made things much better by providing two ways of easily zooming in to view the page contents.

One way of zooming is to use the multi-touch pinch/anti-pinch gestures. Contrary to popular belief, this was not invented by Apple. In fact, Myron Krueger demonstrated this technique around the time that the original Macintosh was first released. That said, the mere existence of pinch zoom is not enough; the devil is in the details, and that’s exactly where Apple excels.

When you put two fingers on the screen and spread them apart, the view zooms in on a point located between your fingers. This is important, because it helps maintain the real-world “stretching” metaphor. An alternative implementation would have been to just zoom in on the middle of the screen. I’ve used interfaces like that — it’s very frustrating.

Another detail that Apple got right is the speed of the zoom. To be absolutely true to the real-world metaphor, the content underneath each finger should remain static relative to the finger. That is, if you put one finger down on the top right corner of an image, and the other on the bottom left corner, and then spread your fingers apart, they would still be over the corners of the image. In iPhone Safari, the zoom is actually slightly slower than this, meaning that you have to move your fingers a little bit further apart to achieve the same level of zoom — but it feels just right.

The second method of zooming in iPhone Safari is to double-tap on any content to make it fill the width of the screen. This is straightforward with an image, but not so much with text. The most common use case is to double-tap on a column of text, and the browser will zoom so that the column fills the width of the screen. In general, this works exceedingly well, but in some cases, it will zoom to the width of a particular element that is smaller that the column. I’ve seen this problem on sites that have threaded comments, such as Hacker News.

On the subject of zooming: many web sites have an iPhone-specific version that uses the the meta “viewport” tag to ensure that the width of the page matches the width of the device. This tag (introduced by Apple for iPhone Safari) has an option named “user-scalable” which allows the developer to control whether the user can zoom in to the page or not. The default is “yes”, but unfortunately many web sites set it to “no”. This can be frustrating on sites like Flickr and DeviantART, where you often do want to zoom in to get a better look at a picture.

Scrolling

The more you zoom in, the more you’ll have to scroll. On the iPhone, you do this using direct manipulation — just swipe in any direction to pull the page in that direction. Note that this is the opposite of how scrolling works on a trackpad. On a MacBook, swiping down with two fingers will move the viewport down, whereas on the iPhone, swiping down moves the viewport up.

When zoomed in, Safari makes it easy to scroll in one direction only. That is, a swipe that is not quite vertical will result in a perfectly vertical scroll with no horizontal movement. This way, when you’re scrolling down a column of text, you don’t have to re-adjust the horizontal position every time you scroll. In my opinion, it’s still a bit too easy to go “off the rails” when attempting to scroll vertically. However, it’s a delicate tradeoff, because you want horizontal scrolling to remain responsive.

When you are in the midst of scrolling, you see bars along on the side of the screen that look very much like a scroll bar in a desktop application. This goes for the entire iPhone, not just Safari. These “scroll bars”, however, are completely read-only. They are just there to help you get a sense of where you are on the page. When you stop scrolling, they disappear. It’s good that they don’t take up any screen real estate, but frustrating when you are on a really long web page and want to scroll all the way down to the bottom. This would be even more of a problem for scrolling back to the top of the page, except that there is hidden feature on the iPhone for this purpose. Tapping the status bar at the top of the screen scrolls the main viewport back to the top. Very useful, but very hard to discover. Well, unless you read the documentation.

When reading said documentation, I actually discovered another hidden feature. To scroll within a frame or a textarea on a web page, you can swipe with two fingers. However, on my iPhone 3GS running OS 3.1.2, this doesn’t actually seem to work with either textareas or iframes.

Just like other iPhone apps, Safari has “kinetic scrolling” — swiping with your finger gives the page momentum, and it will continue to scroll after you’ve lifted your finger off the screen. And when you hit the bottom or the top, it will scroll a bit past it before snapping back. It’s a nice, natural, and cute way of indicating that you’ve hit the end of the page.

For some reason though, web pages just don’t scroll the same as other controls on the iPhone. They seem to have less momentum, or more friction. John Gruber has written about this before, going as far as to say that it’s one of the main ways that iPhone web apps fall short of native apps.

Tapping Links

Besides scrolling, clicking on links is the most common thing people do in a web browser [2]. In iPhone Safari, following a link is as simple as tapping on it. It seems pretty straightforward and uninteresting, but given the size of a human fingertip and the small size of web content on the iPhone’s screen, it’s not as easy as it might seem. Given that most web sites are designed for use with a pixel-perfect input device (the mouse), it’s actually pretty amazing that about 95% of the time, I can manage to follow the correct link in iPhone Safari. I’d guess that the hardware is the major factor here, but it still feels like there is some kind of software heuristic at work. It’s easy to take this for granted, but given my experience with various multi-touch interfaces, it’s actually a remarkable achievement that tapping links on an iPhone is as precise as it is.

Another thing to notice is that scrolling and zooming are very rarely mistaken for a link tap. This comes at a cost of responsiveness — there is a slight delay after you tap a link, as it waits to see if another tap is coming. But the delay is subtle enough that it’s hardly noticeable.

Multiple Pages

iPhone Safari does not support tabs. This isn’t surprising, due to the screen and resource limitations of the iPhone. Instead, it has the concept of “pages”, which are somewhat like multiple windows. When you click a link that would open in a new tab or window (such as in GMail), or open a URL from another iPhone app, it will launch in a new page. When you click on the “pages” button in the lower right, you can flip through all the pages that you have open. From this view, you can close pages, or create a new page.

When a link is opening in a new page, there is a nice little animation that makes it clear that you are going to a new page that is to the right of the current one. Without it, you might become confused and wonder why the back button doesn’t work anymore. This actually happens to me sometimes when using desktop browsers, and I’ve heard other people report having the same problem.

There is a limit of 8 pages that can be open at any time. I suppose this is to conserve resources, and to prevent the list from getting unwieldy. If you have 8 pages open and a link needs to be opened in a new page, you will lose the first one in the list. However, this has never actually happened to me.

Although they are called pages, they behave very much like tabs. They have a close button on the top left, and just like with tabs, when you close a page, the one to its right takes the focus. This is another example of how strongly Apple cares about keeping consistent with the desktop user experience.

The key feature of tabs that is not supported by iPhone Safari’s “pages” is the ability to open a link in the background. You can open a link in a new page by touching and holding the link then selecting “Open in New Page”, but this will immediately switch focus to the new page, rather than loading it in the background.

What’s Missing

Well, when you’re trying to put a fully-functional web browser on a mobile device, you can’t do everything. Here are some of the key things iPhone Safari is missing:

Flash

One of most discussed (and hotly debated) things about iPhone Safari is its lack of Flash support. It was never entirely clear whether this was a technical decision or a political one; that is, until Wednesday when we learned that the iPad won’t support Flash either. From a user experience point of view, this has its pros and its cons, but I think it’s a good thing for the web.

Find-in-page

A small annoyance that bites me from time to time is the lack of find-in-page support. However, there’s a plethora of bookmarklets out there that can add the functionality. (Actually installing bookmarklets is pretty painful, but I digress.)

Security and Phishing Protection

I mentioned the fact that small size of the URL bar makes it difficult to visually detect a phishing attempt. There’s also no way to see details about the SSL certificate. The only security-related thing I see is the lock icon that appears before the title when you’re using an SSL connection, but what good is that if you can’t even see what site you’re connected to?

Update: In the comments, PCheese points out that iPhone Safari has phishing protection just like the desktop version.

File uploading

Any file input widgets in HTML forms are just shown as being disabled. Since there’s no user-visible file system on the iPhone, this isn’t too surprising. Still, it would have been nice to provide a simple way of choosing a photo or video to upload.

Opening links in the background

In the study on tabbed browsing I ran in 2009, I found that many power users habitually open links in new tabs, especially on search result pages and on sites like Digg and Hacker News. I find that the inability to do this on the iPhone seriously changes my browsing habits. And I’m quite surprised that the iPad doesn’t appear to support tabs, though this may of change before it’s released.

Conclusion

The iPhone was a revolutionary computing device, in no small part due to how great iPhone Safari is. In its user experience, Apple did what they do best — put a great amount of energy and effort into perfecting the smallest details of the design. I hope this article has helped you notice more of those details.

The version of Safari on the iPad looks to be highly influenced by iPhone Safari. This is interesting, because its screen resolution is bigger than most web users had in 2005 [3]. If it really is “the best web browsing experience ever”, aspects of its design will no doubt trickle up into desktop browsers.

1. Mobile Firefox (aka Fennec) takes an interesting approach: the back, forward, and bookmark buttons are in a control strip that lives to the right hand side of the page content. It is hidden by default, by can be revealed by dragging all the way to the right.
2. See Weinreich et al.’s Not quite the average: An empirical study of Web use

Measures

The first thing we need to do is to be a bit more precise with the question. What does it mean to “use” multiple tabs or windows, and how should it be measured? There are few possible answers.

We could simply count the number of tabs that a person creates. One problem with that is that when Firefox starts up, at least one tab is created (and possibly more, if it is restoring a session), so someone who opens and closes their browser frequently would have a high number of tab creation events. To eliminate this effect, we only count tabs that are created after browser startup. We also ignore the first tab that is created in any window.

Another thing that’s interesting to measure is the number of concurrent tabs or windows that a person typically has open. For example, two people might create a similar number of tabs, but one of them might have an email client, an RSS reader, and another tab playing music open at all times. It seems reasonable to say that this person uses tabs more heavily than the other person. We decided to measure the number of windows and tabs that were open whenever a navigation event occurred. For consistency, we ignored all navigation events caused by Firefox’s session restore feature when calculating this measure, although it didn’t have a very significant effect overall.

A third measure of tab usage that might be interesting to look at is the number of tab switches that a person performs, but I’ll address that in a later post. For now, we’ll concentrate on how many tabs.

Study Details

First, I guess I should mention a little bit about how the study was conducted. Here was the recruitment email we sent out to family, friends, and colleagues:

We are seeking participants (at least 18 years old) for a research study exploring how people use web browsers.

If you use Mozilla Firefox for several hours a day, and often use multiple tabs or windows, then you are a candidate for the study. If you choose to participate, you’ll install a Firefox extension that will log various actions, e.g. clicking on a link, visiting a bookmark, opening a new tab, and clicking the back button. Don’t worry, the names and addresses of the web sites that you visit will NOT be revealed to researchers.

The study will last for two weeks. During this time, you’ll take part in five short interviews (approx. 30 minutes each) that will be arranged at your convenience. In addition, you’ll be asked to record some brief notes several times during the course of each day (again, at your convenience) and to email your log file to the researchers at the end of the day. Participating in the study will take about 4-5 hours in total over the two week period.

We also put posters up with similar wording across the University of Toronto campus. 21 people completed the study, and 1 person started it but dropped out early.

Unlike many other studies like this that have been done, our study participants had a variety of ages, professions, and technical skill levels. One participant was younger than 20, 14 were between the ages of 20 and 29, four were 30-39, and two were 50-59. Only 6 participants came from a computer science or engineering background, while others had studied education, environmental science, business, and psychology. Six of the participants were full-time students (either undergraduate or graduate), and 15 were working in some kind of office environment where they spent most of their time on the computer.

Results

Tab Creation

First lets take a look at the tab creation rate. Now, keep in mind that these are only tabs that are created after browser startup, and the first tab in any window is not counted. On the X axis is the “tab creation rate”: the ratio of tabs created to navigation actions. (A navigation action is anything that changes the URL of the page, even if it doesn’t result in a top-level page load.) The height of the bars represents the number of participants with a given tab creation ratio.

Interesting…we’ve got a very clear bi-modal distribution. More than half of our participants (13/21) are clustered around the 0.04 mark. In other words, these people create about 4 tabs for every 100 navigation actions. The rest of the participants are loosely centered around 0.14, meaning that they create about 3 times as many tabs as the other people. In fact, we have two participants who are even higher, creating (respectively) 17 and 22 tabs per 100 navigation actions.

Unsurprisingly, the four highest tab creation rates belong to the four participants with Computer Science and/or programming backgrounds. The other four participants in the high part of the distribution are not your typical “techie” types: one is trained as a civil engineer, and the others have backgrounds in communications, humanities, and marketing.

Concurrent Tabs

Another interesting thing to look at is the number of tabs that people tend to have open at any given time. Again, we used navigation actions as our increment of measurement. On the X axis is the number of tabs open when a navigation action occurs, and the height of the bars it the total number of navigation actions that occurred with the that number of tabs open.

Not too surprising — the most common number of tabs to have open is one, with a pretty steady descent down to 9. It flattens out and hits a valley at 13, but then rises slightly again for a second peak at 16. So, again we see a slight bi-modality to the distribution. But if we take the same set of “tab power users” from the first graph, we see that they have roughly the same profile as all the participants put together. In fact, the peak at 16 is almost entirely caused by only two of the power users: participants 14 and 20.

One possible explanation for the bi-modal distribution here is tab bar scrolling. At a typical screen size on a laptop or desktop, the tab bar can fit about 9-13 tabs without scrolling. Many people probably try to avoid having the tab bar scroll, but once you get to the point where it starts scrolling, there’s little additional cost to having more tabs open. So it may be the P14 and P20 are the only ones comfortable with keeping so many tabs open that the tab bar is scrolling.

Take a look at the median and max number of tabs that each participant had open:

(Note that there’s no participant 8…he’s the one that dropped out.)

Participants 14 and 20 definitely stick out — it’s easy to see why they contributed so much to the yellow portions of the previous chart. Participant 14 by far the highest median number of tabs open with 17, while no other participant had a median higher than 6. Participant 20 actually edges out P14 for max tabs though, with 42. (For once it really is the answer.) Forty-two — that’s a lot of tabs! The tab bar would be scrolling two are three times over at this point. He actually commented on this, saying “Now I am opening tabs up from Digg and they are appearing at the end of my massive list. This is truly a bad way to browse.”

P19 is an interesting one…a median of only one tab open, but a max of 27! Participant 2 is similar, but not nearly as extreme: a median of 4 and a max of 20. Even if these two preferred not to have too many tabs open most of the time, they weren’t afraid of opening up lots of tabs when they needed to.

In general though, it looks like most people don’t go far beyond where the tab bar starts to scroll. I’ve marked a gray line on the graph at 13 tabs. At a resolution of 1280×1024, this is the point at which the tab bar starts scrolling (on my computer, at least). We see one person who maxes out at 13, and a few more who max out at 14. In all, there are 9 people whose maximum is between 10 and 14.

Conclusions

There are a few things we can take away from this. First, we saw that people who use tabs heavily can create 2 to 3 times as many tabs as other users. It’s not obvious what the cause for the bi-modality in the distribution is though. From the second and third graphs, we see that having 10 or 11 tabs open is not that uncommon, even for people who aren’t “power users”. And the third chart also show us that even people who don’t have many tabs open on average can sometimes have spikes of a large number of tabs.

Let me know if you have any questions or feedback. Have I explained things clearly? Are there any other numbers you think I should take a look at? Leave me a comment or send me an email. I’ll be posting some other interesting results from my study over the next couple of weeks.

Since my talk, a few people have contacted me to ask about exactly how I did the logging, and did I notice this, or did people do that. Unfortunately, I can’t release my raw data, but I decided to do the next-best thing: release my logging tool. I humbly present tlogger for your consideration:

tlogger is a Firefox extension for capturing click-stream web browsing logs. In other words, it collects data about how the browser is used. Mainly it records navigation events and tab events, as well as the UI actions that cause those events. It’s roughly similar to the Spectator extension, but with a few key differences:

• it’s compatible with Firefox 2 and 3

• it doesn’t submit ANY data automatically, to anyone. Everything stays on in your profile directory, in a human-readable format.

• URLs are obfuscated on a per-user basis. From the log file, someone can see when the user revisits a site or a URL, but there is no way to determine what the actual URL is. It’s also not possible to make comparisons between users.

• it can log a few things that Spectator can’t, like when javascript on a web page changes window.location.href.

The source code is managed on GitHub at http://github.com/pdubroy/tlogger/. For the impatient, you can install the latest version of the extension or grab a snapshot of the repository. In addition to the source code for the Firefox extension, the git repository contains tools for analyzing the log files generated by tlogger.

tlogger is useful for anyone who needs real data about how people use Firefox. Of course, it’s perfect if you’re doing a field study on web browser usage, but it’s also useful for prototyping new UI features for Firefox. Liz Blankenship has already used it for her tabviz project, and discovered some interesting things about her own web browsing habits.

Enjoy! If you find it useful, or if you have any questions, send ‘em my way (email to pat, at the domain dubroy.com). If you make changes, send me a pull request on GitHub.

Andy Edmonds pointed me to an informal survey done by Dave Munger at Cognitive Daily on how many tabs people use. Dave found that most people had only 2-4 tabs open, and that younger people were likely to have more tabs open. But my favourite part was his finding that if you know who Jonathan Ive, Leo Laporte, and Esther Dyson are — you’re likely to have more tabs open.

Liz Blankenship told me about her project on Tab Visualization for an infoviz course at the University of Michigan. Their goal is to help browser users who tend to have “too many” tabs open at once make sense of the information overload they experience. I’m looking forward to seeing what they come up with.

Also, I realized that I haven’t mentioned anything yet about Mozilla’s Test Pilot project, other than a brief mention in my last post. Test Pilot is a Mozilla Labs program that will allow people to do studies like mine on a massive scale. The goal is to have 1% of Firefox users opt-in to being participants in these kinds of studies. My study had 22 participants. Think hundreds of thousands, or even millions. Pretty cool. I can’t wait to see where it goes.

I dropped the ball and didn’t post my slides anywhere before the talk. Boriss and Jono have already blogged about the talk and linked to my slides, and since it’s already generated quite a bit of discussion, I thought I’d add a bit more detail here.

I was hoping to have a video to post, but that didn’t work out. So instead, I decided to try something different: I’ve written up the talk inline with the slides. It’s transcribed from memory, but I think it’s pretty close to the actual talk that I gave. Let me know what you think of this format — is it worthwhile?

You can also grab the full slides of the talk in PDF.

How do people use tabs?

For those who haven’t read my about page yet, I’m a master’s student in Computer Science at the University of Toronto, focusing on Human-Computer Interaction. This talk was about the research I’m doing for my master’s thesis. If I can boil it down to five words, it’s “how do people use tabs?”

To give you an idea of how I got here: I have a love/hate relationship with tabs. On one hand, I find tabs to be amazingly useful, and I don’t think I could ever go back to using a browser that doesn’t support tabs. But on the other hand, I find I run into a lot of problems with tabs. For one, tabs make it much harder to use the back button. Instead of one trail of history, you now have several — one for each tab. If you’ve got 5 or 10 tabs open, and you’re trying to find a page that you were looking at just a few minutes ago, you might not remember what tab you were in when you were looking at it. That makes it really tough to find the page you’re looking for.

Another problem with tabs is that they subvert the traditional task management mechanisms of the OS. Exposé, for example, is a really useful feature on OS X. If you are looking for a particular tab, like GMail — if that tab is not the selected tab in the browser window, you’re not going to find it in Exposé. The same is true of the Window taskbar.

Tabs also force you to make a premature commitment. What I mean is that every time I click on a link, I have to decide whether I want to open it in a new tab or in the current tab. Sure, it’s an easy decision, but it’s still something I have to think about every time I click on a link. And that’s something we all do pretty often.

Finally, we probably all run into the problem sometimes that there are just too many tabs open. They clutter up the screen, the tab bar starts scrolling, and it takes an effort to clean things up. It’s a pain.

So, as I was looking for topics for master’s thesis, I started thinking — could I make something better? Could I come up with something that gives all the advantages of tabs, and eliminates some of these problems?

But as I was sketching up concepts, I started to realize that I really didn’t have a good idea of how or why people use tabs. I knew what I did, and I could ask my friends what they did. But I’m a programmer, and a lot of my friends are programmers, and we all know that programmers are not exactly what we’d call a representative sample.

So I looked at the literature. I had no trouble finding academic papers that looked at how people use web browsers, but surprisingly, I found hardly any mention of tabs. What I found was a big focus on revisitation. A couple papers on revisitation were published recently at CHI — one in 2008, and another in 2007 (and a good summary here). One of them didn’t mention tabs at all, and the other had only a brief mention of how tabs might change revisitation behaviour. I thought this was funny, because in my mind, tabs are highly related to revisition. If I have a page open in a tab, it’s because I want to go do something else, and then eventually come back to that page. To me, tabs offer another kind of revisitation, so surely they warrant more than just a cursory mention?

It seemed to me like a nice opportunity for my research to fill an significant gap in the literature. So I decided that I would do a study to investigate how people use tabs, and how tabs are related to revisitation.

In November and Decmeber of last year, I conducted a field study with 22 participants who each participated for two weeks. Unlike many studies done in HCI, these were not 22 CS graduate students — I really tried to get a variety of people to participate. In terms of age, most of my participants were in their 20s, but I had a few people in their 30s, one in his 40s, and another in his 50s. And in the study, only 6 of the 22 participants came from a CS or engineering background. The others were quite varied: I had some students from the social sciences, a high-school teacher, a professor, and some administrators from the university.

I wanted to gather both quantitative and qualitative data. So, I wanted to know things like:

• how many tabs to people have open, on average
• what percentage of links are opened in a new tab, vs. in the current tab?
• is use of the back button or other history mechanisms correlated to tab usage?

…et cetera. But I also wanted to know why people did things the way they do. And I wanted to learn what people use tabs for, what things they like and dislike, and what problems they run into.

Now, gathering quantitative data is fairly easy. Firefox is pretty easy to instrument, so I built a small logging extension that captured all the data I was interested in:

• Tab events: when a tab is opened, closed, moved, and switched to
• Navigation events: load start, changes to the URL, and load events
• Causes of the navigation events: clicking on a link, using the back button, etc.

(This extension is actually quite similar to the Spectator extension, but for a few reasons, I couldn’t actually use Spectator.)

So that gave me my quantitative data. What about the qualitative data? How would I collect that?

Well, that was actually a really tough question. I tried out a few different ideas, piloting them on some of my friends. In the end, what I settled on was this: periodically during the day, my extension would show a not-too-obtrusive notification asking the user to record a short diary entry about what they are doing right now. An interesting thing about this technique was that I didn’t actually get that much interesting information from these diary entries, but they were actually useful in another way. I interviewed each participant 2 – 4 times over the course of the study, and the diary entries served as a memory trigger, a kind of anchor to bring them back to a particular time or event. And then I could ask them about that event, things like: Why do you think you opened this page in a new tab? Were you still using this tab, or were you done with it? And through these interviews, I was able to collect a lot of really interesting data about how people use tabs, what purposes they serve for them, and why they do things in a particular way.

I completed the data collection before Christmas, and for the past few weeks have been starting to do analysis. I’d like to share some of my initial results with you. Keep in mind that these are very early results — they are far from conclusive, but it looks like there are some really interesting things in here.

One thing is that I’ve heard lots about what people are using tabs for. A lot of these things aren’t that suprising — they are probably things that you do as well — but it was nice to hear about them from other people, especially people who aren’t programmers.

Several people mentioned using tabs instead of the back button. For example, with a Google search, a lot of people will go and open several links in new tabs, and then go and peruse those tabs, and see which ones give the information that they need. Without tabs, they said that they’d click on a link, check it out, go back to the search results page, click on another link, et cetera.

They also mentioned using tabs as lightweight bookmarks. For example, you might look up a recipe for something you want to make for dinner, and instead of bookmarking it, just leave the tab open for a few hours until you are actually making dinner.

Similarly, many people said that they use tabs as reminders. One participant said that at the end of the day, she scans all of her open tabs, and can quickly figure out if there’s anything left to do before she leaves.

Of course, tabs allow people to multitask, to have several things on the go at once. Quite a few people reported keeping a tab open to Pandora or an internet radio station to listen to music while they are working.

And another somewhat obvious one is that tabs are useful for comparison. But what was interesting is that almost everybody said that tabs are better than multiple windows for this. It’s not clear exactly why, but people said that it’s just quicker and easier to switch between tabs than to switch between multiple windows.

Another question I wanted to answer was, what are the advantages of using tabs? This was kind of funny, but I kept hearing people say things like, “it’s just right there.” It seemed that the whole visual and spatial aspect of tabs was something that people really found helpful. People also mentioned that they liked having a visual browsing history. A couple people even told me that this helped prevent procrastination! If they were working on something, and then they went off an a little sojourn through Wikipedia, then the first couple of tabs would still be there in the top left, reminding them of what they’re supposed to be doing.

When compared to the back button, most people reported that using tabs is easier and faster. Some of them couldn’t quite put a finger on why; but others mentioned that with the back button, they don’t know how far back a page is going to be. But with tabs, they know exactly what they’re going to get when they click on the tab.

People also seemd to distrust the back button in a way. They said they weren’t always sure that they’d be able to find the page that they’re looking for, or whether the back button would even do what they intended (”Some sites don’t really agree with the back button,” said one person). Tabs, on the other hand, felt much more certain.

And of course, tabs allow new browsing strategies that weren’t possible before. For example, you can go through a bunch of links and open up several of them in tabs, and then go and investigate them. This can be handy if you’re in the middle of reading an article, but see an interesting link that you’d like to check out.

As for my quantitive results, what I have done so far is only very basic analysis, basically grepping the files and looking for the frequency of certain events. So take these early results with a heavy grain of salt.

One of the first things I looked at was the frequency of tab switching. As my benchmark, I used the number of link click events. Since I can’t (yet) accurately determine the number of actual navigation events, this seemed like the next best thing. And previous studies have shown that link clicks account pretty reliably for about 45% of all navigation events [Note: in the talk, I believe I said 50%].

What I found is that the median number of tab switches was roughly 1 for every 2 link clicks. This is interesting, because it would mean that tab switching is the second-most frequent thing that people do in their browser (link clicks are the most frequent, besides typing, pointing, and scolling).

But, I also found that in 5 of the 22 participants, tab switching was actually more frequent than clicking on links. And for all but two of my participants, tab switching was more frequent than clicking on the back button.

This is interesting, because up to now it’s been assumed that the primary thing that people do in their browser is click on links. And this may still be true (for some people), but tab switching is a close second. This means that the browser is used both for navigation, but also as a task-management tool.

Another thing I wanted to look into was how often people choose to open a link in a new tab. In doing so, I noticed something interesting: 6 of the people in my study never opened a link in a new tab, and 3 others did so less than 10 times. These people still used tabs quite a bit. Maybe they never felt the need to open a link in a new window, but I think it’s more likely that they didn’t know they could even do that. One person actually described to me a long work-around. If she was on a page with two links that she would have wanted to open in new tabs, she would copy the URL of the page, open up a new tab, and paste the URL in the new tab. Then, she would follow a different link in each one of the tabs. She did this so that she could compare between the two sites. The thing is, she was telling me that this was something she liked about tabs — that should could compare between two pages. So, even with the amount of work she was putting in, tabs were a win for her. Clearly she would benefit from knowing how to open up a link in a new tab.

The conclusion I make from these numbers is that opening a link in a new tab is not very discoverable. The only way you would find out about it is if someone told you about the magic Ctrl-Tab shortcut, or if you happened to right-click on a link. But that isn’t very easy to discover.

Finally, I noticed something interesting about the use of the back button. Previous studies on web page revisitation have shown that link clicks have pretty steadily accounted for about 45% of all navigation actions [in my presentation, I originally said 50% --ed.]. The back button seems to be accounting for less and less. In papers by Catledge & Pitkow (from 1994) and Tauscher & Greenberg (from 1995-96), the back button accounted for about 32 – 36% of navigation actions. Hartmut Obendorf and his co-authors, in their study published at CHI 2007 but conducted in 2004-05, they found that the back button only accounted 14% of all navigation actions. [A good summary of the different findings in all 3 studies can be found here]

[Note: I've corrected a few of the numbers here. In my presentation I believe I said that link click accounted for 50% of navigation actions, and that the earlier studies had shown the back button accounted for about 30%. I was slightly off.]

In my data, I’m seeing that the median number of back events is about 1 for every 50 link clicks, and for 9 people, it was less than 1 in 100. I don’t have an exact number of navigation events yet, but assuming that link clicks are relatively stable at about 45%, then back events would be less than 1%! In fact, 7 participants in my study used the back button less than once per day. And these people were among the heaviest users of tabs. Now these are just rough numbers, but even if it’s off by as much as a factor of 2 (which is unlikely), the conclusion here is that the back button is becoming irrelevant for a large class of users.

What’s still not clear is exactly why people are using the back button so much less. It might be that they don’t need it as much when they use tabs, or maybe that it’s harder to use when they use tabs. Or maybe it’s for other reasons entirely. [There were a couple of interesting suggestions about this from the Mozilla folks. It might be that a lot of sites are better designed these days and provide a way of going "back" without using the back button. Or, maybe that it's because many people are using web applications like GMail, in which it's not clear what happens sometimes when you press the back button.]

As I’ve said, these results are based on my intial, fairly basic analysis. I’m planning on digging a lot deeper. With the qualitative data, I’m continuing to analyze and code it, hoping to eventually come up with a kind of “theory of tabs.”

My quantitive analysis has been very basic so far. I’m currently working on tools to help me analyze the logs in much greater depth. (Yes, tools that are even more sophisticated than ‘grep -c’!) My plan is to measure a bunch of obvious things, such as the number of tabs that a person has open, the time that they spend on a tab, the portion of links that are opened in a new tab, etc.

I’m also planning on looking at tab switching as a kind of revisit — when you switch away from a tab and switch back to it, that’s revisiting the page, even though it doesn’t cause a navigation action — and comparing these results to papers on revistation that I mentioned earlier.

But I’m also looking for ideas. There are lots of interesting patterns that I might be able to find, but I won’t find them unless I know what to look for. Please leave a comment below and let me know your ideas.

These are just a few of the lessons that I’ve learned from conducting this study, and they might be helpful to anyone who’s thinking of doing a similar study.

First of all, I found that there are lots of people out there who are passionate Firefox users, who would love to be able to help out the project in any way. People would say to me, “I love Firefox! I’d love to participate in your study.” Even when I told them that I wasn’t affiliated with Mozilla, they were still really interested.

I also found that many people aren’t that concerned about someone seeing the web sites that they visit. Now, the people I talked to are a biased sample, because anyone who was really concerned about their privacy obviously wouldn’t be interested in the study and wouldn’t have gotten in touch with me at all. But out of all the people who contacted me, almost no one had any concerns about how the data was being collected. Now, I didn’t have access to any of their personal information — all URLs were obfuscated on a per-user basis, and no other personally-identifiable data was collected — but still, I was surprised how little concern most people showed. I was very conscientious about explaining exactly how I was protecting their privacy, but most people didn’t seem to care that much. A few even offered to send the full list of the sites that they visited, and even capture a video of them during web browsing. I had to pass on these offers though, as they were outside the scope of my study.

I’ve found that qualitative studies are quite hard — sometimes difficult to design, and definitely difficult to do data analysis on.

Finally, I found that the extensibility of Firefox is a double-edged sword. While it made it really easy to instrument the browser to record my data, the possibility of all kinds of other plugins being installed really complicates the log analysis.

And of course, please feel free to leave your comments below.