Re: scroll bar and drop down list usability

[Ken Fox <kfox vulpes com>]

"Guillermo S. Romero / Familia Romero" wrote:
> I dislike mouses with wheel. You get a stupid (for me) thing that works
> partially as three buttons, but not as a full normal one, just something in
> between ...

Microsoft's decision to make the wheel a middle button was very odd. I've
clicked the button hundreds of times while scrolling -- it's something that
I can't seem to learn to avoid. My point wasn't to advocate the wheel as
some great new innovation, but to say that "scrollbars are so hard to use
that they can be improved most by not using them at all."

Speaking of the wheel, does Gnome have any hardware hackers that can design
new interface devices that we can play with? I think it would be really
cool to have keyboard mounted mini-joysticks, left handed function key pads
and other toys to play with. Face it, the hardware companies don't seem
capable of input device innovations. It took 100 years to get a split
keyboard! (And they *still* put the stupid caps lock key in the wrong place!)

> Not intuitive, but once a user learns it, he will try everywhere.

http://www.linuxweb.com/linux_quotes.html:

  The only "intuitive" interface is the nipple. After that, it's all learned.
  (Bruce Ediger, bediger@teal.csn.org, in comp.os.linux.misc, on X interfaces.)

Actually even the nipple isn't intuitive -- hospitals *teach* mothers
how to nurse. (And according to my wife, not all babies use the interface
properly... ;)

> > * Smooth, continuous motion -- we still do way too much line-at-a-time
> [...]
> 
> It should be tried before doing it. IIRC new companies (Eazel, Helix?) are
> into this. From my experiences with smooth scrolling, I get sick. I dunno if
> smooth is bad, or the implementation was bad, or monitor was bad, but I did
> not like it.

The last time I used smooth scrolling was on an old VT220 terminal. I
really like the idea, but it was actually too fast for me to read while
it scrolled. I see no reason why we can't scroll smoothly as fast or
slow as the user wants. We're using incredibly fast hardware when compared
to the VT220!

> Yeah, that is quite important. Emacs? It is funny, emacs is a pain in the
> ass for newbies, but some things are really better than in other apps (after
> all, I see it as the coder editor on steroids).

Emacs is a pain in the ass for everybody -- we just choose to live with it
because nothing else works as well. I use X Emacs (no holy wars please) and
I wanted to adjust the text colors. The interface required me to adjust
every single one independently -- if I didn't I'd get *totally* unreadable
text in the most surprising instances (like during an i-search). That sucks.
This is an example of the developer pushing the hard decisions about color
usability off the end-user.

> > * Try and remember Fitt's law -- scrollbars are usually tiny and far away
> >   and that makes them very hard to get to. ...
> If in the right, they are far, if in the left (where most of text is, no?)
> they are not. Also the emacs way, where all the scroll is a target, the
> problem is not so big.

I fail to see how the relationship between the text and scrollbar has
anything to do with Fitt's law -- it's the distance from the pointer to
the target that is important. Unless you have a nice terminal that hides
the pointer when you type, you will probably move the mouse *away* from
the text (or you have click-to-focus in which case the mouse could be
anywhere on the screen). If you are in the middle of selecting text,
you probably *start* at the left and drag out the selection to the right.
If the next thing you want to do is scroll, you'll be farther away from
the left side than the right (or at least moving in the wrong direction).

- Ken