As a web planner, you need to anticipate the skills and resources needed for developing, constructing, deploying, and operating the web. For example, if a web's design includes a specification for forms (a feature supported by HTML), you should note that web implementors should have skills in HTML forms as well as CGI (Common Gateway Interface) programming.
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.
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. 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.
You can apply the Web's media characteristics and qualities 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.
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 (the wine bottle model), actual use might differ. Access to a web follows more the pincushion model, 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.
On a larger scale, the entire Web itself, composed of millions of individual webs, resembles a cloud of hypertext (the cloud model shown). 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. 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 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.
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. This choice would make this information unavailable to users with nongraphical browsers.
Forms. Places some important communications functions within forms.
Hypermedia. Places some information in multimedia information, perhaps including movies, sounds, and images.
Virtual Reality (VR). Places some information in VRML constructs.
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.
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.
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 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.
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. 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. Planning must include provisions for surveillance of competitor webs, new presentation technologies, techniques, or styles.
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 processes:
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.
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.
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.
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.
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.
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.
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.
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) 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, 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:
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:
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.
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:
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 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.
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:
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.
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.
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.
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.
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.
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:
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 (https://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 (https://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 (https://www.glocom.ac.jp/index.html)
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, https://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:
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.
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.
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 planners also anticipate needs for the web's presentation by doing the following:
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.