Hands across the screen

Full reference:

A. Dix (1998).
Hands Across the Screen - why scrollbars are on the right and other stories.
Interfaces 37 pp. 19-22. Spring 1998.
(also appears as SOCTR/97/06, Staffordshire University, 1997)
http://www.hcibook.com/alan/papers/scrollbar/

See also:

short update article after conversations with Xerox Star developers: Sinister Scrollbar in the Xerox Star Xplained. Interfaces 38 p. 11. Summer 1998.

my pages on why little things matter in interface design

discussion in comp.humanfactors on Why are the scrollbar placed at the righthand side of the document frame?

Why are scrollbars on the right, and is it the best place for them? There are good reasons to think that the left-hand side may be the better choice, but in virtually every interface since the Xerox Star the scrollbar has appeared on the right-hand side. In this short paper we'll look at this issue and also at the design of a browser several years ago, which raised similar issues in the placement of on-screen buttons. In both cases, the best placement does not look right when you see it statically, but feels right when it is used. The reason for this discrepancy is an aversion to virtual hands across the screen.
keywords: scrollbar, eye movement, screen design, ergonomics

Just another scrollbar

After typing, using a scrollbar must be one of the commonest actions in a graphical interface. As with all common widgets, it is easy to assume that there is nothing interesting in its design. Of course, there have been extensions to the basic scrollbar, such as Ahlberg and Shneiderman's (1994) Alphaslider or Brewster et al.'s (1994) auditory-enhanced scrollbar, and if you look back at older scrollbars, the mode of interaction is sometimes quite different. Also there are variations in current scrollbars: in the buttons placed at top and bottom (one arrow top and bottom, both at one end, both at both ends), in the information added to the scrollbar itself (e.g. miniature view of the document lines), in the feedback from the window (continuous while the scrollbar is being moved or jump scrolling when it is released). However, the basic current scrollbar design is taken for granted.

Figure 1. Rapid eye movement

So for both drag scrolling and jump scrolling the position of the scrollbar is problematic and it seems likely that the left hand side is a better design choice. Why then are virtually all scrollbars on the right? *

Origins?

In fact, the early scrollbars in the Smalltalk and Interlisp environments (the direct ancestors of our current WIMP interface), had user-configurable scrollbars, which could be made to appear either side. But the default and norm was on the left. In fact, the Interlisp scrollbar had a quite different interaction from current ones, with velocity-based scrolling, and the curious behaviour whereby the scrollbars appeared as you moved off the left of a window. The design choices around the latter were one of the early examples studied using QOC design rationale (MacLean et al. 1991).

The history of the change from left to right puzzled me for some years, but it was only recently, on a visit to Rank Xerox's Cambridge laboratory, that I first saw a demonstration of GlobalView, the Xerox Star desktop interface. Its scrollbars were on the right (see right here). So the right-hand-side scrollbar appears to have begun there and has been inherited since by the Apple Lisa, then the Macintosh, and is now in virtually all windows interfaces.

Of course, this still leaves the question of why the scrollbar moved to the right.

A digression - arrows

While examining the Star scrollbar it is worth noting two differences from many current scrollbars. First of all note the '-' and '+' buttons. These scrolled back to the top of the current page, or on to the top of the next page respectively. This feature is available on some current scrollbars (e.g. Microsoft Word 6.0). Less obvious is the direction of the arrows. Compare them with your screen. Current arrows tend to point outwards, whereas the Star arrows pointed inwards. It is not that the functionality has swapped round, just the icon and the action metaphor. In the Star interface the arrows pointed in the direction the text would move in the window, the current designs point in the direction the window will move in the document. This is a fundamental problem that cannot be removed, as the text goes down, the handle goes up. The only scrollbar that I have seen which avoids this paradox was in the Spy editor (produced by Rutherford Appleton Laboratory for the PERT workstation) which had the scrollbar arranged horizontally across the top of the document!

A similar problem

Before returning to the question of why the scrollbar is now on the right, I'll recount a design story with a similar problem.

Some years ago I worked on a project that, amongst other things, compared various designs for browsers. The first experiments compared a hypertext browser with one using an outliner style and one using a plain scrolling window (Monk et al. 1988). The last of these was to have two forms of navigation (Figure 2), a scrollbar and page up/down controls. Along the top of the screen was a scrollbar that showed the current position in the document. The user could move to any location by clicking on the scrollbar (no dragging) and was helped in this by the display of section numbers at appropriate points. Now, this was not too long after the publication of Card, Moran and Newell's (1983) classic and the performance implications of KLM were foremost in the minds of the psychologists on the project. In particular, they wanted to avoid the 'homing' time between mouse and keyboard and so we made all controls screen based, using the mouse, with no keyboard controls or short cuts. For page up/down scrolling we thus eschewed the keyboard and decided to put arrow buttons (yes, much agonising over the arrow directions) on the screen. These were positioned to the bottom right as seen in Figure 2.

Figure 2. Browser - initial design

From the beginning something 'felt' wrong with the page up/down buttons. The keyboard seemed easier to use even though you had to move back and forth from the mouse. However, to give a level playing field with the other browsers the scrolling browser was limited to screen-only controls.

