One of the nice features about the World Wide Web is that it is possible to do all sorts of nifty things, like changing fonts, showing pictures, playing sounds, and having visual effects. Unfortunately, many people seem to think that "possible" is a synonym for "required". It's not.

Presentation is, as we know, important - You might get roast beef and mashed potatoes in your school cafeteria and at Peter Luger's Steakhouse, and it might even taste the same - but chances are, you're going to be more impressed by it at Peter Luger's, where they try to make it look nice, and serve it with all sorts of ruffles and flourishes, than at the school cafeteria, where they don't have time to do more than scoop it up, plop it onto the plate, and shove it across the counter at you. Some societies practically make a fetish of presentation of food; the Japanese, for example, have such a reputation. There are other examples, and not just in food. But the point is that most of us do realize that presentation is important.

Part of that, especially when presenting information, is to avoid distractions or conflicting messages.

Anything that diverts your visitor's attention from your message is, by definition, a distraction. Garish color combinations, such as red or magenta text on a blue or green background, are distractions. So are color combinations where the foreground and background colors are too similar, like dark gray and light gray (both of those color combination flaws make the text more difficult to read). Animated GIF files are sometimes distractions. Music is sometimes a distraction. Hard-to-read decorative fonts are usually a distraction. Non-static visual effects (blink, marquee, etc.) are generally distractions.

Conflicting messages are a little harder to define. In general, if the message of the text is jarring or inappropriate when viewed in the context of its surroundings, chances are that you've got a conflicting message.

Sometimes, conflicting messages are useful - they're not unknown in public service advertising, for example. However, even there, overuse is a bad thing. Distractions are always bad, although the things that cause them may be appropriate in some contexts (and hence not distractions in those contexts).

I'm not telling you not to use those things. Far from it; they can be useful. I'm telling you not to overuse them, and not to use them where they don't serve a message-enhancing purpose.

Animated GIFs, blinking text, and marquees draw the eye. They're the first things that the visitor is going to look at. If there is a definite direction to motion in an animated GIF, the visitor's attention will be drawn in that direction. If you're going to use these effects, make sure that you want your visitor's attention drawn there first. In any case, think about their use carefully, because even after the visitor has looked at them once, they're always going to be visible "out the corner of his eye", and that's a distraction. Distractions are bad.

There are good color combinations, and bad ones. Good ones provide good contrast, and make the text easy to read. In general, dark text on a light background is better than light text on a dark background (light text on a dark background tends to get "swallowed"). Bad ones make text difficult to read, because they provide insufficient contrast. Some combinations aren't just 'bad', they're downright evil. Those combinations are the ones that simply work wrong with the physiology of color perception. Putting red text on a blue background is an example of an evil color combination. It vibrates. It induces headaches or dizziness. You can't look at it for any length of time.

You'll hear a lot of people say that you should stick to black text on a white background. It's not a bad idea, but there's a case to be made that the normal screen white is a bit harsh - like some bleached semi-glossy papers. Experiment a little. You may find that it's a lot easier to read if you use dark blue/navy text on a background that's just a little bit off pure white - say, just a touch of sky blue, or yellow. Be careful when fiddling with colors, though; remember that not everyone supports 24-bit color - or even 16-bit color. Netscape has established a de-facto standard set of 216 colors; if you stick to the colors in this so-called Netscape Color Cube, you should be OK on any browser that supports changing the background color. Today, you're probably OK with just about any color, but note that all displays do not display colors with the same accuracy. You still want to be careful, and check your color selections on different displays from different manufacturers, just in case. Sticking to the Web-Safe Colors (formerly the Netscape Color Cube) might still be a good idea.

Background music is one of my pet peeves. Put simply, I don't like it. I don't like it because I generally have my music playing, either on the computer itself, or on the radio. And there's often no way to turn it off; your choice ends up being to either tolerate it, or turn off all computer sounds. However, there are times when including the sound is a reasonable decision - if the sound has a real connection with the page. That means, for example, that it's perfectly reasonable to have the theme from "Murder, She Wrote" playing in the background on a page about the show, or "Hotel California" in the background of a page about the rock group Eagles. What's not reasonable is putting the theme from "Star Wars" in the background on a page that has nothing to do with the movie, simply because you think it's cool music. That's a distraction. Distractions are bad.

