Forbes slide show

I intend for this blog to have roughly two types of posts: rather long ones in which I really detail design principles through some particular example; and shorter ones where I just briefly describe a particular feature that works well or poorly. One of my friends, upon seeing my new blog, told me, "I'm not going to lie to you, Ari, this is the longest blog post ever written." So today I think I'll do one of those shorter (or at least, more digestible) types of posts.

Happy Fourth of July, folks! In honor of our country's economic situation, today's topic is about the failure of the wealth-creating industry. Specifically, their failure to make good websites.

I'm talking specifically about the Forbes slide show feature (example). Forbes, like many other journalism sites, is in love with slide shows. But they've managed to create just about the worst slide show feature I've ever seen on an allegedly non-amateur website. Rather than forming a narrative about this, I'm just going to list all of the problems with it that I can think of in bullet-point form:

· Slide shows are an unnecessary feature in the first place. Unless you're only displaying a series of pictures with minimal accompanying text that forms some sort of sequential narrative, the format has no purpose. What Forbes displays as slide shows are all essentially text lists accompanied by illustrations. A single page should suffice for these, or at least a format where 5-10 frames are placed on each page.

· Because slides have to be viewed in sequence, they introduce an unnecessary burden on the user. Random-access slide shows are an exception, but neither Forbes nor many other sites do this.

· The Forbes slide show automatically forwards to the next frame. The only other slide show I can think of that does this is PowerPoint, and that's only if you explicitly tell it to.

· Not only does the slide show automatically forward, but the time it stays on each frame is around ten seconds, often not enough to read the text even for fast readers.

· The show allows you to stop it, but as soon as you manually forward to the next slide, the automatic feature resumes. Failure to remember when a user changes a setting is a big problem.

· There are manual controls for going forward and back, but, as noted, they do not override the automatic feature.

· Furthermore, on the first slide, only the 'next' button is displayed, and it looks exactly like the 'play' button on most music players. Along with the 'stop' button, these look like 'stop' and 'play' buttons. Typically when a computer feature has manual forward/backward buttons, the arrows are either double-headed, tailed, angled, or otherwise differentiated from the common isosceles triangle of the 'play' button.

· Yes, there is a speed adjustment control, but it's pointless. Why not simply allow the user to manully forward when they are done with a slide? Unless all of the slides take almost exactly the same amount of time to read, you will either miss content or be waiting for a while for the next one to load.

· When the next slide is loaded, an entire new page loads. This is a perfect example of when AJAX should be used to allow the next frame to display without reloading the entire page. Part of the purpose of a slide show is to be able to move through it quickly when you're done with a slide. The load time should and could be a tenth of a second or less. (Many web slide shows use Flash. I think this is an extraneous use of the plugin, but it works as long as it is not so graphics-heavy that it impedes rapidly moving to the next slide.)

· Consistent with the slide show's general principle of unnecessarily taking control from the user, the middle button-click does not work on the manual forward/backward links. The middle-button click should open a link in a new tab or window, but Forbes has unnecessarily used Javascript to implement the links instead of hard-coding them into the HTML. (The Javascript link implementation could still be set up to work with middle-clicks, but almost no developers bother with this, and Forbes is no exception.) What you end up getting is the button being clicked as normal, plus a new window or tab opening with a Javascript command as a URL, that the browser doesn't know what to do with. Google Chrome, however, brilliantly designed their browser to handle such links, although there are some cases where it doesn't work.

· The slide show starts automatically. When you open it up, you had better be ready to read it. This is not good news for users such as myself, who open up many links and often don't start reading them right away. This also largely prevents you from sending someone a link to an individual slide.

The bottom line is this is a poor implementation of an antiquated feature that should not be used on the type of content it is displaying. Plain ol' HTML displaying several elements at once and allowing you to navigate at your will would be far superior. If they want to keep the slideshow, it should be implemented with AJAX or Flash so that you do not have to load a new page for each frame. And it should be embedded or included in the articles that link to it, rather than standing alone as it does now.

The only reason I can think of for Forbes to have this format of slideshow is to increase their ad revenue by forcing the user to load many pages to view a small amount of content. This isn't a particularly smart idea, because it's just as likely to annoy users (such as myself) who, after having viewed unnecessarily many pages, will just decide not to return to the site.

Blog posting will be scant for the next several days as I move from Austin, Texas to Washington, DC.

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!