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|
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
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)
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
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!
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.
|Figure 3. Browser – redesign|
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
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?|
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
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.
|Main window of Anubis Mounter|
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
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
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:
- the arrows which move the text a line at a time
- the +/- buttons which move the text a page at a time
- 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,
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.