9

Build-Out and Production

You can plan, plan, and plan some more, but ultimately a delivery date looms in your future. In the design and prototyping process, you have developed the plans that are the foundation of the site. Build-out, or production, brings together all the elements toward the outcome of a final, complete, and fully tested website, sitting on the client’s server and ready to go live. It is time to work the plan. Your payoff for the planning time will be a more organized, smoother production process. As much as you plan, you will undoubtedly still encounter surprises and obstacles. You will still need to call on your skills in communication, coordination, and cooperation in order to meet your client’s expectations for a high-quality project.

Building out and producing the site encompasses such processes as the following:

The Web development process is continual. The processes described in Chapter 8 do not cease when the project goes into production. The transition is one of emphasis, from planning to implementation. The feedback loops of an iterative development process continue to raise design issues as the project proceeds, and even after going live. In fact, because a website is in effect always a work in progress, requiring maintenance and updating, the design of your site will always be up for discussion.

PRODUCTION PLANNING

For project managers, the planning never stops. When building out the site, the functional and technical specifications continue to guide the work of the development team. Every production process needs a point person. In a website development project, many individuals work independently but are nonetheless part of a team effort. When the work of some individuals affects that of others with whom they are not in regular contact, communications breakdowns present a huge risk. On large-scale Web projects, a production manager or producer may take this responsibility of supervising production. That person would report to the project manager on a regular basis. In this book, we assume that the project manager is the “production lead.”

The client and development team members alike must communicate all suggested changes to the workplan to the project manager for prioritizing. Direct contact between the client and production people, as well intentioned or innocent as it might be, can become a problem (Figure 9.1). The danger is a short-circuit to the flow of information. The project manager should give close attention to changes, considering the impact of each on the budget and schedule, as well as ripple effects on other aspects of the project. If the project manager doesn’t hear of a change, others who need to know will be left out of the loop. The result will be a communication breakdown.

While planning the production process, the project manager is also keeping the end-goal in mind. Before going live, the website will be handed off to the client (or to the client’s outsourced hosting service). During the course of development, the project manager should be preparing for a clean handoff. The client’s technology team needs to be informed of the technical specifications of the site. Their servers should be running identical versions of any software employed in the Web development efforts. If an e-commerce module will be used, the company will need a digital certificate and secure transmission capabilities.

Figure 9.1 Preferred channels of communication. It is not recommended for a team member to communicate directly with a client, without including the project manager.

The project manager should prepare written production guidelines that address specifics for development of the site, such as the following:

DESIGN

The graphic artists start their production work by extending the client-approved motif and home page images to other graphic elements and pages on the site. A basic principle of user interface design is that the navigation scheme should be consistent throughout the site. New users may take a wrong turn here and there, but if navigation is consistent and the buttons are always in the same place on the screens, they will quickly learn how to move around in the site. Without consistency, users feel lost and disoriented. Unless you have content or services they badly need, they will correct the situation by leaving your site. Also, graphics on the pages should offer visual cues that orient people. The popular directory Yahoo does this explicitly by placing at the top of the page the now-familiar text line showing the hierarchical path that has led to the open page. A common technique is to change the color on the label of the navigation bar for the section of the site the user is currently in.

These design principles do not apply only to navigation. In general, graphics and their placement should be consistent across the site (although certain banners, buttons, and controls will be specific to individual pages). Users will come to look for these common buttons in a standard place. Use of colors and text labels should also be consistent. Of course, the drive for consistency makes the graphic artist’s life easier, too. Who wants to create 100 different designs for individual pages? If the navigation bar and other design elements are consistently placed, designing the rest of the pages is usually a fairly straightforward task.

