Swipe Vs. Scroll: Web Page Switching on Mobile Browsers Andrew Warr, Ed H. Chi Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043 {andywarr, edchi}@google.com ABSTRACT

Tabbed web browsing interfaces enable users to multi-task and easily switch between open web pages. However, tabbed browsing is difficult for mobile web browsers due to the limited screen space and the reduced precision of touch. We present an experiment comparing Safari’s pages-based switching interface using horizontal swiping gestures with the stacked cards-based switching interface using vertical scrolling gestures, introduced by Chrome. The results of our experiment show that cards-based switching interface allows for faster switching and is less frustrating, with no significant effect on error rates. We generalize these findings, and provide design implications for mobile information spaces. Author Keywords

Web browser; Web browser interfaces; Information spaces; Task spaces; Mobile ACM Classification Keywords

H.5.m. Information interfaces and presentation (e.g., HCI) INTRODUCTION

The first web browsers used single document interfaces, where only one web page could be displayed in an individual window at a time. This was problematic when viewing multiple web pages, as the desktop could become cluttered with multiple windows. This in turn made switching between web pages, as well as other application windows difficult. The introduction of tabbed web browsers partially mitigated these issues by grouping browser windows together, reducing desktop clutter and making switches between web pages easier [4]. Today, tabbed web browsing interfaces are commonplace amongst modern desktop web browsers. However, due to the limited screen space and the reduced precision of touch [5], tabbed browsing is much more difficult on mobile devices. How should it work? In what we will called the “Pages” interface, Safari requires users to select a button to enter a web page switching interface to swipe between web pages, where only one web Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. CHI 2013, April 27–May 2, 2013, Paris, France. Copyright © 2013 ACM 978-1-4503-1899-0/13/04...$15.00.

page is shown at a time (see Figure 1a). As it requires a single swipe to traverse a single web page as the number of web pages increases so does the number of interactions and the time to switch between web pages. Furthermore, this arguably impedes users’ spatial memory, making it harder to find things [8] and increasing users’ cognitive load. Safari tries to mitigate this by showing a small portion of the web pages to the left and right of the current page, if any. Safari indicates the number of web pages by a series of grey dots, and the position of the currently page with a white dot. However, this only provides spatial information around the currently selected web page. Users do not get a sense of where a particular web page might be. While these problems are common in Safari, where users switch between web pages more than three times a day [9], these problems also span to mobile applications that follow the same design pattern [1], generalizing to the domain of task management and information spaces [2, 8] on mobile devices. Card and Henderson [2] argued that task management interfaces should aim to reduce the amount of time and the mental load during switches. We are therefore seeking an efficient and better interface for switching by decreasing the number of interactions and time to switch as well as reducing users’ cognitive load.

a)

b)

Figure 1. The web page switching interface on: (a) Safari (Pages interface); and (b) Chrome (Cards interface).

The Chrome mobile browser has introduced a new web page switching model where users select a button to enter a web page switching interface. Users can drag web pages up and down, and web pages are spread out like a stack of cards (see Figure 1b). We will refer to this as the “Cards” interface. Our goal is to compare the two switching interfaces, in the context of web page switching, in order to understand their effect on user performance in terms of time on task and error rates.

EXPERIMENTAL DESIGN