Even if you do include background music, don't make it loop forever. The ideal piece of music will be just about long enough for the visitor to the page to read through the page before it ends. Once. Twice, maybe, if your visitor is a slow reader. But too much repetition gets annoying. If the visitor isn't done reading the page after two cycles of the sound file, let them suffer a period of silence. Another thing that gets annoying is cheesy electronic music. MIDI files are good, in that they don't take up a lot of space. But they don't have the sound of a real recording, and never will. They're always going to sound like cheesy electronic simulations of real instruments. Actually, MIDI simulation of instrument sounds has improved to the point where they're often better than merely tolerable, and "cheesy" no longer applies. It's still better, though, to stick to recordings of real music in formats that have high fidelity.

Other use of sound isn't generally a problem, because it's on the visitor's demand, and the visitor knows what he's getting into. Long pieces, such as recordings of speeches or songs, should have a way to pause them, so that the visitor can leave the machine if necessary and not miss anything. Short items, such as demonstrations of how to pronounce a word, can just be played.

In recent times, multimedia has come to include video, possibly even more than straight audio. When included, the video is automatically going to be the center of attention. Take that into account when you're building your page.

Short form: Make sure that, when you add multimedia effects, you are enhancing your message, not distracting from it. Remember, your main purpose is to deliver a message; you don't want your audience to be distracted from that message, or confused over what that message is.

In our last installment, we noted that the response time of a page - how long before the visitor could start reading it - was important. You don't want to lose your visitors because they get bored waiting for the page to display.

Another technique that can improve response is to manage the size of your pages - large pages take longer to load.

Research has been done that indicates that people start to lose patience if there's no visible response within three (3) seconds; once a response starts, it must be useful within about ten (10) seconds, and complete within thirty (30).

Today, modem connection speeds in the United States so-called "First World" countries are largely 33.6 kbps 5 to 10 Mbps for cable, 1 to 5 Mbps for DSL, with 56 kbps becoming more widespread higher speeds expected to be deployed in the not-too-distant-future. However, there are still quite a number of 28.8 kbps modems out there. There are still people on dial-up, but even in those countries where state-owned telephone systems and high expense are the rule, it's not unreasonable to expect a dial-up connection to be at 50 kbps or so, even in the so-called "developing countries".

Overseas, the picture isn't quite so rosy. In many countries, state-owned telephone systems are the rule, and modems may be restricted in speed or significantly more expensive than in the US. 14.4 kbps and 9600 bps are still common speeds, especially in the so-called "developing" countries.

My recommendation: Tune your pages for about 20 100 kbps in a perfect Web. In other words, assume that the Web responds instantly, and that visitor's browsers can receive the data at 20 100 kbps. That's 2 10 kbytes per second. That means that the browser should be able to start to display the page after receiving no more than 6 30 kbytes of page material, it should be useful within 20 100 kbytes, and complete within 60 300 kbytes. That includes all text, pictures, tags, stylesheets, and so on. That should account nicely for delays in looking up IP addresses, establishing sessions, normal network congestion, and so on. Some people will see worse response; others will get better response. You can't please everyone; shoot for a happy medium based on your expected audience. Those numbers assume a generic audience, from anywhere in the world. If your pages are only of interest to people in your home town, and you know that everyone in your home town has a 56kbps modem 10 Mbps cable connections, and use the same ISP, you can sensibly design your pages around that fact - which will give you more bytes to play with. You could design general interest pages with 35 kbps 9600 bps in mind, to give acceptable response to virtually the whole world, but that will leave you with lots of teeny-tiny pages that will be an absolute bear to manage, and will lead to a lot of unnecessary clicking on links that amount to nothing more than "continued on next page". That causes even more of a performance hit than having 'oversized' pages does; it takes more interaction between the browser and the server to request a new page than it does to get the next piece of the current page. If you can get the initial response within the limits discussed here, you'll be in good shape, even if it takes more time to download the rest of the page.

