Why scrollbars are on the right and other stories

1997’s paper by Alan Dix, published with author’s permission. Reprinted from Interfaces #37, 1998, pp. 19-22.

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.

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

Sinister positioning?

Think of the reason for using a scrollbar. You have a document or list and want to find something. So you scroll a bit, examining the document as you go until you find the required position in the text or list. Now, consider your eye movement throughout this. For English and European languages the text is read from left to right and, furthermore, for lists of titles or names, it is usually the first few characters or words that are significant in identifying whether you are at the right place. So, your eye has to constantly scan from the scrollbar on the right (which you are controlling with a mouse and thus need to look at) to the start of the text on the left. To feel this in the extreme try resizing a window to make it very wide and short and then scroll to find something.

Brewster et al. describe “kangarooing.” This happens on scrollbars where the user can click on the scrollbar below the handle (or “thumb”) causing the window to jump down a screenful. However, when doing this, at some point the handle jumps below the current mouse position and so the page jumps back up on the next mouse click, then down again, etc. If the material is being quickly scanned it may not be apparent at first that this is happening and it is certainly confusing for both novice and expert. As Brewster et al. point out, the feedback of the moving scrollbar can be quite small, hence is easy to miss even if you are looking at it, which, given the important information is on the left of the screen, it is highly unlikely you will be.

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? (see appendix 1 below)

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.

Figure 2. Browser – initial design

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.

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

Figure 4. 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...?

by Alan Dix, School of Computing, Staffordshire University, 1997.

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.

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.

Appendix 1: The exception proves the rule

Main window of Anubis Mounter

Although most scrollbars are now found on the right, I have come cross one recent exception, the scrollbar on the Anubis Mounter control panel. This is a Macintosh utility for mounting SCSI devices whilst the Macintosh is running, avoiding having to shut down and restart the machine every time a device is added. The control panel has a “designer” style very different from the normal Macintosh look and feel. Because of this it does not use the standard Macintosh built-in widgets and hence the builders had free reign.

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!

Appendix 2: Sinister Scrollbar in the Xerox Star Xplained

(written in 1998)

In the article above, I explained how the scollbar first moved to the right in the Xerox Star interface, but that I did not believe this was the correct place for it. Whilst at the CHI98 conference I was able to talk to David Smith, now of Stagecast Software, who worked as part of the Star design team.

He explained how the movement of the scrollbar to the right was not an accident, but a deliberate design decision. The reasoning was that precisely because the left-hand side of the screen is important for reading text it is also important to keep it clear of unnecessary visual clutter. Hence the scrollbar, that had been on the left in the Smalltalk and InterLisp environments, was moved to the right-hand side.

So, given my pronouncement that the right-hand side is a bad idea, am I wrong or were they?

In fact, the answer is that the Xerox Star scrollbar is fundamentally different from current scrollbars and hence the problems I highlighted with current right-hand scrollbars do not apply to the Star scrollbar.

Looking at the Star scrollbar (right), it has three types of control:

1. the arrows which move the text a line at a time
2. the +/- buttons which move the text a page at a time
3. the scroll area with its diamond shaped “handle”

The arrow and page up/down buttons are similar to current scrollbar buttons and the scrollbar “handle” similarly allowed one to scroll to any point in the document. The major difference however between this and current scrollbars is that both kinds of large movement (2 and 3) moved to page boundaries. In each case the top of a page is aligned with the top of the screen. This is very similar to the redesign of the page up/down buttons in my previous article and the disorientation as one tries to match the old and new pages is thus not an issue. Only the line up/down buttons move the text to other, non-page-boundary offsets. This is also not a problem as the small movements make reorientation easy and for repeated line-by-line movement it is possible to position the mouse and then watch the screen as the mouse is clicked or held down for continuous scrolling.

As the Star evolved into the current Macintosh, Windows and X environments, the design changed to the current dragging form where the “handle” is grasped by the mouse and moved to an arbitrary point in the document. The design changed, but the rationale for placement was not revisited leading to the current, unsatisfactory situation.

Another bit of design rationale that got lost in this transition was the direction of the arrows on the scrollbar. On most current scrollbars the line-by-line arrows point outwards whereas the Star arrows pointed inwards. In both cases pressing the upper arrow makes the window move upwards in the text (and hence also the scrollbar handle upwards). Recall, there is no obvious “right” answer for this. If the arrows point outwards they match the movement of the handle, but the text moves in the opposite direction (as you move up the document the text moves down). If instead, the arrows point inwards they match the movement of the text on the screen, but oppose the movement of the handle (the downwards arrow moves you upwards in the document).

David Smith described to me how in the first version of the design documents for the Star, the scrollbar arrows pointed outwards as they do in modern interfaces. However, unsure of the correct orientation, the Star design team performed user studies with both orientations. Whereas the software designers were quite happy with the outwards form, the non-computing users were uniformly confused by this direction of arrows, hence the inwards pointing arrows were adopted for the final Star design. Unfortunately when the Star design documents were passed on to the later design teams for the Lisa and Macintosh, the initial, wrong version of the scrollbar designs was used! Hence we came by our current scrollbar arrow direction by accident and it is precisely the opposite of what was found to be easy to use.

In both these examples, we see that apparently minor design changes can radically affect the feel and behaviour of an interface widget. Little things really do matter.