The experiment was a 2 by 3 within-subjects design. The independent variables were: (i) the web page switching interface (Pages and Cards interfaces); and (ii) the number of web pages, which ranged from 4, 8 to 16 web pages. The within-subjects factorial design was balanced using latin-squares to mitigate ordering effects. The dependent variables were response time to select a web page and the number of erroneous selections. While Safari limits a user to opening a maximum of 8 web pages, we extended our upper limit to 16 web pages as we were interested in differences between the Pages and Cards switching interfaces, as opposed to the browsers themselves and the design decisions and technical limitations that have been placed upon them. We surmised the Cards interface being faster than Pages interface because they pack more web pages in the same amount of screen space. However, given the smaller target sizes for individual windows, we believed users would make mistakes more often, especially when there were more target pages. Formally, we hypothesized that: It would be quicker to switch web pages in the Cards interface than the Pages interface (H1); and, there would be more erroneous selections in the Cards interface than the Pages interface (H2). Participants: Fourteen participants took part in this experiment. The participants’ age ranged from 21 to 34 years of age, with a mean age of 28 years. Eleven of the participants were right-handed and the other 3 were lefthanded. Six of the participants were Safari users and therefore familiar with the Pages interface and ten of the participants were Chrome users and hence familiar with the Cards interface --- two of these participants used both Chrome and Safari. Eleven of the participants were from a large corporation and three of the participants had no affiliation with the corporation. The participants were recruited via hallway intercepts and mailing lists; and received either a 30 minute massage coupon, or $15 perks.com credit. Set-up: We brought participants into a controlled lab setting for this experiment. While it may be argued a controlled lab setting is not reflective of a mobile environment, Cui & Roto [3] have shown that the mobile browsers are usually used in indoor environments in static positions.

factor of page recognition [6]. We ensured that none of the participants were color-blind. Since recognition is not a factor, we can more directly attribute performance differences to the interfaces.

a)

b)

c)

Figure 2. (a) The full-screen web-view application; (b) Pages interface; and (c) Cards interface.

At the top of the application, a toolbar with a color swatch on the left-side indicated the next colored web page to select. Users pressed a button on the right-side of the toolbar to start the trial. The Pages interface presented the current web page with a small portion of the left and right web pages, if any (Figure 2b). Just like Safari, small circles below showed the number of pages currently available, as well as the indicator of the current page. Participants could switch to an adjacent web page, if one exists by swiping either left or right. A page could be selected by tapping the visible web page. The Cards interface presents the web pages as a stack of cards (Figure 2c). The current web page was centered upon opening the Cards interface, unless the anchor position of the web page was higher than the center of the screen. For example, the first web page in the stack (the gray web page in Figure 2c) is anchored at the top of the Cards interface, so it appears no lower than its anchor position. The number of cards in the stack corresponds to the number of web page to select from, with a maximum of 4 web pages being visible at one time. A participant could scroll the cards in the stack by dragging either up or down, until they reached the top or bottom of the stack respectively. Once the user scrolls to a web page they wish to select, a card could be selected by tapping the visible web page.

Participants used a Samsung Galaxy Nexus smartphone running Android 4.1 with a full-screen web-view application developed for the purpose of this experiment (see Figure 2a). A web application was used instead of the actual browsers (Safari and Chrome) because we wanted to remove interface elements (see Figure 1) and performance differences that may influence the results.

In Chrome, scrolling includes an acceleration component, which means the distance scrolled could be greater than the distance the participant dragged. This acceleration was removed, as the Pages interface did not have such an acceleration feature --- a swipe moved one page, regardless of distanced swiped or the swipe speed. As such, our experiment tried to isolate the comparison to interface differences rather than subtle interaction differences.

The application presented web pages as distinct solid colors, because we wanted to remove the confounding

We measured the time from pressing the button in the toolbar to selecting the specified web page indicated by the

color swatch on the top-left. If an incorrect web page was selected the timer continued until the correct web page was selected. Incorrect selections were also recorded.

switching interface. Therefore, we can not confirm hypothesis H2 that there are more erroneous selections in the Cards interface than the Pages interface.

Once a trial ended, a new color for a new trial was presented to the user. Each time, we ensured the user had to travel a predetermined distance from the current page. Participants traverse every possible distance twice for a given condition (2 through N-1, where N is the number of web pages in the condition). For example, if a participant was in the condition with 8 web pages, they traversed 2 through 7 web page distances, traversing each distance twice. The distances to traverse was chosen randomly without replacement from the set, as well as the start positions and colors of the web pages. This was done to mitigate possible learning effects between trials.

However, regardless of the switching interface, a significant effect (F(2,78)=22.82, p < 0.001) was found for the number of web pages. Post-hoc comparisons using Tukey HSD method identified a significant difference between 4 web pages and 16 web pages; and 8 web pages and 16 web pages. No significant effect was found between 4 web pages and 8 web pages.