After the experiment was complete the event logs were analysed. In traditional fashion, the subjects had practice time with the interfaces before addressing the main tasks. During the latter, none of the subjects assigned to the scrolling browser used the page up/down buttons.

This was not a problem for the first experiment, but later we wanted to run a similar experiment, this time with two versions of the scrolling browser. One version was to have only the numbered scrollbar, the other to have only the page up/down buttons. The intention was to investigate the different cognitive structures subjects built up when jumping about the document with a scrollbar compared with scrolling through the document sequentially. However, to be a valid comparison the two designs had to be equally usable, but the users had very clearly voted with their feet (or at least mice) and it was evident some redesign was necessary.

At this point we needed to move from a vague feeling that something was wrong to a critical analysis of the problem. First of all, why did the keyboard 'feel' OK, despite having to move back and forth from the mouse. A little self analysis showed that one could glance down at the keyboard and then return one's eyes to the screen without watching for the finger to strike the right key. After having fixed the button in space, our well-honed motor system is well able take over in parallel. Furthermore, it was very easy to re-fixate on the place where one left the screen. It is almost as if one had a visual stack, or hypertext 'back' button to return to the last gaze point. In contrast, to 'press' the on-screen page up/down buttons, one had to position the mouse over the correct button. This positioning task appeared to interfere with the ability to re-fixate. Also, until after the positioning was complete, one could not return one's eyes to the screen and this typically happened after the button was clicked.

These differences with the buttons were aggravated by the disorienting nature of bitmap scrolling. On older character-map terminals the screens would often scroll line-by-line upwards or downwards allowing the user to see where text was going or coming from. In fact, Bornat and Thimbleby (1986) deliberately designed screen update policies to promote the correct feeling of movement. In contrast, bitmap screens tended to flash between one view and the next. This has not improved and the word processor I am currently using always redraws lines from the top to the bottom no matter which direction you scroll!

Figure 3. Browser - redesign

Having realised that the crucial issue was disorientation we were able to create a design for on-screen buttons by two simple expedients. First, the page up/down function was modified so that a section heading always snapped to the top of the screen. Because of the application data these sections were always guaranteed to be no more than half a screenful long. This meant that if one were scrolling down, this title would have been the one previously in the middle of the screen and if one were scrolling up it would be the next unseen section above. Second, we moved the page up/down buttons from the bottom right to the top left of the screen, and aligned them so that they were next to the beginning of the first line of text. Thus after clicking the relevant button one's eye naturally moved across to the section heading, thus allowing one to instantly re-orientate.

The difference was phenomenal. Suddenly it became natural and easy to use. This design issue was not the focus of our work, so we never verified the difference experimentally. However, the effect was so marked that experiment was unnecessary.

Success! But why did we automatically put the buttons at the bottom right and why, even after verifying that it 'felt' right, did it still look wrong at the top?

Hands across the screen

It was only years later when considering the right-handed scrollbar that the answer to both conundrums became clear. The right-hand side looks right because to grab a scrollbar on the left, or to press a button on the left would mean your hand would have to move across the screen. Wait - of course your hand doesn't really have to move across the screen, the mouse does, but it feels as if it would have to! In fact, for a touch screen, light pen or stylus the right-hand side is a good idea, but not on-screen. Anyway, what about the left-handed user...?

Figure 4. Hands across the screen?

References

• C. Ahlberg and B. Shneiderman (1994). The Alphaslider: a compact and rapid selector. Proceedings of CHI'94, Boston, ACM Press. pp. 365-371.
• R. Bornat and H. Thimbleby (1986). The life and times of ded, display editor. Queen Mary and Westfield College, University of London.
• S. A. Brewster, P. C. Wright and A. D. N. Edwards (1994). The design and evaluation of an auditory-enhanced scrollbar. Proceedings of CHI'94, Boston, Massachusetts, ACM Press, Addison-Wesley. pp. 173-179. (download full paper in Microsoft Word 5.1 (32K) || compressed postscript (220K) || Adobe PDF (53K))
• S. K. Card, T. P. Moran and A. Newell (1983). The Psychology of Human Computer Interaction. Lawrence Erlbaum.
• A. MacLean, R. Young, V. Bellotti and T. Moran (1991). Questions, options and criteria: elements of design space analysis. Human-Computer Interaction, 6: 201-250.
• A. F. Monk, P. Walsh and A. J. Dix (1988). A comparison of hypertext, scrolling and folding as mechanisms for program browsing. People and Computers: From Research to Implementation - Proceedings of HCI'88, Cambridge University Press. pp. 421-436.

In fact the left-hand scrollbar is particularly important in this control panel. With scrolling text the reader's locus of attention is on the initial letters of each line - on the left. In the Anubis Mounter, the interface has an outliner style showing a hierarchy: SCSI bus - drive - partition. To hide or reveal items within this hierarchy the user clicks on the small triangles to the left. That is, not only is the location of attention on the left, so also is the locus of action. Thinking back to Figure 1, if Anubis Mounter had a right-hand scrollbar, this would be the pattern of not just eye movement, but mouse movement as well!