Only at this mature stage of the project are the bulk of the site's Web pages constructed and filled out with content. By waiting until you have a detailed site architecture, mature content components, and a polished page design specification you will minimize the content churning, redundant development efforts, and wasted energy that inevitably result from rushing to create pages too soon. Of course, you will always learn new things about your overall design as the prototype matures into the full-blown Web site. Be prepared to refine your designs as you navigate through the growing Web site and discover both weak spots and opportunities to improve navigation or content.
Once the site has been constructed, with all pages completed and all database and programming components linked, it is ready for beta testing. Testing should be done primarily by readers outside your site development team who are willing to supply informed criticism and report programming bugs, typographic errors, and critique the overall design and effectiveness of the site. Fresh users will inevitably notice things that you and your development team have overlooked. Only after the site has been thoroughly tested should you begin to publicize the URL address of the site to a larger audience.
Typical products or contract deliverables at the end of this stage should include:
- Finished HTML for all Web pages, all page content in place
- Finished navigation link structure
- All programming in place and linked to pages, ready for beta testing
- All database components in place and linked to site pages
- All graphic design, illustration, and photography in place
- Final proofreading of all site content
- Detailed testing of database and programming functionality
- Testing and verification of database reporting features
- Testing of site reader support procedures, answering email, etc.
- Archives of all site content components, HTML code, programming code, and any other site development materials
Most business or departments in larger enterprises will contract with a Web development group to create the initial site design and to build all the pages in the first version of the Web site. They then assume responsibility for the site, doing some or all of the day-to-day maintenance and updating content as needed to keep the site current.
Often not until the practicalities of site maintenance come up do customers realize the importance of understanding the details of how the Web developer generated the HTML and other code that makes up the Web site. Although all HTML is much the same to Web browsing software, how the HTML is formatted and what Web authoring tool the developer used can make a huge difference in how the code looks to a human reader. Consider the two code examples below:
<! START OF SCHEDULE TABLE ======= >
<table summary="Human Investigations Committee II schedule, FY 2001." border="0" width="100%" cellspacing="0" cellpadding="1">
<! =============================== >
Deadline for Submissions</p>
Meeting Dates 2001</p>
<! =============================== >
<table summary="Human Investigations Committee II schedule, FY 2001." border="0" width="100%" cellspacing="0" cellpadding="1"><tr valign="top"><td width="50%"><p class="tabletext">Deadline for Submissions</p></td><td width="2%"> </td><td width="48%"><p class="tabletext">Meeting Dates 2001</p></td></tr>
Which example do you find easier to understand? These code examples are exactly equivalent to Web browser software, but most people would find Example 1 significantly easier to read and understand. If you contract with a developer to build your site, it is crucial to understand how the developer writes code, what state the code will be in when the site is delivered, and whether the software used by the developer is compatible with what you will be using to maintain the site after delivery. Some Web development software produces HTML code that is nearly impossible for a human to read without significant (and expensive) reformatting. Other programs (such as Macromedia Dreamweaver) produce HTML code that is easy for Web programmers to read, which can make a huge difference if you decide to change Web developers or if you decide to edit HTML directly in maintaining your site. If you hire someone to create your Web site, be sure to ask what tools he or she will use to write the HTML and any other code. Ask to see examples of HTML code written for other clients. Check the code to be sure the developer inserts explanatory comments and dividers for legibility in the code. Be sure you understand whether there will be any problems or conflicts in using your favorite Web tools to edit the HTML code your Web developer produces.