Re: scroll bar and drop down list usability

[famrom idecnet com (Guillermo S. Romero / Familia Romero)]

>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?

<personal>
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, and the size is smaller. All mouses I own have three real buttons,
no problem with hands, most apps use them (some even force you to use three,
so a wheel is no-no for me, I even had some hand ache when tried a friend's
one, thanks, but no wheel for me). After all, GNOME is about making things
better, not about buying new hardware.
</personal>

And btw, wheel is single direction, not a complete solution for a 2D thing.
So yeah, maybe great for some users, but if you want a good solution, it is
not, except if you put one letter below each other in your docs. ;] Ok,
exagerated, but you get the idea (not all is text, imagine image scrolling).
We need a good solution that works most of times.

>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.

Gimp does that, Blender does that... many other apps do that. And it must be
great cos I always try to repeat it even in apps that do not support it. For
big docs the best is click, move in a direction and it auto scrolls, the
farther you move the cursor, the faster ths scroll is (like a flight
simulator joystick).

Sometime ago somebody proposed something like this, but placed in the corner
that scrollbars left unused... Fitt's Law "under the cursor" (in working
area, I mean) is even better. Not intuitive, but once a user learns it, he
will try everywhere.

About intuitiveness... lot of things are not, but in the same way that you
expect that a car buyer will read where are the car buttons, you expect he
will read one or two pages with widget descriptions (the description of this
system are two lines, six if you explain it better using small photos to
show "joystick" cursor in action).

>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?

In emacs, hit c-s, then start to type what you want to find. ;]

But the thing about scroll bars is not only about text, other things will
also improve with better system (an integral scroll control).

>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.

Some apps do that, others do not. IMHO drawing scroll bars when you do not
need is a GUI bug.

>BTW, scrolling on menus (including drop-down option lists) is evil. I'd
[...]

That is a famous GUI bug. Report if you see it in a GNOME app.

>> >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?)

Well, emacs scroll bar is not the typical one, and I use it a lot (more than
the rest of scroll bars, I mean). MB1 scrolls down (like an arrow, but there
is none), MB3 scrolls up, MB2 jumps. Weird the first time, but can move
quite faster with it. No feedback the first time, but the area to put mouse
is bigger if you want to scroll in small steps (MB1 or MB3), and gives ultra
fast movement when you want it (MB2).

>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.

Well, some times yes, some times no. Another problem I see is that as lot of
people already use scroll bars, should we use them even if there is a better
method? The joystick thing sounds far better... and it is used to move
applet in the panel, btw. Haha, one thing for lot of situations (minor
variation, panel is drag and drop, joystick will be click and move in the
direction you want to scroll, so you do not have to drag, realease, move
back, drag, release... for big docs, like Adobe's PDF viewer, which is a
pain for docs with 100 pages).

>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
[...]

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. Well, in reality I do not like animations at all (guess how my
autohide panels are set).

> * Immediate feedback -- when the thumb moves the document should too.
[...]

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).

> * 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.)

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.

Blender, a 3D apps uses something like your joystick and key combo, with 2
keys (MB, MB+key1, MB+key2) so you have three actions and you can zoom,
scroll and rotate quickly (remember, it is about 3D). But read above for a
good (?) joystick for 2D.

> * 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.

That is a great idea, no more "jump here and then find page 10". Like Jim
idea of a mini representation of the doc.

>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.

Acorn was good too, MB1 normal action, MB3 inverse. But placing the arrows
in the thumb is even better, all is in one place, less mouse movement.

>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!)

Gimp has that... uumm, I should check it, but I think it uses a small copy
of your image, with a rectangle of your current window, as you move it you
change your view. Jim thing about text, but for images. Thumbnails, even
coarse ones, are enough to know where you are.

GSR