Mobile Heatmap Results

It’s time to share the results of the Test Pilot Mobile Heatmap study launched last month.

My thanks to all the mobile Firefox users who submitted data! I’d also like to thank Gregg Lind and Blake Cutler for helping with the visualization, Lilian Weng and Raymond Etornam for contributing to the study code, and Mark Finkle and Wes Johnston for providing invaluable documentation on the workings of mobile Firefox.

66 Android phone users submitted data to this study. That’s much lower than the participation level of Test Pilot on desktop Firefox, because mobile Test Pilot is not yet bundled with the mobile Firefox beta, and because there aren’t nearly as many mobile Firefox users (yet). Standard caveats about self-selected Test Pilot samples apply. In particular, note that 12% of the users in this sample used the Console at least once. The Console is an advanced debugging feature that’s hidden by default, so it’s safe to assume anyone using it is a developer. Obviously a random sample of mobile web users would have far fewer than 12% developers.

I hope we can re-run this study in the future with more users, but for now 66 participants are enough to let us identity some interesting patterns.

Mobile heatmap - percentage of users

The first visualization shows what percentage of the users touched each element at least once. At a glance, we can see that nearly every user swiped to the left and right sidebars, switched tabs, closed tabs, and touched the URL bar.

Back and Forward

A surprisingly low fraction of users – less than a quarter – used the forward and backward buttons in the right sidebar. This is starkly different from desktop browsing, where Back is one of the most used of all buttons. Three quarters of Android Firefox users didn’t touch these buttons even once! Note that uses of the Android hardware back button were not counted in this study. It’s likely that there is much less call for the software back button because the hardware button is more convenient.

However, I don’t think this explains everything. There’s no hardware substitute for the forward button, and yet only 24% of mobile users hit the forward button. Compare that to the desktop Firefox heatmap, done last year by the Metrics team. 60% of desktop users hit Forward at least once. That’s a pretty big difference! It makes me suspect that going back and forward in a tab’s history is just less frequently done in mobile browsing.

Undo Close Tab

Meanwhile, over a quarter of Android Firefox users hit the Undo Close Tab button at least once. The placement of this button is quite prominent, unlike on desktop Firefox where the feature is hidden away in a submenu. Maybe usage would be higher if the feature was as easy to discover on desktop Firefox as it is in the Android UI!

Mobile heatmap - mean click count per user

The second visualization shows each element’s mean number of touches per user. It’s the total number of times the element was touched by all users, divided by the number of users.

Tab switches and reloads

Something that immediately jumps out here is how many times people are switching tabs. The frequency of every other interaction is dwarfed by the number of tab switches. Because tab switches are so much more frequent than swipes to the left sidebar, it seems like a common use case is to swipe left and then do several tab switches in a row before refocusing on the content. Are users having trouble finding the tab they want, or are they just exploring?

It’s also interesting to see the relatively high frequency of reloads. On desktop Firefox, reload is used less frequently and by a lower percentage of people than the back button, but on mobile Firefox the pattern seems to be the opposite. Is it just because the back button is less important, or is there some special reason that mobile users reload a lot? Perhaps they’ve lost their signal, and are trying to refresh the page after regaining it.


By comparing the two visualizations, we can see some interesting patterns. For example, the New Tab button was used by a greater fraction of users than the Bookmark selector, but the Bookmark selector averaged more uses per user.

Typing URLs

Most users (72%) hit the Edit URL field at least once, indicating they typed or edited a URL. But the frequency of URL-editing was low (5.1). Meanwhile, the frequency of touching the URL bar — which brings up the suggestion screen, or “awesome screen” — was more than three times higher (15.7). This means that two-thirds of the time someone opened the suggestion screen, they did not edit a URL. They might have picked a suggestion from frequently visited sites, from bookmarks, or from history.

Inputting URLs on mobile devices is still quite painful, and the data supports the idea that users do it infrequently compared to desktop — but 72% still had to go through this unpleasant process at least once during the study.

It would be interesting for a follow-up study to look at the number of page loads that result from entering a URL or doing a search on a mobile device, compared to the page loads resulting from links and bookmarks. I suspect the fraction is much lower than on desktop browsers.

Short tab histories

Because tabs were closed on average 23.5 times per user, but the new tab button was only used 1.8 times per user, we can infer that most new tabs are not opened with the new tab button. Most likely, they’re opened by touching a link in web content, or possibly a link in another app, which opens in Firefox if the user has chosen it as the default browser.

