|
|
| Academic Papers · Essays · Poetry · Sports · Writing Samples | |
As the World Wide Web approaches puberty, the prognosis for its teen years is that it may well die of acne. The scarred, pockmarked face of the Web is design—it has been ever since the HTML standard allowed for FONT and IMG tags—and it isn't looking good. There are many people to blame for this, and not all of them work for Netscape and Microsoft. In fact, there is more than enough blame to share among the software providers, web designers, programmers, the business community in general, and the World Wide Web consortium. Merely to establish blame, however, is to miss the point. Design is dying; I'm not certain that we've learned much in the last decade to resuscitate it.
Images on the World Wide Web have, on the whole, been a good thing. It's a ledger balance judgment, really. For instance, prescription drugs have been a good thing, too. They serve very useful purposes, what with fighting diseases and treating symptoms and all. On the other hand, countless people have been hurt by abuse, overprescription, and inflated prices. Graphics on the Web follow a parallel course. The ability to put images on a Web page has led, in many instances, to subsequent abuse of the privilege.
The transgressions surpass the ability of the average RV couple to post dozens of overexposed pictures of their last trip to Branson on a page. Trade that for the ability to display rover-cam shots in near real-time relay from the face of Mars, and we're still coming out way ahead. But ever-downloading pages of oversized photos, animated GIFs, banner ads, and other frontal assaults on the eyes are more the rule than the exception—it reminds me of the adage about eighty percent of everything being junk. And it seems, over the course of the last few years, to have become self-perpetuating; the more sites of this ilk to which people are exposed, the more they come to expect it as a norm.
The entrance of multimedia authoring software into the equation has only exacerbated the situation. At least at the beginning, the visitor to a website only had to worry about the animated GIFs moving (or, at worst, suffering through pages using the infernal BLINK and MARQUEE tags). Now, however, the web visitor—after suffering through an extended period of time staring at a black screen with little more than "loading" and "skip intro" on it—can enjoy pages on which every element lights up, shifts position, and plays a lead guitar riff whenever the mouse cursor chances upon it. Every time. Here's a tip for would-be designers: just because you can do something doesn't mean it's a good idea. There are Flash sites out there that can only be experienced, but try to imagine visiting the slots section of your average Las Vegas casino while in the throes of a grand mal seizure. And why is it that the most grievous offenders of multimedia site design never seem to give the visitor a non-Flash option?
The Web usability guru, Jakob Nielsen, once said, "About 99% of the time, the presence of Flash on a website constitutes a usability disease." Jakob is not known for timorous statements, and this one squarely hits the mark. To expand upon it, we should add useless graphics as a symptom of that disease. Unfortunately, we just aren't willing to commit to a cure, and the World Wide Web has a million Typhoid Marys out there.
There is no reason why a two-tone or three-tone complimentary color scheme should be less than adequate for 90% of site designs on the Web. Four colors begins to get busy, but a judicious designer can make it appealing. Any more than that, and even the best designers can get themselves into serious trouble.
Colors should be chosen with great care and for three primary reasons: readability, visual impact, and supporting tone/identity. The problem is that most people, when creating their Web pages, maybe think about one of those (usually the visual impact). And yes, there is an extreme impact when viewing fuchsia text on a bright yellow background. On the other hand, "blinding" is the impact most designers should want to avoid.
Readability is often the most frustrating, overlooked aspect of design on the Web. It usually begins with a designer who simply wants a website to stand out. If the future visitors are fortunate, it may be limited to an inversion such as white text on a black background. However, it can quickly devolve into a morass of background and font colors, tile-patterned wallpapers, and text that is best viewed using an electron microscope. There are numerous books, web pages, pamphlets, and other publications from which one can brush up on color theory. Suffice it to say that five and half centuries after the invention of the printing press, no one has been able to improve on the readability combination of black text on a white background. Even the World Wide Web hasn't been able to ignore that; if one were to visit every major content site on the Web, almost every site keeps to that convention. It's a standard, and to deviate from it requires the utmost consideration. But it hasn't stopped a lot of sites from doing just that.
Visual impact, as stated above, can have equally disastrous consequences when indiscriminately used. And, in unabashed irony, some of the worst offenders are the websites of Web design shops. A few of the recent "winners" in this category (names withheld to protect the guilty) are: aqua text on turquoise, puce text on brown, and—a real favorite—sepia text on a rust background color with a pinstriped wallpaper that makes any information nearly indistinguishable from the background. The point is not to embarrass this or that particular design shop. The point is that visual impact can cut both ways. If professional designers are missing the boat on color combinations, it doesn't leave much hope for the rest of us.
Supporting an organizational/thematic tone or identity is alternately the easiest and the most difficult aspect of color coordination. If there are corporate colors and a logo, the website at least has a starting point. Those have gone astray as well, but less frequently. Trying to design for identity from scratch, however, is a tiger on the prowl for fresh meat. How does one agree on what "conservative" means in terms of color? What about shocking? What about friendly? Ask ten people what the color red means to them, and you can have ten very distinct answers (in addition to a hundred side discussions about various shades). It's almost supernatural. That makes it problematic to reach consensus decisions on tone. As a result, many Web authors throw caution to the wind and pick colors because they are "pretty."
The resulting confusion over colors can be summed up by saying "less is more." Unfortunately, there are too many sites over the years that believe "more is more," or "the more the merrier," or "the more colors, the more professional the site." It's a technicolor approach to a black-and-white problem.
As with colors, fonts are subject to much abuse. Some of it comes from designers that think everyone else on the Web is viewing it on a 21-inch monitor at 1280 x 1024 resolution and 32-bit color settings. You can always tell those when the pages start to scroll horizontally off the screen. Then there are those that feel compelled to present their headings in exactly the font that they envisioned, which leads them to make their headings into images, which in turn adds cholesterol to the already clogged arteries in the Internet's circulatory system. And the FONT tag in HTML has caused harm in three ways: it thrust presentation onto a structural language, it choked up the page coding with even more tags, and it let people think that they could make up any content deficiencies by overcompensating in fonts.
The Web isn't about typography. It was never designed to be. Fonts are more dependent on the visitor than on the site designer. The visitor may have their own user style sheet in place, may have specified another default "sans-serif" font, may have turned the default font size up to something like 18 point text. The visitor may not have the exact font on his or her system; heck, the visitor may not be able to see, for all the designer knows.
The safest bet is to stick with an old printer's rule of thumb. Keep to sans-serif fonts (never all-caps) for headers and navigation, and use serif fonts for body text. The eyes you save just might be your own.
It's not so easy now to recall, but when the Web was first born, it was meant to be the great information exchange, an electronic library kiosk if you will, with access to the most important, relevant materials one could wish at one's fingertips. For a time, this almost seemed possible. Then came the advertisers. First it was banner ads stretching across the top of a page, all of them blinking with the words "Click Here!!!" shouting at you. Then, through the miracle of scripting, it became possible for advertisers to add pop-up windows to the useless morass of marketing clutter on the Web. Sometimes, not content with one pop-up, websites would force you to sit through three or four windows springing up with no warning.
Alas, this was not to be the end. One would have thought that with the utter collapse of the Internet ad revenue model into a shambles, we could have been free of some of the offenses of ad campaigns past. Instead, advertisers—not unlike roaches in a post-nuclear world—found a way to not only survive, but annoy visitors more banally than ever. The answer: web bugs.
For the uninitiated, web bugs are small advertisements that take place directly on the screen, covering up any useful content you may have actually wanted to read. They are usually animated, and are to date the most annoying form of marketing ever devised. The most devious of these require the animation to cycle completely at least once before the visitor is given an option to get rid of it.
The commercialization of the World Wide Web has been, and continues to be, one of the largest detriments to design. We're all to blame for it, but I think the corporations and marketing geniuses deserve a little more blame than the rest of us. That great electronic library? Oh yeah, it's still there. It's just been perverted into a garish electronic billboard. Happy surfing.
Tables were, like many other tags, at first an enhancement to the HTML standard. After all, the Web was about the interchange of information, and a distinct subset of that information was tabular data. To correctly present tabular data, designers needed the ability to construct and display tables in HTML pages. This is all perfectly logical. And, since designers needed to be able to improve readability of their data, it made sense to add attributes into the standard to specify how elements would align with one another. Then came the nuclear detonation.
Why not use tables to lay out a whole page?
It's an innocent question, one that you can't blame a designer for asking. Picture this state of things: a designer looks at a print layout and realizes that there is nothing in the HTML standard to make a page a certain width, to align objects relative to each other, or to divide the page into sections. The designer gets frustrated. Then someone points out that tables can be width-specific, tables can align objects, tables can be divided into sections. Frames could do similar things, but there were significant trade-offs, especially when it came to bookmarks. It made a certain amount of sense to make the leap at that point. Instead of using a table as part of the page, the page itself could be a table.
This opened up a Pandora's box of problems, some more insidious than others. Keeping in mind that tables were meant for tabular data, not design, the inclination of designers to use table layouts has led to, at best, destruction of the logical structure that HTML was supposed to impose upon the document. This really leads to problems on speech-reader browsers for the visually impaired. It also led to some really horrendous code bloating, especially on pages that contain tables within the table that makes up the page. It meant adding FONT tags on every cell to get the right font in the right place, which further cluttered the markup code of the file. And it added to the time needed to display pages on many browsers as well as adding time to the overall download time of the pages.
The situation has become so bad, in fact, that even David Siegel, one of the first evangelists of table-based layouts with "Killer Web Pages," changed his philosophy back in 1998. The exact quote he used to explain his shift was, "The Web is dead, and I killed it." Siegel has his own theories about that; I have my own. Essentially, it stopped Web design cold with one of two basic design choices, most of which can still be seen today: horizontal navigation menus and sidebar navigation menus. Assume a header and a footer to a page. That page will either have a horizontal navigation bar running parallel to the header with body text underneath, or, it will have a sidebar navigation (right or left), a column beside it containing the body text, and perhaps another sidebar on the opposite side (CNN's website, for instance). And that's where we've been stuck for years. It's become a de facto convention on the web to incorporate site navigation one of those two ways.
To their credit, both the members of the World Wide Web Consortium and designers alike have come to decry the over-reliance on tables for layout design, especially on the grounds that it has completely usurped the original mandate of HTML to present documents as logical structures and leave the presentation up to something else (the user, the browser, the device, whatever). With tables, structure and presentation are so intertangled that it is no longer productive to consider this a long-term alternative. This was the impetus behind the first working draft of Cascading Style Sheets in 1995. To relate back the very first analogy used in this writing, the World Wide Web Consortium tried applying a liberal dose of benzoyl peroxide to the Web. If HTML was getting cluttered with proprietary and presentation tags, the way to fix it was to deprecate or stop using most of the presentational markup and provide an entirely separate method of applying presentation to Web documents. By 1996, the Cascading Style Sheets specification was supposed to deliver designers to the promised land.
Well, even Moses couldn't keep his people from wandering in a desert forty years. And it may take just as long for Cascading Style Sheets (CSS) to get it right. Actually, that's not entirely fair. It may take that long for the browsers to stop flubbing their support for past standards and for the World Wide Web Consortium to quit recommending new standards before the browsers can start adhering to the old ones. The first standard to be thus abused was CSS Level 1, which allowed for control of fonts, colors, borders, margins, and other basic formatting attributes.
As previously mentioned, the working draft of CSS Level 1 standard has been around since 1995. This predates Netscape 3.0, for those of you with a sense of history. Netscape 3.0 in no way supports CSS; it doesn't understand it. Internet Explorer 3.0 tried to understand it and failed spectacularly. Ever since then, that has been the story. Netscape and Microsoft promise to fully adopt the standard and then, either through ineptitude or indifference, fail to deliver. That's not to say that the overall support for CSS 1 hasn't improved in later generations; it has. But it's not full support, and the wide variance between platforms and browsers has exacerbated the situation beyond the original scope of the problem.
If structure and presentation were married in the old philosophy of HTML design, at least it was the result of past practice and observation. The code presented in a reasonably uniform way across browsers and platforms. You don't often find yourself writing pure HTML that has to be optimized for different browsers and platforms. Unfortunately, the same cannot be said for Cascading Style Sheets. The rules are so mangled (most notably in Netscape 4 iterations) and misinterpreted that a perfectly valid rule for one browser will be completely misunderstood in another and may not even show up in yet another. And to give an idea of what kind of quagmire this is, Internet Explorer 5.0 for Macintosh was the first major browser to claim full CSS1 support. This didn't happen until the year 2000. There have been whole scripts developed to determine what kind of platform the visitor is on so that the appropriate tailored style sheet can be applied to the right browser. This does nothing but increase workload, and it should be unnecessary.
In 1998, when browsers were still ignoring or flubbing the CSS1 specification, the World Wide Web Consortium recommended the CSS2 specification, which improved on the formatting characteristics of Cascading Style Sheets and added support for placement. The idea was that by including positioning, the use of table layouts could be eventually eliminated. This was a perfectly logical idea. It also made no impression whatsoever on the browser manufacturers, who still couldn't get CSS1 right.
Here's the real paradox. You need at least adequate support for CSS to get rid of table layouts. As responsible designers, we agree that this makes sense; it also means our pages are easier to maintain, and we're all lazy at heart. So this is a win-win situation at this point. But it is impossible to get a page layout that works with positioning in all the various browsers you have to support. So, the designer grumbles, we'll compromise. We'll use a table layout because it at least presents the page uniformly across browsers with some CSS formatting to alleviate the inevitable code bloat. And this, in turn, leads to the exact opposite: the worst of both worlds. Not only has the designer utterly abandoned the very reason for turning to CSS, but some of the worst CSS bugs known to designers relate directly to—as if the layman couldn't guess—tables. And while this is going on, with browsers still marketing "improved" CSS2 support rather than "full," the World Wide Web Consortium is in process with the standard for CSS3. We are only accelerating the race to be left behind.
The alternative? Abandon column formats altogether and use basic CSS to improve the presentation with purely structural HTML making up the backbone of the document. Unfortunately, that has not proved flashy enough for most people's liking, and will never likely become a viable alternative.
So here we are in the year 2004, with more Web pages than ever (it's in the billions neighborhood). The World Wide Web is an eclectic mélange of colors, images, and fonts mixed in with Java applets and Flash programming. And there is a logical design trap that is problematic, to say the least. As a Web designer, you have two choices, either follow the de facto standards and color within the lines (so to speak), or serve up the mystery meat to your guests. Either way, the tendency of many designers (as a result of the demands of many users) is to put style over substance, form over function, and tacky over tasteful. I've seen too many sites that tried to be too flashy, cute, or savvy for their own good. But the Web keeps growing, design shambling zombie-like on its dead feet. I'm not sure there is anything we can do about it, as it's inherent to the media. But the more designers try to overcome the limitations of the media by sewing together parts from other media (print, television, etc.), the more Web design begins to resemble Frankenstein's monster.
Come to think of it, maybe it's not the design that's dying. Maybe it's the Web itself.