Procedure: Before the experiment, we informed the participant that they were going to be asked to perform a series of selection tasks. Participants were not told that they were would be selecting colors that represented web pages based on the Pages and Cards interfaces, although one of the 14 participants figured this out. The experimenter first demonstrated either the Pages or Cards interface. Participants were asked to practice using the interface by selecting a few colors. When the participant was comfortable with the application, the participant then did all trials for the condition. Upon completing all the selection tasks for a given condition, the experimenter saved the data and the participant was asked to complete a simplified version of NASA-TLX, focusing on perceived success, effort and frustration. Participants repeated this procedure for 4, 8 and 16 web pages based on the predetermined latin-squares order.

a)

The above procedure was then repeated for the other interface. At the end of the experiment participants were asked which interface they preferred and why. RESULTS

Selection Time: Figure 3a shows a chart for the mean total time to select web pages using the Pages and Cards interfaces. A repeated measures analysis of variance on the natural logarithm of the selection time found a significant effect (F(1,78)=86.57, p < 0.001) between the Pages and Cards interfaces, regardless of the number of web pages in the switching interface. Therefore, we can accept hypothesis H1 that it is quicker to switch web pages in the Cards interface than the Pages interface. No interaction effect was found between the web page switching interface and the number of web pages (F(2,78)=1.5, p > 0.05). Error Rates: Figure 3b shows a chart for the mean total errors when selecting web pages when using the Pages and Cards interfaces. A repeated measures analysis of variance on mean total number of errors found no significant effect (F(1,78)=2.15, p > 0.05) between the Pages and Cards interfaces, regardless of the number of web pages in the

b) Figure 3. The mean total time (a) and errors (b) to select web pages using the pages and cards interfaces

Cognitive Load: Friedman tests on the NASA-TLX data showed a marginally significant effect between the Pages and Cards interfaces when they included 8 web pages (C2 (1, N=13) = 2.78, p < 0.1) or 16 web pages (C 2 (1, N=13) = 3.00, p < 0.1), where participants perceived the Pages interface as more frustrating than the Cards interface. Overall, 7/14 participants preferred the Cards interface, quoting the speed of web page selection with this interface.

4/14 participants preferred the Pages interface describing it as “cleaner”, “more familiar” and “more intuitive”. It is worth noting that these participants were iPhone users. The other 3 participants liked either the Pages or Cards interfaces depending on the number of web pages in the interface. These participants preferred the Pages interface for a smaller number of web pages; and the Cards interfaces for a larger number of web pages. DISCUSSION

Our experiment showed that it is faster to switch web pages in the Cards interface compared to the Pages interface. A reason for this is that the Cards interfaces shows at least 3 to 4 visible web pages at once, depending on the position of the current selected web page in the stack of cards. As such, if the web page was immediately visible it could immediately be selected. Whereas, in the Pages interface a user would have to swipe to the web page they wished to selected and then select it. Therefore, the Cards interface required less interaction than the Pages interface and was hence faster to select web pages. “I liked the second one [the Cards interface] because I could select a color from a groups [the visible web pages] I could pick any of the 4 right away.” “If I am on my phone, I want to see a lot of things quickly. [With] the Pages I can only see a page at a time. That is not the best way to do mobile.” NASA-TLX results show evidence of frustration amongst participants with the Pages interface. A reason for this is that it took additional interactions to select a web page using the Pages interface compared to the Cards interface. “Swiping left and right was hard. It was not as smooth going back and forth as going up and down.” As such, not only is it faster to select web pages with Cards interface, it is also less frustrating compared to the Pages interface. A similar result was found in previous research on tree browsers, where squeezing more information onto the display enabled subjects to make multi-hop jumps toward the information they need [7]. Similarly, here the Cards interface is able to squeeze more pages onto a single screen, enabling users to make longer distance switches. On the other hand, because the Cards interface displayed more web pages at once, we hypothesized that participants would make more errors due to the small target size of the web pages compared to the Pages interface. One participant in our study also expressed this concern. “I was afraid of touching the lines of the page and selecting the wrong one.” Surprisingly, our experiment showed that there were no significant differences in erroneous selections for the Cards and Pages interfaces. This raises the question how far the target size of the web pages could be reduced while not

