On Jul 27, 2009, at 7:22 PM, Owen Winkler wrote: > > 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.
If it's too small for you to even see, then I don't see the benefit. > >> 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. Often very easy and simple UI solutions can be mind-numbing. We don't have to *describe* it. The whole point is for it to blend in. For the record, I do not think we need to make anything specific about 50%. The math can be pretty loose, so long as it gets across the basic goal: the timeline is never too small to be unusable. > > 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. I'm not sure how the math in that adds up. Perhaps I should be clear: the target is not explicitly 50%. Every time you post, the post width would get smaller. > > 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. Exactly. When your entire blog is 35 pixels across, it's not exactly easy to do accurate subselection. In contrast, if your blog is 350 pixels across, such subselection becomes much easier. > >> 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 don't think any users are going to understand the 1 post = 1 pixel thing. In fact, they shouldn't have to. All they have to know is that months are displayed relative to the number of posts they contain. Google uses an extremely complicated algorithm that you'd never be able to explain to a user. But users are able to understand what they need to know: these 10 items are what I'm probably looking for. > > 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? I don't think anyone would use it for specific date searching, which is why I find the 1 pixel thing even more mistifying. Largely, I think it's useful for making general time selections. Doing so is difficult when months are displayed at such a small size. Perhaps a better example: someone who has been blogging for years, but only writes a couple posts a month. They could easily have need of such a tool, but it is currently difficult for them to access since each month is small enough to be unusable. > 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. I frequently would like to select a swath of posts, but the timeline is just too small to be useful. Furthermore, it simply is confusing to have small UI elements that users can't understand. Even if they wouldn't have any use for it, it isn't good to have a confusing element occupying a large amount of space on the page. > >> 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. That does not address the original issue, so it cannot be considered a "proposal." > > 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. I suggested 2 solutions. > > 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. First off, your math is a little off. It's more like 99% of the timeline is bare. According to the 1 post = 1 pixel doctrine, there should really only be 1 pixel (of the 750 pixel space) occupied. However, I do agree that we should do this regardless. > These instructions would simply go away after enough posts fill the > timeline to begin to cover the words. Good idea. > 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. No, that is not the intention. The goal is simply to make the timeline *usable* instead of being a cut off blob of random letters in the corner. Quite simply, the human eye has a lot of difficulty in analyzing things 1 pixel wide. When the entire timeline is only a couple pixels wide (even less than 50), it's usability as a proxy is greatly decreased. > 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. Again, that is not my intent. > > 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? I never said anything about positioning the loupe accurately being the primary objective. I'd ask you this: what is the current purpose of the timeline? That is the purpose of this change. > 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. Fine, then let's just stick with automatic scrolling. > >> 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. I'm not sure what you mean by this. Isn't that the usability issue which blake's suggestions attempt to address? To access posts which have scrolled off, just scroll them back in. > 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. Despite their excellent construction, I have always found the Simile timelines to be rather complicated. I think the timeline is complicated enough without introducing even more complexity into an already confusing system. > 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. Agreed. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
