Re: scroll bar and drop down list usability

["Ben FrantzDale" <frantb rpi edu>]

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

I use that in emacs all the time (C-s). I've often tried to use it elsewhere
by accadent. Emulating the emacs behaviour would be usefull (though C-s is
already save and C-f has a different be havior).

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


I've enjoied the behavior of my IBM Thinkpad 600. It has three buttons and
the little red erasor thing between the G and H keys. In Linux the three
buttons are button 1, 2 and 3 but in windows, holding the middle button and
pusing the red thing up and down creates the behavior of a scroll wheel
mouse. This has the Fits' law advantage that the ``grabing hand'' scroling
does (as found in Adobe Acrobat among others) but with those you have to
keep moving the mouse up and down to scroll any distance (you drag up, then
let go then move the mouse down and repete).

I've long thought that it'd be nice if my linux apps worked this way with
the middle mouse button. The problem, of course, is that middle
button==paste. Obviously some windows can't be pated into but for input
windows I suspect this could be avoided by canceling the paste action if the
mouse is pushed more than x amount.

Just 2 more cents :-)

--Ben