Left Brain, Right Brain

By Amit Asaravala

Although once responsible for such page elements as color, layout, and typography—in other words, "the way things look"—more and more designers are finding it difficult to define their roles in today's Web team. Job descriptions in this field now require applicants to have strong HTML skills in addition to traditional artistic foundations. Some even require JavaScript experience. And on any given day, a designer might find that he or she is not only responsible for creating the look of a navigation bar, but also for producing the style sheets and scripts that will power the rollover effects in that bar—a duality that would have seemed anomalous only a few years ago.

This line blurring surrounding professional responsibilities is also evident in the tools of the trade. Adobe's ImageReady and Macromedia's Fireworks have long allowed users to generate HTML and JavaScript code after the graphics have been created. Dreamweaver, which is arguably an authoring and production tool, can now be found in the design sections of most buyers' guides. Even Photoshop, perhaps the most traditional design tool of all (with the exception of the paintbrush), will be able to output entire Web pages when version 6.0 is released.

Part of the reason that the duties of a Web designer are so hard to define is that the definition of design itself has morphed to mean more than making things look the way they look. These days, design seems to encompass the entire process of creation. When we began planning this issue, the editors and I initially envisioned an issue centered on visual design. Yet, when we presented the theme to our columnists, guest editors, and feature authors, we simply said, "the topic is design" and let them interpret it as necessary. What we got in return was eye opening.

There were, of course, the aesthetically focused articles that are required of a design issue. But in our Programming section, where one doesn't normally expect design articles to fit well, we found that our authors wanted to write about software design. Even in our Design section, authors spotlighted the syntactical aspects of HTML and how they can be manipulated to create universal visual effects. Whether the experiment proves anything is up to you to decide, but it does show that design is by no means a single, precise set of skills.

Contributing to the ambiguity is the fact that Web design is a relatively new industry, especially when compared with the evolution of print design. Less than six years ago, when Netscape and Mosaic were changing our perspectives of the Web, a company's technical staff—if a company had a site at all—was the sole group responsible for creating, and therefore designing, all of its Web pages. There wasn't as much emphasis on the front end versus the back end, nor on content versus presentation. People were just beginning to balance form and function issues on their pages and many didn't yet have the experience to know that well-built sites require collaboration not only among skilled developers, but also among talented designers. (Some companies are still having trouble with this concept; for a real treat, complete with animated GIFs, thick table borders, and a tiled background, see gassers.com.)

But as the necessity for well-designed pages grew, so did the list of rules. If you were a designer, it was enough, at first, to know about the 216-color palette, and to modify your hopes for brilliant arrays of color around that limitation. Then, you had to create layouts that would fit within a 600-pixel wide window, but that wasn't too much of a problem because you were used to designing for print, where the page was a fixed width anyway. But then you had to design pages that flowed with the size of the user's browserand that could be any size. This caused you to wonder how you would ever position the elements on a screen so that they could wrap and shrink and move without ruining the integrity of the design.

At some point, someone told you that your pages might look funny in different browsers. And what could you do? You were already busy learning how to seamlessly account for Java applets in your pages. You were using tables to align images, looking for ways to make submit buttons less obtrusive and input fields less gaudy, trying to deal with the seemingly endless limitations that print designers will never have to worry about.

It's obvious that Web design requires a far greater interaction with the medium than does print design. But should designers really be making technical decisions? Should they be planning out rollovers and determining the correct way to slice an image so that it fits into a table? When sites turn to XML and XSL, will designers be responsible for writing style sheets? Companies that answer "no" may find themselves with disjointed Web teams and disjointed sites. The role of the designer in today's Web is amorphous, an example of the sciences breaching the arts, or perhaps the arts reaching out to the sciences.

Write to me with your ideas at amit@webtechniques.com.