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 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.
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.
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.
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.
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.
| 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:
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. |
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.
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
| 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. |