166 WHO: Riding the Project Life Cycle: We Never Forget a Phase

For you, this means titling the logo image “logo.gif” instead of “uglyswirlwithstupidbevel.gif,” calling the November header graphic “nov_head.gif,” and so on. For the web technician (or you, if you write your own HTML), this means naming the disclaimer page “disclaimer.html,” storing images in a single directory labeled “Images,” and so on.

If care is taken throughout the development process, then updating and maintaining the site will be easy and logical, whether updates are performed by you, a production person, or your client.

Testing

Though a web development team will test its product throughout the project life cycle, many web projects plan for a distinct testing phase. In this phase, the development team has the opportunity to test the deliverable against the design and functionality specifications.

In some cases, real users may test a site. In other cases, a specially trained testing team will do the job. Testing by real users usually tells you more about the site. We often get the most useful feedback by showing work to the guys who deliver sandwiches. Be elitist in choosing typefaces but democratic in designing interfaces. The Web is for people, not for experts.

Regardless of the testing technique involved, team members must work together to track down the source of problems and implement solutions.

We guarantee that there will be problems. For one thing, no two web browsers interpret code and markup exactly the same way (see Chapter 2). For another, what seems clear to you may be baffling to the people who use your site. Web designers tend to live two years ahead of the curve; web users, who actually have lives, tend to live behind the curve. You know that little rotating box takes visitors back to the home page; visitors may not. Testing will reveal problems in browser compatibility and user acceptance; then it’s up to you and your team to solve those problems.

Deployment

You’ve completed the site. The client has signed off on it. The files have been transferred to the web server. Think you’re finished? Not quite yet. Successful projects demand a smooth transition from the web team to the client.

Taking Your Talent to the Web

167

The updating game

In the early days, clients viewed the web designer as a species of magician. They knew they had to have a web presence, whatever that meant, and they felt that you held their fate in your hands. Not only were they eager to approve what you created (because it was all magic to them), they also were more than willing to retain you as the perpetual updater and refresher of their online identity.

Then came FrontPage, GoLive, and Dreamweaver—tools that theoretically let “anybody make a website,” whether they knew what they were doing or not. Now, the possession of FrontPage does not turn your client into a web designer any more than ownership of a Roland Drum Machine turns the neighbor’s kid into Keith Moon. But the ability to generate HTML, the language with which web pages are created, has convinced too many clients that they can save a buck or two by purchasing one of these web-editing tools and updating their sites themselves. The results are often disastrous, for reasons that will be obvious to any creative professional, but incomprehensible to many clients, whose esthetic sensibilities have been shaped by cooking up pie charts in PowerPoint. Not that we’re bitter.

There are several ways to manage the transition. In one of the better scenarios, you’ve designed a database-generated site for a large client with much money and created a custom publishing tool enabling them to add fresh content to the mix without befouling the site.

Alternatively, instead of providing clients with a custom publishing tool, you might hook them up with an existing product, such as Zope (www.zope.org) or Allaire Spectra (www.allaire.com). Some of these tools use standard web languages such as HTML and XML; many use custom markup and are part of larger proprietary product families. Some are simple enough for a client to use; others require considerable developer involvement, which is one way of keeping your finger in the pie—if that’s your idea of fun. What you gain in billings you may lose in IT people, who quit from the frustration of continually guiding clients through complex processes requiring specialized knowledge. This, however, is your boss’s worry, not yours (unless you own the web agency).

168 WHO: Riding the Project Life Cycle: We Never Forget a Phase

In still other cases, your client will assign an in-house person or team to take over the site. Sometimes these folks are in-house designers with solid web experience. Sometimes they’re overworked marketers with a copy of FrontPage.

Regardless of how the site is updated and by whom, in this final phase of development, you get one more opportunity to preserve your work and serve your client by creating documentation, providing client training, and maintaining contact on a consulting basis.

Create and provide documentation and style guides

“Care and Feeding” instructions accompany everything from puppies to houseplants, and websites demand the same loving attention. It is important to provide the client with detailed notes on the location of files, the fonts and color palettes used, photographers or illustrators involved, and so on.

As more and more clients plunge into the business of updating their own sites, it is vital to provide them with every possible scrap of information. If you don’t take pains with this postpartum part of the process, your client may paint a moustache on your Mona Lisa or send visitors running for their lives when a Style Sheet or JavaScript file is accidentally deleted.

Remember: A book design is a book design, a finished ad is a finished ad, but a website is never finished, and the client can always louse it up. Do everything in your power to save your clients from themselves.

By the way, such documentation should be created even if the web agency retains control of the project (including updating and maintenance). After all, six months from now, do you really want to scratch your head trying to remember which font you used, where your navigational menu graphics were stored, or which script was responsible for a given function? Of course not. This documentation will be easier to create, and the site will be easier to update if you’ve followed the advice given earlier in this chapter and designed for easy maintenance by establishing and following logical naming and structural conventions.

Taking Your Talent to the Web

169

Provide client training

Sometimes it is enough to tell your clients which fonts and colors you used. Sometimes it is enough to tell your children not to play with matches. Usually, it is not enough. That’s why, whenever possible, the designer and other team members should have after-meetings to discuss the site in detail and provide as much client training as possible.

Besides helping the client avoid ruining a beautiful site, in-house training also sends the message that your company cares. Clients who know you care will come back with additional projects and will tell their friends on the golf course about the integrity of your company.

If your clients are going to be writing HTML or (bless us) creating new images, it is worth sitting down with them, at their computer or yours, and pointing out the fine nuances of what you’ve done. You might even buy fonts for them (matching the fonts you used), install the fonts on the client’s computer, and show them how to work with Extensis Suitcase or Adobe Type Manager Deluxe.

You may feel ludicrous doing this, especially if the client is not a graphic designer, but it’s foolish to underestimate other people’s creative potential. Besides, if they’re going to do the work anyway, you owe them and yourself every possible assistance.

This whole thing is fairly unsavory, we’re afraid. It’s rather like a dentist training patients to extract their own teeth, but it is an aspect of the business, and coping is better than lamenting.

Learn about your client’s methods

Training is often bi-directional. While explaining your methods to an inhouse peer (or turning a client into a junior web designer of sorts), you also should learn as much as you can about the way your client will work with the site. If possible, you should learn about the software your client will be using. It’s highly unlikely that your client will create HTML and other web markup by hand. Fortunately, the number of WYSIWYG web editors considered good enough to use is fairly limited, so you can learn the basics and pitfalls of your client’s software of choice even if you never touch the stuff yourself.