Authoring tools make the job easier. The World Wide Web Consortium (W3C) has developed a standard called cascading style sheets (CSS) that can help. CSS attempt to address the problem of display by defining how various kinds of content should be displayed in a consistent manner. Style sheets are one way to create consistency across the site. The CSS can be embedded into a page, but its true power is realized as a separate file that can be linked to other pages. Then, in making one change to the style sheet, you can modify the entire site. A site can also use embedded CSS on specific pages along with a linked style sheet. Of course, for consistency’s sake, you will want to refrain from too much individual design.

CSS also can help maintain the design integrity of the site after it has been handed over to the client. Design specialists can create the style sheets during the development process. When the site is handed over, developers can train inhouse personnel on how to use the CSS for new pages. Instruction, along with documentation in the form of a mini-manual or sample HTML, is important because haphazard use of style sheets can also make a big mess. With a bit of hand-holding, however, nondesigners will be able to update the site with new content while retaining the integrity of the design.

If the project is a database-driven site, graphic artists can prepare the standard template pages that draw information from the database. There is no need to await the content in the database. It’s better to create the templates and set them in place using sample or dummy data so they can be reviewed and tested for usability.

DEVELOPMENT SITE

If you are working on a large or complex website, you may be using a development server to build out and test the site before copying it to the live server, known as the production server (Figure 9.2). As production work progresses, your team will continue to post content and install programs to the development server. You want this site to be accessible to members of the development team, but not to the whole world on the Web. At best, it is an embarrassment for a work-in-progress to be unveiled prematurely. Depending on the circumstances, exposing the site can potentially cause more serious problems. The most secure option is for the server to reside behind the firewall, on an intranet that is accessible only to those within the company or coming from select Internet protocol (IP) addresses. The site may even be posted “blind,” which means it’s available on the Web, but password protected or simply not yet assigned a domain name.

Figure 9.2 In-house development using development server and production server. Notice that the development team publishes to the development server. The tester tests the site on a development server before it is moved to a production server. The tester then tests on a production server

The development server will be a hub of activity. Programmers, graphic artists, and editors will be enhancing the site on a regular basis. As new programming functions are added, they should be tested. Before a site is handed over to the client, all of the content and data will have been placed, and all databases and programming formally tested.

In an ongoing production environment, two servers may be running—both a development server and a production server. Under this arrangement, the development team can test and debug the new version without affecting service on the live site. When the site has been perfected, files can be released to the information technology (IT) department, which can then post new and updated files on the live site or install patches or new programs. This two-step process with separate but identical servers is a necessity for any site that runs programs. Software must be rigorously tested and debugged under real-time conditions. It’s not something you want to perform on a live, stable site with your customers watching. Development programming can really make a mess of things. You want to perfect the site performance offline. Once you’re live, it’s showtime, and you want to be absolutely sure you’re ready.

CONTENT DEVELOPMENT

The project manager must monitor the content development process closely. Programmers and graphic artists will be able to complete much of their work using dummy data. Sooner or later, however, the content must arrive. Missing or late content, especially with accountability on the client end, is a leading cause of deadline slippage. It’s important to stay on top of the content situation. Content encompasses multiple media—written text, graphics, photos, audio, or video. The files may be stand-alone for HTML calls into a static Web page, or they may be records in a backend database.

Often, the content needs work on the developer’s end. You can control the amount of work by writing detailed specs for content in production guidelines; however, it might be advantageous to the schedule for members of the development team to take on some of the content development responsibility. For instance, suppose the marketing design staff of the client is modifying print graphics for use on the website, but they lack experience with Web graphics. It would be more efficient for your experienced Web artists to assume this task. In fact, they might end up redoing the client’s work anyway, which leaves you with the worst of both worlds. Of course, preparing the graphics files is a commitment of time and resources. If this responsibility is beyond the scope of the agreement, then additional compensation is appropriate.

