Arthus Erea wrote: > > 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.
An explicit count of posts does not estimate how many posts you've written in a single month. It would be difficult to gauge post counts by month if the width of a post is always changing. Your suggestion itself is a vertical bar of varying width as a proxy for a single post. > 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. A reason not to do this is that it's complicated. Simply compare the descriptions: * One pixel width represents a single post. * A post is represented by a number of pixels equal to a ratio that would never allow the bar to be less than 50% full, but never less than one pixel per post. Just describing the thing is comparatively mind-numbing. The user experience would be confusing -- After they post their second post, the timeline does not change size. Not until after posting 415 posts would the width of the post in the timeline get any larger. The math is not challenging but offers difficulties. For example, with 415 pixels of space to show 2 posts, which of the two is the wider one by one pixel? Maybe we don't care and just fudge it, but these are just a handful of simple considerations that don't come up at all when 1 post = 1 pixel, especially when the pixel-position of the loupe is intended to be critical for the selection of the subset of items. > 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. Whether a blog has 1 post or 5 years of posts, one can reasonably claim that the simple 1 post = 1 pixel is easier to understand than a complicated behind-the-scenes formula. What you're talking about is a cosmetic change with questionable beneficial effect. I find it mystifying that one would even use the bar for exact date searching. Do we have any experience, anecdotal or tested, where users of any experience use the timeline interface to do anything other than page through the posts they have listed, or look at nothing more specific than a swath of posts over a generalized timeframe? It seems paradoxical to me that a person with such a limited set of posts as you describe, having not been a prolific blogger for very long, would even need to make such specific use of the timeline feature. > If you oppose the change to dynamic sizing, please provide an > alternate proposal. Simply ignoring this usability issue does not make > it go away. If you re-read, I think you'll see that the alternate proposal is to do exactly what we're currently doing -- one pixel equals one post. If anything, any adequate solution to the original usability problem is still undetermined. The issue is that new users don't know what that timeline block is for. A simple display of the words "TIMELINE - drag the loupe to highlight a range of items to display" (or whatever verbiage is more descriptive) in the left 30-50% of the timeline that is bare immediately after installing Habari would give users all of the information they need, and completely address the issue. These instructions would simply go away after enough posts fill the timeline to begin to cover the words. Resizing the posts to be multiple pixels wide doesn't address this issue at all. It seems to attempt to allow users to more carefully select a subset of posts. I posit that there is no reason to do this. The timeline can be paged simply by clicking to the left or right of the loupe, so it's easy to get at the next immediate set of items. Positioning the loupe directly to select a very specific set of items is never going to be exact unless you position the loupe against the markers on the screen. Perhaps you have some unmentioned use case where positioning the loupe exactly over posts that aren't labeled to know what would be selected would be a useful feature? As the utility of widening the per-item rectangle has been described so far, it seems not worth the effort to do something that will complicate the code and user experience. > 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 dislike both the idea of interface elements that don't appear until you hover near them and having to use an additional button control to produce the scrolling effect. We have existing components, and users are familiar with major applications' interfaces that scroll automatically when you drag contents (like the loupe) near their edges. They are also familiar with interfaces that allow you to grab the background and scroll the entire interface. > 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. I don't have a problem with dragging the timeline itself, although there is the tricky business of where the loupe position should rest after the scroll completes. Also, I'm not sure that this would scroll the range fast enough to get at, for example, my 1999 archives within a reasonable amount of time. Perhaps if there was inertia? :) To address the usability issue of accessing posts that have scrolled off the initial timeline, the Simile timeline widget has a useful application of multiple scrolling layers, where each is draggable. Dragging the month layer scrolls time faster than when dragging the day layer. Having a similar, single, small draggable band (or perhaps a loupe on that thing, where each pixel is a week or a month) as the bottom part of the timeline could visually indicate both the range in the view and the overall number of posts that are present, ergo present more value as an additional interface component than just a button that allows scrolling. It should also perhaps be possible to search for a time range using the textbox, since sometimes you just don't want to futz with this crap. Owen --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
