I think one of the most loathsome and ubiquitous UI sins is the "show more" style of navigation, where some ajaxy cruft goes and makes the page longer, propagated with more data. Paginated navigation (ex: flickr) is much friendlier and lends itself well to digging deep into the past whereas services such as Twitter, Brightkite, facebook and the like have practically solidified their role as platforms for ephemeral and trite chatter with one simple UI decision.
Except that every goddamn webapp completely fucks up pagination! They all implement the completely braindead pattern where the most recent N posts are on page 1, and then count up into the past. The resources found on "Page 2" get pushed down every time a new item is posted.
It really couldn't be any shittier, and only a handful of people have ever implemented anything else. It also makes it impossible to usefully cache the whole page, which is just deadly for an API.
At minimum, your page numbers should be in the same reverse order that your content is. A better implementation is to have the pages represent fixed periods of time (hours/days/weeks/months/years).
It's better to not expose paging in the UI than to cock it up like everyone else. Having real links to "Page 2" in Twitter's timeline would be a terrible idea -- it would be anything but a permalink, as the content would change completely 20 tweets later.
I would totally get behind one page = a given time window, as long as the time window is configurable, or at the least, page n is an offset from what was the first item on the first page when you started paging.
Well. I don’t agree. At least for search this is a useful approach much of the time. Especially in cases where there is some non-transparent (e.g. not newest first or something like that) ordering of the results and if there are many of them.
So this has its applications and calling it a “loathsome […] UI sin” is more than a bit over the top.
Perhaps a little over the top, but I stand by my assertion that search is not an excuse for having no intuitive way to reach into the past on a timeline.
Comments
I think one of the most loathsome and ubiquitous UI sins is the "show more" style of navigation, where some ajaxy cruft goes and makes the page longer, propagated with more data. Paginated navigation (ex: flickr) is much friendlier and lends itself well to digging deep into the past whereas services such as Twitter, Brightkite, facebook and the like have practically solidified their role as platforms for ephemeral and trite chatter with one simple UI decision.
Except that every goddamn webapp completely fucks up pagination! They all implement the completely braindead pattern where the most recent N posts are on page 1, and then count up into the past. The resources found on "Page 2" get pushed down every time a new item is posted.
It really couldn't be any shittier, and only a handful of people have ever implemented anything else. It also makes it impossible to usefully cache the whole page, which is just deadly for an API.
At minimum, your page numbers should be in the same reverse order that your content is. A better implementation is to have the pages represent fixed periods of time (hours/days/weeks/months/years).
http://www.dehora.net/journal/2008/07/20/efficient-api-pagin... is the only clear elucidation of this insanity I've seen.
It's better to not expose paging in the UI than to cock it up like everyone else. Having real links to "Page 2" in Twitter's timeline would be a terrible idea -- it would be anything but a permalink, as the content would change completely 20 tweets later.
I would totally get behind one page = a given time window, as long as the time window is configurable, or at the least, page n is an offset from what was the first item on the first page when you started paging.
Well. I don’t agree. At least for search this is a useful approach much of the time. Especially in cases where there is some non-transparent (e.g. not newest first or something like that) ordering of the results and if there are many of them.
So this has its applications and calling it a “loathsome […] UI sin” is more than a bit over the top.
Perhaps a little over the top, but I stand by my assertion that search is not an excuse for having no intuitive way to reach into the past on a timeline.
Twitter still supports pagination, it just isn't exposed in the UI.
http://twitter.com/?page=20
Your screen is infinite. It isn't a book, it doesn't have pages. I appreciate the "show more" style of navigation because it fits how the screen is.