Production Planning
How careful planning can help ease production headaches
6/29/98
by Brian Dame
As a production specialist, I'm the last stop in the web development assembly line. I stand waiting, wrench in hand, for other team members to pass along all the parts I need to build a site. Team members often extend their deadlines in order to buy themselves extra development time, but the launch date always stays the same. What does that mean for me? With tight deadlines and no room for extensions, I need to do a lot of careful planning if I'm going to finish building the site on time.
I don't think I've ever worked on a web project that's stuck to a schedule and met every milestone. Copy isn't written, the client wants to make changes at the last minute, or the design has to be modified to reflect a new company logo. This is sometimes frustrating, but it's also normal. It's part of building large-scale web sites. Since I can't control these aspects of the project, I try to focus on what I can control. If I can set up a game plan and stay organized, I have a much better chance of meeting the launch date. This article offers some tips and tricks that reflect what I've learned about production planning.
Gathering Materials and Resources
By the time a project goes into production, all the copy and art for the web site should be ready. I say "should" because although these are the building blocks of the site, I usually don't have all the pieces right from the start of production. Though I may not have everything, I still try to organize what I do have into a form that's usable for my purposes.
If your project manager has been nice enough to provide you with a detailed site plan, that can be a good starting place in organizing your production pieces. The site plan gives you an idea of the scope of the project and makes it easy to see if you have all the resources you need. I like to start off by going through all the copy I have and checking it off on the site plan. Once I'm sure I have all the copy, I can start getting it ready for production.
Preparing Copy for Markup
I'm sure you're familiar with the various ways that clients send copy. I've received copy as email, Quark XPress documents, handwritten notes, spreadsheets, and (in one case) as a huge Microsoft Word document containing all the text intended for the site. Since I don't want to miss any critical data, I like to break the copy down according to the site plan. I create folders for each section of the site and save all copy into its appropriate folder.
Since I'm breaking down all the copy anyway, this is a good time to convert everything to ASCII text so I don't wind up with any weird characters (which are caused by leftover formatting). Most HTML editors, such as BBEdit or HomeSite, offer the ability to convert files to ASCII with the click of a button. When you convert formatted files, such as Microsoft Word or Quark XPress files, make sure you save copies of the original documents so you can refer to them later for layout and style information. At this point, I rename files so that the descriptions make sense to me instead of to the client.
Organizing the Directory Structure
With all the copy organized and converted, I can start figuring out the directory structure of the site, or how its folders will be organized. Determining the folder structure of a site can be one of the most difficult tasks of a web project. The decisions you make now can greatly affect how you interact with the site later. Your goal is to create a folder structure that will allow you to access files quickly, without having to spend a lot of time digging through subdirectories or scrolling through hopelessly long file lists. Also, since more than one person may be working on the project, a well designed structure will allow you to comfortably hand off entire sections of the site to another team member without worrying about confusion or overwriting of files.
HTML Files
I always start with where I'm going to store my HTML files. If at all possible, I only want one page at the root level (or top level) of the site: the home page. All the other HTML files will be stored in their own folders. For example, let's say I'm working on a site with four main sections: Products, Services, Company Background, and Contact Information. I'll create a folder for each section so that once I start writing my HTML, I'll know exactly how each page relates to other pages on the site. You may be tempted to create subdirectories inside each main section folder, but I don't recommend it. If you keep the structure simple, you'll have a consistent path for all images and links.
Image Files
Deciding on the best place to store your images can be tricky. Many people like to set up image folders inside each main HTML folder. I prefer to set up one image folder off the root that contains all the images on the site. This can get unwieldy on large sites, but the advantage is that all images will have the same path (/images/imagename.gif). This comes in handy when you need to search for and replace an image that appears on several pages. It's consistent and easy to remember, since all of your images are in a central folder.
Applications
HTML and images will make up the bulk of the files on your site, but you may have other types of media that you use, such as a web application. Applications can be confusing if you don't take the time to learn how they work. For instance, most of the applications on the sites that I've worked on serve pages from a template directory, which may be located inside another folder. Since the programmers decide the folder structure for applications, I have to make sure that the way they set things up doesn't conflict with my plans. Pathing within applications has to be consistent with that used on the site as a whole, or you could end up with broken images and links. Make sure you take the time to communicate with the person responsible for the application early on. That way, you can both avoid having to fix things later.
Working with Design Source Files
Until recently, optimizing images for a site was the most time-consuming task involved with building web sites. I spent most of my time working in applications such as Photoshop that were not designed to work with web graphics. Because of this, I needed to use two or three different applications to optimize images. Thankfully, the folks at Macromedia and Adobe understand the problem and have provided us with solutions.
Macromedia Fireworks (http://www.macromedia.com/software/fireworks/) and Adobe ImageReady (http://www.adobe.com/prodindex/imageready/main.html) are two new graphics applications that make the task of optimizing images for the web much more simple. While both of these programs have lots of useful features, I'm only going to discuss their batch optimization capabilities.
Batch Processing Images
Large sites can contain hundreds or even thousands of images. I don't know about you, but the idea of optimizing 1,000 images one by one is a scary thought. With the batch processing capabilities of Fireworks and ImageReady, you can optimize large groups of images in one step.
Before you can set up batch processing, you'll need to size all your images correctly and name them appropriately. Whatever name you give the source file will be the name that is used for the optimized file, with an appropriate extension attached. Next, you'll need to group all your images according to their optimization settings. For instance, let's say all the headers on your site should be optimized using an adaptive palette, 16 colors, and no dithering. All of these header images will go into one folder. For each different optimization setting, you'll create a new folder. Once you've done that, you're ready for the easy part.
Fireworks and ImageReady handle batch optimization differently, but the process is very simple in both. You just set the optimization options in either program and select the relevant image folder. In a matter of minutes, you can optimize every image on your site.
Creating HTML Templates
If I had to build each HTML page from scratch, it would probably take a year to finish a site. Creating and modifying templates is the fastest way to develop your site. The tricky part is making sure that each template is absolutely perfect before you start pouring content into it.
I can't tell you how many times I've begun adding content and then realized after I had built half the site that there was something wrong with the template. For example, I might forget to add text links at the bottom of every page. Or I might realize that one of my tables is ten pixels too wide. Some of these mistakes are easy to fix, but others may require that I go back and manually change a hundred pages or more.
To avoid this, always make sure you have everything in the template before you begin pouring in the content. Communicate with the project manager and the designer to make sure all required navigation elements are included in the page. Ensure that all text and link color settings are correct as well as font sizes and faces. If you are including JavaScript in your pages, check that it works correctly before using it in your templates. In short, double check everything.
Testing the Finished Site
You've put in countless hours building your site. You're ready to sleep for a month. But along comes the project manager asking tough questions like, "Does everything work?" She wants to make sure that there are no broken links on the site and that it works on all targeted browsers.
"Uh, I think so," is probably not going to cut it with the project manager. So what can you do to test whether things are working? Luckily, there are some useful programs to help you check that your site is functioning as it should. I like two in particular: Linklint (for link checking) and the World Wide Web Consortium's HTML validator.
Linklint
Linklint (http://www.goldwarp.com/bowlin/linklint/) is a link-checking program written in Perl. It runs on both Windows and Unix platforms, so it doesn't matter which platform your site is hosted on. There are many link-checking solutions out there, but I've found Linklint to be the most powerful. It allows you to check links both locally and remotely, so that even if your site is hosted on a different machine from the one on which you're running Linklint, it will still work. The best part is that Linklint will generate a report that you can view in your web browser, making it easy to find pages with broken links.
Since Linklint is written in Perl, it doesn't have a graphical interface. This can make it difficult to use. If you have a little Unix knowledge, you'll have no problem running the program. If your Unix skills are lacking, I recommend that you spend a little time reading the instructions before jumping in.
HTML Validation
A while back you could get away with using lots of proprietary tags on your site. The folks at Netscape and Microsoft have tried to please site designers by offering them tags to create better, more controlled layouts. The problem with these proprietary tags (tags that tend to work only on one browser) is that they offer no support for other browsers. At best, your layout won't be perfect. At worst, your site may be completely invisible to anyone without the right browser. If you want your site to be seen and used by the largest possible audience, you need to work within HTML standards.
The World Wide Web Consortium (W3C) has provided developers with an HTML validation service (http://validator.w3.org/) that checks documents for compliance with HTML standards. It's easy to use and it works amazingly well. You simply add the proper document type definition (DTD) at the top of your HTML files and then enter your site's URL for validation. The validator will generate a report that identifies all invalid HTML and gives you detailed descriptions of what you did wrong. It's an excellent tool for identifying your site's compatibility problems.
You've organized, structured, tested, validated, and corrected your site. Everything works as it should. The client is thrilled and the project manager is amazed that you finished on time. So what's next? Now you can take that month-long nap. Or with the time you saved, you can begin your next project -- on schedule.
Resources
Bare Bones Software
http://www.barebones.com/
Makers of BBEdit, an HTML editor for the Macintosh.
Homesite
http://www.allaire.com/products/HOMESITE/
Information about Homesite, an HTML editor for Windows 95.
Organizing Your Site
http://www.hotwired.com/webmonkey/html/96/45/index2a.html?tw=backend
Webmonkey article offering tips on file naming, directory structure, and other site planning issues.
Fireworks
http://www.macromedia.com/software/fireworks/
New product from Macromedia offers batch processing and other web graphics tools.
ImageReady
http://www.adobe.com/prodindex/imageready/main.html
Adobe product designed for web graphics production. Includes batch processing and other web-specific features.
T is for Template
http://www.hotwired.com/webmonkey/html/96/50/index2a.html?tw=html
Tips from Webmonkey on using templates to speed production.
Modular Web Design
http://www.webreference.com/dlab/9801/
Webreference.com article on designing with "modules," design templates created for different site sections.
Linklint
http://www.goldwarp.com/bowlin/linklint/
A link-checking program written in Perl that runs on both Windows and Unix platforms.
W3C HTML Validator
http://validator.w3.org
Free HTML validation tool created by the World Wide Web Consortium (W3C).
Brian Dame is a senior production specialist at THINK New Ideas' (http://www.thinkinc.com/) Atlanta office. In his spare time he maintains Harold's Machine (http://www.iweb.net/~harold/"), a site containing web production tips and tutorials.
© 1998-1999 Anchor Productions, Inc. All rights reserved.