Scrollbars are interesting interaction widgets. They seam so obvious, we don't even notice them. But how did they develop? Watching the new OS X Lion and Ubuntu Unity changes in scrollbars, I remembered two interesting articles about how scrollbars moved from left to right side of the screen and why is the right side not such a good idea ("Hands across the screen" and "Sinister Scrollbar in the Xerox Star Xplained"). The idea is that eyes have to move from the text one is reading on the left side of a screen, to the scrollbar on the right and back, which requires a lot of unnecessary eye movement.
Let's take a quick look at the evolution of scrollbars:
From "Hands across the screen": "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 behavior whereby the scrollbars appeared as you moved
off the left of a window."
2. Moving scrollbars to the right in Xerox Star
From "Hands across the screen": "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"
"Looking at the Star scrollbar (left and 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 above) moved to page boundaries. In each case the top of a page is aligned
with the top of the screen. 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."
3. Remaining on the right ...
... in Macintosh OSes, Sun Open Look, RISC OS, OS2, Windows, BeOS, KDE, Gnome ... and also turned arrows in opposite direction. The size of a drag area also started to vary in size depending how much content there is in the window.
From "Hands across the screen": "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)."
3.1 Macintosh OSes
Notice omitting the top and bottom pages from Lisa to OS 1 and moving top arrow to the bottom from System8 to System 9. The latter change makes sense since it brings the arrow buttons close, so one could move up and down the text without moving a mouse up and down the screen. The grouping of arrows was used before in AmigaOS2, BeOS, Next and SunOS terminal (until v4 I think). In System 7, the scrollbar was omitted if not needed to get some more screen estate and not to confuse users with a nonfunctional scrollbar.
|| 1991 & 1997
| Apple Lisa
|| Mac OS 1
|| System 6
|| System 7 & 8
|| System 9
|| OS X
3.2 Microsoft Windows.
Not much has changed here. The scrollbar was omitted if not needed in Windows 95 (I think, but not quite sure).
|| 1995 & 2000
| Windows 1
|| Windows 2
|| Windows 3.0 3.1
|| Windows 95
| XP & Me
|| Vista & 7
3.3 Other OSes
Open Look had arrows integrated with the slider (something similar was rediscovered years later). The scrollbar could be moved to the left. Open Look and Rics OS had a middle line resembling analogue sliding buttons with Open Look also showing the darker grey line for revealing the amount of context. BeOS had both arrows on the top and on the bottom (similar to the below SunOS Terminal - see point 4.) while Haiku (a version of BeOS) omitted them and used "most standard version". Amiga gadtool scrollbar resembled the Next's scrollbar but was positioned on the right. Risc OS used mouse buttons to manipulate the thumb movement (similar to Athena scrollbar).
4. On the left side
It is interesting that NextStep was bought by Apple and they did not
think that the left side was the right one. Plain Emacs and Ghostview
have scrollbars on the left (if I'm correct the latter uses
Athena Widgets). So do some terminal emulators such us xterm, rxvt, etc (which use Athena widgets or some of Xaw's forks). Some applications allow to move a scrollbar to the right side as well. But it depends on the application and widget
library it uses. AFAIK Gnome (GTK+ widget set) and KDE (Qt widget set) don't have an option for the scrollbar side. Neither do Windows and OS X. Although web text forms can have a left sided scrollbar. PALM has an addon to do this. Other than that ...
5. Potable devices and scrollbars on the right side
On portable and touch screen devices, the scrollbar on the right side makes sense as otherwise one would cover the screen while scrolling the text. They have a minimalistic touch where Arrows are mostly omitted - mostly because of the precious screen estate and other means of navigation (keypad buttons) where scrollbar is used for informing the position. iOS scrollbars come visible when we move the pointer over the right edge of the window. This is so called overlay scrollbar.
| Android v1
|| Symbian 40
|| Symbian 60
6. Overlay scrollbars ...
... are the next thing on the desktop as well. OS X Lion will have them and Ubuntu Unity as well. One can argue whether this is good or not. For portable devices it makes sense since the screen is freed by a few pixels on the right side. But for desktop computers and laptops with wide screens, the gain is not obvious. Although, in a full screen mode we would have less distracting elements.
Canonical has made a video about their overly scrollbar implementation.
Some DESIGN decisions and manipulations EXPLAINED
I already explained some of the design principles. Here are more detailed explanations.
OPEN LOOK scrollbars (left) use the visual
metaphor of an elevator on a
cable, but functionally they are similar to the
Athena Scrollbar widget. The drag area (the thumb in an Athena
Scrollbar widget) doesn't change size; instead, as shown in he below
picture, there is a separate area that indicates the proportion of the
data that is currently being displayed.
Also similarly to Athena scrollbar, Risc OS allowed manipulating scrollbar arrows with pressing mouse buttons. For instance, a left-click on the down arrow might cause
the window to scroll down, while a right click in the same place would
An Athena scrollbar looks and operates differently than a scrollbar provided by a Motif or Macintosh. While Motif and Mac scrollbars have separate parts to invoke different types of scrolling, the Athena scrollbar moves text according to which mouse pointer button you use and how you use it.
|To move text in this direction:
||Place pointer on scrollbar and:
| Either up or down
|| Hold down second pointer button and drag thumb.
|| Text follows pointer movement.
|| Click first (left) pointer button.
|| Scrolls towards latest saved text (towards bottom of window).
|| Click third (right) pointer button,
|| Scrolls towards earliest saved text (towards top of window).
| Either up or down
|| Click second (middle) pointer button
|| Scrolls to a position in saved text that corresponds to the pointer's position in scroll region.
Like the Athena Scrollbar widget, the Motif scrollbar has a “thumb” or
slider that can be dragged up and down to scroll the associated
window. You can also click above or below the thumb to move it a
screenful at a time. Unlike the Athena widget, it also displays arrows at
either end that can be used to scroll line by line. The
associated window scrolls in the indicated direction as long as
the pointer button is held down in one of the arrows.
I'd really like to know the background of other scrollbars design
of the above mentioned systems. If anyone knows something about this issue I'd be glad to include it in this post. I might have also missed some important changes or made mistakes - so please let me know if you see, spot or know something more about scrollbars.