Small Initiatives

This article by Jay Small was originally published in 1997 in MediaInfo.com, an online-focused magazine by Editor and Publisher. Obviously, much has changed since then, and the author's updates and annotations are included in italics.

Youll hear it at least once from almost every Web site manager you meet:

Sometimes I feel like I know nothing about this medium. I cant keep up with all the changes.

Thats what we say, but we often design Web documents with bold assumptions that defy our spoken sheepishness. Look at the track record of the newspaper industry in online design:

• The Wire, from The Associated Press, throws animated graphics, Java, JavaScript and a three-frame design at Web visitors in the very first screen. By modem, the page often takes two minutes or more to load fully. In fact, the AP has announced a pending redesign for the page, partly to address these problems. [The AP redesigned The Wire at least twice since this article was first written, then finally replaced it with CustomWire, which allows news sites to provide more of their own look and feel -- JS]
• The Internet site of the Chicago Tribune (among others) uses Shockwave-enhanced information graphics, which require users to find and install a browser plug-in lest they see a hole where the moving pictures should be. [Again, the cited site has been redesigned more than once since the original writing -- though the Trib's site is one of many to use information graphics animated with Flash, which has inherited much of the hype from Shockwave -- JS]
• Star/News Online of Indianapolis (a familiar site to this writer) offers display classified ads in Adobe Acrobat Portable Document Format -- which, again, requires users to find and install a plug-in. [I was manager of that site at that time, and proud of the fact we could even offer display classified ads in ANY format. The PDFs are no longer on the successor site, IndyStar.com, though they lasted almost five years -- JS]
• Even tiny newspaper sites run JavaScript clocks, animated banner ads and multiple HTML frame sets. And just about every Web site, newspaper-based or not, has at least a few pages that appear to be built for only one browser brand on only one operating system.

Do we know what were doing to our Web visitors? Its often doubtful. But we do these things based on assumptions: what we think we know about interactive design. Whether valid or not, all of our assumptions come with risks that should be measured. Thats the objective here. The statements that follow are culled from (a) at least one expert who said so in a seminar, (b) books on Web design, or (c) casual conversations with people who should know.

"Web visitors prefer clicking to scrolling"

When you see sites front-loaded with 40 graphic links and 10 news headlines, all visible without scrolling, its a safe bet the site manager either said this or believes it. And this statement is validated in usability studies on graphical user interfaces.

But its a user preference, not an either-or decision. Web visitors scroll when the content is interesting to them. They might not click at all if that front-loaded page is too busy or fails to explain whats behind those 40 links.

Still, its possible to build on this assumption as we present information.

Non-linear storytelling is a buzz phrase in new media circles these days. Put simply, its presenting a story in component parts (text, images, sounds or moving images), cross-linked so visitors can drill in from any angle at any level of detail.

Because the information is distributed, components in non-linear storytelling tend to be more concise than in a linear presentation. That means less scrolling and more clicking to move among elements.
It also means more production work for the online staff. Its especially labor intensive to collect materials prepared in linear format for print editions, then break them up and repackage them intelligently. Further, few newspaper companies have an online-only reporting staff to supplement newsroom coverage exclusively for the Web.

Where staff is limited, one approach might be to concede that print-edition content will run as-is on the Web site. That move saves staff time for exclusive online content, which can be planned and prepared in non-linear format. Sites that use shovelware (computer gear that automates publishing of newspaper content to the Web) are already suited to this approach. The newspaper articles and visuals become the underpinnings for Web-specific content. [All still true today, mostly -- JS]

Navigation links work better on the right side, near the scroll bar

This assertion is logical on the surface. The idea is that keeping clickable elements close to the scroll bar will reduce pointer movement and mouse activity for users.

Web sites and Usenet newsgroups on the subject of graphical user interfaces even report evidence of higher clickthroughs on the right side.

Swell. But its hard to do this right. HTML 3.2, the current flavor, relies on left-to-right, top-to-bottom geometry. Its easy to build a background image that puts a stripe of color behind a left-side navigation table. It's much harder to do it on the right side; impossible, even, to keep the links flush to that scroll bar without using frames. [No longer true -- JS]

Do we even gain much by trying? Pointer movement is much less an issue for users of trackpads or pills than for users of traditional mice. The Microsoft Intellimouse and comparable products permit scrolling from any pointer position on the screen. Gradually, navigation positions near the scroll bar may lose their benefit. [Indeed, though Eyetrack research also hinted right-side navs may help, Internet conventional wisdom pretty much shoots down this idea -- sites almost globally favor navigation on the top and/or left these days -- JS]

Still, there are ways to do this. Want right-side navigation with a vertical color stripe? Use an HTML table. Put a content cell or cells on the left side, and apply a background color to a vertical cell with navigation links on the right side. Center the table in the document; otherwise, that list of links that looks nice on the right side of a 640x480 display will appear in the middle of a larger window.

HTML frames are another option, though poorly designed frame sets can slurp up precious bandwidth and even cause browsers to crash. Handle with care. New flavors of HTML permit layering: precise placement of elements on a document, and even on top of each other. Layering has great potential to solve navigation problems, if only Microsoft and Netscape can agree on a standard method. A few sites offer Java and/or JavaScript navigation tools often drawn in separate browser windows so theyll stick around on users screens as they click from page to page. Again, handle with care: Java can be slow to load, poorly implemented Java or JavaScript can cause crashes, and neither approaches 100 percent compatibility with Web users. [Some things never change -- JS]

"The browser window is too wide for easy reading of text"

This assumption, adapted from the print design world, emerges from numerous studies of reading habits and typography. For that matter, its simply intuitive to anyone who has tried to read long blocks of text running all the way across a computer screen. Its hard. It strains your eyes.

Newspaper designers know the conventional wisdom that 9-point news text looks best in the 14- to 16-pica-wide range. Book designers, often working with type in the 12-point range, often use wider columns successfully.

Meanwhile, Web designers shoot at a moving target. Computer screens are significantly harder to read than printed text. And, though most site visitors mercifully leave their browsers set to factory defaults for text display, those defaults are far from standard. Sure, Netscape Navigator and Microsoft Internet Explorer both default to Times 12-point, but the type looks much larger (relative to graphic objects) on PCs than Macs.

Even if a designer settles on an ideal width, theres the matter of achieving it consistently. Plenty of newspaper- and magazine-based sites rely on HTML tables to pull text in from the left and right edges of browser windows. But tables have a quirk: browsers must draw out the entire table geometry before beginning to display its contents. Users stare at a blank table, often for several seconds, before text appears. The longer the run of text or the more complicated the table, the longer users wait.

Want to see this quirk in action? Go to Newsworks, the New Century Network megasite, using a modem. NCN has recently streamlined the design of this page, but youll still wait about a minute for anything but the top-of-page Newsworks logo to appear on this page. Its not necessarily sloppy work on NCNs part, its just the way tables work. [NCN and the Newsworks site are long gone -- JS]

The New York Times site, among others, eschews tables around stories in favor of the HTML block quote tag. [Not true anymore -- JS] Each application of this tag moves text in about one inch from the window margins. Its not as precise as a table, since users control the width of the window but the block quote tag is compatible with just about every browser and uses slightly less bandwidth.

No matter how you get them, narrower columns mean longer text. That means more screens to scroll through so this assumption butts heads with the idea that visitors prefer clicking to scrolling.
The best tactic for readability is brevity. But if a long run of text is required, consider using subheads tagged with internal document links. Visitors can then click from section to section of a long article.

"Visitors respond to things that move or make noise"

Part of the fun of Web design is the ability to appeal to the senses. Animated visuals are everywhere, especially in ads. We can send out audio and video feeds in real time, or shock information graphics to tell stories with interactive layers of moving content.

This is the stuff that makes sites cool, right? Well, yes, but its also the stuff that cuts into audience size. By conservative estimates, at least 20 percent of Web users dont have the right computers, browsers or plug-ins to work with all the common multimedia formats. [Some things DO change. The install base for Flash, PDF and streaming-media plug-ins is now well over 90 percent apiece, though version variations are wide -- JS]

With rare exception, you cant see streaming video or hear streaming audio without a plug-in. You cant play with Shockwave or Flash graphics without plug-ins. Animating a GIF image adds to its download time.

Worse, many sites using even one or two of these formats fail on a fundamental level: they dont explain to visitors how to get, install or configure the required plug-ins. Sure, you could link to the manufacturers site. But even assuming that sites documentation is adequate for general use, it is little help to visitors who want to make your multimedia files work.

Sites with high multimedia overhead, such as those that promote new movie releases, often offer visitors multiple entry paths. Got the gear? Take the bells-and-whistles path. Missing the plug-ins? Take the low-graphics path. Its a polite concession to the have-nots of the Web community, if you have production time to manage multiple paths. [Alternative views are still a great idea, and can be partly executed just through CSS -- JS]

If you really want people to see your dancing grasshoppers, tell them exactly how to get and use the plug-ins. If the manufacturer will permit it, offer the plug-ins for downloading from your site, with customized documentation and navigation suited to your audience.

"Visitors want to interact with each other and with us"

If you consider what Web visitors go through just to get online, its no wonder they expect a richer experience than simply reading text on a screen.

Fortunately, software to deliver interactive features on Web sites is commonplace. Products from Microsoft FrontPage at the low end to Web Crossing at the high end permit creation of message-board style forums. EarthWeb and I-Chat offer Java-based real-time chat within Web browser windows.

Yet, as much as users want interactivity, it isnt always easy for them. As you travel the Web, you begin to notice how each site has its own way of presenting message boards and chat. Each has its rules and modes of operation. There are no standards.

Veterans of Internet Relay Chat know how overwhelming its command lines and thousands of channels can be. IRC servers can lag maddeningly as they try to communicate with each other. A given user can upload a chat message that other users wont see for several minutes hardly equivalent to real-life chat.

Most disturbing is the lack of control publishers have over these forums. We facilitate discussions, then back off and watch them happen. Forum designers have to make room for long legal disclaimers and cumbersome pages of instructions. [Hoo, boy, if only I had seen the blogosphere and Facebook coming in those days! -- JS]

Here's where Web managers can take a cue from America Online. AOL operates perhaps the easiest-to-learn, easiest-to-use message boards and chat rooms. It's worth emulating that simplicity of design, if only because many of our Web visitors either started with or still use AOL for online access. AOL also is masterful in its use of scheduled chat events with celebrities and newsmakers.

Now what?

Though purists shudder, HTML is evolving from a document formatting language into a design language. Market pressures force the issue. Too many Web publishers, from advertising agencies to corporate information directors to media outlets, are frustrated with the limitations of the language and the lack of standards.

Trouble is, HTML is evolving willy-nilly. Microsoft and Netscape, the two biggest browser manufacturers, are headed in different directions as they implement more precise typographical and layout controls. So itll be easier in the future to design Web pages with the precision of print, but harder to make those pages look the same to all your visitors. That is, unless the two browser giants can agree and thats the riskiest assumption of all. [Now there's one browser giant with two very different versions, a rising but still small open-source alternative, and some also-rans. But standards compliance is improving across the board -- JS]