[good process] | [good toolchain] By William Paul Fiefer (home) [main menu]

Sites done right   |   Good Webs   |   Postscript

Sites done right™ There currently is no formal system of Web site development in use. You can see this when you get lost while browsing a Web site, when you lose its narrative or expository theme, or when you chase dead URLs. You can feel this after you wait an interminable period for a page to download, only to find its graphic punch exceeds the value of its contents. The speed workaround of loading a site to your drive is an irresponsible shuffling of cost. The Web developer is storing pages on space you paid for. Site development, and most important, the development of mid-sized (5,000 or more pages) to large (50,000 or more pages) sites is a nonstandard process. If you hear otherwise, ask the person claiming to use such a system to explain it. The next thing you'll hear is mumbo jumbo. The situation is similar to how mid-sized and large software systems were developed before software engineering practices gained a wider degree of acceptance. Leaving site development to chance, or to ad hoc rules, wastes time, money, creative talent, and the bandwidth used to propagate the chaotic, disorganized sites that result. Unsystematic design continues costing further down the timestream as revision, maintenance, operational, and other costs mount. Webs are an evolutionary advance of publishing, and the way to manage this new form of publishing is with an editorial process that has been modified through a merger with software engineering. The marriage is ideal for blueprinting Web sites at every level of abstraction. Why? The classic editorial process tries to systematically and reliably manage the creative process and its practitioners. Software engineering does the same, using such ideas as business systems analysis, business process modeling, and systems and architecture design in a standardized fashion to create large programming systems. The Web is a hybrid system, simultaneously content and software, but a publication all the same. This hybrid system requires hybrid controls. Hybrids work because sophisticated editorial and software engineering processes are geared toward the repeated, reliable, rigorous generation of large, complex, deadline-driven publications and software systems. The methodologies are ideal for developing large Web sites. The goal in using them together is to rationalize the lifecycle of content at a Web site. [header] Good Webs Good Webs are well-designed intranet and Internet Web sites. The goal of Web design is to systematically create these Webs. A well-designed site has pages with a consistent look-and-feel; a navigable, document-populated interior space; ordered, reliable, easily located, well-maintained information; and useful, reliable, regularly updated content. Everybody who builds a Web wants a Good Web. To get one, know your needs and have a clear picture of what you want from your site. Specify every aspect of the site content lifecycle, including analysis, content production, and overall operations. When you articulate your design you make it easier to produce the site you want. Such a Web site has a clear message and structure and is simple to maintain. Start building your Web by evaluating your needs through specification interviews and analysis. Harness the efforts of your publications, communications, internal communications, public relations, and systems departments to form the specifications. Record what you want; create what you record. Gathering requirements and creating specifications forces you to emphasize quality before design. Craft solutions only once the problem is understood. Assess the overall project and review your findings so you can judge the feasibility of each step before approving any work. Intranets are bandwidth-rich so focus on building one, but intranet sites become Internet sites with small modifications; design each site with the world in mind. After you approve a design, implement it incrementally. Stage your site construction. Make sure you can resume halted work, and that the development won't break down if a specification changes. Your site must be upgradable, expandable, maintainable, modifiable, and useful. A site is a system, not multiple panels bound by menus. So, your site must exhibit consistent style throughout, working for, rather than overwhelming, users. Serve your audience: prepare orientation and training materials so your users can exploit the full potential of your site. Document how your site is used, its procedures, styles, standards, setup, teardown, formats, directory structures, link structures, logfiles, and URL inventories. Structure and comment all HTML, source code, and configuration files. This documentation is integral to site development. Exploit the fact that Web sites provide social and data flow through organizations just as paper records and physical interactions do now. Make it a rule for your site to offer predictable interactions at every junction possible. Specify how your interfaces work: these are where people meet the machine. Structure your information so it moves in standard formats through multiple channels. Implement an editorial schedule to rollout and retire content. Test all of your links. Specify response times, backup schedules, and site security. Make sure your clients and configurations deliver the most from your system. By keeping in mind that the Web is a presentation medium with unique managerial requirements, you'll build a solid final product. Your Web will be information-rich and link-rich, will conform to clear specifications, and will satisfy a specific audience. Your Web will have focus and scope and, if you wish, the power to delight. You will have a Good Web. [header] Postscript In 1978 and 1979, Tom DeMarco, Larry Constantine, and Ed Yourdon promulgated the structured software development methodologies. Their ideas were so powerful that more than 20 years after their introduction, most shops still haven't adopted them. All three authors went on to cover object-oriented development methods, the importance of software quality, the value of democratized, humane management, and the social impact of computing. What isn't widely known is that DeMarco, Constantine, and Yourdon were actually writing science fiction.

© Copyright 1992-2008, William Paul Fiefer (yamada@prairienet.org), all rights reserved. You incur specific legal obligations under the terms of my copyright and little else under my privacy policy. This page is made possible by maple.sugar.buddha™ and translated into English by my Mom. Sweet enlightenment!™ Last updated 01 January 2008.