Chapter 5 -- Web Planning Chapter 5 Web Planning CONTENTS Principles of Web Planning Web-Planning Techniques A Web Plan Example Web Planner's Check Planning is a crucial aspect of web development because it is when many decisions are made that affect the design, implementation, and later promotion of a web. This chapter surveys issues of web planning, starting from principles based on the Web's media characteristics and user experience discussed in Chapter 4. You can plan a web at many phases of web development, including strategic, policy, and systems planning. Specific techniques and instructions for individual web planning are described in this chapter, including strategies to define the web's purpose and objectives, domain and audience information, and web specification and presentation. Principles of Web Planning You can apply the Web's media characteristics and qualities discussed in Chapter 4 to define a focus for web planning. The Web's dynamic characteristic tends to make planning an ongoing, continuous process in which issues of multiple authorship and rapidly changing information relationships come into play. The Limits of Web Planning: What a Developer Can't Control When developing a web and making it available to the public to freely browse, you have no control over a range of factors. The first step of the planning process is to recognize these factors and consider how they might limit planning for a particular web. The factors over which a developer has no control include user behavior, browser display, links to the web, and the resources outside the web. User Behavior Because the Web is a dynamic, competitive system based on user choices and selectivity, a web developer can't control how users are going to access and use a web's information. The Web's porous quality, in particular, means that users do not need to enter a web from a designated home page; instead, they can enter from any arbitrary page. Although a developer's intent might be to guide users down a series of pages, as shown in the left picture of Figure 5.1 (the wine bottle model), actual use might differ. Access to a web follows more the pincushion model shown in the middle of Figure 5.1, where users might enter at any given point, and thus a web has no true "top." Users might enter a web at any arbitrary link. Figure 5.1 : The Web's porousness makes user path planning difficult. On a larger scale, the entire Web itself, composed of millions of individual webs, resembles a cloud of hypertext (the cloud model shown at the right in Fig. 5.1). Users in the cloud model don't even necessarily experience a single web, but instead move from page to page in Web space, through navigation techniques such as subject, keyword, or space-oriented searching. In particular, when a user enters a web as a result of a spider keyword search, the web pages that match the search pattern might lead a user deep inside what the web developer might consider the introductory or welcome pages of a web. The Web's porous quality is a consideration during planning as well as in the other processes of development: analysis, design, implementation, and promotion (as described in detail in later chapters). During the planning stage, it is possible to intend to build a web with a different entry pattern than the pincushion model. In fact, it often is possible to shape general user behavior toward a wine bottle model by using navigational cues, web publicity, and other design strategies. During the planning stage, however, the best web developers can do is to identify the general model of user behavior for which they are aiming. Although user behavior can't be controlled, a statement of the planned general user access model can serve as a guide for later processes of web development-particularly design. Possible planning models for user behavior follow: Guided  This model guides the user through a sequence of pages, much like the wine bottle model in Figure 5.1. The designation of a home page tends to support this model, which often starts the user from the "top" of the web. This is a common model for planning the default page of a Web server (the page that comes up when the user requests the URL consisting of the server name only). A guided model for user behavior requires a design of the links of individual pages (see Chapter 7, "Web Design") to support a guided (but not necessarily linear) path. This model also is common for webs that tell a sequential story or explain a series of concepts. Cued  This model provides the user with many cues for choices of links to follow, with the expectation that the user should be prepared to choose from them with minimal guidance. This model is more common for webs containing complex information that a user might access often, such as reference or database information, or for webs that support users with advanced or prior knowledge of the web's domain information. Floating  In this model, the user might be presented with only selected cues on each page that relate only to that page's information, as opposed to the navigational cues present in the cued model or the narrative cues of the guided model. A floating model might be most appropriate for entertainment or play webs, where the user is encouraged to explore links in a web from a context not necessarily related to gaining a comprehensive understanding of a topic or looking up information. Although a developer can't control a user's entry point into a web, an explicit statement of a general user model (guided, cued, or floating) might help designers create a design to support a user's likely path through a web. It's important to note that being unable to control a user's entry point or path through a web is not necessarily an undesirable feature. In fact, many would say that this porousness is precisely the power of hypertext itself; it allows users to follow links based on their interests or thought processes. The User's Browser and Display As described in Chapter 1, "The World Wide Web as a Communications System," and Chapter 2, "A Developer's Tour of the Web," the client/server organization of the Web allows for a wide variety of browsers to be available to users. A web planner can't know what kind of browsers users will have. Moreover, new browsers are in development, and future browsers are certain to provide more and different features than the ones presently available. Therefore, different users, based on their browser's operation, will experience a web differently but share common navigational needs, as outlined in Chapter 4. Some users might perceive a web using a text-only browser, whereas others might use the most current graphical browser that supports extensions to HTML. Therefore, in planning a web, developers need to consider what information will be essential so that it's not lost to users who have text-only browsers or browsers that don't support HTML extensions. If developers place important or essential information in a graphics file, for example, some users might never see it, because not all Web browsers support graphics. The choices for planners in addressing user browser display include a series of choices that might limit information available to some users. Planners choose where essential information can be placed: Text  Places all essential information in text (or in the ALT fields of images in a document) so that a user with any browser can access it. Graphics  Allows for graphics to play a major role in transmitting important information. In particular, imagemaps might be used extensively for information selection (see Chapter 16, "Imagemaps"). This choice would make this information unavailable to users with nongraphical browsers. Forms  Places some important communications functions within forms (see Chapter 14, "Forms, Tables, and Frames"). Hypermedia  Places some information in multimedia information, perhaps including movies, sounds, and images (see Chapter 15, "Multimedia"). Virtual Reality (VR)  Places some information in VRML constructs (see Chapter 28, "Virtual Reality Modeling Language"). By explicitly making choices about which level of browser display to support, the web planner sets many decisions for the web specification that guides web designers and implementers. Setting these limits is crucial, particularly when the web's intended audience is known to have only a certain level of capability for accessing the web, or the purpose of the web is to reach a large audience (perhaps to the non-Internet regions of the Matrix through e-mail access). Because of the diversity of Web browsers, web planners also have to take into consideration how little control over information display they will have. This is a change from traditional desktop publishing, in which every aspect of font style and size, alignment, and other layout features are controlled carefully. HTML, working on a different philosophy for presenting information, is intended as a semantic markup language rather than a page layout language. Web planners must recognize that the tags in an HTML document define the structures of a document-not necessarily how these structures are displayed. Many browsers render the unordered list differently, however; some use graphical dots, and text browsers may use an * or an o. Indentation and alignment of lists may vary from browser to browser. Even the font size and style of a displayed document often are under a user's control. This issue of rendering relates to the levels of HTML (and extensions to HTML, some of which are browser-specific) a web developer chooses to employ. Part III, "Web Implementation and Tools," covers these levels in detail. The bottom line is that web planners should avoid trying to micromanage or specify page layout. Although such page layout might be optimized for a particular brand of browser during implementation, users with other browsers might be disappointed with their brand of browser's rendering of the same page. Links Into and Out of a Web In a web, many links might be made to resources on the network that are beyond a web developer's control. These resources may move, making the link no longer valid (the link then is said to be stale). Users following a stale link from a document will encounter an error message and not get the information the developer originally had intended for them to access, thus degrading the experience of the users of the web. At the planning stage, a web developer can make some policy statements that address this "links out" issue: No links out  This is the most stringent option. It states that no links will be made from the web to resources that are not under the direct control of the web developers. The benefit of this policy is that the developers have absolute control over the resources that are the destination points of the links in a web. The problem with this strategy is that the benefit and value of external resources are lost to the users. This policy might work best for webs that contain only information pertaining to a single organization. Buffer layer  In this option, web planners designate a core group of web pages that are separated from outside links by a layer of local web pages of a minimum depth. The web planners might designate that there will be no outside links closer than three links away from the home page of the web, for example. In this case, the home page constitutes the core set of pages, and there are at least three links between a page within this core set and a link outside the web. Note that a user still can enter the web in the pincushion or cloud model of access to a page that has external links on it. If this web uses a guided model for user access, however, these outside links are placed beyond the user's immediate attention while in the core set of pages. This buffer layer might be the best strategy for web developers who don't want to lose their users too soon to the outside Web. Figure 5.2 illustrates a web with a three-page buffer between its home page and links to the outside Web. Figure 5.2 : A web with a three-page buffer in the outside. Centralized out  In this option, the web planners may choose to designate a single page or set of pages to contain all the links outside the web. A common practice for webs is to include a page containing interesting external links of this type, listing Web links to external resources on a single page. The benefit of this strategy is that users can have a good idea when they will be leaving the local web. This helps users who arrived at the web for a specific purpose to avoid getting "thrown out" of the web before finding the information they want. Free exit  In this option, no restrictions are placed on making links outside the web. This approach allows the particular page developer to determine when outside links should be made. This is the most flexible option, but it might send users out of a web quickly. When links are made outside a web, other issues come into play: link connections and content reliability. A stale link is one that will not technically resolve to a resource because of a permanent change in that resource's availability. A broken link is a temporary problem with a link, such as when a remote computer host is down for maintenance. Web users realize that stale and broken links are unavoidable aspects of Web navigation. For projects that require flawless access, planners may choose a policy of no external links in a web to avoid these problems. Not only can a link to an external resource become stale or broken, but the content to which it refers can change in unexpected ways. This can be particularly troubling when a developer links to resources created by people for very informal reasons (for example, a school project or a hobbyist's project). A web developer might have linked to a photograph of a train at a remote site, for example, and perhaps this photograph is key to the web's information content. The hobbyist who made that photograph available is under no obligation to forever offer a picture of a train through that link, unless by an agreement with the web developer. The hobbyist might change the image at that link every month. Next month, the users might retrieve an image of a tree. Thus, link planning and maintenance is an important part of web development, and the planning process involves taking into account which resources always must be stable or readily accessible. Just as developers can't control which resources exist through the links out of a web, they cannot control the links that are made to their webs. When a web is made publicly available, any link in a web (any URL that refers to an HTML page) can be used in any other work on the Web. (Developers might make statements explicitly forbidding these links, but this kind of restriction rarely is implemented on the Web and might even be considered a breach of Web community tradition.) Someone linking to a web could misrepresent its purpose or content, perhaps unintentionally. Although a web might be a description of "The XYZ Company's Modem Products," someone at a remote site might identify this web as "instructions for hooking up to a computer bulletin board." Developers can track down references to a web by using a Web spider (see Chapter 1) and often will be able to correspond with anyone who might have misinterpreted the meaning or purpose of their web. Although a benign case of a misunderstanding easily may be fixed, it's not clear whether developers will be able to suppress or stop malicious references or links to their webs. The legal issues involved are not resolved. A developer might run across someone who describes his or her modem products web as "the lamest modems made" or even maliciously spreads the web's URL among large groups of people, with instructions to "click on this link until the server crashes." The latter case is a bit more clear cut because there are explicit rules of conduct that most users, at least at most sites, must follow, and these usually include rules against intentionally damaging any equipment. Moreover, the commonly held set of traditions on the Net itself definitely prohibits maliciously crashing a server. Another view, however, is that the user who makes the comment "the lamest modems made," about a web might simply be exercising his or her freedom of speech, and a developer might be able to do nothing about it. In actual practice, a developer will find that links into a web are made in good faith and that any misinterpretations or misunderstandings of a web's purpose can be resolved. The Opportunities of Web Planning: What a Developer Can Control Despite the long list of issues outlined in the preceding section over which a web developer has little or no control, there are many issues a web developer can control. In particular, the Web's media qualities give the web planner many opportunities for planning at the strategic (long term), systems (multiple webs), and single-web level. The following list surveys planning issues related to the qualities of the Web described in Chapter 4. Specific planning techniques to address these issues follow this list. Multiple user roles  (user as consumer or as consumer/producer) These possibilities open up the potential for interaction among web information providers and users, as well as a participatory form of information dissemination instead of just a one-way broadcast of information. Involving users actively in information creation and dissemination is not done often, and planning for it involves a careful definition of the policy for and purpose of user-provided information. Porous quality  This quality of the Web works in favor of a web developer who plans information structures that are modular and self-contained, and that contain a sufficient number of navigation and context cues for the user. These kinds of information structures, whether they are individual pages or groups of related pages (a package), can have multiple uses for different places in the same web or for different webs of the same organization. These multiple-use information components reduce production and maintenance costs, because information creation and updates can take place in a single location within a web, and the updates can benefit all the links where this information is referenced. This efficiency is analogous to computer-software modules that can be referenced in different parts of a computer program or even in other computer programs. Dynamic quality  This quality of the Web works in favor of a web developer who uses key parts of a web to meet the users' time-dependent needs. A news organization creating a web for mass communications can have a page that contains the current headlines, which are updated throughout the day, for example. A user accessing this page can expect to see different contents from day to day and even throughout a single day, or over several hours or minutes. This dynamism works in favor of meeting the needs of the users for current information. In contrast, poor planning for information updates results in out-of-date information on a web, and the dynamic possibilities are lost. The level of dynamism on a web depends on what kind of information a web offers. Stable information might require no updating. Other information might be valid for periods of time-perhaps years or months-and might require only periodic updating. The key is for web planners to identify the updating needs of a web's information (this is covered in more detail later in the section "Domain Information"). Interactive quality  This quality of the Web can engage users and provides a way for web developers to customize information to meet users' needs. Planning for interactivity involves a careful process of audience identification and analysis in which these needs and the mechanisms by which they can be met are defined. Competitive quality  This quality of the Web requires that planners take a long-term view of any investment in web-delivered information. Planning is essential for information maintenance as much as the technical maintenance of a web. Planning for web promotion must be done so that a web gains the attention of users (see Chapter 9, "Web Promotion"). Planning must include provisions for surveillance of competitor webs, new presentation technologies, techniques, or styles. Web-Planning Techniques Web planning is a dynamic, continuous process that involves a constant balancing of opportunities and resources. Web planning often takes place within a context that is more general than just the concerns about the technical composition of a set of HTML pages. Often, particularly for larger organizations, communication on the Web is part of a strategic effort to reach users, involving many media outlines beside the Web. The following sections outline techniques for planning at different levels, starting from a strategic level (in which the focus is on an organization's needs for communication), a systems level (in which the focus is on the web-delivered portion of an organization's on-line communication techniques), and the web level (in which the focus is on an individual web's audience and purpose). People Planning Without a doubt, people are the key to the success of a web site. Because developing a web involves such a diverse range of skills, a talented team of people working together is crucial to success. Although just a few years ago it was not uncommon for a single generalist (a Web master) to be the sole developer of a web, today the trend is for a team approach, in which people with a variety of specializations work together to produce a web. Whereas the attention in web development years ago was on the people with technical talent (the Web server administrators and implementers of HTML), the attention now has shifted to content developers and producers. This isn't too surprising; nearly anyone can learn how to write HTML, but it takes great ability to develop web information well. Eventually, the focus may shift more toward creative information producers-just as in movies and television, talented performers often are at the apex of recognition and reward. When planning a web, look for people who can perform the roles outlined in the process chapters of this book: Planners  Make many choices about a web's elements and strategic growth. The planner is often the administrator or initiator of the web project itself and in many cases may be considered the leader of a web team. Planners should have strong management and people skills as well as a good understand of the Web's technical makeup and possibilities (see Chapters 1, "The World Wide Web as a Communications System" and 2, "A Developer's Tour of the Web"). Analysts  Perform the critical task of constantly monitoring your web's content and its use by its audience. An analyst needs to play devil's advocate to determine what parts of a web are working to meet the audience's needs and which are not. To do this, an analyst needs to be both confident and diplomatic, with the ability to communicate bad news to other members of the web team. A close match for analysts to be on your team may be people in quality assurance, copy editors of magazines or newspapers, teachers, or researchers in human-computer interaction or computer-mediated communication (see Chapter 6, "Web Analysis"). Designers  Create a pleasing look and feel for the Web, going beyond just the appearance of a web in terms of graphical appearance, but including hypertext and hypermedia organization and design. A web designer should have all the technical skill of an implementer, a strong sense of the web's objectives and audience, and a through feel for the World Wide Web and the Internet as a new medium (see Chapter 7). Implementers  Create HTML, CGI scripts, or Java applets based on the design and specification of a web. CGI scripts and Java require computer programming and good skills not only in coding but in software engineering techniques. Implementers need to create software that is dependable and maintainable. Look for people who are computer programmers to fill these roles. Many universities teach these skills (unfortunately, many schools teach only web implementation skills), so the pool of potential implementers is great (see Chapter 8, "Web Implementation"). Promoters  Work on the public relations, advertising, and marketing issues of a web. To staff your web team, look for people involved in these fields in other media, with the cautionary note that the potential candidates must have a good understanding of the social and some of the technical aspects of Web communication. You don't get this understanding from participating in a proprietary service like America Online. The Web has a unique set of social characteristics that play an important part in promotion (see Chapter 9, "Web Promotion"). Innovators  Like web analysts, the web team should never become stagnant or self-satisfied with its work. Instead, it should continue to integrate new techniques and technologies that meet the needs of the web's audience. An innovator also should be concerned about the quality of the web's interface and content and seek to continuously improve it. Good candidates for web innovators include quality-assurance people and technologists who work with cutting-edge innovations (see Chapter 10, "Web Innovation"). Administrative Planning As described in Chapter 3, "Options for Web Connections," an important part of developing a web involves considering how you want to create your presence on-line. For professional or serious web developers, a dependable, professional presence and a skilled web-development team are crucial for success. In addition to the people, policy, and process planning this chapter outlines, administrative planning should be made for the following: A stable Web technical presence  This presence should include a domain name (to permit switching of Internet service providers when necessary as well as for identity reasons) and adequate Web server performance. Improving Web content  When developing a web, you're not just making a home page. Your goal should be to develop sustainable, reliable processes that continuously improve the content of your site. The Web, like life, is always under construction. Your goal is to take steps to the excellence of the content of your construction. Your audience then will begin to rely on you to always do better in the flux of Web communication. A Capability Maturity Model for the Web An organization adopting a technology often passes through several stages of interest and involvement. Awareness of a promising technology might cross over to curiosity and testing. This testing then might develop into growing expertise. A wealth of expertise in a technology then might lead to its widespread use in an organization. A model for proceeding through these steps can help an organization understand the key issues and tasks to move from one level to the next. The Software Engineering Institute (SEI) at Carnegie Mellon University (CMU) (http://www.sei.cmu.edu/) has developed an organizational life-cycle model for the acquisition of software engineering technology for an organization. Called the Capability Maturity Model (CMM) for software (ftp://ftp.sei.cmu.edu/pub/cmm/), its purpose is to define the characteristics of a mature, capable process for creating software. The framework describes five levels that an organization may traverse in software-engineering practices. These stages proceed from immature, unrepeatable processes to mature, repeatable ones. The five stages follow: The Initial level  An organization's ineffective planning hobbles good software-engineering practices. Projects typically are planned poorly and their success is unpredictable. Very few stable software processes exist in the organization, and these are attributable to individual rather than organizational capability. The Repeatable level  An organization establishes policies for software project management and procedures to implement those policies. The key to achieving this level is for the management processes to make successful practices repeatable. A process that is effective is "practiced, documented, enforced, trained, measured, and able to improve" (ftp://ftp.sei.cmu.edu/pub/cmm/ASCII/tr25-overview.ascii). The Defined level  An organization documents a standard process for developing and maintaining software across the organization. This standard includes an integration of both the management and technical-engineering processes involved. An organization-wide group coordinates software-engineering process activities, and there is organization-wide training so that individuals can fulfill their assigned roles. For each project, the organization's standard software process is tailored to a "coherent, integrated set of well-defined software engineering and management processes" to best meet the needs for that project. Software quality can be tracked because processes are stable and repeatable. The Managed level  An organization sets quality goals for products and processes, and productivity and quality are measured. The risks for moving into new application domains are predictable. The resulting software products produced are of high quality. The Optimizing level  The entire organization focuses on continuous process improvement. Innovations are identified and transferred to the whole organization. Defects can be analyzed and processes adjusted to reduce them. Organizations at the optimizing level continuously improve through incremental improvements in existing processes and innovation in technologies and methods. Mapped to the activities of web development, the CMM described in this list provides a good framework for approaching the Web. Web development shares some characteristics of software engineering (it is created and deployed on computers, for example). Web development, however, involves more skills in information shaping and communication. The preceding CMM is, overall, a good framework for approaching the Web. Web planners can use this CMM for software as a basis for a CMM for web development. This model then can help as a framework for strategic planning in using Web communication: The Initial level  An organization uses Web communication haphazardly, with no defined processes or standards. Individuals with knowledge of HTML are assigned to develop webs without much thought for communication strategies or process issues. Success is unpredictable or is not evaluated or measured at all. Any beneficial results are attributable to individual effort and talent rather than organizational capability. This is the amateur stage of web development, when knowing HTML is the sole criterion for developing a web. The Repeatable level  An organization establishes and defines policies and processes for web development. These processes focus on information shaping so that success can be repeated. This involves evaluation of results, documentation of processes, and some training of developers. The Defined level  An organization documents a standard process for developing and maintaining webs across the organization. This standard includes an integration of both the management and technical processes involved. An organization-wide group coordinates the development process and activities. There is organization-wide training so that individuals can fulfill their roles. For each project, the organization's standard development process is tailored to include a set of web development and management processes to best meet the needs for that project. Web quality can be tracked because processes are stable and repeatable. The Managed level  An organization sets quality goals for products and processes, and productivity and quality are measured. The risks for moving into new application domains are predictable. The resulting Web products produced are of high quality. The Optimizing level  The entire organization focuses on continuous process improvement. Innovations are identified and transferred to the whole organization. Defects can be analyzed and processes adjusted to reduce them. Organizations at the optimizing level continuously improve through incremental work on existing processes and innovation in technologies and methods. A web planner can use this framework to set strategic goals. An organization already might be developing webs at the initial level, where creative individuals drive success. Without strategic plans for moving to the higher levels, however, this organization generally will not be able to predictably repeat successes or continuously improve quality. Although software engineering differs very much from web development, there is a correspondence in the complexity of product, culture of skills, and technical practices and development environments between both disciplines. The CMM for software therefore can guide web developers in attempting to move to higher levels of maturity. Note The Web-Integrated Software metrics Environment (WISE) is a Web-based management and metric system for managing software development teams. Although not explicitly designed for developing webs, its operation might help give insights into web development and management processes. WISE is on the Web at http://research.ivv.nasa.gov/projects/WISE/wise.html Web Policy Planning As part of defining policies for web development, planners should begin to address policy and administrative issues that are bound to arise during the course of developing, deploying, and using information on a web or set of organizational webs: Developing information  Policies must be set out to identify the processes, products, and responsibilities for web development. This is an essential framework for ensuring that everything gets done, there is no duplication, and the important definition and standardization take place. Issues outlined previously for user access, information display, and link policy should be identified. A decision about technological change rates for the web should be made-how much and how fast new technology should be introduced to the web (Chapter 10 includes more information on monitoring technological change). Providing information  Policies must be developed to state the mission or purpose of the web (or larger system of webs) in an organization. This mission statement then can define content and serve as a guideline to determine appropriate content and appropriate allocation of resources. Policies for information providers should be created. When developing a collection of Web-based information on a particular topic area, information provider maintainers should Keep aware of current developments in Internet resources on that topic. Become knowledgeable in the domain area represented by the field of study of the collection. The maintainer also should rely on domain experts to help advise on the significance and value of information sources. Be available and accessible for comments from users and domain experts and for timely maintenance of the collection based on these comments. Provide leadership and vision toward making the collection serve the interests of the users by seeking out user opinions and frequently testing the usability of the information. Ask for and acknowledge the assistance and collaboration of others in shaping the information in the collection. Actively seek and install new resources, links, or information-presentation methods in the collection. Provide periodic publicity and announcements about the collection to appropriate on-line discussion forums and indexes. Seek a replacement when they no longer are able to develop the information in the collection or when they are absent for an extended period. Using information  Policies must state how the training needs for web developers as well as local and client users will be addressed. Information policies must state who should be accessing the web(s) of an organization, and how and why they should be doing it, including statements about appropriate use for intended and unintended audiences. Intellectual property, information-dissemination, and copyright policies must be set so that users and developers know the boundaries of information use. Top 10 Ways to Make Your WWW Service a Flop As part of an effort to gather information about information systems quality, the Coombs Computing Unit of The Australian National University has created a page that gives some good advice about what not to do when planning or developing a web. This list is at http://coombs.anu.edu.au/SpecialProj/QLTY/FlopMaker.html System Planning Strategic and policy planning can guide web planners in creating a framework for increasing quality on a web. The next step is to plan organization-wide strategies for on-line (and off-line) communication. This work involves media definition, integration, and differentiation at the level of several webs or communication channels (the systems level). Communication on the Web involves mediated communication and, as outlined in Chapter 2, the Web has particular characteristics and qualities as a medium. Therefore, the first step in web systems planning is to explore how the Web can play a role in an organization's communications needs. This process of definition can start with an inventory of the arsenal of communications methods that an organization already may be using. An organization already might advertise its products in print, television, radio, and structures (such as billboards), for example. The organization also might sponsor events or make donations to worthy causes for the good will and publicity that may result (for example, sponsorship of public television broadcasting). The Web does not need to replicate or replace all of these existing communications methods; instead, it should enhance, supplement, or replace only some of them. Sponsoring worthy events or resource lists on the Web is possible, for example, as well as many forms of advertising in Web-based magazines. Another example of communication replacement is in-house communication. Local webs might be constructed to supplement or replace existing forms of intra-organizational communication. Organizational webs might facilitate extra-organizational communication. The Web offers international or global organizations an effective way to communicate worldwide. After a role is defined for what communication tasks an organizational web or set of webs might fill, the next step in web systems design is integrating the web or webs into the existing organizational communication infrastructure. An organization already might have an Internet domain name with an e-mail address, or it might have on-line communication systems in place, such as Gopher or an FTP site. An organization web can be integrated with these existing Internet information systems. Users accessing the FTP or Gopher sites might be referred to the organizational webs as sources of further information. The organizational webs may draw on the Gopher or FTP sites for content. If no existing on-line communications system exists, a set of webs must integrate with lines of communication in place. A paper-based catalog can be translated to a web, for example. Customer service representatives might attend to Internet e-mail questions as well as phone-in questions. The key is that a plan for web systems integration links the elements in web development to existing organizational communication flows. After definition and integration, the next step is differentiation. A system of webs might, at first, simply replicate or supplement other activities. These webs must provide value over these other forms, however, or an organization should discontinue the web activity. This is a process of differentiation, in which communication tasks are best left to the media that most satisfactorily serve those tasks. Instead of promoting a system of webs as the solution to all of an organization's needs, only those communication tasks that seem best suited to the web should be planned or continued. Web Element Planning After strategic and systems planning, a developer comes down to the very specific task of planning a web. The planning techniques described here address particular aspects of each of the web-development elements: audience information, purpose statement, objective statement, domain information, web specification, and web presentation. Audience Information Creating effective communications, particularly mediated communications, requires that developers plan what they want to communicate to whom. Information about the target audience for information is crucial for creating successful communication. In fact, many would consider information about an audience to be a valuable resource. Knowing the audience is key because audience information, like the purpose statement, helps shape the whole information content of a web as well as its look and feel. If developers do not have a specific audience in mind for the web, a specific audience will use the web, and that audience's experience of it might be positive or negative as a direct result of the choices the developers make about the web's presentation. A web influenced by accurate information about its intended and actual audience should have a higher probability of successfully communicating its intended message and information. Excellent planning for audience information involves two steps: defining the audience and then defining the information that it is important to know about that audience: Define the target audience. A developer should write a statement describing the target audience for the web. A developer might want to reach "scholars who are interested in botany," for example. Although this statement is simple, it serves as a valuable guide for developing many of the other elements in web development. A plan to reach the audience defined as "everyone interested in science" is a very broad one. Although a web might be created successfully that reaches such an audience, it might be an unrealistic audience planned for a new web or for developers without the expertise or resources to support it. One technique for helping to define an audience is to generate a cluster diagram. Figure 5.3 shows a sample cluster diagram in which overlapping circles represent different audiences as well as the inclusion/exclusion relationships among these audiences. A web developer might be interested in reaching just professors at universities who are professional botanists, for example, or any professional botanist or teacher of botany at any level. After making the cluster diagram, the planner can shade in the sets of people in the intended audience. Ovals in the cluster diagram represent the audiences and their relationships (such as overlapping or inclusion). The cluster diagram also shows related audiences as a way of explicitly identifying audiences that the developer might not want to reach. Figure 5.3 shows an oval for students, for example. The developer might not plan to reach grade school and high school students, but might include them in the diagram in order to show their relationship to members of the target audience. Many scholars might teach younger students, for example. As such, some of the target audience (botany scholars) might have an interest in gathering and developing material for younger audiences or in issues involved in teaching. This clustering process can continue until the planner zeroes in on what the specific audience wants. The diagram might prompt considerations about exactly what audiences should be reached. Perhaps only professional botanists who also are botany professors are the target audience, for example. Note that a web may target multiple and overlapping audiences rather than just a single group. Define critical information about the audience. The definition of critical information depends largely on the purpose statement for the web (covered in the next section). If the web intends to reach scientists interested in botany, what characteristics of these scientists are important? Educational level? Area of specialization? Personal characteristics such as age, height, and weight? For some purposes and some audiences, different information is important. Weight and height information might be important only if the web attempts to sell the scientists clothing or equipment for their research that depends on their body characteristics, for example. Otherwise, such information might be totally irrelevant. The key is to identify the relevant information about the audience in the planning stage based on an initial statement of purpose. In later stages, this list of key characteristics can be refined and then can serve as a basis for gathering audience information and analysis. Figure 5.3 : A cluster diagram helps define a web's audience. Because the planning process itself is incremental and continuous, the developer might not yet know exactly what information about the audience is important. The cluster diagram can generate possible characteristics of that audience as a starting point for later refinement. Based on the audience defined in the cluster diagram, a developer can generate lists of that audience's characteristics, concerns, and activities. Botany scholars-characteristics: highly educated, interested in biological, environmental processes skilled in critical thinking Botany scholars-concerns: funding for projects publishing findings getting the right equipment teaching valid research methodologies reading related publications Botany scholars-activities: attending conventions conducting research communicating with the public teaching gathering samples serving in industry roles Some items listed might fall into several categories; notice that "teaching" showed up both as a concern and an activity in this list. The next section shows how planning for the purpose statement helps trim down this list of possible audience information to the most relevant items, which then can serve as the database of audience information a developer will be concerned about collecting and maintaining. Purpose Statement The statement of purpose serves as the driving theme throughout web development. The purpose helps a developer choose what information about the audience to gather and maintain, and it influences the form of the web's presentation. Not having a succinct purpose statement for why a web is operating makes it very hard for web designers to choose among techniques to present information. Without a statement of purpose, web analysts have no basis for evaluating whether the web is operating effectively. Moreover, a web without a clear purpose often conveys a cloudy message to the user; the user will wonder, "What is this for?" and have no clue as to an answer. To define a web's purpose, a developer needs to make a statement about what the web should do with regard to the following elements: The subject area  What area of knowledge serves as the context for what the web conveys? This area of knowledge does not have to be a traditional Library of Congress subject classification (such as Botany or Biology). It might be "information about the odd-bearing division of XYZ Industries." The audience  The purpose statement contains the audience identification within it. This audience identification is a part of the purpose statement because so much of the "What is this supposed to do?" question about a web revolves around the specific audience mentioned in the purpose statement of the web. The level of detail at which information is presented  The purpose might be, "To provide a comprehensive overview of botany for botany scholars," or it might be more specific, such as "To present basic reference material about botany for botany scholars." This level of detail influences how much domain information needs to be gathered and maintained. The user's expected benefit or response  What will users of the web gain from it? The purpose statement might include the phrase "in order to keep current in the field of botany," "in order to keep up with current developments," or some combination of these kinds of statements. Planning the purpose statement forces the web planner to make many decisions about the message the web will convey. A well-formed purpose statement serves as a touchstone for all the other web-development processes and elements. Indeed, the purpose statement itself might play a very important role as one of the first pieces of information about the web presented to users. Here are some sample purpose statements that contain many of the points outlined in the preceding list. Notice that the more complete the statement of purpose, the easier it is for a user to answer the question, "What is this for?" when encountering the web. "This information server (ftp.arpa.mil) provides selected information about the activities and programs of the Advanced Research Projects Agency (ARPA). It initially contains information provided by the Computing Systems Technology Office (CSTO) and associated information about the High Performance Computing and Communications Program. Additional capabilities will be added incrementally to provide additional information." -from the ARPA home page (http://ftp.arpa.mil/) "The purpose of this center is to serve the needs of researchers, students, teachers, and practitioners interested in computer-mediated communication (CMC). This center helps people share resources, make contacts, collaborate, and learn about developments and events." -from the Computer-Mediated Communication Studies Center (http://www.december.com/cmc/study/center.html) "The purpose of this server is to provide access to a wide range of information from and about Japan, with the goal of creating deeper understanding about Japanese society, politics, industry, and, most importantly, the Japanese people." -from the Center for Global Communications home page (http://www.glocom.ac.jp/index.html) Objective Statement After a web developer plans for the purpose of the web, who the audience is, and what the developers need to know about the audience, the next step is to combine all this information to arrive at a specific statement of web objectives. As such, an objective statement is much more specific and lengthy than a purpose statement. An objective statement makes clear the specific outcomes and information that will implement the stated purpose of the web. The objective statement therefore expands on the general descriptions given in the purpose statement. An important difference exists, however: Although the purpose statement might stay the same, the objective statement might change as new information about the domain or audience becomes available. A phrase in the purpose statement such as "to provide access to a wide range of information from and about Japan" (Center for Global Communications home page, http://www.glocom.ac.jp/index.html) could be implemented with a variety of specific objectives. The objectives could include showing Japanese cultural information, geographical and climate information, and selections of on-line Japanese publications. Whereas the purpose statement says, "here is what we are going to do," the objective statement says, "here is the information that will do it." Unlike the purpose statement, the objective statement does not necessarily need to be written on the web's home page. Instead, an objective statement is behind-the-scenes information that guides the development of other elements in web development. From the statement of purpose given for the Computer-Mediated Communication (CMC) Studies Center, for example, the statement "help people share resources" can be used to generate a set of specific objectives: Purpose  Help people share resources Objective  Provide a list of resources with links to the following: major on-line collections of CMC-related material, bibliographies, academic and research centers related to CMC, and on-line journals Over time, this objective statement might change by expanding to include links to other kinds of forums for subjects related to CMC. Also, changes in the objective statement might require that features are removed from the web. Planning the objective statements gives a developer a head start on another web-development element: domain information. Domain Information Domain information refers to information and knowledge about the subject area of the web, including both on-line and off-line sources of information. Domain information includes not only information that will be presented to users of the web, but also all information and knowledge the developers of the web need to know in order to do a good job. Therefore, the collection of domain information serves as an "information store" from which both the developers and users of the web will draw. The purpose of the web itself might be to provide an interface to this information store, or it might be that this information store is only incidental to the purpose of the web, playing a supporting role as background information for the developers. In either case, planning for domain information is essential. Steps for planning for domain information follow: The planner should define what domain information is necessary for the developers to know and what information will be provided to users. Are there specialized databases to which developers or users must gain access? Is there an existing store of on-line material that will serve as a basis for user information? What kind of background in the discipline do developers of the web have to appreciate and understand in order to effectively make choices about information content and organization? What other material might be needed, either by the users of the web or by the developers? Plan for the acquisition of domain information. After the information store is defined, how can it be obtained? Is a large collection of information files easily accessible? Or is there a paper-based information source that the web developers should read or a course they should take before trying to build the web? Developers working on creating a web about botany should have some appreciation for the topics and subdivisions of the field in order to make judgments about how information should be presented, for example. Plan for updating and maintaining the information. It's not enough to define and acquire a database. If it is time-dependent information, when will it lose its usefulness? How will it be updated? Who will update the information? What will be the costs of this updating and maintenance? The degree of attention paid to domain information acquisition and maintenance varies a great deal according to the purpose of the web itself. A web that purports to be an interface to current satellite imagery of the Earth's clouds, for example, must necessarily have constantly updated domain information. In contrast, a web for information about British literature might require updates as new knowledge is formed, but not on an hourly or minute-by-minute basis. Web Specification The web specification is a refinement of the objective statement in more specific terms, adding a layer of constraints or other requirements. These requirements might restrict or further describe in detail what the web will offer and how it will be presented. The web specification, for example, takes the objective statement "to provide links to bibliographies in the field" and makes it specific with a list of the URLs that will be provided. The specification statement also can characterize limitations on the information and its presentation, such as "no more than 10 bibliographies will be listed on the resources page; if more are required, a separate bibliographies page will be made." The specification acts as a guidebook for the designers and implementers who will create the actual files of the web itself. The specification should completely identify all resources (for example, links; web components such as forms or graphical imagemaps; or other resources, such as sound, image, movie, or text files) that should (or can) be used on the web. The web specification also should identify any restrictions based on choices or policies discussed previously, such as for an intended model for user traversal, link policy, and the presentation of essential information. Similar to how the objective statement can change while accomplishing the same purpose, the specification statement might change while accomplishing the same objective. (The URL to a resource required by an objective statement might change, for example.) The major issue when planning for the specification is for the web planner to make sure that the people developing the web have the tools, training, and time necessary to develop the web according to specifications. One part of the specification could state that a customer can order a product by using the forms feature of HTML, for example. In such a case, the planning process must identify the capability to build these forms as a skill web implementers must have. The web specification also can exclude specific items based on information policy decisions. The specification might state that the forms feature of HTML is not to be used (because some Web browsers do not support forms), for example, or that no graphics are to be used. The specification therefore acts as a list of building blocks and tolerance limits that can satisfy the objective statement for the web. Web Presentation Although the audience definition, purpose and objective statements, and domain information are most closely associated with the planning process of developing a web, the development of a web's presentation also must be planned. The web's presentation is the whole look and feel of the web, along with its actual implementation. Web designers planning for the web's presentation rely heavily on the web-specification statement as a basis for making choices. Planning for web presentation involves verifying that resources that comprise the Web are and will be available to support the files on the server. Therefore, the person planning for the web's presentation must work closely with the web server administrator (sometimes called the Web master), whose duties include allocating space or setting any special file or directory permissions so that the web presentation can be implemented. Web planners also anticipate needs for the web's presentation by doing the following: Generating a set of possibilities for web presentation based on current or possible specifications. These possibilities might include sample HTML pages or, if the specifications allow, graphical imagemaps or forms to help the user interact with the information. Planning the work schedule necessary to implement the web according to specifications, including how much time it will take to implement and test web pages, verify links, and implement changes based on new specifications. Creating and maintaining a pool of generic web components (for example, common web page layouts or forms to serve as templates for web implementation). Creating a mock-up of the web based on an initial specification. This mock-up could be created quickly from generic web components and offer a rapid prototype to be used in the other web-development processes. Although the implementers working on the web's presentation are the ones to actually write HTML files, the implementers aren't the "authors" of the web itself. As demonstrated in this chapter and the rest of the chapters in this part, many processes are involved in developing a web. Whether one individual is involved or a whole team, all developers take part in creating an effective web. A Web Plan Example You can get a good idea of the kind of decisions a planner might make by looking at a sample set of web-planning information. I've created the Web Development web (http://www.december.com/web/develop.html) to support readers of this book. Figure 5.4 shows the planning information front page for this web. Figure 5.4 : The Web Development web Planning page. Links off the planning information front page connect to detailed plans for each of the elements. Figure 5.5 shows the audience information, for example. I continuously work on updating and refining the planning information. You can take a look at my planning information on-line at http://www.december.com/web/develop/wdplan.html. Figure 5.5 : The Web Development Audience Information page. Web Planner's Check Good webs don't always happen by accident. If you are a web developer, spend some time thinking about why you will build it and who will come. Web development planning depends on your understanding of the characteristics and qualities of the Web as a medium for communication and your ability to make choices among the many possibilities for expressing information on the Web. There are limits to what you can and cannot control in web planning and development. You can't control user behavior, browser type, or links in and out of your web. You can plan for people; administrative issues; and a model for increasing your information's quality, policy, and web elements.