The numbers, in this case, refer to the size of the image. The two browsers with the lion's share of the browser market, Netscape Navigator/Communicator and Microsoft Internet Explorer, All of the major players in the browser market are both 'intelligent' browsers. That means that, given appropriate information, display of a web page can be optimized. One of the possible optimizations is to place the text on the canvas and leave space for the slower-loading pictures. However, in order to do this, the browser needs to know the size of the picture. This, as with the alternative text, is done by adding attributes to the IMG tag - specifically, the 'height' and 'width' attributes. These may be specified in any valid measurement, but the most common by far are pixels or percentage of display size.

The attributes in question follow the expected format:

<IMG src="foo.gif" width="635" height="480">

or

<IMG src="foo.gif" width="60%" height="60%">

The order in which they are specified doesn't matter, although it is conventional to specify width first.

If you are displaying a picture at other than its actual size, be aware that if the aspect ratio (the relationship between width and height) is not preserved, the picture will appear distorted. If you make a picture larger than its actual size, you will see the effect called pixellation (it will become apparent that the picture is built up out of lots of little single-color squares); if your make it smaller, detail will be lost. Both effects can detract from the appearance of the page; the loss of detail is less noticeable, however, unless the details of the picture are of high importance (as in a reproduction of text). In general, it is best if the picture's actual size and display size are identical.

Note that, regardless of display size, the larger the actual size of the picture, the slower it will load.

Some wWebsite management software (most notably Microsoft FrontPage) generally allows for the generation of 'thumbnails'. These are much-reduced copies of the pictures in question that 'stand in' for the actual picture where only a very small image (up to 100x100 pixels, generally) is needed. Normally, the thumbnails are linked to the full-sized image. The benefit of using thumbnails is that they load faster than displaying the full-sized picture in the same area.

The advantage of specifying the display size, as indicated, is that it becomes possible for the browser to display the text without needing to wait for the images to load first. This allows a faster apparent response time to the user, which reduces the chance that your visitor will lose patience waiting for your page to load, and go elsewhere. And keeping your visitors' interest is what web design is all about.

Everyone knows the old saw, "A picture is worth a thousand words", and recognizes how true it is - you can't, for example, convey the sheer majesty of the Grand Canyon in words alone; you've just got to show the picture - and even that doesn't do it justice, but...

The same is true on the web - you don't try to describe things in detail when you can put up a picture instead. And the Web makes it easy to put up pictures.

But the title of this article is not an error. And it's just as true as the original. Why?

Put simply, it's because pictures don't always work. You may have inadvertently chosen a format that the visitor's browser doesn't support (stick to GIF and JPEG, although PNG is probably safe as well), or traffic to your server may be so high that graphics are being throttled, or you may have screwed up the link. And what's going to happen? You're going to get a big blank with a little icon in it, saying "there's supposed to be a picture here, but I can't get it".

Or, what if your visitor is blind? Braille-based systems are most likely not going to handle pictures well. Neither will text-to-speech systems.

All this may not be a problem if the picture is simply to add interest, and doesn't itself convey crucial information to the visitor. But more and more, people are using images for things like navigation links and effects on informative text. And when those pictures are unavailable, the site becomes close to useless to the visitor, because most people seem to forget one little thing - the words that are worth the thousand pictures.

I speak here of the ALT attribute to the IMG tag. One silly little omission that can kill a site. And it's so easy to include, too. All you need to do is change

<IMG SRC="foo.gif">

to

<IMG SRC="foo.gif" ALT="This is a picture of a foo">

That's it. Now, when your server is throttling so that foo.gif isn't sent to the visitor's browser (or when you link to fpp.gif by accident, and don't realize it), they'll still know what's missing. You can put longer captions in there, too. But the most important use is when you're using graphics as navigation buttons. In that case, they become absolutely essential - otherwise, how will anyone know where they'll lead you - some browsers don't provide useful information about a URL in a status line, and even with those that do, the user may not be in the habit of checking. It's best to play it safe, and make the ALT text provide useful information about what the graphic button does.