increasing erroneous selections and reducing recognition of the thumbnails. However, there was an increase in the number of errors as the number of web pages in the switching interface increased. This may have been the result of an increase in cognitive load. Friedman tests on the NASA-TLX data showed a significant effect (C2 (1, N=13), p < 0.001). As the number of web pages in the switching interface increased, perceived success decreased and perceived effort and frustration increased. CONCLUSION

The results suggest that the Cards interface enables faster switching, is less frustrating when navigating a large number of web pages, and does this without significantly increasing erroneous selections. These findings could generalize to interfaces for mobile task management and information spaces, where a Card-based interface could provide an efficient and better interface for switching by decreasing the number of interactions and time to switch as well as reducing users’ cognitive load. As mobile use continues to climb, research in helping users manage tasks on these devices will become more important. We believe we have made a step toward greater understanding of how to design for mobile information spaces. REFERENCES 1. http://developer.apple.com/library/ios/#samplecode/PageContr ol/Introduction/Intro.html#//apple_ref/doc/uid/DTS40007795 2. Card, S. K. & Henderson, A. H. Jr. A multiple, virtual workspace interface to support user task switching. In Proc. CHI 1987, ACM Press (1987), 53-59. 3. Cui, Y. & Roto, V. How people use the web on mobile devices. In Proc. WWW 2008, ACM Press (2008), 905-914. 4. Dubroy, P. & Balakrishnan, R. A study of tabbed browsing among mozilla firefox users. In Proc. CHI 2010, ACM Press (2010), 673-682. 5. Holz, C. & Baudisch, P. Understanding touch. In Proc. CHI 2011, ACM Press (2011), 2501-2510. 6. Kaasten, S. Greenberg, S. and Edwards, C. How people recognize previously seen web pages from titles, URLs and thumbnails. Report 2001-692-15, Department of Computer Science, University of Calgary, Alberta, Canada, November. 7. Pirolli, P., Card, S. K. & Van Der Wege., M. M. 2000. The effect of information scent on searching information: visualizations of large tree structures. In Proc. AVI 2000, ACM Press (2000), 161-172. 8. Robertson, G., Czerwinski, M., Larson, K., Robbins, D. C., Thiel, D. & Dantzich, M. 1998. Data Mountain: Using spatial memory for document management. In Proc. UIST 1998, ACM Press (1998), 153-162. 9. Tossell, C., Kortum, P., Rahmati, A., Shepard, C. and Zhong, L. 2012. Characterizing web use on smartphones. In Proc. CHI2012. ACM Press (2012), 2769-2778.

Web Page Switching on Mobile Browsers - Research at Google

May 2, 2013 - running Android 4.1 with a full-screen web-view .... “If I am on my phone, I want to see a lot of things quickly. [With] the ... CHI 2010, ACM Press.

265KB Sizes 3 Downloads 502 Views

Recommend Documents

Object Views: Fine-Grained Sharing in Browsers - Research at Google
and even a small developer mistake in such a signature may expose the entire system .... Delegating Responsibility in Digital Systems: Horton's. “who done it?”.

QuickSuggest: Character Prediction on Web ... - Research at Google
Apr 30, 2010 - used by some automobile GPS navigation devices. Unlike some previous .... substantially. Training the language model on the same do-.

Pseudo-randomness Inside Web Browsers - Springer Link
for JavaScript programs to access operating system services for retrieving random or entropy values without changing Web browser security poli- cies.

Remedying Web Hijacking: Notification ... - Research at Google
each week alerts over 10 million clients of unsafe webpages [11];. Google Search ... a question remains as to the best approach to reach webmasters and whether .... as contact from their web hosting provider or a notification from a colleague ...

Designing Usable Web Forms - Research at Google
May 1, 2014 - 3Dept. of Computer Science ... guidelines to improve interactive online forms when .... age, level of education, computer knowledge, web.

Protecting Browsers from Extension Vulnerabilities - Research
separation, and strong isolation into our extension system. Instead of running with ...... Jackson, Matt Perry, Dawn Song, David Wagner, and the. Google Chrome ...

