Do you remember your very first web page? The first one you ever saw? I remember the first time I saw a web page. I’m not sure if such a memory is unusual, or if many people remember their first glance at what was to become ubiquitous in a very short time.
The time was late 1993 or early 1994. I was working at Intel as a contract software developer when one of the other developers asked me if I’d seen this application called Mosaic. I wasn’t among the first to see this new type of application, but at that time the Web was still in its most primitive form. The first web page I saw had a white background, a larger, bolder header, and text formatted into several paragraphs. It wasn’t anything special, and nothing to excite interest. However, in the page was a thing called a hypertext link, an underlined piece of text that, when clicked, opened another page—one on a completely different computer, connected to the first only by a domain-driven location.
The second site, like the first, was also incredibly simple. It featured the same black text on a white page, and the only typographical variation was the larger font for the titles. It was completely empty of any graphics. No CSS; no images or Flash; not even a
BLINK. However, the two pages did demonstrate all that was critical about the Web: both pages were available to anyone with an Internet connection, each was at a specific location that could be called up again, and the pages were served through a coordination between server and client that was both unprecedented and mesmerizing.
What an odd way to begin a book about graphics: describing plain web pages completely devoid of any graphics. There is a purpose behind my madness. By describing this earliest glimpse of the Web, I hope to make an important point—that web graphics are not an essential component of the web experience. We can strip a page down to the most minimal markup without any use of Cascading Style Sheets (CSS), images, Scalar Vector Graphics (SVG), or Flash, and the page continues to be Web-like and useful.
Graphics are not necessary to the web experience. They can, however, add immeasurably to the richness of the Web, making the difference between a site that’s lively, compelling, and exciting, and one that’s merely functional. By looking at web graphics less as an essential component of the Web and more as an exhilarating companion and accessory, we can begin to free ourselves from the restrictions on, and requirements for, web graphics that have sprung up over the years, and to push against the “musts” that have constrained their use. Musts such as the following, for example:
Web animation is good. On the other hand, web animation is bad. Same for Flash, Ajax, scripted effects, SVG, the
canvas object, and so on.
The creation and use of web graphics should be left to the professionals. One must have years of training and be hugely dedicated to work with web graphics.
Sophisticated graphics require expensive software and equipment to produce.
Web graphics are inaccessible bandwidth pigs that eat mobile devices for lunch.
Web graphics are serious business because, as everyone knows, working with web graphics is hard.
So many musts, so little time.
I’m reminded of one of my favorite scenes from the Kevin Costner movie Robin Hood. In the movie, a Moor named Azeem (played by Morgan Freeman) is sitting at the edge of a village celebration, light shining on his dark skin. A cute little village girl approaches him shyly and asks, “Did God paint you?” Azeem responds in surprise with, “Did God paint me?” He then laughs gently and replies, “For certain.” “Why?” she asks. “Because Allah loves wondrous variety.”
All the various forms of web graphics—from CSS to images, Flash to SVG—can be many things, including useful, functional, and professional. Leaving aside all these practical considerations, though, I like to think that what graphics add to the Web is a wondrous variety. To support such a view, one can’t be held down by all the musts; the only real “must” with web graphics is that they don’t interfere with the functionality of the page. Once that’s assured, anything goes.
In the rest of this chapter—the rest of this book, in fact—we’ll look at the wondrous variety of web graphics. In the process, we’ll also show we can bust every one of rules just described, and have a blast doing so.
A functional world might be efficient, but it’s not terribly interesting. It would be like living on a diet of bananas, nut and seed granola bars, and vitamin water—it might keep you alive, but it wouldn’t be fun in the long run. In the end, when functionality is pushed up against individuality and choice, individuality triumphs. Black cars were good enough for Ford, but not the rest of us. Black and white TV was useful, but we wanted In Living Color. The whole premise behind the iPhone is that one can never have too many color buttons to touch. The push for variety has been the forerunner for the overall evolution of any invention in the past, and the Web is no exception.
If all web pages were simple text, we wouldn’t need the enhancements we’ve achieved in serving up web applications. We added graphics, though, which pushed the color requirements, as well as the sizes of pages. Our monitors improved, both in size and number of colors supported.
Music. Did someone mention music? Music to download, music to share, music to create and publish online, and music to sell. In just a few short years, the iTunes, eMusics, and Amazons have redefined not only how we use the Web, but how we find, purchase, and listen to music.
Of course, now we’re faced with the ultimate media: video, including complete movies being streamed from sites. Let’s see, tonight I think I’ll watch Core through Netflix. Or perhaps I’ll watch Max Headroom through Joost.
Pop! There went the Web! None of this is essential to the Web, but having access to such things has become essential to us. Some would say it was the economy of the Web that pushed improvements in web services. I put such improvements firmly on the graphical goodies.
Which of the items mentioned, though, are web graphics, the topic of this book? Most people think of image files with extensions of JPEG, GIF, or PNG when they hear the term “web graphics.” However, I consider anything that impacts the visualization of a web page, above and beyond the components that provide the initial structure, part of the family of web graphics. This includes:
Image files, as we would expect
Visual attributes associated with the page elements, and the CSS that controls them
Embedded or integrated graphics, such as VML, VRML, SVG, and the
Scripted effects, such as those made popular with DHTML and now Ajax
Packaged, interactive animations such as those provided by Flash
Frameworks and libraries that generate graphical effects using any of the above
The one item missing is video, and that’s primarily because video examples are a little hard to embed in book pages. Perhaps by the time this is ready for the second edition, we’ll have a workaround for this particular challenge, and I’ll add it to the list. For now, other than video and Flash, these items form the basis of this book.
Back when matchbooks proliferated about as much as smokers welcome in restaurants, many of the matchbooks would have a picture of a clown or dog or some other character with the words, “Draw Me!” across the front. The matchbooks were put out by various art schools, and aspiring artists would do just that, sending in the result to get an evaluation of their skill. Evidently, to the schools, we all have a little artist in us because few people would be dissuaded from signing up for a course.
One of the “musts” associated with web graphics is that we “must” be artists, or we “must” be designers, or even that we “must” have a degree or specialized training. Creating web graphics does require some artistic ability, but as the early matchbook art schools discovered, there’s a little artist in all of us.
While a professional graphic artist may be necessary for many effects, it’s not true for all. In fact, there are many effects that can be created with only a minimum of training, a little technology, and a willingness to give something new a shot.
For instance, later in the book I’ll cover SVG, a way to create graphics using an XML vocabulary. The approach seems intimidating at first. How does one create a sophisticated graphic from simple primitive elements such as the following?
<circle r="6" cx="24" cy="16"/>
Yet there are by-the-number approaches one can take to make copies of an original design and then convert part or the whole to SVG, using a tool no more complex than a text editor.
Well-known computer technologist Sam Ruby uses SVG icons for each of the entries in his weblog. They’re quite nice, and this surprised me a little because I never thought of Sam as a nascent artist. He wrote a post that described how he created the icons, using nothing more complex than
vi, a popular Unix text editor.
The steps he followed are:
Embed the pattern to be copied or converted into an SVG document.
Resize it, if necessary.
Trace the areas on the original graphic using a sequence of SVG elements, such as circles and squares.
Use SVG paths to outline components of the graphic that don’t fit within the existing pattern of other elements, such as circles.
Adjust width, color, and position as desired.
Remove the original image.
Though Sam didn’t mention how he knew where to position the figures and their sizes, they wouldn’t be too difficult to estimate from trial and error: change both position and size using the text editor until your copy fits as you want. Once you’ve captured the pattern in SVG, remove the original image, and voilà, you have your new design.
To simplify the approach, you can print out the original image, place it under graph paper, trace over the design, and use the lines in the paper to plot the outlines of the graphic elements you want to copy, as demonstrated in Figure 1-2. Then it’s just a matter of transforming graph points to SVG polyline or path points.
Though having to map from a graph to an SVG document can be a bit tedious, the approach does demonstrate that you don’t have to be an artiste to be creative. Of course, it would be nice if we could eliminate the tedious work with a handy tool or utility, but these all cost so much. Don’t they?
See Sam’s original post on his SVG approach, with examples, at http://www.intertwingly.net/blog/2007/02/16/Recreational-SVG.
If you want to do web graphics, be ready to put up the big bucks.
Graphics work can require an initially heavy investment in more than just time. You could have to shell out thousands for a beginning setup: a high-end 12MP camera, possibly a scanner, definitely a modern computer maxed out with memory and space, expensive software, and so on.
You could have to shell out the bucks, and if you’re a professional or have the money, all I can say is, happy spending! If you’re not a professional, though, and don’t necessarily have a lot of extra money, you can still do some pretty amazing things in web graphics for little or no cost. All it takes is a little ingenuity and a good understanding of what is or is not needed for working on the Web.
Take that high-end camera I mentioned. If you’re a serious photographer, you’re going to want to invest as much as possible in a good digital camera and accompanying lens. The investment will pay off in the long run.
However, if you’re mainly interested in photos for illustrative purposes, as a way of capturing events, or just for fun, most digital point-and-shoot cameras do an excellent job and provide enough resolution to print to the Web. In fact, you don’t necessarily need a 12+MP camera unless you’re considering publication to professional magazines, or expanding the images into larger wall art.
Consider the sizes of most images you find online. Very seldom are they over 600 pixels in width. Even the largest images are seldom beyond 800 to 1,000 pixels wide. Most of the point-and-shoot cameras I found online when writing this book can easily provide images up to 1,000 pixels wide and still provide plenty of detail, in a range of ISO speeds, and with built-in zooming lens, all for less than $250.00 US—and that’s high end for a point and shoot.
Once you have your images, what kind of computer do you need? Well, the software you use tends to drive what you need for a computer, but nowadays computers are getting cheap. Even laptops are running less than $500, and one can get a desktop machine with a really nice monitor and plenty of memory and disk space for less than $700.
Again, depending on the software you use, you might not even need a more modern computer. I’ve used computers that were four and five years old to provide image processing and had little problem. The processes may be slower, but as long as the image file sizes are small enough (there’s that point-and-shoot camera again), they’re not so slow as to be painful.
Of course, if you’re going to be using Adobe Photoshop, you’ll need the newer machine, but you don’t need Photoshop to process pictures or create graphics. The GNU Image Manipulation Program (GIMP) does an excellent job, works well with a variety of image types, and—with a little help from another free program, UFRaw—can even manage RAW files, which are image files where most or all sensor data is maintained with the image.
Another popular graphics program is Paint Shop Pro, and though not open source or free, it is most definitely affordable. In fact, there are many no-cost or low-cost software alternatives, a couple of which we’ll look at (along with some of the more expensive varieties) in Chapter 3.
As for non-photographic work, the field gets even richer. In the last section I detailed a couple of approaches for incorporating other graphics into new SVG files. Instead of using a graph, you can use something like Inkscape to either trace over an image or create your own images and have the file saved as SVG.
Find more on images, image utilities, and programming with images in Chapter 2.
How about if you’re a software developer who wants to work with graphical frontend tool sets? After all, we’ve known for years about Microsoft’s developer networks with their $2,500 price tag, and the tool sets from Adobe and other companies that cost in the hundreds, or even the thousands. Unless you’re a professional using such tools for a living or a really dedicated hobbyist, such prices are beyond most of us. Even the professional can’t afford most of the tools nowadays—they’re priced for corporate access.
I can’t guarantee that all applications will run on all computers, but I will guarantee that none of the examples and applications covered in this book will require you to buy anything. In some cases, you’ll need to download trial software, but the trials will last long enough for you to get a feel for the software and definitely complete the exercises demonstrated in these pages.
When considering the use of graphics on a site, people should ask themselves three questions:
How much bandwidth will the combined use of graphics cost?
What impact will the use of such graphics have on accessibility?
Will the graphics work on a smaller device?
The “fun” part of web graphics is that the site should be fun to everyone who accesses a web page or application—not just mouse-using, sighted people with high-end broadband connections and the latest computers and monitors.
There is no getting around the fact that many uses of graphics are not very accessible, but a surprising number are, or at least provide alternatives for those reading pages using screen readers or screen magnifiers. Something such as the
alt attribute in an
img element provides a way to textually describe an image. Providing a text link to go with an image’s mouse-driven menu item allows access to site navigation regardless of whether a person is using a keyboard or a mouse.
As for bandwidth, image size can be optimized with little or no degradation in quality, and scripting can provide functionality to easily expand images from thumbnails. One of the simplest approaches to improving performance and speed of page downloads is to serve images from different subdomains.
Most browsers allow only two simultaneous HTTP requests to one domain. If you’re serving up several images, only two can be accessed at any one time when this limitation applies. To enhance the page loading experience, especially if you’re using a lot of images, you can create several virtual subdomains, such as the following:
img1.somedomain.com img2.somedomain.com img3.somedomain.com
Another workaround to loading files is to embed graphics directly in the page. Newer graphical techniques, such as SVG and the
With the increasingly popular use of handheld devices, such as the new iPhone, sites have to play a virtual Gulliver, growing and shrinking gracefully to match their surroundings. At a minimum, sites can provide mobile CSS and programmatically strip images and Flash shows from a page. At a maximum, web applications using a variety of dynamic effects can provide sophisticated applications for devices with web access.
All three areas—accessibility, bandwidth, and mobile devices—can present challenges in the use of web graphics, but none are so insurmountable that the use of graphics has to be eliminated completely. There’s no need to take web pages back to the version-one pages I described at the beginning of the chapter. How much of a challenge depends on how important the graphic is to the site.
Not a bit of it. As demonstrated in earlier sections, for almost every effect there are examples, samples, tutorials, and step-by-step instructions for how to create and re-create them. More than the documentation and other helpful material, the Web is rich nowadays with libraries and application programming interfaces (APIs) and frameworks in which to create sophisticated web applications that incorporate or are based on web graphics.
When creating static graphics, I’ve found that once you categorize an effect—“Web 2.0 reflection,” say, for reflecting titles—there’s invariably a tutorial, usually with figures, that leads you step by step in how to do it. Most of the tutorials are for use with Photoshop, but the steps can be mentally converted for use in other tools.
Embedded graphics such as SVG and the
canvas object manage much of the tedious details of creativity, and all you have to do is pull together the pieces to create a more complex whole. Best of all, since both systems are based on open text in a web application, you can see how others have created effects and learn how to emulate such yourself. That’s actually why I’m such a big believer in both SVG and the
canvas object and have devoted so much space in the book to both.
Many rich web applications make use of Ajax graphical effects, such as hiding and showing page elements, moving or sizing, layering, fading, and responding to the application user’s actions. The more common of these can be found already implemented as a single function call in a variety of libraries, such as Prototype, JQuery, moo tools, Dojo, Dean Edwards’ base2, and so on. There are also server-side frameworks that allow one to code in Ruby, Python, or PHP, and have both the client and server-side functionality managed.
Though not covered in this book, even newer development tool sets and frameworks—such as Microsoft’s Silverlight, Adobe’s AIR/Flex, and the open source OpenLaszlo—can be used to create the graphics. It’s rare when a person has to actually code a more complex visual effect from scratch.
Creating graphics does not have to be hard. Once you keep in mind the key element behind the use of graphics—that they aren’t essential—you’re then free to explore and innovate. Most importantly, you’re free to have fun.
First, though, just when I’ve convinced you to flout conventional wisdom and break rules, we’ll take a look at certain uses of web graphics in the past where convention and rules were basically blown out of the water, resulting in web sites that scare children and can physically harm small, furry animals. Seriously, these examples break that one, fundamental rule of web graphics: they must not interfere with the functionality of the web page. I call this list my Web Graphics Hall of Shame.
Of course, now that I’ve made a mockery of the rules of web graphics, I must backtrack and state that there are times and places for some rules. In the world of web design and development, we’re defined as much by our mistakes as our successes. In many ways, web design is perpetually living in the 1980s, so to speak, and surrounded by an excess of both the frivolous and the epitome of poor taste. We laugh at what we’ve done, even as we hold such in affection.
In light of this, I give you the Web Graphics Hall of Shame. Before beginning, though, note that I don’t come here in disdain, but in celebration. Each of the web graphics listed in this section is a symbol of our growth, and as we all know, growth pains mark progress.
Using the technique made popular by the night-time comedian David Letterman and a generation of follow-up pundits, I give you the Hall of Shame, in descending order.
For a time the Web was littered with sites that were “under construction,” many staying this way for months, or sometimes even years. Typically the page had some cute animated “Under Construction” graphic, a claim of wonderful things to come, and that was about it.
At times there would be some very decent use of graphics, so I don’t want to necessarily pin the awfulness of these sites on the graphics. No, it was the overwhelming number of such sites that at one point left me with an idea that the Web was nothing more than the domicile for those with big ideas and little follow-through.
Today, you rarely see an “Under Construction” animation or image. It, like so many other uses of web graphics, was something that represented a specific era. Now most sites under development usually just have the site name, a description of what the site will be about, and perhaps links to additional information. Most sites don’t even publish the URLs to search engines until they’re ready for rollout, which is the better option.
This is a book on web graphics, not web design. However, it would be remiss of me not to touch on design where it pertains to the use of graphics and, in particular, to briefly discuss the sameness of use that defines entire generations of web design, and the part of graphics in such crimes against individuality.
In the beginning (and I don’t mean that in a Biblical sense), pages had a sameness of look and feel, primarily because we didn’t have a lot of choice. Until the first generation of Mosaic was released, we couldn’t even add images to a web page.
Now, even when we have considerable choice, web graphics advances and the availability of new techniques contribute heavily to whatever is the current look. Years ago, when the use of background images was new, everyone used a background image. Later, when the use of DHTML started to become more popular, script-driven drop-down menus were big. Then came Flash splash pages, rounded corners, and today’s use of reflected mirror-image logos and the ubiquitous “beta” to describe services in a state ranging anywhere from bloody alpha to desiccated reliability.
Much of this sameness of design is based on excitement associated with “new toys” and our being enamored with their novelty, using whatever is new in web graphics capability as a driving force for design, rather than using the web graphics that work for our own individual tastes and needs.
Black text on white may be the most legible, but it soon paled on the generations of people used to color television and color photography, not to mention the flower power generation where everything was colorful even when black and white.
Luckily the W3C rescued us from a land of monochromatic pages by providing some attributes with the release of HTML 3.2. Included among these was the ability to change font color, background color, and, in a dizzying display of markup generosity, add a background image.
Suddenly, the Web was alive with color…and color…and color…and color. Where before we had sedate black and white, now we had bright and bold background images with pink, blue, red, and yellow text—sometimes all mixed up on the same page.
Not only that, but we could also change the background for individual table elements. Since most page layouts were managed with HTML tables, not only could we have an overall page color and pattern, we also could break the page into many different pieces and give each its own color or pattern, all in a blurry, headache-inducing visual extravaganza. It was like giving hamsters espresso made from the finest Colombian beans and turning them loose on color wheels, each with packets of paint attached.
Color is good, and I sometimes think we focus too much on what is tasteful and elegant, and not enough on individual expression. At the same time, though, putting text directly on a patterned background, or dark red print on black, or yellow ochre on pink, results in unreadable text. You can provide a subtle, transparent background image behind text, or use different colored fonts on different colored backgrounds, but you have to use caution. The first priority has to be readable text, not design.
(I was not immune to this colorful exuberance myself, experimenting with both color and pattern over the years. When I smile at the rodent with the wheel, I do so only in shared amusement.)
The caffeine hamster still lives, appearing from time to time. A good place to look for examples is at Tripod sites (http://www.tripod.lycos.com/). Just search for “rainbows” and “unicorns”—you’ll find plenty of examples. Most sites returned are ones that haven’t been updated for years, providing a history of web design embedded in really awful amber.
There are some sites that I read only reluctantly, not because of the writing or other content, but because the sites have so many widgets tied into external sites that it can take minutes for them to load all the data. I sit there, watching the status bar on my browser as one resource after another is loaded—too many from ad sites that have some serious performance problems.
Embedded access to external web sites has been a part of the web experience for years—mostly ads driven from some externally controlled process. In the last few years, though, we’ve seeing an explosion of externally linked material via the use of widgets.
Widgets add to the richness of the site: photos served off a Flickr widget; directions given via a Google map; a YouTube video or two; current bon mots from Twitter. However, widgets clamor for resources, not only in the web page, but also in your browser.
A minimal set of very useful widgets that are pertinent to the site’s topic and focus can add to the uniqueness and novelty of a web site or application. If these are fronted by simple, lightweight, and attractive graphics, you’ll be congratulated on your good taste.
However, indiscriminately slapping widgets in a helter-skelter display of clashing demands, solely because they’re “cool,” is gluttonous behavior that will, ultimately, cost you visitors.
It’s hard to remember all the way back, but I vaguely recall that when the Netscape Navigator browser was first released, you had to license the product. Hard to imagine today, now that browsers are freely available, but Netscape’s Navigator dominated the browser market until 1995. That was the year that Microsoft released its first browser, Internet Explorer.
The first version of IE wasn’t anything interesting, but that all changed later, especially when both Microsoft and Netscape released version 4.0 of their products and introduced us to what became known as the Browser Wars.
As for CSS, the more famous IE-specific “bugs” were given names as solutions were found to work around the problems—names such as “Peekaboo bug” and solutions such as the box model hack.
The early browser wars were some of the worst times to develop web applications, but they were also important years in the growth of the Web. If companies had waited until organizations such as the World Wide Web Consortium (W3C) released specifications and then adhered directly to them, we most likely would not have the increasingly sophisticated technologies, specifications, and browsers that exist today. This includes advances in web graphics, many of which started life as a proprietary object or extension of one browser or another. Still, what a pain it was to be a web developer in the late 1990s. Tim Berners-Lee, proud papa of the Web, wrote the following in 1996, in the publication Technology Review:
Anyone who slaps a “this page is best viewed with Browser X” label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network.
When Dynamic HTML (DHTML) was first introduced, what an incredibly exciting time in web development. With DHTML we could collapse and expand portions of the page, change colors, use transparency and clipping, and even create animated effects. Almost immediately, we started using DHTML for everything, and that included critical components of a web site, such as the navigation.
In the latter part of 1999, I was hired by a new dot-com in Boston to basically get the company’s bread and butter applications back on their feet. The company had used an initial VC funding to hire a design group that burned through $1.2 million creating basically very pretty pages, none of which worked if scripting was turned off. None of the server-side functionality was created, but even if it had been, the site was completely dependent on image-based drop-down menus requiring mouse access. The irony of the situation was that one of the key testers of the system was blind.
What we did was ruthlessly rip out all script-based DHTML menus, simplified the site structure, and actually got to work building the backend application. Menus were images, true, but were given hypertext links, keyboard access, and alternate text.
It’s easy to see mystery meat navigation today. If you use Firefox as a browser, install the NOSCRIPT Firefox extension, turn scripting off globally, and see which sites you can still navigate. Murmur to yourself, “Naughty, naughty” when you discover ones you can’t.
In the early days, the only active component of a web page was an animated GIF, and the world went insane with their use. There really isn’t anything wrong with animated GIFs, and I use animated images such as throbbers (animated status indicators) myself, though sparingly.
It was the overuse of animated GIFs that became the problem. It seemed as if some sites had hundreds of these movable beasties, and not only did they slow down page access times, but also all that animation only served to distract, giving one a headache and a strong desire to flee for one’s life.
There’s also another very real threat associated with any animated effect. People who suffer from photosensitive epilepsy can have seizures triggered by web page animations of a certain type. Any animation with a repeating pattern that can cause the monitor to flicker at a frequency between 2 Hz and 55 Hz (as noted in the U.S. government’s Section 508 guidelines at http://www.section508.gov/index.cfm?FuseAction=Content&ID=12#Web) can cause such a seizure and should be located in a secondary page with a note warning the person entering such a page that the content is animated.
Animation is good as long as the web page reader controls the animation. We need the ability to turn on that movie, presentation, and so on. We need control, and animated GIFs deny us this control.
Ajax effects, such as the yellow fade that signals a change, are different. They’re over quickly, and they serve a useful purpose: highlighting that a change has occurred. Animated GIFs, though, just sit there and move.
Animated annoyances are still around; however, most today are Flash, and most are ads. Why some people assume that if we’re annoyed enough we’ll click their ad or buy their product is beyond me. I think, though, that those who create animated ads are still mentally stuck back in a time of pages full of flying butterflies, gems that sparkled, cars that moved their little tires, and little choo-choo trains that puffed little-bitty clouds of smoke.
I suggest intervention, both for the creator of such ads and for those who host them. In the meantime, to see some interesting uses of annoying animated graphics (in addition to other murderous uses of graphics, not to mention horrid use of MIDI files), return to our friend Tripod (http://www.tripod.com) and this time search on “butterflies” and “rainbows.”
Even today, it’s not unusual for the front page of a site to be a splash page, playing some animated Flash sequence that, once finished, displays an “Enter Site” message.
The concept isn’t bad, but it is counter to the Web, which implies that we never take control from the users. Splash pages do this by forcing people to wait through an animation in order to get to the “meat” of a web site.
Web sites that resize your browser window also fit under the category of “taking control away from the user.” There’s a difference between opening a separate help window and mucking with the user’s existing window. It’s a bad practice, as bad or even worse than splash pages.
A comparable method for preventing access to content by the reader is the newer ads that use DHTML to position ads directly over articles or photos, which keeps you from viewing the item until you either view the ad in its entirety or find the small “Close” button that allows you to close the ad. Again, why a company would think we’d be disposed favorably to clicking through on a link or purchasing a product based on their annoying behavior boggles the mind.
Splash pages are effective only when the creators provide a “Skip Intro” or comparable link that lets a person jump beyond the page. It’s still not the best approach, but at least it doesn’t use graphics to disrupt the site visitor’s web experience.
I imagine you would think the use of the
BLINK element or the comparable
MARQUEE would rate number one on this list. There is probably no more hated element in all of HTML than
BLINK, with its irritating demand for attention. Just as with animated GIFs, the users of blink seem to believe that people have to be slapped for attention when viewing a web page. Or perhaps static text can’t possibly be entertaining enough.
MARQUEE element was never quite as bad as
BLINK, and never had such wide usage. It provided the same level of annoyance, though, scrolling text too fast to read and distracting you from the material you’re trying to understand.
The problem with both elements is that they, again, take control away from the application users or other site visitors. They distract without adding any meaningful content or service. They’re a graphical device used to add an illusion of interaction when no real interactivity is supported. They’re a cheap trick.
About the only places where both elements are in use today is in sites that have been long abandoned. Unfortunately, though, we now have modern variations of both, some of which are served via Ajax.
Many online newspaper sites provide headline or video sections where items are continuously scrolled, showing the top stories. Usually the scrolling occurs too fast to click the item you most want to see. A better approach is to present the top three most compelling headlines and a link to see additional items. At a minimum, providing a link to a secondary page that lists all items gives people an option.
A popular weblogging search engine did a major redesign fairly recently, and as part of the effort added a scrolling marquee-like effect to the top part of the page that was based on the use of tags (keywords used to classify web content) and refreshed using Ajax calls. Not only was it not useful, it caused performance problems with some browsers (such as my own Firefox on the Mac).
A popular Flickr badge used in page sidebars was based on an animated effect that would quickly expand and then contract images among the thumbnails presented, creating an effect that obscured most of the photos. Recently, people have started using a more static approach, which demonstrates that most uses of such animation is based more on a developer’s wanting to “play” than a true customer interest.
Again, gentle uses of animation to highlight important information in an unobtrusive manner can provide useful information, while uncontrolled animated effects do little more than annoy. Now, if only we could get this point across to all of those animated ad creators.
Now that we’ve seen browser wars and animated “Best viewed by” messages competing with color madness and uncontrolled page overlays, what use of graphics could possibly be so awful that it beat out all of these and
BLINK as the worst use of graphics in a web page? Oddly enough, it’s an element that we can’t see.
Before the adoption of CSS there were two main ways to control page layout. The first was HTML tables, and the second was a one-pixel transparent GIF commonly known as the spacer GIF.
When the IMG element was added to HTML, it was given attributes such as
height, as well as padding through
hspace. Typically the
hspace attributes were used when controlling placement of content within table cells or other web page elements.
If you wanted to move content down the page or over to the side, you could use a spacer GIF and provide a width and height (or vspace or hspace) to create the effect. By using this technique, you could move text blocks, indent paragraphs, position elements where you wanted them, and so on.
There’s no universal agreement on who created the idea of the spacer GIF, though David Siegel, who wrote the book Creating Killer Web Sites(Hayden Books), is generally thought to be the first to make such tricks publicly known. For a real blast from the past, you can read his description of it at http://www.killersites.com/killerSites/1-design/single_pixel.html.
I still have my spacer GIF, a file called blank.gif, that I used in addition to tables to create various designs on my web sites. It was a clever idea, as was the use of HTML tables, for controlling layout in such a way that the layout would adapt as the browser was resized.
However, when the spacer GIF was used, people seldom set the
alt attribute to an empty string (“”), which would ensure the image wasn’t picked up by screen readers. It must have been awful to access a page loaded with spacer GIFs, none of which had alternative text.
The spacer GIF, HTML table,
FONT tag, and attributes like
background all shared one thing in common: they provided ways of working around the lack of consistent CSS support and enabled not only a quick growth of web pages, but the first rudimentary controls on web page layout and appearance. Unfortunately, their use reduced the urgency to create and spread adoption of standards such as CSS, and even to this day, they are used in way too many sites, as people resist learning the newer technologies (since what they have still works).
I picked the spacer GIF as representative of the family of such old and outdated techniques to control the page’s visual appearance. I placed it first in this list because no other single element has had such an adverse impact on the growth of standard, cross-browser web graphics.
As I wrote earlier, the only real rule for web graphics is that they shouldn’t interfere with the functionality of the web page—in other words, they shouldn’t interfere with the web experience. This means that:
The use of color and pattern shouldn’t be such that the content is hard to find and read.
Animation should be useful, not distracting or harmful.
The web page reader should be given control of any animated or advanced graphical techniques.
The web page reader should not be kept from the content through use of abusive graphic techniques.
Graphics should not be used to interfere with necessary functionality at a site, such as navigation.
The use of web graphic techniques should serve a purpose, and should not be used just to be used (note, though, that enjoyment is a viable “purpose”).
Other than these frankly common-sense approaches to using web graphics, there really are no other rules. Graphics do not have to be hard or expensive, or require that we all be a combination of Picasso and Norman Rockwell. All that’s really required is a curiosity, an interest, and above all, a sense of fun. If this describes you, then you’re ready for the rest of the book, and the wondrous variety of web graphics.