Not only does the content need to come in according to schedule, but it must also be satisfactory in quality. It probably will not be possible for you to check every piece of content personally, and in fact, you may not feel qualified to judge it. You should, however, establish a system that ensures that somebody is responsible. The Web is full of copy that, by all appearances, has never been edited. Companies take great care in editing and proofreading brochures or press releases, yet when it comes to publishing on the Web, quality control seems to relax or be nonexistent. The nature of Web pages is that editorial changes are easy to implement after publication, whereas with print pieces you get only one shot. Nonetheless, it’s best to resist the temptation to “worry about that later.” Print and graphical content should be checked against the specifications you’ve communicated and for a general quality review.

Content development for a website project is accomplished in one of two ways:

Offline Content Development

In offline content development, as the name would indicate, you build pages offline, on a workstation rather than on a Web server. You would generally use this method in building a basic site of static pages. In this process, you build pages or content files and, when complete, they are uploaded (copied) to the server. This procedure is generally the case for regular HTML pages or fully prepared database files. Master templates or style sheets for the design can make offline development much more efficient. Nonetheless, the technique is not very scalable to websites that contain many pages.

Online Content Development

As a site grows, the viability of updating and adding pages manually diminishes, until it becomes less and less feasible. As an extreme example, imagine building all of the pages for a site like Weather.com, which gives up-to-the-minute weather maps and forecasts for cities nationwide. Maintaining a site like Weather.com, or Amazon.com with so many individual product pages, is possible only because the content is drawn from a database.

Each page is created “on-the-fly” by the server in response to your request. When, for example, you request the weather report for Chicago, your computer sends the request in the form of a command to the Weather.com server. The server then follows three steps:

So, through automation, creating such a rich site is a piece of cake. Well, almost. Data must still be created and placed in the database.

The Web development team can access the backend database online and maintain it from any Web-connected browser. E-commerce sites commonly use an online content development process. Company personnel must continually update information, adding new products, deleting old ones, and changing prices, or posting new promotions. Those closest to these marketing and product decisions are probably not database experts; however, user-friendly interfaces simplify the process. Using standard browser software, authorized staff can access Web pages set up to edit records in the database through text-based form fields, pulldown lists, and dialog boxes. With appropriate security and authentication processes in place, staff or contractors can maintain the site from any location connected to the Internet (Figure 9.3).

Online content development is a powerful tool. With some upfront investment, you gain tremendous scalability with database-driven websites, which is truly a strategic asset in today’s Web marketplace.

Figure 9.3 Content editor or data analyst posting new content to live website on production server. A. Online content development: posting content by using a Web page interface. B. Offline content development: posting content by copying data directly to server and database.

PROGRAMMING

If you’re managing a database-driven site, you will need some software engineering to make it all work. As the functionality of websites has grown beyond basic HTML with JavaScript and plug-ins for multimedia, it’s fair to say that any commercial website requires a programmer’s skills for advanced scripting, if not in actually writing programs.

The most highly technical part of the development process, software programming is also the least predictable. Sometimes development goes as expected, but it is not at all unusual to meet with some bumps in the road. Traversing those bumps is where the going can get tough. The following concepts should be kept in mind:

Programming is a black art. Even its practitioners will tell you so. Some admit that their power over the mysterious innards of the computer is all voodoo. Whatever the source, the magic is difficult to perfect the first time. Programming is basically a process of invention and reinvention, trial and error. All in all, it’s a messy, inefficient process, but that’s the only way to do it.

Programming is a creative process. Sometimes, programmers can come up with a routine in a flash, whereas other times it requires more thinking and analysis. The more experienced programmers have the benefit of having addressed and solved similar problems in the past.

Programming is a precise, detail-oriented discipline. A slight mistake or omission can cause big, seemingly inexplicable problems. It may be difficult to identify the cause of the problem, and the time it takes to do so can easily take the project off schedule and over budget.

Programming work starts with the functional specification, the programmer’s road map. The programmer is conceptualizing the relationships between pieces of data, and the functional specification shows how they are intended to work together. The technical specification is at once a planning document and a record of the work. With these documents, the programmer starts developing ideas about the code that will best deliver the desired functionality.

