Web DesignDuring Fall Comdex we unveiled the first major redesign of The BYTE Site. Does it appeal to your sense of form and function? That's for you to decide, but either way, the lessons we learned might be useful to you. Our goal was to improve the look and feel of the site--easy to say, hard to do. Here are the six rules that guided us.
RULE 1: Map the Site on Every Page
Like Ptolemaic minds at the dawn of the Copernican revolution, Web users often feel rootless and disoriented. Your own web, if it's woven to a consistent pattern, can offer comfort. We map The BYTE Site with a standard header made of a row of buttons that link to the site's main areas. Below that, we include the page's title, preceded by an icon that matches one of the buttons. The row of buttons is a standard device that says, "You can go to these places." The matching title adds an important fact that many sites omit. It says, "You are here."
Another way to achieve the same effect might be to show the button for the current area in an alternate, "pushed-in" state. That approach would eliminate the need to echo the area's icon in every title but would violate the semantics of buttons. On our site, clicking on an area's header button means, "Go to the root page of that area." If you're already deep inside that area, clicking on the header button produces the same action--bouncing you to the area's root--without changing the button's state. That classic user-interface no-no leads to Rule 2.
To achieve a consistent look, a Web site must appeal to the ancient traditions of publishing. Tables of contents and chapter heads remain as useful as they were in Gutenberg's day. But to achieve a consistent feel, a site must also embrace the modern traditions of interactive software. Whatever looks like a button should also act like one. Whatever doesn't, shouldn't.
Without a high level of automation, however, this kind of consistency is a luxury you simply can't afford. Life's too short to edit hundreds or thousands of Hypertext Markup Language (HTML) pages by hand, much less reedit them when you decide to reorganize your buttons. Our homegrown HTML generator solves that problem for the BYTE archive, which contains 99 percent of the site's 5000 pages. But standardizing the last 1 percent--a few dozen handcrafted and highly visible pages--became a burden.
One solution to standardizing the last 1 percent, called the server-side include, entails marking the places in your HTML files where the Web server should insert boilerplate text as it sends the files to browsers. Another solution, and the one I favor, also requires marking where to insert boilerplates, but instead it re-lies on a preprocessor to do the insertion. I prefer to use this method because not all Web servers support on-the-fly inclusion and because they already have enough work to do.
Our preprocessor is a Perl script (see http://www.byte.com/art/netcol/netproj.htm) that replaces what's between this pair of HTML comments:
<!-- begin stdhdr --> <!-- end stdhdr -->
with boilerplate. It also expects a title--of the form <h1><img src...--and standardizes the border, alignment, and spacing applied to the title's icon. To use this system you have to enumerate the set of files it manages in another script, which doubles as an inventory list for the non-automatically generated part of the site.
RULE 3: Use Small, Discrete Images
Small GIFs that introduce elements of bulleted lists, a common decorative enhancement, can also play a key functional role. Our table-of-contents pages use them to document relationships among articles, text boxes, figures, photos, and tables (see the figure). Our search-results page uses them to distinguish between two types of data--BYTE articles and vendor-supplied press releases--drawn from different areas of the site. These small GIFs load quickly and, once cached, reload instantly. Deployed consistently, they can create visual patterns that map underlying structures of data.
Full-screen image maps, on the other hand, are a disaster. Putting one of these on your home page invites entry yet repels it with a force inversely proportional to the speed of the visitor's link.
Bandwidth aside, the image map is a questionable device because it violates another convention of software behavior. In a hyperlinked environment, users rely on interactive feedback to distinguish among the sensitive regions of the screen. When you point to a textual or graphical link, your browser reacts with two kinds of feedback: It changes the cursor, and it reports the name of the link destination.
When you point to a spot on an image map, the cursor changes, but the browser can report only coordinates on the image map, not the link target that those coordinates imply. Some image maps delineate hot spots more clearly than others, but there's no getting around the absence of the crucial feedback that confirms transition from one hot spot to another. This glitch affects both the user-hostile full-screen image map and its friendlier cousin, the banner image map that appears in the header or footer position on many sites' pages.
What to do? The BYTE Site avoids image maps entirely; when we use images as links, each image refers unambiguously to a single link target. If we were to switch from the row of buttons to a banner style, we'd build the banner out of a series of discrete chunks.
There's yet another solution at hand: client-side image maps. With this technique, HTML tags define particular regions of an image and explicitly associate those regions with link targets. But while Netscape Navigator 2.0 and the Microsoft Internet Explorer both support this feature, the majority of the browsers visiting our site don't, yet.
RULE 4: Create "Tabbed" Indexes
I've found a nifty way to emulate index tabs in HTML. We use this technique to manage a series of text boxes in an article (e.g., http://www.byte.com/art/special/9511sota/506023a.htm) and to index the company, product, and date views of the Virtual Press Room (vpr) (e.g., http://www.byte.com/vpr/compall1.htm). The device uses a repeating row of textual links that map a series of pages (or regions within a page). When you click on one of these links, it goes dead--that is, it becomes unhighlighted (and preferably font-enhanced) to announce, "You are here."
You can achieve this effect by hand for a small series, but the HTML coding is tedious. For vpr, I use a Perl script (http://www.byte.com/art/netcol/netproj.htm) to iterate over lists of index items--either letters of the alphabet or dates--and generate the necessary HTML.
RULE 5: Create Many Paths to Information
Each row of index tabs in a vpr view also carries an iconic link to a search screen. That's one of the ways in which The BYTE Site maximizes its internal interconnectedness. Here's another: On table-of-contents pages in the archive, references to figures and tables link to the locations in articles where these elements appear. Other links to these same elements occur in the text of the articles.
Why duplicate them? Magazine designers are always looking for ways to provide "multiple entry points" to information. On the Web you can literally do that.
As usual, you need automation to implement this rule in a cost-effective manner. It was easy to make the Perl script that builds vpr views tack an iconic search link onto each row. For the table-of-contents links to elements inside articles, it was a bit trickier. The Epsilon Extension Language (EEL) program that generates the table-of-contents pages has to scan articles for link targets of the form
<a name=linktarget>: <h3>Title</h3>
and build matching link sources like this:
<a href="[unarchived-link]" Title</a>
Here's another example: an uplink from each table-of-contents page to its parent (the Web equivalent of cd ...). Initially I omitted these, relying on the native backtracking ability of browsers. If you start on the archive's main page and follow the path August 1995 -> News and Views -> Apple's New Multimedia Macs, you can climb back up the tree by clicking on your browser's "Go back" button.
But what if you arrive at the article "Apple's New Multimedia Macs" by way of a search, either from the BYTE search page or an external one? Now the "Go back" button takes you back to that search page. There's no easy way to explore the context surrounding "Apple's New Multimedia Macs"--that is, the other August 1995 News & Views articles. An uplink on every table-of-contents page supplies the crucial missing path.
RULE 6: Degrade Gracefully
The tabbed indexes in vpr views rely on two visual cues to focus attention on the current tab: font enlargement and absence of highlighting. If your browser doesn't support the nonstandard <font> tag, the effect diminishes but still works. This is an example of graceful degradation. Other advanced HTML features, notably tables, degrade disastrously when they are viewed via Lynx or a first-generation GUI browser. For that reason, we use tables sparingly.
How much do you care about less-capable browsers? That's your call. Knowing how many Lynx or Mosaic 1.x users visit your site (see "Damn Lies," February BYTE, to learn how to collect that information) helps you to scope the problem. But remember that even a small share of the Web population can represent a lot of people. For example, the 3 percent of our visitors who use Lynx form a group that is 3500 strong--and growing. And some of those visitors, I was recently reminded, are blind.
To serve up tabular data to the full spectrum of browsers, the ultimate solution starts with cell-tagged data--in HTML or any other format that fully specifies rows and columns. Then it mechanically derives a plain, ASCII-formatted version. Finally, it delivers either the rich or plain version according to the capabilities of each incoming browser. I commend sites that do this. Ours doesn't--yet.
Practice What You Preach
As I wrote these rules, I found our site guilty of several violations. Buttons didn't always behave as buttons should (see Rule 2); archive pages didn't offer redundant access to the search function (Rule 5); and some graphical links lacked text alternates for Lynx users (Rule 6).
As I correct these flaws, I'm exploring the design opportunities--and the challenges--of Netscape Navigator 2.0. Using its <frameset> tag, I have prototyped a Smalltalk-style article viewer (see the figure) that promises to vastly enrich navigation of the archive.
How will my six design rules play out in this environment? Beats me; I only know that somehow they must. Watch the site and let me know what you think.
TOOLWATCH
MHonArc
(http://www.oac.uci.edu/indiv/ehood/mhonarc.html)
Point Earl Hood's masterful Perl script at a file of E-mail messages in Unix format, and it creates a threaded HTML archive, complete with decoded MIME attachments. There are other excellent mail-to-HTML converters (e.g., Kevin Hughes' hypermail, http://www.eit.com/software/hypermail). MHonArc doubles as a great Perl tutorial.
BOOKNOTE
The Essential Distributed Objects Survival Guide by Robert Orfali, Dan Harkey,
and Jeri Edwards
John Wiley and Sons, 1995 ISBN 0-471-12993-3 Price: $29.95
This worthy sequel to The Essential Client/Server Survival Guide explores two competing distributed-object architectures--CORBA and OLE/COM. The authors prefer CORBA, but they frame the debate in ways useful to anyone curious about the technical underpinnings of a global computing fabric.
Using small icons as data-type cues: Small icons that serve as list bullets can define the types of the list elements (above). They can also define the sources of data on a search-results page (below).
Tabbed indexes in HTML: Repeat a row of text links, varying the position of a single "dead link" to mark the location of the current page. We use this technique to manage a series of text boxes in an article (above) and to present views of vpr (below).
Multipane browsing with Netscape Navigator 2.0 frames: With this exciting HTML extension you can consolidate large sets of pages--here a whole issue of BYTE--into a single multipane browser.
Copyright © 1994-1995
