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