Wednesday, July 1, 2009

Huffington Post and the "Quick" Read

Burdensome User-Friendliness and Inconvenient Convenience
Once this blog is really on its feet, I will only be updating every two or three days. But I'm going to be posting a bit more frequently at first, because right now it needs a little more of what's known as "content".

It's something of a truism now (my last post notwithstanding) that our world is moving at an ever-faster pace and our attention is demanded by more and more sources. Nicholas Carr writes:

As people’s minds become attuned to the crazy quilt of Internet media, traditional media have to adapt to the audience’s new expectations. Television programs add text crawls and pop-up ads, and magazines and newspapers shorten their articles, introduce capsule summaries, and crowd their pages with easy-to-browse info-snippets. When, in March of this year, The New York Times decided to devote the second and third pages of every edition to article abstracts, its design director, Tom Bodkin, explained that the “shortcuts” would give harried readers a quick “taste” of the day’s news, sparing them the “less efficient” method of actually turning the pages and reading the articles.

This is not a particularly heartening trend (to be addressed later), but there are at least better and worse ways of doing this from a design perspective. There is a trend in software design, beginning at the start of this decade and peaking with the Web 2.0 craze, of making interfaces that are supposed to be very warm, inviting, user-friendly, and convenient. I suspect this is motivated by developers watching too many high-tech and futuristic movies and TV shows in which all interaction with computers takes the form of big flashing red warning signs, slick-sounding beeps, and large single buttons that do things like launch nuclear wars. (See: the Season 4 premiere of 24, in which a "hacker" is sitting at his computer watching lines of black-and-white text and code whizz by, Matrix-style, when a flashing red box pops up on his screen, and he calls his friend at the Counterterrorist Unit and says, "There's been a corruption on the internet!" Oh, sure.)

Examples of this in real life include Windows ME and XP, and just about anything made by Yahoo. What are supposed to be friendly and easy interfaces end up having two predominant features. The first is that they are ridiculously graphics-laden without being particularly attractive, so that, despite the constant increase in computer speeds, you often get the feeling that computers are far slower than they used to be. And the second is that the new interfaces are so good at thinking they know you what you want to do that they can't listen when you try to tell them what you really want.

Huffington Post and the "Quick" Read
The Huffington Post manages to combine the worst of all these trends: "easy-to-browse" "info-snippets" that are graphics-laden and obstruct you from actually reading the article. For example, if you visit the site today and look under "Most Popular on HuffPost", you will see this picture and headline:

"Say, that sounds enlightening," you think to yourself. You click the link, but instead of the riveting piece of prose you're expecting, you see:


Some may find this a convenience, but I have a hard time believing that this is really meant as a convenience or seen as such by many people. First of all, the preview itself is not a condensed piece of content. It only shortens the article, but still has a great deal of other content, including several links to other articles, and an ad larger than the snippet itself. The purpose is obviously to encourage rapid browsing and increase ad revenue.

But the aspect of the Quick Read that makes it all but pointless is that this "preview" itself takes a few seconds to load -- not even noticeably faster than loading an entire new page. The preview is simply too content-laden. This becomes more clear if you notice what happens in the few seconds after you click a post: the page grays, and a box appears saying, "Your request is being processed." That request is actually an entire new page being requested from the server, processed by the browser, and loaded onto your screen, without opening a new window. The reason there is no noticeable difference in the time involved between the Quick Read and just opening the article itself is that there really is no significant difference as far as the amount of network traffic and processing involved.

What a Useful Preview Might Look Like
If you buy the idea that previews really are a good idea, it seems that there is one basic principle that would make them useful: dramatically shortening the amount of time you have to spend absorbing new content. A major facet of this is making it much faster to access that content. Loading an entire new tab with a new article can take 5-20 seconds. It would be nice if you could first browse a preview that takes substantially less time to load -- say, a fraction of a second.