The only time that ALT text isn't entirely useful is when you have an imagemap (click on different parts of the picture to go to different pages). In that case, treat it like a regular picture (i.e., give it a good descriptive ALT text), but make sure that you mention that it's an imagemap - and provide plain text links for each region that you've defined, so that your visitor isn't totally dead in the water when the image doesn't come up.

Short and sweet. But, oh, what a difference.

(When I originally wrote this, the HTML specification didn't require the ALT attribute, although it was strongly recommended. In HTML4 and XHTML, it's required. Even if you're writing to earlier HTML specs, use the ALT attribute anyway.)

(This can actually be considered a digression referred to in the introduction. Nevertheless, it should be useful in establishing the context for the rest of this series.)

With all the millions of websites out there, there are, broadly speaking, only two reasons for a website to exist. And every page exists for exactly one of those reasons.

The two reasons boil down to:

  • I have this website because I have something to say.
  • I have this website because I can.

That's it. 'Having something to say' is a pretty broad topic; it covers everything from 'I'm a major corporation doing image burnishing and product/service selling' right down to 'This is my hobby, and this is what I want to tell you about it'. Whatever the specific reason, it lends legitimacy to the page.

What doesn't is 'because I can'. This is simply showing that you're 'cool', that you know what a web page is, and that you've learned enough about either HTML or a particular HTML-generating tool (which may be a provider's automatic generation software) to be able to create a page that doesn't break when someone goes to look at it. If that's all, why bother? This is the equivalent of a programmer learning a new language and writing the traditional 'Hello, World' program in that language - even if it's his first language, he's going to feel pretty silly about showing it off, especially to other programmers.

C'mon, folks - we already know that the medium is not the message, in spite of any pithy sayings to the contrary - so why use the medium if you have no message?

You'll hear that 'everybody' has a web page. You'll hear that you 'have to' have a web page. Stop for a minute. Think about who's telling you this. Ask yourself where they heard it from, or how they benefit if you do. Ultimately, it's going to come down to somebody trying to sell you something - internet access, web presence, web design services, and so on - or somebody trying to take you for something - essentially free advertising, overpriced addons to the services you really need, and so on. Think carefully. Ask yourself 'Do I really have something to say?'. If the answer is yes, and the cost isn't unacceptable, hey, go for it. If the answer is no, why bother?

(Actually, there used to be a third reason to have a web page - early browsers didn't have 'bookmarks' or 'favorites', so a lot of people set their 'home page' to be a page that had nothing but links to other websites. By the time I wrote this, originally, that usage had largely been relegated to 'legacy' status, and people had mostly converted to using bookmarks/favorites. I don't count this as 'having a message', although it was a legitimate reason to have a web page. Since some early browsers didn't support the file: protocol, allowing the browser to read the page from the user's own computer, it wasn't unusual to have these pages stuck somewhere on a provider's server. I no longer consider this to be a legitimate reason to have a web page; I'm not aware of any browser that fails to have both bookmarks/favorites and the file: protocol.)

The rest of the series will assume that there's a message involved somewhere.

For a number of reasons, I find myself spending quite a large amount of time surfing the web. As more and more people decide to have a website, I see more and more pages that will present problems of various types. Many of these problems can be avoided. This series will discuss what I perceive as the problems, and what I consider a good correction of the problem.

It cannot be emphasized enough that these are my own opinions, and are quite definitely not set in stone. They are, however, generally echoed by authors of books on web page design, with varying degrees of emphasis.

I had thought to attempt to classify errors, but I could not come up with a satisfactory scheme to classify them - quite often, any scheme I came up with ended up placing a common error into multiple classifications, in spite of the fact that I intended the classifications to be disjoint and comprehensive. So, I'm not going to classify them, just go through them one at a time.

I also expect that I will be digressing occasionally, and expounding on general concepts - or perhaps launching into tirades on topics that I have particularly strong feelings about. Bear with me. Don't let it provoke you into flames; try to stick with civilized discussion. As I said, this is my opinion. You're free to ignore it, and I'd quite frankly prefer that to getting involved in pyrotechnics or competitive urination.

Profile

freetrav

October 2022

S M T W T F S
      1
2345678
9101112131415
16171819202122
232425262728 29
3031     

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags