At several points in my web design career, I’ve worked with folks accustomed to creating for print. Invariably, these folks have been unhappy when their gorgeous designs make it into a web site, and their complaints have broken down into a number of common areas.
In the interest of helping my fellow Web site builders (and myself in the future) to work joyfully with print-oriented people, I wanted to relate some of these common misunderstandings, and, hopefully, give enough background on each of them to help both sides better appreciate where the other is coming from.
It’s important to note that I do not regard one or the other media as being superior from a design standpoint. Print has the advantages of being highly controllable in the presentation of your material; the Web has interactivity and immediacy on its side. Both have their place, but it’s important to avoid confusing the two.
When you start to design a print piece, the very first thing that you usually decide upon is the dimensions in which the finished product will be presented. Even if it winds up being scaled up or down, the proportions are usually set, and don’t change without redesigning the whole piece.
When you go to the Web, the very first thing you throw overboard is control over your page size and proportions. Your visitors may come to your site with a high-resolution monitor capable of displaying thousands of pixels (“picture elements” – dots on the screen) across and down the screen, and may have their browser set to use all of that available area.
Or they may come in with an old, low-resolution monitor, or using a laptop with a theater-style widescreen display on it. They might also shrink their browser window down so that they can keep tabs on something else they’re working on, skewing the proportions of your site completely out of recognition.
All of this means that, for the print designer, the most basic of precepts becomes a shifting heap of sand under their carefully-built layout. Elements of their design shift by not just a smidge, but by a whole lot. Things that they had counted on being visible together no longer are. Stuff at the bottom or the side of the page get cut off, and have to be scrolled to before they’re seen.
There are ways to get around some of these limitations, to be sure. Requiring that your site visitors come in with a certain resolution, designing your page so that it always displays at a fixed width or using plug-in tools that replace the technical standards of standard Web pages with tools more amenable to the designer’s will are all potential “solutions” to this problem.
However, each of these does violence to the most basic philosophy of the Web – that information will be interpreted and presented by whatever tools the user chooses, and often with a good deal of control exercised by that user, if he or she chooses. By insisting that they, not the visitor, should have the final say over how their site is presented, print designers misunderstand the fundamental principles of the Web’s architecture.
So, what are the tradeoffs imposed on users when designers decide to use one of the methods mentioned above to impose their design intentions on the presentation of their site?
Specifying minimum acceptable (or “recommended”) screen resolutions is the mildest of these, and is equally mild in its effectiveness. Users can (and may very well) ignore the advice, and will probably find it a bit off-putting. It sends a subtle message along the lines of “you must be this tall to play,” which may be interpreted as “if you don’t measure up, please go away.” Not a message you probably want to send.
Designing the page for a fixed width is a very common tactic, and one that generally works reasonably well, but it, too, has drawbacks. For users with very wide screens, the unused area of their browser window represents wasted space, and may be distracting. For those with very narrow screens, a fixed-width design means horizontal scrolling – which is always highly distracting. Distractions on the Web are always a bad thing, because a less-distracting site is always just a click away.
Finally, using plug-in tools, such as Flash or Java, can satisfy the designer’s itch to exercise total control over the presentation of their content, but at a steep price. Content loaded into these tools is usually very slow to load (“big and fancy” equals “fat and slow,” especially for a home user on a dial-up connection).
Even worse, not everyone is set up to use such plug-ins, so just to get to your content requires that they install special new software on their system. Some proportion of your users won’t even be able to do this, either because the software’s not available for their system, or they don’t have sufficient permissions on their computer to install software. For these users, your lovingly-built site is a big black hole. Not good.
All of this boils down to one basic take-home message: relax and let go of your desire to control the size and shape of your site. Your users will decide it for themselves, and your design needs to be flexible enough to accommodate their decisions.
Does this mean that you have no control at all over how and where things will be laid out? No, the situation’s not nearly that dire. Some hints:
- Think in percentages, not inches (or centimeters). You can specify that an element should be, say, 60% of the width of the window. If you really just have to think in terms of measured distances, your unit of measure is the pixel, not the inch or centimeter.
- Keep the important things to the top and left. So long as you’re designing for a language that’s read left-to-right, you can be pretty sure that the top left-hand corner of your page will appear in any browser that visits your site. Critical stuff should go there. (If your target language is read right-to-left, it’s the top right-hand corner that’s your most valuable screen real estate.)
- Alignment of design elements is usually relative to something else. You can usually count on being able to say, “I’d like for this to show up directly under that.” While with a modern browser allows you to say “put this 23 pixels from the top, and 49 from the left side,” not all visitors have modern browsers – and not all modern browsers are faithful in executing such instructions.
- Ask for the moon, settle for less. Always bear in mind that different browsers may not respect your wishes, so your design needs to “degrade” gracefully to accommodate them. However, you can design it so that it looks closest to your intentions under certain circumstances – and make sure that the majority of your visitors match those circumstances!
When you build a print piece, you usually know what sort of paper you’ll be printing on, and you can choose very carefully-calibrated process colors. You can even select special surface treatments such as spot gloss or foils to really dress a piece up. You can be confident that your piece will appear the same way on the last copy that’s printed as it did on the first one – or else the offset shop’s going to hear about it!
None of this is true on the web.
Again, hardware varies from one visitor to the next. Some people have display equipment that can handle millions of colors with fidelity enough to make a grown man cry. Others can barely manage a couple of hundred colors – and these can also make a grown man cry, particularly if he’s looking at his formerly-beautiful web site on them.
CRTs have brightness and contrast controls, but users cannot be expected to carefully calibrate them to an ideal profile. People have glare on their screens, or their equipment could even be failing. Different operating systems even have different characteristics in how they render color.
Furthermore, the web uses RBG values (“Red Blue Green” – corresponding to the basic colors of the parts of each pixel on a screen) to define colors, as opposed to the CMYK (“Cyan Magenta Yellow blacK” – corresponding to the ink colors used in process printing) familiar to print designers. The two have a certain degree of equivalency, but one is designed around emitting light in a specific wavelength (color), and the other is based on reflecting light best at specific wavelength.
Even worse, you’re restricted to a range of 256 levels for each of the RGB values, instead of the nearly infinite variability available to you in CMYK. This still yields a range of over 16 million colors, in an ideal world… but it’s not impossible that your site will be viewed on a system that can only handle a few hundred or a few thousand colors, with those millions of possibilities mapped down to a color that appears in a far more restricted palette.
The only good news here is that such restrictive hardware is becoming relatively rare and anachronistic. Even so, a palette of a few millions of colors – that will not be faithfully reproduced – is an unfamiliar environment for most print designers, so they must resign themselves to a lot more tolerance of color variation than they’re accustomed to.
In print, a very high fidelity image, at thousands of dpi (“dots per inch”), is pretty much just as fast to look at as one rendered crudely at a lower resolution. Faster, actually, as clarity is your friend on paper.
On the web, generally speaking, the nicer your image, the longer it’s going to take to get to your audience. In an environment where you get about 5 seconds – 15 if your users are really patient – to get a page in front of someone, before they click away to find a faster site, every bit you can trim from your overall page size is to your advantage.
In order to help web designers with this dilemma, most browser include support for three major graphic formats, each of which has its own benefits and drawbacks. They are the GIF (“Graphics Interchange Format”), JPEG (“Joint Photographic Experts Group”) and PNG (“Portable Network Graphics”) formats.
GIF is designed to provide compact files, but, more importantly for the web, supports transparent areas in the image. If your graphics will have edges that are anything but horizontally square, this is a very important feature. The GIF format also permits crude animation, allowing you to substitute all or part of the image area at timed intervals, including support for repeating the process. This was a very useful capability early in the development of the web, but if you want to do animation, there are now far more powerful tools available for it. (See the section on Interactivity, below, for more information.)
The major drawback with GIFs is that they can only have 256 colors (although, with some tweaking, you can pick the exact set of 256 to be optimized to best match those colors your image uses). For a large photograph, 256 colors is almost certain to result in some serious – and visible – degradation of the image’s quality. For simple line art, though, particularly if you will be overlaying a background of some sort, GIF is a great format to use.
JPEGs are ideal for most photographs, permitting you to use an essentially unlimited palette (the full 16 million-plus colors available to the web), and, better yet, offering variable compression of your image. The compression is “lossy” – which just means that at some point, it will also visibly degrade the image quality. Since the compression is variable, though, you can select the ideal balance between size and image quality for your purposes.
However, the JPEG format does not support transparency or animation, so if either of these is important for your site’s design, JPEG will not work for you. The JPEG format is ideal, though, for photographs and other detailed images where you need good color quality at a low cost in file size.
The last format, PNG, was consciously conceived as an alternative to GIF at a time when the holders of a technology incorporated into the GIF standard were making noises about demanding royalties from companies that supported GIF in their browsers and other software. It does combine many of the strengths of both GIF and JPEG, including, most critically, support for transparency and a full range of colors. PNG was not intended to compete with JPEG for photographic images, however, and does not incorporate support for image compression like JPEG does.
The file size for PNG can be about the same as for the GIF format, though most image editors are biased towards producing higher image quality and larger files. The real problem with PNG, though is that it is a newer – and imperfectly supported – format. Not all browsers can deal appropriately with its transparency capabilities, and many popular image-manipulation programs do not adequately optimize their PNG files.
PNG files are best suited for the same sorts of applications that you’d consider GIFs for – line art and places where you need transparency for your design. The further qualification for using PNGs is that you must be certain that your audience will be running browsers with adequate support for all of the format’s features, and that you can learn how to optimize the image files for size.
As you can see, even with only three formats to consider, there are a lot of tradeoffs and options to think about as you look at how to send your graphics to the user’s browser. One final thing to ponder as you determine how to incorporate graphics into your design: They may not make it onto the user’s screen.
If the user has graphics turned off, or is using tools that suppress material suspected of being advertising, or if something just goes wrong partway through the transmission of the page to the browser, one or more of your images may simply not appear. Your design should be robust enough to survive even this calamity, though, so that your visitor can still use your web site, even if everything doesn’t go perfectly in delivering it to them.
Whole careers have been devoted to excellent typography, and selecting just the right type face, or font, to convey a certain mood, a level of excitement, a call to action. Now, along comes the web, and brings along with it a new, much more constrained environment in which to work.
All content on a web page is transmitted either as text or as graphics. The graphics we’ve talked about a little bit already, but the text is where you can get really efficient about how you send information. A page full of words sent as text takes just a few kilobytes, and just a second or so, even over a slow connection. (A kilobyte – often abbreviated as “KB” – is just over 1,000 characters – letters, numbers, punctuation, that sort of thing.) A page of words sent as a graphic image could require ten times that (many megabytes – “MB”) or more – and take long enough for the visitor to wander off to someone else’s site.
Sending your content along with instructions for formatting it adds just a little bit of overhead. These instructions, or “markup,” form the basis of the concept of HTML (“Hyper Text Markup Language,” where the “hyper” part refers to the ability to include links to other content). A nicely laid-out page of text, before you add in the graphics, might weigh in at a dozen KB or so, and take just a couple of seconds to show up.
Part of the markup on a formatted page of text is the specification of the font to use. So far, so good. However, since it’s just the specification, now we’re dependent on the font being available at the other end. This is where the experienced typographer starts to pull out her hair. If your design uses a font that’s not available on the visitor’s machine, the browser will substitute another font (you can even specify a list of substitutions to try) but the resulting page will look subtly – or wildly – different from your original design.
Clearly, it’s in your best interest to use a font that’s widely available. Most web designers choose from the list of standard fonts available on a default installation of the current edition of Microsoft Windows. Microsoft maintains a good deal of information about web typography on their web site, and is a good resource to use in choosing fonts.
If there’s a font that’s just critical to your design, or which is somehow tied to other materials (a distinctive font associated with your branding, for example), you can send text in it as a graphical element, but be aware of the drawbacks of doing so.
Download size is an obvious issue, but a more subtle problem is accessibility for the vision-impaired (and those who don’t display images). This can be partially addressed by providing the text of the element as “alternate text,” displayed if the image is not available, and used by tools that enable the vision-impaired to browse the web.
Another problem is findability – search engines, while they will also utilize this alternate text, typically give it less credence than they do marked up text in determining what your site is about. Search engine optimization is a whole branch of web and information design, and is too large a topic to tackle here, but this is one easy pitfall to avoid.
One last note on web typography – you don’t get a guarantee of fine control over the formatting of the text, even if the font you’ve selected is available. If you’re accustomed to being able to tweak kerning (the space between letters with complementary shapes), leading (the space between lines of text), and even setting exact font sizes, you will find that some users will just not see these painstaking choices accurately rendered.
A basic browser displays all text in one of seven font sizes. Newer browsers will let you specify the exact size you want – but it’s subject to override by a user who has asked that all text be shown larger or smaller than specified. (This is to accommodate folks who have poor vision – or who have great vision and like to cram as much data as possible onto their screens.)
So, go ahead and lay out your page using font sizing and other typographical elements so that it pleases you. But don’t depend on having that level of control to make your site “work.” A visitor should be able to use your site, and not get lost on it, even if their browsing tools are not quite up to your standards.
So far, we’ve discussed a lot of limitations that the web places on the designer accustomed to working on paper. Now, let’s turn to the opportunities it offers, with an eye towards neither squandering nor overlooking these important capabilities.
First and foremost is the ability to include hyperlinks, which are simply places where the user can click to move to another page of content. Links can move the user around your own site, send them to someone else’s, or even trigger more advanced interactivity.
In designing links into your site, it’s important to respect the norms that have developed as to what a link looks like. A classic link is underlined and blue, purple if it’s already been visited, and maybe red as it’s being clicked. The creative designer inside of you may cringe at the thought, but that’s the convention.
It’s possible to make links completely disappear into the text of your content, or to alter their appearance so that they’re not so glaring. Many sites suppress the underlining, or alter the conventional colors to better match their chosen palette. It’s common in such instances to turn the underlining back on and change the color when the visitor moves their mouse pointer over the link.
These are okay things to do, but do them with the awareness that you will be sacrificing a tiny moment of thought for each visitor, as they have to consider how to find links on your site. If your links are blue and underlined, no further cogitation is necessary; the user can click with confidence.
Of course, it should go without saying that you should avoid making something blue or underlined – and never both – if it is not a link. (You, in the back – go sit in the corner for even thinking such a thing!)
As we consider other methods of interactivity, please allow me the hubris for a moment of quoting from my own book, Small Business Projects/INTERNET, where I talk about web design in general, and address a classic “rookie mistake” in specific:
Some years ago, IBM ran a television ad depicting a couple of gonzo web designers demonstrating a version of a web site for a client, on which they had made it appear that the client’s logo was on fire. The message of the ad was absolutely on point – glitz for the point of glitz is pointless to your customers.
The ability to make things happen when you move your mouse pointer over elements of the screen (a “mouseover”) is a powerful capability – and one that should be used in moderation. Wild animation is almost always a distraction from the message of your site. Audio elements that spring into action unbidden will cause most folks surfing your site from the office to immediately close their browser to avoid being caught slacking.
Basically, anything that you’re doing to stroke your own ego, without it having a clear purpose in serving your visitors’ needs should be eliminated from the design. Sites that win awards for demonstrating advanced design concepts are rarely sites that you want to actually use.
Mouseovers are often used to present menus or detailed information about a topic. For menus, they can be a very efficient way to package a lot of options into a very little space on screen – but they can also be highly frustrating to actually use, as you know if you’ve ever navigated several layers deep into an application menu, only to twitch and lose the mouse focus.
People surf the web on laptops, with touchpads or other pointing devices, and can’t always maintain the precision necessary to navigate a site that relies exclusively on popup menus. (Never mind the person who’s disabled the underlying technologies for security reasons, or who suffers a physical infirmity and cannot easily hold a mouse pointer steady.)
Using a mouseover to present detailed information related to the element being pointed at can make the information unprintable, in addition to sharing the problems noted for mouseover menus, above.
Wild animation – indeed, nearly any animation – is rarely necessary to clearly communicate information to your visitors. There may be instances where you’ve thought, “if only I could show them this in motion, they’d understand immediately.” On paper, obviously, this was not possible; on the web, it is, so use it if it’s that critical to making your point clear. But don’t animate things just to demonstrate how terribly clever you are as a web designer.
Audio is tremendously tempting for some folks. It’s particularly common to want to put “mood music” in the background of a site, or play sound effects when certain actions are performed.
First of all, audio takes up gobs and gobs of bandwidth to download, and can slow down the display of your whole site. Secondly, most music and many sound effects are copyrighted, and the copyrights are often defended by lawyers who have very limited senses of humor or decency, and who might gladly sue you into the dust. Finally, as noted above, unless your users actively request the audio portion of your site, you’ll flat-out lose many of them as the first note sounds.
Unless it’s the only way to relate some critical piece of information, and you are sure that you have the right to use it, and you let the user explicitly ask for the sound to start, avoid including audio in your web site design.
The most powerful and potentially useful form of interactivity available on the web is the ability to collect information from your users. By using web “forms,” as they’re called, you can have data sent to you via e-mail, stored in a database, or both. By utilizing a series of pages to lead the user through the process, you can accept orders online. (Be sure to investigate security for the data transmitted from your users before accepting credit cards information.)
Again, this is a topic too broad to really explore adequately here, but many possibilities will probably occur to you as you consider this capability. Another thing to be aware of is that you can also build your web forms so that they check the data submitted to be certain that it’s valid for your purposes before it’s accepted. This can be as simple as ensuring that an e-mail address is properly formatted, or as complex as checking to be sure that all of the options chosen for a product order are compatible with one another.
These capabilities cross over into the realm of serious programming, and may be outside of the scope of what you will take on as a web designer. However, by being aware of the capabilities, you can design for them, and incorporate them into your design.
One final variety of interaction I’d like to touch on before we wrap up our discussion of the limitations and possibilities of web design is the “applet.” (This is a diminutive of the term “application,” which in this context means “computer program.”) Applets can be built in Java or, more commonly, in Flash.
Flash is used extensively in modern web design, but I’ll be a curmudgeon here and say that I’ve only very rarely seen it used appropriately. Most of the animation you see on the web, wild or otherwise, is executed in Flash. Most streaming video is delivered using it, and many sites use it to provide glitzy navigational elements.
Flash files are generally pretty easy to build, using the (very expensive) tools that Macromedia provides for the purpose. This makes them terribly tempting for many web designers, because they can accomplish a lot of interactivity without having to do a lot of hard-core programming.
Unless you’ve just got to have these things, avoid the use of Flash. Its files are typically bloated, leading to very slow site load times. Sure, you can pop up a loading progress indicator, and that will keep some visitors waiting long enough for the thing to load, but for what purpose? If it’s solely to show off how clever the designer is, the visitor is likely to resent the slowness of the site, and is very likely to look elsewhere for what they need.
As noted earlier, Flash also has the drawback of requiring the installation of a specialized “plug-in” to permit the visitor’s browser to play its files. In all fairness, many browsers come with the Flash plug-in already installed, but many users will not – or even cannot – install it, leaving a large empty space on your page where your Flash element should have appeared.
Java is much harder to use, as it’s a full-blown programming language, with all the power and complexity that entails. It’s sometimes used to provide advanced calculations and specialized tools on the web, and is often perfectly suited for that purpose. Java programs can be small and efficient, or they can be bloated and slow to download, depending in part on the skill of the programmer, as well as the complexity of the program.
Due to short-sighted litigation from Sun Systems, Java is also often unavailable to the casual browser, as it’s no longer included in a default installation of some leading browsers. It may also be disabled for security reasons. Generally speaking, you probably won’t need to incorporate Java in a web design, unless you need its capabilities for a very specific purpose.
Testing your site
I’ve discussed a lot of cases where “some browsers” or “some users” may restrict your ability to employ a given capability in your web design. The best way to get a feel for what limitations you’re laboring under is to test your design in the environments where it will be used.
Before the first line of HTML is written, test your design on paper by showing it to people – strangers are even better than friends who don’t want to hurt your feelings – and asking them to describe to you how they’d accomplish a given task. Probe to see if the design is too busy – or too spare – for your targeted audience.
Once it’s been rendered on a web page, try out your site design in as wide a variety of browsers, operating systems and hardware configurations as you can lay your hands on. Try it on a dialup connection; run it over a high-speed one, too. If you’re re-launching an existing site, have a look at the usage log analysis and find out what your visitors are most commonly using, and try the site in exactly that environment.
Click on every link, and be sure that it does what you intended. Test all interactive elements similarly. Again have other people look at the design, and ask them to complete certain tasks. It’s better if you describe the tasks generally – “Order a blue widget” – rather than specifically – “Go to the ordering page and add a widget to the shopping cart, and then select the color blue as an option.” Seeing how your tester attempts to solve those intermediate problems will tell you a lot about the effectiveness of your design.
Once you’ve gone through a good testing regimen, you can feel good about releasing your design to the world. Don’t consider the job done and over with, however – you will need to stay abreast of changes in the norms of web design, ensuring that your site remains fresh and contemporary in its appearance and usability.
Like a good print piece, a web site has a definite shelf life, and will eventually need to be revised or rebuilt entirely. However, by investing the energy and time up front to make the design as robust as possible, you can ensure that it will serve you well for a long time to come.