The key here is, first, to make the preview actually be condensed, meaning it should just be a short snippet of the article along with a link to continue on to the full version. Most of the time involved with loading new pages (and therefore also the Quick Read) is not in fetching the data from the website, but in processing it into something visual and interactive. This is why AJAX has become the cornerstone of Web 2.0 technology: it can take a page that is already loaded, fetch some new data, and use that to invoke minor changes on a page that has already been rendered. The most time-consuming component of accessing new information is removed. There are numerous other web apps suffering from the same problem. The lesson to designers: don't use Javascript to alter page structure that has been rendered -- just alter content, and only what has actually changed.

But in the case of the HuffPost QuickRead and similar features on other sites, even the extra fetching stage is unnecessary. Unless the data you're displaying will increase the page size by several times, or unless it might have changed between the time the user loads the page and the time they access to scripted feature, all of the data can be included in the page itself and simply hidden. This is actually remarkably straightforward: the previews can be put in a hidden element, which the "Quick Read" button then displays. This can occur in just a few milliseconds, or the designer can add snazzy effects like having it fade in over a few tenths of a second, without having to worry about the effect being jerky. I make liberal use of both of these principles in my own web projects.

Making Convenience Convenient
The other crucial flaw with the HuffPost Quick Read feature is that it intrudes on normal use of the site. The scenario that the designers should first have in mind is how the site would work without this feature, and then aim to make it so that the user can use the new feature without having to think about it, but so that they can still use the old functionality easily if they want to.

There are two reasons the current HuffPost layout violates this principle. The most significant is that it is not clear without some deliberate poking around as to which links will result in a "Quick Read" and which will take you to a new page with a full article. It seems, after clicking around a bit, that only the "Most Popular on HuffPost" links result in a Quick Read. Other links may or may not provide a separate Quick Read option below the main link. The problem with this is that there is not a sharp stylistic or functional distinction between "Most Popular" links and the myriad other types of article links on the main page. Here are nine of the different article title/summary/link styles that are to be found on the main page:







And these are only the links to specific articles hosted on their own site; this doesn't include the link styles for the various feeds, aggregates, splash pages, external feeds, and so on featured on the main page. Can you tell just from looking at this what is going to happen when you click each of these types of different links? Can you discern a good reason why the behavior should differ among them? They should either be the same by default, or clearly differentiated if there is to be some functional difference between them.

It would seem sensible enough for all of the links to behave in the same way -- opening a new article in a new window -- and then offer the Quick Read option and let the user decide to use it if they want to. This would preserve the principle of allowing for new functionality while not making the interface actually more difficult to use by forcing the user to spend more time thinking about how to use it.

Very closely along these lines, the Quick Read should be made to be compatible with my best friend, the mouse middle click button, which is supposed to force a link to open in a new tab. This is particularly important on a site like HuffPost, where there may be many links on the home page that you want to open without getting navigated away from the home page. Currently, if you middle-click a Quick Read link, you don't get the article opening in a new window. This is only true in Google Chrome, but both Chrome and HuffPost can and should change this.

Summarizing Aggregates
Finally, of course, one might question the desirability and usefulness of the snippet trend to begin with. Although it seems problematic to encourage it, this at least makes sense for a publication like The New York Times: their prose is well worth reading in full, and really shouldn't be summarized if it is to be read at all. But it's true that many people don't have time to read all of it, and arguably there is some value in having a pre-condensed version if people are just going to skim it anyway.

But The Huffington Post is already a site of summarized and largely pirated content anyway (not to mention all of the softcore porn and just flat-out insane content). For example, not only is it laughable that this bulleted list (apparently pound signs are passing for bullets these days) of five items copied from another publication merits an entire article of its own, but the Quick Read version of this article is no shorter than the actual article. This is the exception rather than the rule, but the rule is not so far off. How much time is HuffPost really saving us by offerring us one-paragraph versions of two-paragraph articles? There is perhaps some virtue in the concept of the summary or snippet for very long and very important articles. But must we really introduce hierarchies of summaries and snippets -- links to summaries of abstracts of excerpts of snippets of erstwhile articles?

Give me salacious celebrity gossip and sanctimonious know-nothingness on childhood vaccines, HuffPost, but give it quick!

No comments:

Post a Comment

You can use some HTML tags, such as b, i, and a.