Re: scroll bar and drop down list usability

[Ken Fox <kfox vulpes com>]

"Guillermo S. Romero / Familia Romero" wrote:
> >It increasingly strikes me that scroll bars should be located on the left
> >side of windows rather than the right.  The same is true of the button which
> >displays the list for drop down list controls.
> 
> xterm and nxterm allow that. emacs also does that. At least mine (some by
> default, other by config, like the terms).

IMHO this is the least of our problems with scrollbars. I think the entire
design of a scrollbar is sadistic. They aren't bad for showing where you are
in a linear space, but they are *very* hard to use for moving through the
space. The mouse wheel is a superior scrolling device because it avoids the
scrollbars. Can't we do something better than glue a wheel to scrollbars?

For many things we don't need scrollbars at all -- the display space itself
can be used for scrolling/panning. Just click on the space and drag. This
solves two problems: 1) the focus of attention and scrolling area are the
same, and 2) the scrolling area is easy to hit (Fitt's law). For keyboard
scrolling, I think a spring-loaded mode (hold control key or something)
combined with arrows should be standard bindings for anything that uses a
scrollbar.

In "Humane Interface" Jef Raskin talks about a LEAP key which is a simple
incremental search feature used in the Canon Cat word processor. You press
LEAP followed by another key and the display scrolls to the next occurence
of that key -- it's basically incremental text search. I'd like to see that
feature *everywhere* scrolled text is displayed. If we get incremental
search right maybe we wouldn't need so many scrollbars?

Another thing we need to remember is to optimize use of the display so
that scrollbars aren't displayed at all when the information will fit the
screen. I absolutely detest the web browser interfaces that force me to
use vertical and horizontal scrolling to enter text when 80% of the
display is totally unused.

BTW, scrolling on menus (including drop-down option lists) is evil. I'd
like to hear the rationale web designers use when forcing me to choose
the state/province/country/etc. from a list. Not only is that insulting,
but then they make me type in my postal/zip code too! They could figure
out my state by looking at the zip. Oh, yeah, that takes them like 10
minutes to code. Much better to make thousands of users take 20 seconds
each to enter redundant information...

> >Of course I'm assuming a left-to-right language, like english.
> >My cursor is usually close to the left side of the page.  Why not put
> >commonly used controls nearby?  That would make my wrist happy.

For similar reasons I've reached the opposite conclusion. The scrollbar
is usually the least important of all the controls on my display. That
means that it should be way over to the right where it's out of my
concentration. (Does seeing the little bar shrink and wiggle everytime
you add a line to a document annoy anybody else?)

> And arrows in the same place, not one top andother bottom. Some GUIs already
> use it... and IIRC GTK allows it with some themes (experimental?). I think
> this kind of things (where are the scroll bars, where are the arrows) should
> be totally configurable. If is not a great problem in the sense of too much
> options, but will help lot of people (not everybody wants things in the same
> way, nor the same color).

I've heard a good argument that too many configurable options is just letting
the user decide solutions to user interface problems -- usually the hard
problems that the developer can't figure out! I like configuration because
it means I can try out new ideas, but we shouldn't avoid the hard problems
just because we provide configuration.

Anyways, here are some of the things that I think are important with
scrolling.

 * Smooth, continuous motion -- we still do way too much line-at-a-time
   scrolling and that makes it *very* hard to read while scrolling. This
   would be a perfect configuration option: scroll speed. It should always
   be single pixel motion, but with a variable timer between scrolls. (The
   API to applications should still be line at a time -- just have the app
   render the next line into a pixmap and copy it in a scan line at a time.)
   (Ok, I admit, some display devices are so bad that the flicker with
   scan-line-at-a-time scrolling is worse than jump scrolling a line. That
   should be a rare situation though -- most of our monitors work fine.)

 * Immediate feedback -- when the thumb moves the document should too. Don't
   make me guess where I'll be in the document when I release the thumb.
   Dragging the thumb should scroll (smoothly!) as fast as possible; ignore
   the scroll speed I've set.

 * Try and remember Fitt's law -- scrollbars are usually tiny and far away
   and that makes them very hard to get to. Use scrollbars for feedback, but
   not for input. Beginners may use them, but it would be easy to offer
   suggestions for other scrolling techniques if someone is using the bars
   a lot. (I would love to see a joystick glued to the left side of the
   keyboard for panning a document with my left hand while working the
   mouse with my right. The mouse wheel would have fit better on the
   keyboard too -- it doesn't need to be pointed to work.)

 * Add visual references to the scrollbar -- proportionally sized thumbs
   are really nice, but so would table of contents markers (start of pages,
   sections, chapters, etc.). Also, let me mark locations in the scrollbar
   and then jump between them.

I'm agnostic when it comes to the position of the arrows in the scrollbar.
The best design I've seen is Open Look where the arrows were on the thumb
and holding down the arrow warped the mouse so that it stayed over the
arrow even though the thumb was moving. This design works IMHO because I
most commonly grab the thumb and drag and then adjust the display with the
arrows. (Arrows are only useful if the resolution of the scrollbar is too
coarse -- moving the thumb a pixel scrolls the display by more than a few
lines.) NeXT was the next best scrollbar I've seen. The old Microsoft bars
with the fixed size thumbs and far apart arrows were the worst.

> For me something is usefull when I try to do it everywhere (anybody tried to
> scroll with middle button or using a small window in a corner, like Gimp? I
> have done many times, and needed a pair of secs to realize that it will not
> work).

Panners are great, but they need to display more reference information than
scrollbars. If clicking on the panner brought up a little scale model of your
document and all you had to do was move a highlight across the model it
would be easy to use. Sort of like a spring-loaded** Zoom World. (Raskin's
book again. Highly recommended!)

- Ken

** I'm using spring-loaded to mean a mode that the user must exert continuous
   force to keep active -- like holding down a shift key. This is my first
   post on this list and I'm not sure if people know GUI jargon. Should we
   define everything we use and capture them in a FAQ?