|
|
|
|
Lynda Lester
lester@ucar.edu
http://www.scd.ucar.edu/staff/lester
In this paper we examine the nuts-and-bolts details of how to create a newsletter or electronic magazine (webzine) on the World Wide Web. We discuss two general imperatives: what to do and what not to do. In the "do" part, we look at the principles of good web design. In the "don't do" part, we identify egregious errors (many of which I've made myself). Hopefully this will save you time, effort, and humiliation.
The message of this paper can be summarized in three sentences: Keep it simple. Keep it consistent. Remember the user. Take this mantra to heart: Keep it simple. Keep it consistent. Remember the user.
And now for the details!
This paper covers four topic areas:
So, let's be off!
Surfing is not information retrieval. These are two different action items! What pulls in surfers can be disastrous for people trying to retrieve information.
What 's disastrous for information retrieval? Here are some hints:
The fact is, animations and moving objects are distracting, irritating, and tick a lot of people off. They obfuscate information retrieval. You don't want anything to do that!
What else makes it difficult to retrieve information?
A lot of sites out there are just too cool. "This site is shocked! If you don't have it, go get it!" (I don't think so!)
As far as a webzine goes, cool doesn't cut it; too often it gets in the way of content. Content is the most important component of a webzine. Content is more important than design. Users will forgive bad design, but they won't forgive bad content -- they'll be gone. Ciao! Sayanora! Auf Wiedersehen!
Cool gimmicks pull in surfers with attention deficit disorder. You don't want surfers. You want a loyal readership. Cut the cool.
So, how about that content?
The truth is, any newsletter succeeds on the basis of a faithful audience. The way to get that audience is by giving them content they want -- not content that you want to give them. There's a big difference. You have to keep that in mind at the outset when you design your webzine, because you will have a bunch of conflicting goals as to content.
Over here are the organizational goals. Content that meets organizational goals can look like this: "We are a great organization. Let us tell you all about ourselves. We produce a lot of fine products. Let us tell you about the functionality of our fine products." This type of content is usually public relations, image building, and marketing.
Over here are your own personal goals. Maybe you want to write heartwarming human-interest stories for the Scalable Vector Operating Systems Bulletin. Maybe you want to show the world that you can design a whizzy web site with a fire-engine-red background.
And over here -- over here are the users. The users don't care about the organization's goals or your goals! They won't come to your webzine for irrelevant bits of information that overload their mass storage systems. On the web, people have no tolerance for irrelevant bits.
Users come to a site only if there is content that speaks to them. What kind of content is that? Content that will help them be more productive, solve a problem, or do something creative or meaningful. Something relevant.
Let's say you have a hardware store. You could put up a web site that just says, "We're a great store, we have many items for sale. Come see us!" Or you could do what Ace Hardware does: provide a handy, personalized "paint estimator" that calculates exactly how much paint a customer might need (for instance) to paint a living room. The customer fills out an interactive form with the length x height of the walls, number of windows and doors, and shape of the room, hits "submit," and presto! "You should buy two gallons. And a spare for future touchups! Have a nice day!" (Thanks to Dave Kleinberg from NetObjects for citing this example during a talk at the April '98 Web.builder conference in San Francisco.)
When you create a webzine, the first thing you do is decide what kind of content your users want. Then you organize that content into logical sections.
Let's take a look at a real-life example. SCDzine (http://www.scd.ucar.edu/zine ) is a technical newsletter I produce for the Scientific Computing Division at the National Center for Atmospheric Research. Readers of this publication are atmospheric researchers and programmers who use NCAR high-performance computing facilities to do their science.
The content for SCDzine is divided into six sections, which appear in the table of contents. The most important sections are at the top of the contents page, because in good web design, you always put the most important things first.
Here are the three most important sections:
The above three sections -- Columns, Hints, and News -- are examples of relevant user content for readers of SCDzine. This is what's going to lure them in off the street and onto the web.
Once they're in, however, they'll probably stick around to peruse the next three sections, which address other content goals such as organizational image building. (It's all right to serve other content goals, as long as you provide user-defined content at the top of the hierarchy of importance.)
Here are the next three sections:
It's near the end because it's dull.
It's OK to have fun on the web, as an extra bonus feature.
Cool doesn't cut it, content does; users drive content; remember the user.
They should make a movie called Designer on the Edge of a Nervous Breakdown.
Designing for the web can make you crazy, to say the least. You have to publish on Unidentified Flying Platforms (UFPs) that you cannot see and over which you have no control. Users may be accessing your newsletter in 37 flavors via a chaotic variety of monitors, computers, browsers, and connection speeds. You have to plan for these different configurations when you create your webzine, or you'll run into trouble. "Gotcha!"
:-)
Here's a picture of Mr. Bill, a character from the TV comedy Saturday Night Live. Mr. Bill is so happy! He has just spent two months creating a webzine that looks great on his Mac with the 21 inch monitor viewed in Netscape 3.0 over a T3 line!
:-(
Here is Mr. Bill two weeks later when he learns what his newsletter looks like on everybody else's platforms. Oh, no, Mr. Bill! Everything is ruined! Ohh, noooooo!
Mr. Bill thought because his newsletter looked good on his own system, it would look good everywhere else. Thinking like this is the kiss of death. One thing you can depend on is that your newsletter will look and behave differently on other systems.
Therefore, in the first stages of designing your webzine, you should go out and see how it behaves on multiple platforms. Test the prototype on computers in the usability lab, in coworkers' offices, at a friend's house, at the library or the university. Test for usability before you chose a final format. This will eliminate having to undo embarrassing mistakes later on.
Let's look at some problems you might run into.
Resolution. Monitors come in different resolutions, from high resolution (1280x1024) to low resolution (640x480 pixels).
On a hi-res monitor, you can view a lot of content -- logo, headline, pull quote, byline, illustration, navigation bar, six paragraphs of text -- with room to spare. On a low-resolution monitor, hardly anything fits on the screen. Logo, headline, a paragraph of text -- that's all, folks!
So what do you do? You put the most important elements at the top of your web pages, because that's all your 640x480 users are going to see without scrolling down. (You want the most important elements to be visible right away, before your readers take off for another site.) Also, don't let your images take up too much screen real estate. On low-resolution monitors, small objects look huge!
Bit depth. Another endearing thing about monitors is that they come in different bit depths -- that is, the ability to display millions, thousands, or only 256 colors. If you're creating a color scheme for your web page and you pick a high-end color, it won't show up on a lot of monitors. If it's a pastel shade, chances are it will display in gray; if it's a little more robust, it will dither (look grainy). Dang! There goes your apricot-brandy logo! There goes your lavender-chiffon navigation panel!
To avoid mutant or hueless colors, use a "browser-safe palette," which contains 216 colors guaranteed not to fade, futz, or ferment. You can find one at http://www.bagism.com/colormaker/colormaker-original.html (click on "Changing Background & Text Colors").
Use the medicine dropper tool in Photoshop to sample one of those colors when you design a graphic element, or type in its hexadecimal name when you code an HTML tag for a background color (e.g., <BODY BGCOLOR="8899FF">, and you'll be sure the color will look the same across all monitors -- even those that are color-challenged.
Luminosity/hue. Eewww! Were these photos taken in a coal mine? No, they look fine on a Mac monitor. But on a Sun, they look like, uh, soot!
Due to different graphics cards, Mac and SGI monitors tend to display colors lighter and warmer; PC monitors display colors cooler and darker; Sun monitors display oversaturated and extremely dark. At least in my experience.
So when I process digital photos on a Mac, I lighten up the images till they look overexposed. When they display on a Sun, they still look like glow-worms in a cave, but at least they're identifiable.
Test the results of your image processing on different computer monitors to get the hang of it before you process 200 digital photos. Or you'll be sorry!
Window size, or, How wide is that browser in the window? Browser windows are expandable and contractible -- like accordions! Monitor sizes range from small (laptops) to large (21"), in varying resolutions, from low to high. So there will more or less displayable content fitting into windows that are either tiny or large. Well, that really narrows down the possibilities, doesn't it?
Because you never know how wide those windows will be, you should never design a page with a total fixed width greater than 535 pixels. If you do, and your users' windows are narrower than the width you chose, 10-60% of your content can disappear offscreen.
Size is doubly important if you want your users to be able to print articles from your newsletter. At 8-1/2 x 11", American laser-print paper is often too narrow to capture all the content of large, fixed-width web pages. Users will get truncated text and guillotined images. You don't want that!
Avoid hard-coding widths for your pages, and make sure your layout wraps gracefully -- that is, expands or contracts on demand. (Think of an elastic waistband that can accommodate the loss or gain of a few pounds.)
Of course, sometimes you do have to define a width -- for a table or a panel, for instance. If you do, remember that secret maximum number: 535 pixels. Don't make your page wider than that, or you'll lose text in narrow windows.
Welcome to the Land of 1000 Computers and Browsers! You'll note these points of interest:
What fun! You've got about a dozen different operating systems, versions, and browsers to watch out for. (Personally, I don't pay much attention to Brand X browsers anymore. Netscape and IE have captured pretty much the whole market, and it's hard enough troubleshooting for multiple versions of those. And most of my users use Netscape anyway.)
What are some of the things that get squirrely?
Tables, for one thing. Tables designed in Netscape 3.0 can look insane in Internet Explorer 4.0.
Line spacing, for another -- IE and Netscape on PCs use extra leading. You'll weird out when you see it the first time, if you're used to a more compact textual look.
Then there are extension tags that aren't part of the HTML standard (the Netscape "spacer" tag, for example). Stay away from them.
Don't design for leading-edge capability (4.0 browsers and higher) unless you provide for graceful degradation -- that is, be sure your webzine looks at least mildly sound of mind and body in earlier versions -- or unless you don't mind throwing your low-end users to the dogs.
And check out your zine on as many different versions of Netscape and Internet Explorer on as many operating systems as you can.
Hard? No. Easy? Yes. (Liar!)
All network connections are not created equal. If your webzine is out there on the Internet (not on a fast-lane Intranet), you'll have to face the ramifications of a sloww-w-w network connection. This can be a shock, especially if you're sitting on a T3 line and the pages always load fast for you.
Slow modems -- and sluggish, overloaded networks, no matter how fast the connection -- mean slow downloading. For example, a 356K gif takes about two minutes to download on a 28.8Kbps modem, and four minutes to download at 14.4Kbps. Who's going to stick around for that! (Even on a 45Mbps T3 line, I've seen transmission rates slow to 3Kbps during peak periods.)
Therefore, you should shoot for small file sizes whenever possible, in both your text and graphics files. You can shrink the file size of your images in two ways.
For more information on optimizing the size of your images for the web, see http://www.infohiway.com/faster, http://www.webreference.com/dev/graphics, and http://www.gifwizard.com. (I got these URLs from Web Pages That Suck, a fantastic book that's listed in the references at the end of this paper.)
In summary, as industry pioneer Guy Kawasaki (keynote speaker at Web.builder '98 in San Francisco), says: "Eat your own dog food." In other words, experience for yourself what it's like for your users to access your webzine. Design accordingly.
Information architecture is how you organize your data.
[Spy music, burning fuse, voice from tape cassette . . .] "Your mission, should you choose to accept it, is to devise a system that allows users to parse the data in your webzine as easily as they parse the layout of a newspaper page."
Good information architecture means users can move efficiently through your webzine and find what they're looking for. Bad information architecture means they can't, which will make them confused, frustrated, and angry.
The mission-critical components of information architecture for a webzine are (for your eyes only!) . . .
Momentarily, let's go into the field and observe some real-life web archaeology.
Case study #1: Entire verbiage of the home page for one web newsletter:
OUTREACH NEWSLETTER
November 1996 issue or (in MSWORD FORMAT)
Spring 1997 issue or (in MSWORD FORMAT)
The page also includes two flashing, rainbow-gradient rules; two spinning balls; an ambiguous blinking icon; and a rotating "NEW" gif.
What's wrong with this picture?
The rotating, flashing, blinking thingies, obviously; but more importantly: lack of identity. Who publishes this newsletter? Who reads it? What's it all about?
Your home page is a keyhole into your webzine. It communicates an identity, establishes a metaphor, and lays down the foundation for the look and feel of the entire site. The "Outreach Newsletter" is eminently unidentifiable.
Case study #2: The logo for another web newsletter: "ECN No Name Newsletter." (The "ECN" acronym is never expanded.) We have no idea who they are -- and they don't either.
Case study #3: This web newsletter calls itself "The Interactive King of All Media Newsletter Web Site." (Opposite problem -- megalomania! Of course, it's a fanzine for Howard Stern, so the metaphor is perhaps correct.) The home page for this newsletter has a black background (don't you do that -- it impairs readability), 16 gifs, 75 multicolored headlines, 119 links, and enough information to sink a phone book. The lesson here: Organize! Your home page is not a junk drawer!
On a home page, less is more. "Be simple" is a good operating precept.
Recipe for a home page. The home page for your webzine should communicate a sense of identity. It should display a logo and provide a metaphor that helps users know what kind of a publication they're dealing with. It should also establish the navigational look and feel of your zine, which you will perpetuate consistently throughout the site. Finally, it should identify by whom and for whom the newsletter is published.
Example: SCDzine home page. At the top is the SCDzine logo. Directly underneath are three "viewports" opening into technicolor clouds. This establishes an atmospheric sciences metaphor, which is appropriate for its users (atmospheric scientists). The navigational look and feel of the newsletter are established: purple navigation bar on the left, white text area on the right. A notice at the bottom of the page identifies both publisher and users.
The web is opaque; it's hard for users to intuit the depth and complexity of your site. Therefore, you should always provide alternate ways for people to find information. The three methods of navigation I recommend for a webzine are: article index, search engine, and table of contents.
Article index. The article index lists by topic all articles in all issues of the webzine. If you want to read an article on a certain subject but don't know its title or what issue it's in, this is how you find it.
Search engine. If you type in a keyword, the search engine lists all the articles on that topic (with links to the articles) and ranks them by priority. (You help the search engine by putting META tag keywords in the heading section of each HTML file.) SCDzine uses the search engine HTTDIG, which was free software downloaded off the net.
Table of contents. It's OK to have a long table of contents. In fact, it's better than chunking your TOC into sections that require multiple hyperlinks. People hate clicking and waiting for a new page to download a lot more than they hate scrolling down a few screens.
Also, it's OK to have long lists of links with no white space between items. Usability tests show that lists of super-condensed information work well on web pages, and that white space between items isn't as helpful as it is in print.
Consistent look and feel. One more general piece of advice about navigation. The navigational look and feel of your site should be uniformly consistent throughout your webzine.
The web is weird enough without you switching things around all the time. Be consistent in your navigational look and feel, and your users (like Motown singer James Brown) will say: "I FEE-EEEL GOOD!"
A good link is a predictive link. A predictive link is one that tells users where they're going before they click. Descriptive links with more words are often more predictive than links with fewer words.
Let's say you have a link called "Index." Index of what? Site index? Back issues? Important words (like the index in the back of a book)? If you label the link "Article index," users will know better what to expect.
Perhaps you have a link called "Movies." Would this deliver a list of downloadable Quick Time animations? MPEG clips? Videos for sale? Plot summaries? If you label the link "Movie reviews," users will know better what to expect.
Now here's a descriptive link, followed by a descriptive tag line:
Edmund's Complete, Updated, NEW CARS Book Content
Over 565 Models: MSRP and Dealer Invoice Prices, Standard and Optional Equipment, Specifications, Reviews, etc.
Between the verbose link and the tag line that follows, we know where we're going! (This example, and additional material on the benefits of predictive links, can be found in the book Web Site Usability: A Designer's Guide, listed in the references at the end of this paper).
You can apply the concept of descriptive links in your newsletter's table of contents by including the title of each article followed by a tag line. For example:
TAGS bagged!
Text And Graphics System reaches end of life
Let there be no doubt what the link points to. De-scriptive, pre-dictive!
There are numerous ways to organize your webzine in terms of file structure. Two common ones are deep (we are talking bathyspheres!) and shallow (flatland).
A deep structure means you have a limited amount of information on each screen, and you click a hyperlink if you want more info. To get from point A to point B in a deep structure might require traversing a number of intermediate pages, and lots of clicks. Each click takes you deeper in the file system. Down, down to the bottom of the sea!
"Deep structure, good!" was the prevailing web design philosophy a couple of years ago. Here's a quote from p. 68 of Designing Large-Scale Web Sites by Darrell Sand (John Wiley: 1996):
... [C]ontent should be filtered into smaller units of relaxed content. Information is reduced to concise, conceptually related units, facilitating rapid scannability, with access to greater detail if so desired. This technique is referred to as progressive disclosure . . . This allows users to drill-down to greater detail without having to parse through overly crowded pages of text. Everything cannot fit on a single page; therefore, it is much better to organize the information into smaller, comprehensible chucks.
How fickle is fashion! How soon we learn that what we did two years ago was stupid!
In the scenario above, you may have to wait 5-20 seconds every time a new page loads! If your users do this eight times in a row, they'll be fed up! As far as a webzine is concerned, drill-down is bad.
Usability tests conducted by User Interface Engineering, a Boston firm, indicate that people are loathe to click. But they'll scroll!
This is why I recommend a shallow structure for a webzine, so you can get from the home page to a desired article within two clicks. Like this:
Home page (with list of issues) -->
Table of contents for selected issue -->
Article
Simple! Obvious! EZ! No complicated mental mapping required.
Keep it simple. Keep it consistent. Remember the user.
This is my favorite part. I just love this part. Here's where we explore visual appearance, writing for the web, and creativity.
Just for fun, let's look at some really gross mistakes you should never make in web page design.
Never:
For more goofball mistakes you should never make, check out the Bud Uggly Web Page Design site (http://www.wwwvoice.com/bud/bud.html) -- you'll stay there for a half hour poking around, it's that entertaining! -- and the "Web Pages That Suck" home page (http://www.webpagesthatsuck.com), maintained by a couple of web geniuses with a great sense of humor.
So much for design don'ts. What should you do?
Well, you could borrow ideas from the handy SCDzine article template. Each article page in SCDzine contains these standard (consistent!) elements:
Note: If you want to specify a font, give the browser several similar choices in your HTML code, in case the user doesn't have the font you specify; and stick to common fonts. For instance:
<FONT FACE="helvetica, arial">
(And don't expect that this will necessarily work!)
This may not be a snazzola whizzy "cool" design, but it's functional and easy to understand at first glance. It's simple. It's consistent. It's usable.
And now a word from our HTML gadfly.
When you code your image source tag in HTML, always use the WIDTH, HEIGHT, and ALT parameters. For example:
<IMG WIDTH=80 HEIGHT=106 ALT="clouds" SRC="clouds.gif">
The WIDTH and HEIGHT parameters give the dimensions of the image in pixels. When the page loads, the browser allocates space for the image, loads the text, then finishes loading the image. This allows users to get started reading text right away.
The ALT tag describes the image for users who have image loading turned off. (That is, users with slow modems or users in a hurry -- potentially, a lot of users!)
If you don't use the ALT parameter, users who are not displaying images will miss out on any message your images convey. That's a bummer -- especially if some of your images are navigational. "Help! I've fallen onto a web page and I can't get out!"
Scriveners, take note! Writing for the web is different than writing for hardcopy.
Here are some guidelines to remember:
In their article "Concise, SCANNABLE, and Objective: How to Write for the Web" (http://www.useit.com/papers/webwriting/writing.html), John Morkes and Jakob Nielsen provide an prime example of how not to write for the web:
Nebraska is filled with internationally recognized attractions that draw large crowds of people every year, without fail. In 1996, some of the most popular places were Fort Robinson State Park (355,000 visitors), Scotts Bluff National Monument (132,166), Arbor Lodge State Historical Park & Museum (100,000), Carhenge (86,598), Stuhr Museum of the Prairie Pioneer (60,002), and Buffalo Bill Ranch State Historical Park (28,446).
Here's that piece recast for the web:
In 1996, six of the most-visited places in Nebraska were:
- Fort Robinson State Park
- Scotts Bluff National Monument
- Arbor Lodge State Historical Park & Museum
- Carhenge
- Stuhr Museum of the Prairie Pioneer
- Buffalo Bill Ranch State Historical Park
One point from the "writing for the web" list of guidelines, above, is worth added emphasis: You should learn to write catchy heads. At the National Enquirer, people earn big money for this. You too should develop the knack, because catchy heads increase readership. For instance: "Mesh, you caches!" beats "Meshed cache structure" six ways to Sunday!
Here are some examples of headlines from SCDzine and CUG.log (the newsletter of the Cray User Group, available from the CUG home page at www.cug.org):
Once you've provided fortified, vitamin-enriched content your users want, developed a coherent site architecture, and produced well-designed pages, you can start to have a little fun.
One great thing about the web is that it can accommodate a large number of color images. This would be prohibitively expensive in print publications -- four-color separation, prepress, glossy paper, no way! But you can use photos like mad to enliven your webzine. (It helps to have a digital camera so you can download photos directly into your computer -- or at least a scanner to digitize hardcopy photos. And incidentally, you must know Photoshop.)
You can have a lot of fun with interactive photo essays.
To do a photo essay, write a few interesting paragraphs on your selected topic. Arrange a bunch of illustrative, clickable thumbnails underneath and oganize them to tell a story. Write thoughtful or amusing captions.
Example: Recently the Scientific Computing Division at NCAR dismantled a CRAY Y-MP supercomputer that had been onsite for eight years. To create a photo essay, I took six dozen photos (digital photos cost nothing to develop!), selected the best ones, and organized them by categories:
Each category had four to eight thumbnails linking to larger, full-color photos with descriptive captions. The caption for the semi truck was, "Now THAT's a utility vehicle!").
Users like photo essays. They can play around and learn something at the same time. And as we all know -- a picture is worth a megaword!
All your articles aren't going to be page-turners. How to you enliven a dry technical story?
One way is by using creative illustrations. A recent article in SCDzine called "How to get a GAU," described how to apply for computing resource allocations (General Accounting Units, or GAUs). The sum total of GAUs available to users is called the GAU pool.
The illustration was a no-brainer: A "user" in a swimming pool with a dialog balloon (drawn in Photoshop) over his head reading, "Water's fine!" Photo caption: "A user enjoys the GAU pool." (I took the original photo at a conference when I saw an attendee take a dip in the hotel pool.)
An article on what happens when different subroutine names "collide" (cancel each other out) was called "When names collide" and had a poster of space ships from the old science fiction movie, When Worlds Collide. (I found the image through the Internet Movie Database Search (http://us.imdb.com/search), solarized it in Photoshop, and swapped out the lettering.)
You can also get creative with portraits. One way to escape the homogenous sameness of corporate mug shots is to snap photos of your authors in casual or unusual poses (again, a camera helps). Once I persuaded two of my coworkers to stand directly behind my boss and hold their arms out to the side. Result: A photo of my boss with six arms! Caption: "A webmaster needs six hands to keep up with developments in the field."
Another article discussed batch output. The accompanying photo showed the author eating a cookie. Caption: "Consultant enjoys cookie batch output."
You can use humor to perk things up, as long as you don't insult corporate dignity. One recent article in SCDzine feted the promotion of two long-time engineers. The first accompanying photo had a standard, informative caption. The second showed both men in deep thought, pondering. Caption:
"Say, Basil, what do you think the problem is with using VLAN/ELAN technology to simplify the host add-move-change problem by allowing multiple logical networks to coexist on a single physical infrastructure?"
"Well, John, I'd say that once again, it's due to overheating of the glycgroms in the thermoperamulator."
We now come to the end of this paper. Press "fast rewind" for the instant replay.
Here it is:
Keep it simple!
Keep it consistent!
Remember the user!
See http://www.amazon.com for reviews of all these books.
Lynda Lester (lester@ucar.edu) is a writer, editor, web designer, and amateur photographer in the Digital Information Group of the Scientific Computing Division at the National Center for Atmospheric Research in Boulder, Colorado, USA. She is managing editor of SCDzine and CUG.log.
She has won 16 awards from the Society for Technical Communication for her professional work, including three awards at the international level. She also won the second place award for a trade news article in 1992 from ACM/SIGUCCS (the Association for Computer Machinery Special Interest Group for University Computing Centers).
She is listed as a writer on technology at The Mining Company website.
Her home page is at http://www.scd.ucar.edu/staff/lester.