The alternative that I'm going to suggest is a combination of two techniques I have covered recently, film-strip rollovers and absolutely relative positioning.

It's impractical to swap a large JPEG image to achieve a rollover effect. It's not a good idea to have text on a JPEG image anyway as the compression used doesn't work well for type. Having multiple rollover images is also a fairly complex process. Breaking images up into a multitude of smaller slices is one way to get round it but a single image will load faster and cleaner than one that is all sliced-up because there is only one request sent to the server and one download.

Ideally, we should have a static JPEG image for the main picture and then place small, bandwidth-friendly, link buttons on top of that image. Those button images can have transparent backgrounds, if you like, so that they blend in with the background image seamlessly. This gives the best of both worlds – efficient JPEG compression for the background image and crisp, clean type on the button – plus you have the benefit of having rollover effects that you can control.

Putting a button on top of an image is easy with CSS. If the image is the background of a relatively positioned CSS box (div), we can use absolute positioning to put small buttons anywhere we like on top of that image with pixel accuracy, achieving perfect image-on-image registration if necessary.

• The cursor changes to a pointing finger.
• The status bar (if present) would show the URL of the linked page.
• The context is a clue in this instance but it's not always the case.

Now, when the mouse goes over the links, they emboss and when they are clicked, they deboss. These are tri-state buttons, each with a normal (off) state, a rollover state and a clicked state.

To make it easier to decipher the source code for these two pseudo-imagemap techniques, I have put the navbar example and interactive image on to separate pages which will open in new windows.

The only small price to pay for not using imagemaps is that with div buttons, we can currently only have rectanglar hot spots. There are situations where you might have to use ovals or polygons. For those, you will have to stick with imagemaps for the minute.

For someone used to designing for print, dealing with Web pages can a be a frustrating and hair-pulling experience – if you let it.

If, instead of fighting the medium, you work with it, and go with the flow, you will live longer and happier. 'Nuff said.

In print, technical stuff like this is usually handled by people at the production end. Knowing exactly how to trap certain colour areas or what dot gain and undercolour removal settings are required are tasks considered to be too technical for the average 'designer' – although he or she will probably be familiar with the terms.

It is asking a lot for any individual to know everything about everything. In a small company, you might have to know more than a designer working in a larger company with more resources to draw upon. A word of warning – 'Technicalities' can't just be ignored just because you don't understand them. The problems won't solve themselves.

The first step is in recognising that there is a problem. Without that recognition, you are really flying blind and sure to end up with a disaster on your hands. At best, it will be an embarrassment but it could just as easily cost you money or your job.

Having identified a problem, the second step is to find someone who can solve it – someone who can advise you, if it is a relatively simple matter, or to whom you can sub-contract the part of the work that needs done. Now, it might well be that what you are trying to do is totally impractical, or there might be a better way to do it that will cause less problems. 'Expert' advice does not come cheap. When you are estimating a job, it's up to you to build in a contingency for outside help if it is not available in-house.

Relying on software programs to get things right is a BIG mistake. Even the best WYSIWYG editors are flawed. The only 'perfect' Web page software is a text editor used by someone who knows what he or she is doing. A WYSIWYG editor can save time and provide valuable shortcuts but it's like any other tool, only as good as the person using it.

A printed page filled with fifty words costs the same (in effort and ink) as one with two thousand words. If you have to fit a lot of words on a page, you can make the type smaller. Printed type remains readable down to four points or less. On the Web, more words means more bandwidth and the smallest type you can get off with is nine pixels high.

Although it is less of a problem now than it used to be, everybody still doesn't have high speed broadband access to the net. For small Web pages, there is very little difference in page load times between a modem and broadband. Under ideal conditions, a page of 32k will take six seconds to download with a modem and one second with broadband. At 64k, the modem will take twelve seconds but broadband only about two. 64k is a substantial amount of text, about ten thousand words. A typical full browser page size JPEG image (760 x 420 pixels) will take about the same length of time.

So, text isn't generally a problem. Large image areas and Flash animations are.

For general audiences, with a higher proportion of dial-up users, smaller pages are obviously better. Allowing for a maximum download wait of ten seconds, a page 'weight' of 50k is a good upper limit to aim for. That includes text, images, scripts, style sheets and anything else. For more sophisticated audiences with a higher proportion of broadband users, this figure can edge up. The danger, as always, is judging page load times purely on your own computer or internal network. Even with broadband, there can be bottlenecks that slow down traffic at peak times or in remote locations.

You have to meet half way!