Blake, You address the issue of scrolling very well, but not the principal issue.
You say that "1 pixel = 1 post" without offering a rationale for *why* this is important. I find the proxy argument uncompelling for two reasons: 1) We don't really need a proxy when there is already an *explicit* count of posts in the navigator. 2) We could have a *global* post width, which is permanent across searches. So, "X pixels = 1 post" — you'd still be able to see changes as you search. This global limit would be calculated such that the timeline would not be less than 50% full when all posts are displayed. The fact is, the timeline is basically unusable for the vast majority of blogs. Most people have *not* been blogging for 5 years, with hundreds of posts. Even I find the timeline unusable, with my meager comment/post count. If you oppose the change to dynamic sizing, please provide an alternate proposal. Simply ignoring this usability issue does not make it go away. As for the timeline scrolling, we do still need to do fix that, since there will be a floor of 1 pixel = 1 post. At this point, I think the optimal solution is a combination one: 1) Make the timeline scroll automatically when the loupe is dragged to the edge. 2) Have arrows "fade in" when you hover near either extreme. You can then click the arrow to move. I don't like the idea of making the whole time draggable, simply because it confuses what "dragging" means in the UI. The same action shouldn't do two different things in roughly the same UI element. On Jul 27, 2009, at 5:38 AM, Blake Johnson wrote: > > On Jul 23, 3:49 pm, Arthus Erea <[email protected]> wrote: >> Right, I definitely thought of this issue. >> >> To resolve it, there will be a floor of 1 pixel = 1 post. That way, >> it'll never become so small as to be unusable. >> >> Horizontal scrolling will be implemented as needed. >> > > I dislike the idea of having dynamic sizing. I like that the size of > the timeline is a good proxy for the number of posts. This is > especially useful when entering search terms. If we leave 1 pixel = 1 > post (the current size), then we still have to deal with scrolling > anyway. > > I have been toying with some different ideas for how entire timeline > scrolling can be accomplished. The old method, which was a bit clunky, > was that the whole thing slid when you held the loope at either > extreme of the timeline. This is fairly easy to re-implement (I have a > hacky version that kind of works), but it if we do go with this, I'd > like to at least modify things such that the scrolling speed is > dependent on how much the mouse moves beyond the bounds of the > timeline. > > Other possibilities include: > - make the whole timeline draggable. This would be very natural to use > and would require no additional UI elements. However, it would mean > that the mouse cursor would display as a hand for any mouse hover > position over the timeline, not just over the loope. > - add an additional scroll bar-like UI element below the timeline when > needed > - add arrows to the left and right of the timeline which can be > clicked to scroll > > My plan has been to try all of these and play with them to see what I > like best. Opinions are welcome. > > --Blake > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/habari-dev -~----------~----~----~----~------~----~------~--~---
