The Art of Implementation
model of rome built in a day
By now, you've probably noticed that for a course that's ostensibly on "web design," I've said relatively little on the nitty gritty aspects of designing a web site, or using a particular tool set, nor have I used many illustrations from the web proper. In large part, this is because I believe one has to firmly understand the underlying principles of design and the inner workings of one's medium before one can hope to practically apply any particular skill set. Also, once understood and eventually mastered in a general way, a skill becomes easy to apply to a particular task, such as designing a web site, an information architecture, or any design task. Finally, the state of the web is transitory at best HTML is dead, and the days of the GIF and text web site are numbered or more accurately, broadband Internet will explore and explode whole new fields of interaction and content, demanding ever-greater versatility from the designer. Having only one skill or mastering only one tool won't serve you well in the long run.
As I've said elsewhere, "web design" is nothing more than a specific application of more general skills, including Information, Interaction, Graphic and Interface Design. Many of the constraints specific to web pages today are artificial they stem from limitations in bandwidth and the current version of the HTML protocol, and these limitations will go away over the next few years. Stressing that a web page should be no more than 40K in size, or focusing on what a particular browser version is capable of are important constraints to understand, but only for the moment.
Ultimately, the best way to fully learn any skill is by applying it; making mistakes and getting lost are important parts of the learning and discovery process. My goal has been to lay a solid framework for understanding how things work, the specifics are in large part a matter of personal style. To be fair, this is also my own particular m.o. I tend to design from the top down, and prefer to understand the bigger picture before taking something apart or putting it together. Many people prefer a bottom up approach, beginning with the first piece of the puzzle without knowing what the end result will be. Both approaches are useful and effective; as I say, it is in part a matter of style.
I've tried to address below some of the more basic issues in creating a specific web page and / or web interface, by showing how to structure and break apart an actual page.
laying it out
How do you figure out what goes into a design on a particular page? This is a tricky issue: the design tools themselves don't necessarily have any limitations. Photoshop, Quark, Illustrator have no real constraints on size, density, color, layers - you are more or less free to design whatever comes to mind. However, the web itself currently has a great many constraints:
For now, designing for the web means tailoring one's work to meet the limitations of the medium, while also accounting for the constraints of a particular project does it have to work on every screen in the world, or only over a corporate network? Bandwidth will continue to expand, and the protocols that define the web will continue to evolve until you can actually guarantee that someone will see what it is you've intended and designed. best to have a general understanding you're applying to a specific situation, so you can deal with new situations when they arise.
solving the puzzle
For now, the web is extremely flat; it doesn't support the complex layering that one can achieve in Photoshop or Quark, for instance. In fact, until CSS, HTML provided for exactly two layers - foreground and background. And the background image in HTML tiles - it repeats itself from left to right and top to bottom until it fills the screen (to eliminate that effect, use an image that's larger than the largest screen size - say 1200x1600 - but beware size and bandwidth constraints). Unfortunately, style sheets provide more options, and Dreamweaver supports style sheets. I say unfortunately, because without understanding how CSS will be interpreted from one machine to the next, designers who are used to using such techniques in print can readily apply apparently similar techniques to the web, without fully understanding the issues or implications. For simplicity, I'll stick to explaining how to lay things out with HTML.
The assumption here is that you've used another tool such as Photoshop, Illustrator or Quark to create your initial design; in point of fact no web editor (e.g. Dreamweaver) allows you to create images and designs the way design tools do. Rather, WYSIWYG web editors allow you to take the pieces that comprise a web page, and assemble them into a finished page and site, without requiring you to know HTML.
borrowing and stealing
I'm not of course suggesting you simply steal someone's site, rather that you utilize another site's code to speed your implementation. There's a substantial difference between constraining your work to someone else's, and using someone else's work to facilitate your own. In the code development world, re-using code is actually encouraged and planned for, and works extremely well to speed development. Class inheritance is based on this premise, as are Cascading Style Sheets. Because the HTML is visible to the end user, it's a readily available resource for web site development.
no man is an island
One final note on creating the images, text, HTML, folders, style sheets and more that comprise a web site it's important if not in fact required to consider the overall development process and life cycle of the web site. Developing good habits regarding naming conventions, file and folder structures, and retaining many design file iterations should actually be a part of the design process. You or another designer or developer may need to revise the design or the finished site, and in a professional setting, it's likely that many people collaborate on a site, and virtually all sites evolve and change over time. Clearly naming and organizing the image and text files you create that make up or go into a web site will save countless hours of work down the road; if not for you, then for someone else.
all content © copyright 2003 neil verplank, unless otherwise stated