Chapter 8 -- Web Implementation Chapter 8 Web Implementation CONTENTS The State of the Art in Web Implementation An Implementation Overview Implementation Principles Implementation Processes Web Implementer's Check If you are a web implementer, your challenge is to create a working web. Working with the universal grid and link diagrams from the design process (see Chapter 7, "Web Design") as well as the web specifications and domain information, you create HTML or other software and multimedia to accomplish the web's objective. To do this, you need to have excellent knowledge of HTML and other languages, skills in using the computer system on which the web will be deployed, and excellent file management and organizational abilities. You also need good writing skills, a talent for layout and design, and a sense of how the intended audience uses and thinks about the information presented in the web. Part III, "Web Implementation and Tools," delves into HTML implementation in detail, covering tools and techniques. In particular, Chapter 11, "Design and Implementation Style and Techniques," describes implementation techniques and style, including file-management techniques, composing text, and style. This chapter focuses on how implementation fits into the overall methodology for web development described in Part II and the relationships among the people and processes involved. The roles, goals, and principles outlined here should be helpful for the web implementer to develop repeatable, process-oriented techniques for implementing webs. After this process and people overview, this chapter surveys the processes for HTML implementation: working with others, choosing the level of HTML compliance, testing, solving problems, and continuous implementation. The State of the Art in Web Implementation The explosion of interest in the World Wide Web and its native language, HTML, has fostered enormous competition among Internet software vendors. The big players-Netscape (http://www.netscape.com/) and Microsoft (http://www.microsoft.com/)-remain in heavy competition to create the most popular software for the Internet. Fortunately for the user, this competition has given rise to a very wide range of choices for software. Unfortunately for the developer, the competing commercial forces, combined with the popular interest in (and misconceptions about) the World Wide Web, have resulted in a more fragmented communications environment. The nature of this fragmentation is several-fold: There are now more variations in HTML elements.  Different brands of Web browsers recognize different HTML elements, many of which have not been recognized as standards by the World Wide Web consortium (http://www.w3.org/). The slow process for the ratification of HTML standards has given browser manufacturers strong power to set those standards. There are now more kinds of associated software that work with Web browsers.  Some Web-delivered information depends on plugins and add-on software to be used with the browser for displaying information. In many cases, these plugins are available only for certain platforms and can be used only with certain brands of browsers. Languages such as Java promise to break the platform independence and "plugin" model for transmitting Web information. There are now more kinds of media involved in Web information and communication.  There are now more kinds of ways for sound, video, animation, and other affects to be implemented on the Web. Many of these media types involve special formats and plugins for interpretation. Others, such as Java-based media types, promise to provide a more platform-independent, seamless way for users to perceive media. Chapter 15, "Multimedia," covers these developments in more detail. Automated techniques for HTML implementation have emerged.  No longer do many professional web implementers depend on hand-crafted HTML pages. Instead, the trend is toward automatic generation of HTML pages based on databases and/or templates. Chapters 11, 17, "Implementation Tools," 18, "Development and Language Environments," and 27, "Creating and Managing Dynamic Web Sites: Differentiating Data from Display," cover tools and techniques for automated HTML implementation. Despite all the advances and changes in web-implementation technologies, the need for trained and talented implementers who take a process-oriented view toward implementation has changed. The concept of implementation as one part of an overall methodology to meet Web user's needs hasn't changed. Web implementation performed within the framework using a repeatable, process-oriented approach is one way to cope with constantly changing technology. The rest of this chapter gives you an overview of how implementation fits in with the other web-development processes to create quality web information. An Implementation Overview Figure 8.1 shows an overview of the implementation process. The goal is for implementers to combine the output from the design and planning processes, as well as any updates or maintenance specified as a result of the analysis process, to create a working web. A key feature of the entire web-development process described in this part is that web design, planning, and other processes are separated from web implementation. This allows developers to make decisions about design that are independent of language-specific or implementation issues. The job of the implementer is to bridge this gap between these abstract processes and the specific needs of implementation. This separation of processes helps implementers because they are free to make the decisions they need to make at their level of responsibility. This separation also helps designers and planners focus on the needs of the audience without worrying about the changing methods and practices for writing HTML. The implemented web is the object that users often consider to be the whole work of the web, although the chapters in this part describe a great deal of other work essential to creating an effective web. Figure 8.1 : Web implementation. A web implementer should gather the following information, which should have been generated by other processes of web development: Design products  As a result of the design process (see Chapter 7), the web designer creates a look-and-feel diagram and a package, page, and link diagram. These two products are the major guidelines a web implementer uses in a working web. Web specification  As a result of the planning process (see Chapter 5, "Web Planning"), a set of specifications for web tolerances, limits, or other parameters has been set. This web specification guides the web implementer in making decisions about many of the specifics in a web. Updates and maintenance requirements  As a result of the analysis process (see Chapter 6, "Web Analysis"), a web analyst may determine a set of corrections in HTML or updates in information. Updates also may result from the planning process or the innovation process (see Chapter 10, "Web Innovation"). Technology specifications  As outlined in this chapter, HTML, although intended to be a set of standards for browser-independent HTML features, is not, in practice, a stable set of guidelines for marking up hypertext documents. Instead, many popular browsers implement nonstandard features that are used widely, and the standardization process is slow to make decisions about and formally codify these extensions. Competition among browser manufacturers creates an environment in which creative innovations (and more nonstandard HTML features) are made available. As a result, this constant innovation in browsers and techniques creates a situation in which the web implementer needs to keep up with changes and the current state of HTML, and possibly change or update code as a result of standardization decisions. User input  The web implementer often has close contact with users through mail links in the working web. Users might report faulty links or have comments on how the web works overall. Some of these comments might be minor implementation issues; others might require more work in the planning, analysis, or design process. As the preceding list shows, as a web implementer, you balance many issues in accomplishing your task. Your goal is always to create and maintain the best working web possible, and you therefore must be in close contact with the web analyst, web planners, and web designers. Specifically, your web-implementation task includes the following work: Integrating the design and other information listed previously to come up with a strategy for implementing a web Designing a file-management system that adequately meets the needs for web implementation Creating templates, software, and web components that can be used to implement the web quickly and efficiently Writing HTML files to implement the web "by hand" or through HTML editors, generators, languages, or development environments Maintaining the HTML files so that they are technically correct (validated to the level of HTML as currently known), current (with regard to information or other updates), and usable (have no broken or missing links and meet user needs) The process of web implementation, then, is how a web becomes a working object available for use. In the following sections, I introduce the principles, techniques, and typical implementation problems and solutions. Implementation Principles Based on the principles for the Web's media characteristics and qualities, as well as user needs and experience, web implementation consists of principles that can assist you in decision making. Overall, these principles recognize the dynamic, porous nature of the Web and how the strategies of the design process attempt to take these into account. Web implementation Works continuously.  Just as a web's development process often is continuous, so is a web's implementation. Because of this, web-implementation procedures should be designed with process orientation, allowing for replication, improvement, and reliability in file management and HTML coding techniques. In many cases, a web, once implemented, might remain static. But the dynamic characteristic of the Web often requires a web to be redesigned and reimplemented. Involves separation of tasks.  All web-development processes involve separating the processes of web development so that the implementer makes the decisions about specific HTML structures "just in time." In other words, a web planner or a web designer should not be making decisions about a web at the HTML level. Instead, the web implementer makes decisions about the web based on tolerances and instructions provided. Involves layering of detail.  A web implementer can work most efficiently by creating generic web components or software that works with templates for creating HTML files. This same template idea can be used to design file systems as well as page layout to achieve the goals of a consistent web. Implementation Processes The skills of a web implementer involve process skills, not just skills in technique. Creating repeatable successes in web development and fostering the continuous improvement of a web requires close work with others, testing, solving problems, and looking at web implementation as a continuous process on a product that may never be truly finished. Working with Others Although much of a web implementer's time is spent constructing HTML files, an implementer also works with other people. Even if one person is the sole developer of a web-the planner, analyst, designer, implementer, promoter, and innovator all rolled into one-he or she still has to work with people in a very important group: the users of the web. Without a representative user, or at least a close analysis of users' characteristics and a good understanding of them, a web can get off base and fail to meet users' needs. And, as Figure 8.2 illustrates, web implementation involves a great deal of human communication and collaboration. Figure 8.2 : Web implementation involves communication with other web-development processes. The analysis process of web development (see Chapter 6) is a process to help check that the audience's needs are being met on the big-picture level. A web implementer is intimately concerned with minute decisions about the construction of hypertext: the placement and creation of hotspots, links, and specialized features such as forms or graphical information maps. A good web designer should have created a look and feel for the web, and the web specification should be complete. There still are many decisions for a web implementer to make, however, because it is impossible to fully specify every last detail of a web. In fact, the only complete record of all the minute decisions of a web's design and specification is the web itself. Therefore, it's important for a web implementer to keep lines of communication open and operating with the following people: Web planners What does a web implementer know about the audience that might help the planners better identify or meet the audience's needs? Are there parts of the design that a web implementer knows are not meeting the needs of the audience or are extraneous to the purpose or objective of the web? What are the planners considering for the future? This information might help a web implementer anticipate directory or file requirements, or other requirements in order to create prototypes or web components for these. Does a web implementer feel that some parts of the purpose or objective of the web have not been expressed in the web specification or design? What skills does a web implementer need to implement the web itself? Are there specialized skills or resources that a web implementer doesn't have? Web analysts What performance problems is a web implementer aware of in the web's design (many images on one page, huge pages, problems with interfaces to databases)? An implementer can inform the web analyst to pay particular attention to these areas of the web for timing and user feedback. What are the patterns for web use? How can a web implementer help the analyst interpret the file-use statistics? Does a web implementer know of a particular page that seems to be underused or overused, considering its purpose? What overall performance concerns does the web analyst have? Suppose that the purpose of the web is to get orders for products, and the number of orders is low. The web implementer might know that orders are low because the order form is difficult to use. What other aspects of the implementation might be causing problems or dissatisfaction in users? Web designers What aspects of the web design are impossible or awkward to implement? What design decisions haven't been considered or specified with sufficient detail for a web implementer to implement? What issues of look and feel or linking in the web design does a web implementer think need to be changed or modified? What overall concerns does a web implementer have about how the web design is meeting the purpose and objective of the web? Web promoters What suggestions does a web implementer have for publicity and timing of web announcements and public releases? What features of the web does a web implementer feel need to be brought more to the attention of users? What problems does a web implementer see with the current way that web development (publicity, inputs to the planning analysis and design processes) is being done? Web innovators What ideas does the web implementer have for incorporating new forms of HTML development techniques, tools, or processes into web development? What critique of proposed innovation ideas does the web implementer have? Audience representatives Does a web implementer have access to a pool of representative audience members for testing the implementation? The analysis processes should involve a detailed study of the results of web use. Direct, unsolicited feedback from users about a web also can be very valuable. Can a web implementer use the forms capability of HTML to include response forms or comment boxes for eliciting user feedback? Using this feedback, a web implementer often will be the one to get e-mail from users describing a stale link or a problem with the web. What sense does a web implementer gain about the users' overall satisfaction based on this feedback? What suggestions or comments might a web implementer pass on to planners, designers, and developers? Overall, a web implementer might find that the people processes in implementing a web can be as complex, if not more so, as developing the HTML itself. This should not be a great surprise. After all, a web is developed and used by people, and people are notoriously inexact and changing. In all these interactions, a web developer should remain patient and listen; interpersonal communications skills in eliciting constructive criticism often play a major role in helping to implement the web in the best way possible. Choosing the Level of HTML Compliance Note The specification for new standards of HTML is always in the works. Check the Web sites for the HTML working groups at the Internet Engineering Task Force (http://www.ietf.org/) and the World Wide Web Consortium (http://www.w3.org/). The latest on HTML specifications should be available at http://www.w3.org/hypertext/WWW/MarkUp/MarkUp.html. Implementing a web using HTML is discussed in detail in Part III. The purpose of this section is to give the web implementer an overview of the levels possible and the benefits (and possible problems) with each. During web planning, the level of HTML compliance already might have been specified, such as, "implement to strict level 3.2 HTML." Or, it might have been implied by the specification of where essential information should be located in the web (such as in text only or possibly in graphics, multimedia, or virtual reality modeling language). The levels of HTML follow: Level 0 Description  This is the "lowest" level of HTML-the level that all Web browsers (even the [e-mail] e-mail browser or other text-based browsers) can render. Benefits  Conformance at this level may be key to providing access to a web's information to anyone in the Matrix (see Chapter 1, "The World Wide Web as a Communications System," for a discussion of on-line cyberspace). This level also may support possibilities for widespread access to the Matrix through wireless personal digital assistants with text-display capabilities. This level of HTML compliance ensures that all a web's information is available to anyone using text-only browsers. Drawbacks  Level 0 HTML doesn't have the expressive capabilities or the many graphical and more advanced markup features of higher levels of HTML. Level 1 Description  This level adds inline images and many different logical and physical text-rendering styles. Benefits  This level maintains much of the same functionality and flexibility as Level 0. The rendering styles for text, of course, won't all work for nongraphical browsers or ASCII text-only browsers. Drawbacks  Although Level 1 adds some functionality over Level 0, most modern browsers support Level 3.2 HTML. Level 1 therefore is somewhat in a middle ground where it adds functionality that can't be used by bare-bones browsers (such as the agora e-mail browser) but doesn't capture the benefits of Level 3.2 HTML. Level 2 Description  This level adds forms to help solicit information from users (see Chapter 14, "Forms, Tables, and Frames"). Benefits  The forms feature is key to developing interactive applications. Drawbacks  Although most modern browsers support forms, some do not. The use of forms requires that the information provider be able to operate CGI programs (see Part IV, "Gateway Programming"). Level 3.2 Description  This level of HTML was released in May 1996. (Note that there was never a 3.0 HTML because of problems in the standardization process; the proposed HTML 3.0 had too many features to be standardized quickly.) This level includes tables, the applet element, physical formatting, and other features. Benefits  Rendering tables is essential for many design requirements. Drawbacks  Users of lower-level browsers won't be able to use many of the Level 3.2 features. Extensions  The most popular HTML extensions in use now are those added by Netscape Communication's browser, Mozilla (http://www.netscape.com/). Description  Adds features such as frames, JavaScript, client-side image mapping, GIF animation, and other features-many of which may be expected to appear in future official standards for HTML. Benefits  Used creatively to meet user needs, these features can add flair and interest to a web. Drawbacks  Many of these features are visible only to users of Netscape's brand of browser. Other browsers may render some of these features satisfactorily; some browsers may not render some of these features at all. Some of these features, even if used, often are not used well (for example, the <BLINK> tag). More HTML Description  Additions for future versions of HTML include style sheets (http://www.w3.org/pub/WWW/Style/), math formulas, and elements to display figures and text, such as BANNER and FIG. Besides the on-line sources of information at the Internet Engineering Task Force (IETF) and World Wide Web Consortium (W3C), the collection at Yahoo! (http://www.yahoo.com/Computers/World_Wide_Web/HTML/) contains a great deal of on-line information about HTML. Methods of validating HTML for levels of compliance with specifications are covered in Chapter 7. The HTML Station I've prepared a Web site to support you in HTML information and syntax: The HTML Station at http://www.december.com/html/. This site links you to reference information and demonstrations of HTML. You'll find information about all levels of HTML, as well as examples, tag summaries, and links to the latest supporting and reference information. Testing the Web After a web implementer generates a prototype web, it can be tested in the following ways. A web implementer can click through the web and see how the prototype works, trying tasks that users would do (find the page for a certain product, for example). The look-and-feel diagram and the package, page, and link diagrams never really capture the experience of an actual working web. In going through the prototype, the implementer can ask How does this work together? Is there any page that seems unneeded? Does a web implementer feel that the web conveys the sense of a consistent, coherent design? A web implementer can bring concerns to the web designer and also adjust the web prototype's implementation until it is more satisfactory. Tests of the web also can be done by Designers  Have the designers who created the look and feel and other design products go through the prototype with a web implementer. What opinions do they have about how the web looks and how the major pages fit together? Other web developers  An implementer can check with the planners, analysts, promoters, and innovators of the web. What suggestions do they have based on seeing the prototype? Representative audience members  If possible, an implementer should ask member(s) of the target audience to go through the prototype web to give comments and feedback. The prototype might be too rough for the audience members to be able to say exactly how they feel about it, but it might be possible to observe how the audience members navigate through the prototype. Identify the problems they have. These comments can help web implementers quickly identify areas where they might have to provide additional guidance and information. Solving Implementation Problems During the course of web implementation, many minute details can present problems. Typical problems include the differences in browser renderings, changes in HTML extensions, and new HTML features (some of which might be proprietary to one brand of browser). Other performance problems may arise, such as user complaints about download time and user requests for text-only versions of the web. Working with graphics and icons often brings problems with resolution and "nicks and cuts" in the rendering. After web implementers build and demonstrate a prototype and get some comments from other web developers and audience members, they can continue implementation based on these results. The comments from the prototype even might lead to a redesign. More likely, some parts will be redesigned while the implementation of other parts of the web go forward. Remember that the redesign of the web probably will be more or less continuous over the deployed life of the web. In a way, the web itself is always an evolving prototype. For an implementer, the key is to continue to craft HTML files and keep track of changes to design (particularly when they affect all files, such as changes to the look and feel of the universal template). Over the long term, web implementers must be concerned with web maintenance-both the maintenance of the HTML features and the information (wording) in the files themselves. Web implementers should Work closely with the web analyst to detect stale links. If possible, use automated programs to do this (for example, MOMspider, as described in Chapter 6). Routinely check the web pages for any updates they need to make in the wording and presentation of the information. This can be crucial particularly if web planners make a major change in the target audience or purpose of the web. Routinely check the web's access statistics. (The Web master should be able to set up a program to collect these.) Look for links that show up in the error logs for the server, because they might be stale or malformed links. If a web implementer must change the name of a file, provide a link in the old file's name for a period of time with a link moved notice and provide users with a link to the new file. Using a carefully designed directory and a file-naming plan, they should be able to avoid as many of these link moved notices as possible. Continue to build a store of knowledge about HTML (and its extensions) and identify new ways to more efficiently implement the web's design. Sample Web Implementation Documentation I've developed a page describing my implementation process for the Web Development web (http://www.december.com/web/develop.html). You can take a look at the implementation information I have there at http://www.december.com/web/develop/wdimplement.html. Web Implementer's Check Implementing a web is a demanding part of web development. A web implementer must work closely with others: the web planners, analysts, designers, promoters, innovators, and, most important, the users. Working with HTML files and directories also is part of a web implementer's job. If web implementers are just starting a web, they first should gather all the information possible from the other processes and web elements: look-and-feel diagrams; package, page, and link diagrams; audience information; purpose and objective statements; domain information; and web specification. Building a web prototype is the next step in implementing a new web. A web implementer can create templates based on the look-and-feel diagrams for the whole web as well as templates for pages that serve other functions. Link these pages based on the package, page, and link diagram to create a web prototype. Implementers should test the prototype web and seek comments from web users, designers, planners, analysts, and promoters. Ideally, they should observe at least one representative audience member using and commenting on the prototype web. In the long term, a web implementer must work continuously; change and growth are characteristics of good webs. A process of continuous implementation and testing and open communication with other web developers and representative audience members are essential. Implementing a web is very challenging; it draws on technical abilities to create and manage a complex system of HTML files, expressive capabilities with language and design elements, and communications skills in asking for and receiving feedback to continuously improve a web.