Web-scale Image Annotation - Research at Google
models to explain the co-occurence relationship between image features and ... co-occurrence relationship between the two modalities. ..... screen*frontal apple.

web-derived pronunciations - Research at Google
Pronunciation information is available in large quantities on the Web, in the form of IPA and ad-hoc transcriptions. We describe techniques for extracting ...

Improving Access to Web Content at Google - Research at Google
Mar 12, 2008 - No Javascript. • Supports older and newer browsers alike. Lynx anyone? • Access keys; section headers. • Labels, filters, multi-account support ... my screen- reading application, this site is completely accessible for people wit

Cascode Switching Modeling and Improvement ... - Research at Google
cascode GaN FET technology. Experimental results of a 20W phase-cut dimmable LED driver are demonstrated to verify the proposed modeling method and solutions. Index Terms—Cascode Switching, Universal AC Input,. Dimmable LED Drivers, Small Signal Mo

Insecure Context Switching: Inoculating regular ... - Research at Google
For most computer end–users, web browsers and Internet ... Apple Safari, Perl, GnuPG, and ICU. .... attention due to its use in attacking Apple's Safari web.

Web Browsers as Operating Systems: Supporting ...
as padlock icons for HTTPS (i.e., HTTP over a secure transport layer). ..... allowing policy authors to focus on higher level abstractions like filesystem paths.

Automatic generation of research trails in web ... - Research at Google
Feb 10, 2010 - thematic exploration, though the theme may change slightly during the research ... add or rank results (e.g., [2, 10, 13]). Research trails are.

Swapsies on the Internet - Research at Google
Jul 6, 2015 - The dealV1 method in Figure 3 does not satisfy the Escrow ..... Two way deposit calls are sufficient to establish mutual trust, but come with risks.

DRAFT 5/5/2008: Estimation of Web Page ... - Research at Google
Figure 1: Illustration of two different fixed crawl cycles over time, where each blue circle is a page ... Figure 2: 50 simulated estimation paths using the irregular.

a motion gesture delimiter for mobile interaction - Research at Google
dition, Rico and Brewster [10] reported that users rated motion gestures more .... using the Android SDK [1] for use on the Nexus One phone with a Qualcomm ...

Query Suggestions for Mobile Search ... - Research at Google
Apr 10, 2008 - suggestions in order to provide UI guidelines for mobile text prediction ... If the user mis-entered a query, the application would display an error ..... Hart, S.G., Staveland, L.E. Development of NASA-TLX Results of empirical and ...

Computers and iPhones and Mobile Phones, oh ... - Research at Google
Apr 20, 2009 - predominantly from desktop and laptop computers) that were .... 10. Query Category Distribution. Percentage Difference Compared to Desktop.

Mobile Computing: Looking to the Future - Research at Google
May 29, 2011 - Page 1 ... fast wired and wireless networks make it economical ... ple access information and use network services. Bill N. Schilit, Google.

Understanding information preview in mobile ... - Research at Google
tail and writing responses to a computer [14]), a better un- derstanding of how to design ... a laptop or desktop is that the phone requires a lower level of engagement [7]: .... able, with a range of 10 to 100 emails per day (M = 44.4,. SD = 31.4).

Incremental Clicks Impact Of Mobile Search ... - Research at Google
[2]. This paper continues this line of research by focusing exclusively on the .... Figure 2: Boxplot of Incremental Ad Clicks by ... ad-effectiveness-using-geo.html.

RAPID ADAPTATION FOR MOBILE SPEECH ... - Research at Google
A large number of the ... number of parameters in MAP adaptation can be as large as the ..... BOARD: Telephone Speech Corpus for Research and Devel-.

On Distributing Symmetric Streaming ... - Research at Google
¶Department of Computer Science, Dartmouth College. This work was done while visiting Google, Inc., New York, NY. financial companies such as Bloomberg, ...

Question Identification on Twitter - Research at Google
Oct 24, 2011 - It contains two steps: detecting tweets that contain ques- tions (we call them ... empirical study,. 2http://blog.twitter.com/2011/03/numbers.html.