Programmers are known to log long hours. Therefore, after a good, thorough analysis, the work that ensues could go at a fast clip. Obviously, it’s important to be sure that the programmers are moving in the right direction. Project managers have a couple of methods for doing so:

A detailed, up-to-date technical specification is a way for the programmers and others on the development team to communicate with one another. A fix in one part of the program often causes a bug in another. Documentation of the work then becomes useful in debugging. Also, if new people are brought onto the team, the technical specification can be useful in communicating the project status and how it got where it is. That said, throwing new programmers onto a project already underway is probably not going to help your schedule any. Remember Brooks’ Law, introduced in Chapter 1: “Adding manpower to a late software project makes it later.”

SCHEDULING

By now, it’s no doubt apparent that scheduling the programming phase is also a black art, if not a wild guess. One rule of thumb is to take the initial estimate and consider it to be not merely a best-case scenario, but quite possibly an insanely optimistic one with a probability teetering close to zero. To quote again from Frederick Brooks’s The Mythical Man-Month:

All programmers are optimists. Perhaps this modern sorcery especially attracts those who believe in happy endings and fairy godmothers. Perhaps the hundreds of nitty frustrations drive away all but those who habitually focus on the end goal. Perhaps it is merely that computers are young, programmers are younger, and the young are always optimists. But however the selection process works, the result is indisputable: “This time it will surely run,” or “I just found the last bug.”

So as a practice, you might as well take your initial estimate and double it; better yet, triple it to take into account testing and debugging. The ambiguity of the schedule is another argument for close tracking throughout the process. You should keep the technical specification current and pay steady attention. If you watch the progress and keep your eyes on the goal, you will more accurately estimate the completion date as the project moves along.

The incredible deviation, of course, is cause for concern. A $250,000 website that goes over budget because programming takes two or three times longer suddenly costs $500,000, which is enough off target to concern any senior manager. A $10,000 project can become $20,000, a lesser transgression in dollars, but as a percentage it’s no better, and that’s one way accountants will surely measure. Smaller projects seem more likely to come in close to estimates. It’s simply a matter of dealing with fewer unknowns.

CONNECTING THE DOTS

While designers work with dummy text in developing their page design templates, programmers work with dummy page templates in their work. With two tracks progressing in parallel toward the endpoint of full integration, the project manager’s role is coordination. Eventually, the programmers will be coding the Web applications that connect their backend database to the client-approved page templates. When those routines are completed, tested, and debugged, you are ready to start moving the actual content into the database. Suddenly the project starts to look like a real website. Having made this watershed point, the work can proceed quickly; however, before development moves too far along, it’s time to solicit user feedback in a structured way.

USABILITY TESTING

Customer focus is the mantra of contemporary business, and website design is no different. With pages laid out and content ready to be poured in, you are in a position to gather users to test your design decisions. No matter how skilled and experienced a design team you’ve assembled, user testing always seems to offer new revelations.

True user testing is a structured observation of real users individually performing a standardized set of tasks. Start by developing a list of tasks that are representative of the functions of your website. In stating these tasks, use neutral language and emphasize the outcome, not the procedure. Questions you might ask for the Campus Posters, Inc. website (introduced in Chapter 8) could be as follows:

A series of users then come to the usability testing sites and perform identical tasks. Request that users “think out loud” while they perform their tasks. How else can you know what’s going on in their heads? At minimum, the project manager should attend the user testing sessions. Depending on the size of the project, others on the development team may want to join as well. You may also want to videotape the session as documentation, to share results in the group, and for future reference.

Testing out the site with actual users is always interesting and usually informative. You will see a surprise or two and experience insights on matters that hadn’t occurred to you. You may well find yourself saying, “Aha! Of course!” For example, you may find that because of an overly creative visual design, users cannot find the home page button on your navigation bar. Or perhaps users want to search based on a criteria that you hadn’t considered. Clearly, you need some design revisions. Usability testing should not be confused with software testing or quality assurance, which is the subject of the next chapter.