On Fri, Dec 11, 2009 at 3:02 AM, Albert Cahalan <acaha...@gmail.com> wrote:
> It's perfectly reasonable to have a scroll bar that isn't anywhere
> near the edge of the screen. (scrolling a list, etc.) We must not
> forget this when discussing things like "infinite target width".

Of course. My point here is simply that many activities have one large
scrolling content region (or, at least, one primary one); In cases
where the scrollbar is conceptually at the edge of the screen, we
should be sure that it is also technically at the edge of the screen.

In a sense this consideration is orthogonal to the issue of scrollbar
width, in that it should be ensured regardless since it has huge
usability benefits in many likely scenarios (though, as you point out,
certainly not all).

> That said, at least for the common case of the scrollbar being at
> the edge of the screen and possibly elsewhere, there is a solution.
> Scrollbars could widen up as the mouse goes over them, overlapping
> into/above the area that is to be scrolled.
>
> It's a nice solution, allowing for scrollbars 100 pixels wide.

This is an interesting thought, but it seems to me that it's actually
a solution proposed for the wrong circumstance. The scrollbars that
lie at the edge of the screen are the ones that needn't be large,
since grabbing them (assuming they are properly edge-aligned) is easy
regardless of their width.

It's those that float within the UI, such as a scrolling left column
(eg. Pippy examples) that are hardest to target, and which need
adequate affordances to make them usable. Increasing the target area
dynamically on hover is definitely a solution worth experimenting
with.

> Speed is critical of course. Being slow like the Frame would be
> some kind of torture. My best guess for appropriate timing:

I'm not even sure an animation would be critical to understanding this
model. One possibility might be to only increase the size of the
scroll handle (leaving the "bar" itself thin), when the cursor is
within range of it. It could grow from its center, so that it hovers
above yet centered on the bar it belongs to, perhaps settling on a
width 3x that of the bar.

Eben

> a. movement begins in less than 30 ms
> b. movement is done in less than 200 ms (no exceptions ever)
>
> In that time there ought to be 6 to 12 frames drawn. Drop frames
> as required to meet the required performance.
>
> I'm thinking the speed ought to vary, like this:
>
> 0 ms, 8 pixels (begin state)
> 20 ms, 12 pixels
> 40 ms, 16 pixels
> 60 ms, 24 pixels
> 80 ms, 40 pixels
> 100 ms, 72 pixels
> 120 ms, 88 pixels
> 140 ms, 96 pixels
> 160 ms, 100 pixels (end state)
>
> Motion blur would help. (precomputed I suppose)
>
_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Reply via email to