Re: [Usability] Re: A bunch of UI issues

[lukekendall optushome com au]

On  6 Feb, David Moles wrote:
>  On Wed, 2002-02-06 at 05:01, lukekendall optushome com au wrote:
> > 
> > (If you clicked in the middle of a scrollbar, you jumped to the middle.
> > If you clicked at the top, you jumped straight to the top.  It was
> > brilliant. Page up and down were by shift-click on the up/down arrows,
> > which of course were adjacent rather than at opposite ends of the
> > scrollbar.)
>  
>  What I don't understand about that is why they put them only at one
>  end. :)

True.  I imagine it was just to conserve scrollbar space.  Not really
compelling, it seems, until the active area became quite small; in
which case I guess one set should vanish, since the effort involved in
moving from where the cursor is, to the scroll arrows would then be
small anyway.

Oh, wait, I see - then you've got widgets appearing and disappearing,
requiring more conscious effort by the user.  Once the user has become
accustomed to the arrows being in a particular place, then no conscious
thought is required to head off in that direction.

So, I actually think that it was a wise choice.

Certainly, whenever I've really thought about features of the Nextstep
user interface, I've been impressed by the depth of good thought that
went into it.  That or ludicrous amounts of blind luck.  :-)

> > I always thought that a scrollbar where you could just to mark the
> > current position (so a clickable mark would appear in the scrollbar),
> > would have been incredibly useful.  Like vi's mark and jump (m and ')
> > functions for jumping around in a file to places you decided were
> > significant.
> > 
> > The problem with David's suggestion is if you paged through a context,
> > the scrollbar would be filled with ghost images.
>  
>  I was thinking of just leaving one ghost the last place you went --
>  solving the "Wait, I didn't want to scroll after all" problem which
>  seems to be what MS' snap-back-if-you-drag-too-far-sideways "feature"
>  is supposed to solve.

Agreed, that would solve that $ #^& feature that MS is so fond of.

>  A bookmarkable scrollbar would be something else (and also pretty 
>  cool if it could be done cleanly enough.)

Sure.  I guess I saw more possibilities in your suggestion.

Anyway, it wouldn't require much effort; you'd only need to record
linear positions.  E.g. if you were scrolling in a text file, you need
to record the line numbers that have been flagged, and do an integer
division for each to display it at the appropriate place. (You need to
recalculate if the number of lines changes.)

I imagine a growable array of ints would be a good data structure.
You'd also need to be provide a function to note edits, to keep the
bookmarks displayed in the right place.  It would record an addition (or
deletion) of a bunch of lines.  You'd also need a function to bookmark
a scrollbar position, and one to delete a bookmark.

Note that I imagine the bookmark as being just a 1-pixel horizontal
black line in the scrollbar, and hit-detection being used.

Slightly more complex data structures would be required if you wanted
full vi mark and jump functionality (i.e. where you can assign a 1
character label to a position, so you can jump to it by name as well as
by mouse click).

luke