The high frequency of switching and closing, combined with the low frequency of back, forward, and new tab, suggests to me a usage pattern where most tabs are opened to a link and used only to display that single page before being closed. The common desktop-browsing pattern of surfing to many sites in a single tab — building up a tab history that makes the back and forward buttons useful — may be a rarity in mobile browsing sessions.

What else do you notice in these heatmaps? What would be interesting to investigate in a follow-up study?

8 responses

  1. nemo wrote on :

    I do use undo close tab, but I also quite frequently accidentally hit it when scrolling through the new tab list. I very much miss the multi-column tab list that was hidden away when I was not using it.

  2. glandium wrote on :

    About undo close tabs, the only time i use it is when i’m closing a tab when i really meant to switch to it. And this is unfortunately too easy to do. I guess this is why it is so used.

  3. S. Albano wrote on :

    When I am navigating on a site with a lot of links, I avoid forward and back like the plague. Each time they are used, it triggers a long page load. Instead, I open links in new tabs. That way I have instant access to the main site once I finish reading an article, rather than waiting for a page load after pressing the back button. In essence, the tabs are replacing the forward back functionality for me.

    In Opera Mini, I use forward and back like I do on the desk top. They appear to cache quite a few pages in history, so they are much less painful to use.

  4. Mook wrote on :

    Interesting that the right bar was shown by >80% of the users, but the elements inside it are all pretty low. Either people who use any one of those are unlikely to use any other one (really? people who use back hardly overlap with people who use forward?), or it’s too easy to mis-trigger showing the right bar, and people had to cancel it (and up to 40% of the people in the sample did this). Probably the latter, given that there are 10.6 mean clicks per user for showing the right tab, and 4.3 mean clicks per user for all of the elements in the right bar combined…

    Are there useful ways to reduce the times people unintentionally open the right bar? I know I do this often, for both bars.. In my case, often while trying to pan inside a page too large to see on a single screen.

  5. Gervase Markham wrote on :

    I think your conclusions are right. I _always_ open links in a new tab because I know (or think) the load is going to take ages. When I’ve finished with a tab, I close it. I hardly ever go forward and back. When I accidentally click a link to open in the same tab, I’m annoyed! This requires a long-click and then tap as well, which makes it feel clunky, but it’s still better than waiting ages for a page load.

    And yes, the thumbnails are so tiny (and often of different news articles on the same site) that it’s very hard to tell which is which.

    I would use Undo Close Tab because it’s easy to close a tab when trying to select it. Why not have the close button appear in the _far_ corner while the tab list is open? You could still close multiple tabs in quick succession by tapping it several times, but you couldn’t accidentally hit it when switching.

    I do pick things from history – but I’m often picking the same thing, and it’s still not top of the list! The awesomebar seems a lot less awesome on mobile.

  6. WalterK wrote on :

    RE: Forward Button.
    Though I opened right bar numerous times before, I was convinced that there was no Forward button until some time last week :) My confusion aside, Forward button is an important feature. It’s most useful when I accidentally press hardware back button (and I press it a lot) and want to return to the page I was on.

    As for my browsing pattern, it is similar to S.Albano’s above. I tend to open links in new tabs and close the tabs as I read them. It makes browsing much faster. While links are loading in the background, I continue reading the current page. Then I switch to the loaded page without any wait. It’s the same patter on the desktop as well – middle-click on a link and continue reading the current page.

    On a totally different topic, am I the only one who is totally fine with XUL browser speed and responsiveness on my MyTouch 4G phone? It has some checker boarding on larger pages, but that could’ve improved over time…

  7. Hippyonandoff wrote on :

    I found the forward button! Thank you, google brought me here as I searched for it in vein.

    Can I suggest, given my experience and comparing the ui to Dolphin, that a reason fort forward not being used is its location.

    Also, given the awful refresh time for old and new pages to open, users probably avoid navigation always. I do. Painful to watch pages reload.

    My 2 cents. I will instal the plugin so you have my data in the future

    You are doing a great job. Keep it up!

  8. TiagoTiago wrote on :

    Has there been any analysis done regarding these results and comparisons with the UI conventions used in other mobile browsers and in the mobile OS itself in the respective devices?

    ps: Shame on you guys for not recognizing a valid email address! I thought you guys were all about respecting the standards etc…Please fix your email address validation code ASAP. Or if you feel you don’t got the skills to code a proper address validity analyzer, if a valid and working email address is essential for whatever reason, just send an email to the specified address no matter how alien it looks, with a link asking the user to click on to validate their address; obviously if they do get the link it means the address is good.