The immediate nature of Web-based applications coupled with the pressure for continuous evolution forces a Web engineer to establish a desi...
The immediate nature of Web-based applications coupled with the pressure for continuous evolution forces a Web engineer to establish a design that solves the immediate business problem while at the same time defining an application architecture that has the ability to evolve rapidly over time. The problem, of course, is that solving the immediate problem (quickly) can result in compromises that affect the ability of the application to evolve over time. This is the designer’s dilemma.
In order to perform Web-based design effectively, a Web engineer should work to reuse four technical elements :
Design principles and methods. It is important to note that the design concepts and principles apply to all WebApps. Effective modularity (exhibited by high cohesion and low coupling), information hiding, stepwise elaboration, and other software design heuristics lead to Web-based systems and applications that are easier to adapt, enhance, test, and use.
Design methods for object-oriented systems can be reused when Web-applications are created. Hypermedia defines “objects” that interact via a communication protocol that is loosely analogous to messaging. In fact the diagrammatic notation proposed for UML can be adapted for use in design activities for WebApps. In addition, a variety of hypermedia design methods have been proposed.
Golden rules. Interactive hypermedia applications (WebApps) have been constructed for more than a decade. Over that time, designers have developed a set of design heuristics (golden rules) that can be reapplied during the design of new applications.
Design patterns. As we noted earlier in this book, design patterns are a generic approach for solving some small problems that can be adapted to a much wider variety of specific problems. In the context of WebApps, designpatterns can be applied not only to the functional elements of an application, but to documents, graphics, and general aesthetics for a Web site.
Templates. A template can be used to provide a skeletal framework for any design pattern or document that is to be used within a WebApp. Nanard and Kahn describe this reusable design element in the following way:
Once a template is specified, any part of a hypermedia structure that conforms to this template can be automatically generated or updated just by calling the template with relevant data [to flesh out the skeleton]. The use of constructive templates implicitly relies on the separation of hypermedia document contents from the specification of its presentation: source data are mapped into the hypertext structure as specified in the template.
Each of the four reusable design elements is discussed in greater detail in the sections that follow.
Architectural Design
Architectural design for Web-based systems and applications focuses on the definition of the overall hypermedia structure of the WebApp and the application of design patterns and constructive templates to populate the structure (and achieve reuse). A parallel activity, called content design, derives the overall structure and detailed layout of the information content that will be presented as part of the WebApp. WebApp Structures
Overall architectural structure is tied to the goals established for a WebApp, the content to be presented, the users who will visit, and the navigation philosophy that has been established. The architectural designer can choose from four different structures when developing the design for a typical WebApp. Linear structures are encountered when a predictable sequence of interactions (with some variation or diversion) is common. A classic example might be a tutorial presentation in which pages of information along with related graphics, short videos, or audio are presented only after prerequisite information has been presented. The sequence of content presentation is predefined and generally linear.
Another example might be a product order entry sequence in which specific information must be specified in a specific order. In such cases, the structures shown in figure above are appropriate. As content and processing become more complex, the purely linear flow shown on the left of the figure gives way to more sophisticated linear structures in which alternative content may be invoked or a diversion to acquire complementary content occurs.
Grid structures are an architectural option that can be applied when WebApp content can be organized categorically in two (or more) dimensions. For example, consider a situation in which an e-commerce site sells golf clubs. The horizontal dimension of the grid represents the type of club to be sold (e.g., woods, irons, wedges, putters). The vertical dimension represents the offerings provided by various golf club manufacturers. Hence, a user might navigate the grid horizontally to find the putters column and then vertically to examine the offerings provided by those manufacturers that sell putters. This WebApp architecture is useful only when highly regular content is encountered .
Hierarchical structures are undoubtedly the most common WebApp architecture. Unlike the partitioned software hierarchies which encourage flow of control only along vertical branches of the hierarchy, a WebApp hierarchical structure can be designed in a manner that enables (via hypertext branching) flow of control horizontally, across vertical branches of the structure. Hence, content presented on the far left-hand branch of the hierarchy can have hypertext links that lead to content that exists in the middle or right-hand branch of the structure. It should be noted, however, that although such branching allows rapid navigation across WebApp content, it can lead to confusion on the part of the user.
A networked, or “pure Web,” structure is similar in may ways to the architecture that evolves for object-oriented systems. Architectural components (in this case, Web pages) are designed so that they may pass control (via hypertext links) to virtually every other component in the system. This approach allows considerable navigation flexibility, but at the same time, can be confusing to a user. The architectural structures discussed in the preceding paragraphs can be combined to form composite structures. The overall architecture of a WebApp may be hierarchical, but one part of the structure may exhibit linear characteristics, while another part of the architecture may be networked. The goal for the architectural designer is to match the WebApp structure to the content to be presented and the processing to be conducted.
Design Patterns
Design patterns are a generic approach for solving some small problem that can be adapted to a much wider variety of specific problems. In the context of Web-based systems and applications, design patterns can be applied at the architectural level, the component-level, and at the hypertext (navigational) level.
When data processing functionality is required within a WebApp, the architectural and component-level design patterns and others are applicable. Hypertext-level design patterns focus on the design of navigation features that allow a user to move through WebApp content in a facile manner. Among many hypertext design patterns proposed in the literature are :
• Cycle—a pattern that returns the user to a previously visited content node.
• Web ring—a pattern that implements a “grand cycle that links entire hypertexts in a tour of a subject” .
• Contour—a pattern that occurs when cycles impinge upon one another, allowing navigation across paths defined by the cycles.
• Counterpoint—a pattern that adds hypertext commentary, which interrupts content narrative to provide additional information or insight.
• Mirrorworld—content is presented using different narrative threads, each with a different point of view or perspective. For example, content that describes a personal computer might allow the user to select a “technical” or “nontechnical” narrative that describes the machine.
• Sieve—a pattern that guides a user through a series of options (decisions) in order to direct the user to specific content indicated by the sequence of options chosen or decisions made.
• Neighborhood—a pattern that overlays a uniform navigational frame across all Web pages in order to allow a user to have consistent navigation guidance regardless of location within the WebApp.
These hypertext design patterns can be reused as content is translated into a format that allows navigation through a WebApp.
Navigation Design
Once the WebApp architecture has been established and the components (pages, scripts, applets, and other processing functions) of the architecture have been identified, the designer must define navigation pathways that enable a user to access WebApp content and services. To accomplish this, the designer must (1) identify the semantics of navigation for different users of the site and (2) define the mechanics (syntax) of achieving the navigation.
A large WebApp will often have a variety of different user roles. For example, roles might be visitor, registered customer, or privileged user. Each of these roles can be associated with different levels of content access and different services. A visitor may have access to only limited content while a registered customer may have access to a much broader range of information and services. The semantics of navigation for each of these two roles would be different.
The WebApp designer creates a semantic navigation unit (SNU) for each goal associated with each user role . For example, a registered customer may have six different goals, all resulting in access to different information and services. A SNU is created for each goal. Gnaho and Larcher describe the SNU in the following way:
The structure of an SNU is composed of a set of navigational sub-structures that we call ways of navigating (WoN). A WoN represents the best navigation way or path for users with certain profiles to achieve their desired goal or sub-goal. Therefore, the concept of WoN is associated to the concept of User Profile.
The structure of a WoN is made out of a set of relevant navigational nodes (NN) connected by navigational links, including sometimes other SNUs. That means that SNUs may themselves be aggregated to form a higher-level SNU, or may be nested to any depth.
During the initial stages of navigation design, the WebApp structure (architecture and components) is assessed to determine one or more WoN for each user goal. As noted, a WoN identifies navigation nodes (e.g., Web pages) and then links that enable navigation between them. The WoN are then organized into SNUs.
As design proceeds, the mechanics of each navigation link are identified. Among many possible options are text-based links, icons, buttons and switches, and graphical metaphors. The designer must choose navigation links that are appropriate for the content and consistent with the heuristics that lead to high-quality interface design.
In addition to choosing the mechanics of navigation, the designer should also establish appropriate navigation conventions and aids. For example, icons and graphical links should look “clickable” by beveling the edges to give the image a threedimensional look. Audio or visual feedback should be designed to provide the user with an indication that a navigation option has been chosen. For text-based navigation, color should be used to indicate navigation links and to provide an indication of links already traveled. These are but a few of dozens of design conventions that make navigation user-friendly. In addition to conventions, navigation aids such as site maps, tables of contents, indexes, search mechanisms, and dynamic help facilities should also be designed at this time.
Interface Design
The interface design concepts, principles, and methods are all applicable to the design of user interfaces for WebApps. However, the special characteristics of Web-based systems and applications require a number of additional considerations.
The user interface of a WebApp is its “first impression.” Regardless of the value of its content, the sophistication of its processing capabilities and services, and the overall benefit of the WebApp itself, a poorly designed interface will disappoint the potential user and may, in fact, cause the user to go elsewhere. Because of the sheer volume of competing WebApps in virtually every subject area, the interface must “grab” a potential user immediately. Nielsen and Wagner suggest a few simple guidelines based on their redesign of a major WebApp:
• Server errors, even minor ones, are likely to cause a user to leave the Web site and look elsewhere for information or services.
• Reading speed on a computer monitor is approximately 25 percent slower than reading speed for hard copy. Therefore, do not force the user to read voluminous amounts of text, particularly when the text explains the operation of the WebApp or assists in navigation.
• Avoid “under construction” signs—they raise expectations and cause an unnecessary link that is sure to disappoint.
• Users prefer not to scroll. Important information should be placed within the dimensions of a typical browser window.
• Navigation menus and headbars should be designed consistently and should be available on all pages that are available to the user. The design should not rely on browser functions to assist in navigation.
• Aesthetics should never supersede functionality. For example, a simple button might be a better navigation option than an aesthetically pleasing, but vague image or icon whose intent is unclear.
• Navigation options should be obvious, even to the casual user. The user should not have to search the screen to determine how to link to other content or services.
A well-designed interface improves the user’s perception of the content or services provided by the site. It need not be flashy, but it should always be well structured and ergonomically sound.
