Recently Eric Meyer wrote a little rant on the counter-intuitive manner in which most weblogs are organized; posts in reverse-chronological order on the main page and chronological order on archive pages. Eric later brainsormed possible solutions for the poor organization of weblogs. The solution that he proposed centered on the creation of a threaded-list UI for blogs that, along with cookies used to record a visitors reading history, would help separate read and unread posts from each other.
While something like what Eric proposes could be a helpful change from the way weblogs are typically formatted, I think that this might be a case of using a chain saw to slice a tomato. I say this because at the center of Eric's grip with how weblogs are currently organized stems from his experience of frequently needing to skip to older posts to see the context of a weblog's current post:
It's frequently the case that I'll drop by a weblog and the most recent post will refer back to a two-days-ago post, or maybe to three posts scattered over the previous week. In some cases, the most recent post makes no sense without having read the older stuff. So I have to skip to the older material, read it all (making sure I get it in correct order), and then come back to the newest post.
I believe that a good bit of the frustration that Eric expresses here could be avoided if weblog authors provided links to related posts in a clear manner. For example, providing a simple table of contents listing related entries could work wonders here. I'm envisioning something like:
-date- : older entry #1
-date- : entry on another blog related to entry #1
-date- : older entry #2
-date- : this entry
-date- : more recent entry
etc.....
Jakob Nielsen's latest alertbox column, PDF: Unfit for Human Consumption (Alertbox), is a rant on the PDF format's inherent lack of usability.
While I agree with much of what he says, since PDFs are best used for documents that you want to preserve formatting for printing and not for documents which are to be be regularly viewed on screen, I take exception with his comments on the format's inherent navigational shortcomings.
He states that even when a PDF file has its own navigation aides, they don't typically help because they’re nonstandard and based on a paper metaphor rather than hypertext navigation.
First, I'd say that Acrobat Reader's navigational aides, due to the application's widespread distribution, are quite familiar to many users. The application's "paper metaphor" can, admittedly, get in the way of efficient screen reading of PDFs, but this is quite useful for PDFs best use, the transmission of documents for which you wish to preserve a set print format (like forms). Finally, I've found that, through the use of hyperlinks and side-panel table of contents, I've been able to produce PDF files that have been praised for their ease of navigation.
Overall, I must agree with the gist of this article, since too often PDFs are thrown up on a site because it's easier to simply hit a "create PDF" button than transforming content into a usable HTML format.