Chapter 1. Introduction

Introduction

Increasingly, software applications are built using web technologies and made accessible via web browsers (e.g., Internet Explorer, Firefox, Safari, and Opera). They are commonly referred to as web applications, or hosted applications—applications based on a software as a service (SaaS) model, 1 or cloud computing. 2 These web applications are different from more traditional web sites in that their emphasis is on allowing users to accomplish tasks such as send email, make travel reservations, find homes, pay bills, transfer money, buy products, send invitations, and so forth (Figure 1.1, Figure 1.2, Figure 1.3 and Figure 1.4). Web sites, on the other hand, are content oriented and are designed to facilitate browsing and consumption of rather static information (Figure 1.5).
1SaaS is a software application delivery model where a software vendor develops a Web-native software application and hosts and operates it (either independently or through a third party) for use by customers over the Internet. Customers do not pay for owning the software; they subscribe to it and pay a regular subscription fee for using it.
2Web applications are considered to be a form of “cloud computing” because applications and files are hosted in the Internet “cloud,” which consists of thousands of computers and servers, all linked together and made accessible via the Internet.
B9780123742650000013/gr1.jpg is missing
Figure 1.1
Users can manage their email via the Web, as in this example from Yahoo! Mail, which is similar to its desktop counterparts such as Microsoft Outlook, Mozilla Thunderbird, and Eudora.
B9780123742650000013/gr2.jpg is missing
Figure 1.2
Users can search for travel options and make reservations using web applications like Expedia.
B9780123742650000013/gr3.jpg is missing
Figure 1.3
Users can find homes for sale, assess the value of a home, and see recent sales of homes in a neighborhood on sites such as Zillow.com.
B9780123742650000013/gr4.jpg is missing
Figure 1.4
Users can buy products on sites like Buy.com.
B9780123742650000013/gr5.jpg is missing
Figure 1.5
Ultragrain allows users to access static information about the company and its products on its web site (www.ultragram.com).

Benefits of Web Applications

The trend in favor of web applications is understandable in view of the benefits these applications offer, as described in the following sections (Baxley, 2003; Turnbull, 2006).

Ease of access

Typically, the only software users need to access and use web applications is a browser such as Internet Explorer, Firefox, Safari, and Opera. Users do not need to download and install separate software to use different web applications, although there are instances when they have to download helper applications or plug-in modules, such as Adobe Flash, Java, Microsoft Silverlight, and so forth, to access all or part of a web application.
Moreover, because both the application and information are stored on servers of the application's providers and not on users’ computers, users can access web applications from almost anywhere, as long as the computer they use has a web browser and Internet connectivity. This remote data storage also facilitates sharing and collaboration among users; for example, users can share bookmarks with applications such as Delicious (www.delicious.com) and Furl (www.furl.net), and remotely collaborate on the same documents using productivity applications such as Google Docs and Spreadsheets (docs.google.com) and Zoho (www.zoho.com).

Ease of deployment

Web applications are also popular with businesses and software developers because they can be developed, updated, and maintained remotely without requiring users to install (or reinstall) them. A related advantage of web applications is that they can perform as specified regardless of the operating system on users’ computers. They can be built once and deployed to almost any user, rather than creating separate versions of applications for Microsoft Windows, Macintosh OS X, GNU/Linux, and other operating systems.

“Trained” user base

The Web's growth and widespread adoption (from 16 million users in December 1995 to almost 1.5 billion users in June 2008, according to Internet World Stats; www.internetworldstats.com) has made the Web style of interaction familiar to a large number of users. Most Internet users can now be expected to be familiar with web browser terminology such as home, back, forward, bookmarks, hypertext links, submit buttons, and so forth. With this knowledge, and the fact that using web applications does not require elaborate installations, barriers to their use (or at least to try them out) are much lower. Further, it helps that many popular web applications are now available for free or have a free trial period.

Maturity and reliability of network connectivity and web technologies

An important roadblock for earlier web applications was unreliable network connectivity and significantly inconsistent web standards support—that is, HTML, CSS, and JavaScript—in web browsers. This is no longer the case. Adherence to web standards is improving, and browser inconsistencies that used to cause frustration for web developers are decreasing. In addition, network connectivity and broadband access is becoming more reliable, more ubiquitous, and cheaper to use. According to Website Optimization the use of broadband Internet access grew to 57 percent in US homes in March 2008 and was 90 percent among active Internet users (www.websiteoptimization.com/bw/0807/). This stable platform has also spawned the availability of visual development tools and frameworks to facilitate web application development.

Challenges to Designing Interfaces for Web Applications

Despite these benefits and increasing use, designing interfaces for web applications remains difficult. Challenges in creating usable interactions are mainly related to the underlying “loosely coupled” web architecture, a limited set of interactive controls natively supported in web browsers, and the lack of design guidance as to how user interactions should be implemented.

“Loosely coupled” web architecture

An important challenge faced by web application designers is caused by the “loosely coupled” or “stateless” nature of the Web. The Web's interaction paradigm is very simple: Users request web pages with web browsers, and servers respond by sending the requested pages to the browsers or informing users if there are problems retrieving those pages. However, once a user's request is satisfied by the web server, by sending the web page to the browser, the connection between the web server and the web browser is severed. When a user makes a subsequent request, the connection is established again with the server until the new web page is “reloaded” in the user's browser.
Each page reload, or page refresh, is marked by perceptible delays caused by the need to establish the connection, the server to respond to the request, the network to receive the page, and the browser to reload the page. This creates a jumpy and discontinuous experience for web application users. For example, a user browsing a hierarchical tree structure of items may have to wait after every click to expand, or collapse, a data node for the page to reload and see the expanded, or collapsed, view. Although this problem is addressed to a great extent by the use of scripting technologies such as JavaScript and Rich Internet Applications (see Chapter 8), it's an important user experience issue faced by most web applications.

Limited set of controls, or widgets, to support application design

In the current version of HTML (version 4.01), native support for controls is limited to text boxes, radio buttons, checkboxes, dropdown lists, and command or action buttons. It does not offer support for sophisticated interactions common in desktop applications such as spin controls, calendars, wizards, tabs, toolbars, drag-and-drop, floating palettes, dialog boxes, context-sensitive menus, and so forth, which are available in even basic desktop applications. Although such controls can be developed using JavaScript and Cascading Style Sheets (CSS), a lack of inherent support for them has led to a variety of implementations with inconsistent presentations and interactions.

Inconsistent interaction approaches

Both the underlying technological architecture of the Web and the limited set of controls available make it difficult to create interactions for web applications comparable to desktop applications. Additionally, because most web applications are designed to be browser-agnostic, interactions and appearance cannot be simulated to match all operating systems; for example, tabs in the Macintosh OS X Aqua interface are visually quite different than the tabs in the Windows Vista interface (Figure 1.6).
B9780123742650000013/gr6a.jpg is missing
B9780123742650000013/gr6b.jpg is missing
Figure 1.6
Tab controls in the Macintosh OS X Aqua interface (a) and Windows Vista interface (b).
Although the Web's relatively unrestricted development environment offers considerable creativity and flexibility to designers, the resulting diversity and inconsistency in user interfaces and interaction approaches in web applications is often challenging for users. This is due to the fact that users are faced with a variety of styles of interfaces and interactions, each with its own vocabulary of objects, actions, and visuals mixed together in the same application (see Tidwell, 2006). Figure 1.7 shows an example of changing the tab name in Zoho Notes (a note-taking web application like Microsoft OneNote) and Zoho Sheet (a worksheet web application like Microsoft Excel). To change the tab name in Zoho Notes, users must double-click the tab name and a Rename dialog pops up. In order to change the tab name in Zoho Sheet, users must right-click the tab and select the “Rename” option, which displays a pop-up window to allow users to change the tab name; double-clicking just selects the text.
B9780123742650000013/gr7a.jpg is missing
B9780123742650000013/gr7b.jpg is missing
Figure 1.7
Two different interaction approaches for changing the tab name in Zoho Notes (a) and Zoho Sheet (b).
Note
The next version of HTML (version 5) will support additional form elements that are currently part of the World Wide Web Consortium's (W3C) Web Forms 2.0 (www.w3.org/TR/web-forms-2/). This new version offers additional form controls (e.g., the <datalist> element to create combo-boxes and the <output> element to show values derived from other form controls) as well as an extension to existing form controls (e.g., <input type="date" />, <input type="email" />, etc.), which makes web application development a little easier. Opera (version 9 and above) currently supports Web Forms 2.0 enhancements and offers a good platform to develop interactive prototypes.
To address these design challenges and accompanying usability problems, many corporations develop user interface design guidelines and style guides to manage the web application's “look and feel.”
Applying design guidelines to develop usable web applications is not easy, however. Design guidelines are limited in their effectiveness, as they often advocate high-level principles (e.g., make system status visible; recognition is better than recall; prevent errors) or offer very specific guidance (e.g., align table headings to match the alignment of column data). On the other hand, design style guides focus on branding and visual design aspects and are usually specific to a platform (e.g., Macintosh OS X Aqua and Windows Vista) or to applications developed by a specific corporation (e.g., “Oracle Browser Look and Feel [BLAF] Guidelines,” 2004), and do not necessarily provide detailed guidance for developing usable interactions.
Design guidelines and style guides are also quite lengthy and difficult to follow, because implementing one interaction requires user interface designers to be familiar with several sections within the document. For example, Apple's “Human Interface Guidelines” document is about 400 pages long, and to create a dialog with form controls, a designer would have to be familiar with several sections within “Part III: The Aqua Interface” (Figure 1.8), which has about 250 pages allocated to it.
B9780123742650000013/gr8.jpg is missing
Figure 1.8
“Part III: The Aqua Interface” section of Apple's “Human Interface Guidelines” comprises about 250 out of the document's 400 pages.
Finally, design guidelines and style guides can also become too esoteric to be useful to those not familiar with human–computer interaction. This can limit their effectiveness as a means of communication among web application development team members, including customers, subject matter experts, clients, requirement analysts, software developers, product managers, and marketers, who are unlikely to be well-versed in human–computer interaction and usability.
Using design patterns addresses many of these concerns and can complement design guidelines and style guides to create better, and consistent, interface designs and improve usability of web applications.

Design Patterns

The notion of patterns was introduced in the field of architecture by Christopher Alexander and his colleagues in A Pattern Language (Alexander et al., 1977) and The Timeless Way of Building (Alexander, 1979). They explained the nature of patterns as follows:
Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. (Alexander et al., 1977, p. x)
Thus, patterns explicitly focus on the problem within the context of use and guide designers on when, how, and why the solution can be applied. Patterns are practical and describe instances of “good” design while embodying high-level principles and strategies.
Patterns have recently become attractive to user interface and software designers3 as well for their following benefits:
3Inspired by Alexander's work in the field of architecture, the concept of patterns was applied and became popular in the field of software after the publication of Design Patterns: Elements of Reusable Object-Oriented Software (1994) by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (commonly referred to as the Gang of Four or simply GoF). Subsequently, patterns also became popular in the field of human–computer interaction from the works of Tidwell (www.designinginterfaces.com), Welie (www.welie.com), Borchers (2001), Graham (2003) and Van Duyne et al. (2002, 2006).
Proven design solutions and guidance for their use. Patterns identify real solutions and not abstract principles or guidelines. In addition, by making the context and problem explicit and summarizing the rationale for their effectiveness, patterns explain both how a problem can be solved and why the solution is appropriate for a particular context. However, because it's a generic “core” solution, its use can vary from one implementation to another without making it look “cookie-cutter” or discouraging creativity.
Improved design process. Identifying design patterns and cataloging them can help user interface designers increase productivity by reducing time spent “reinventing the wheel.” Furthermore, if user interface components are built for patterns in the form of a design pattern library (see Chapter 13), designs can be developed, tested, and iterated rapidly, and can help shorten release cycles.
Reusability and consistent interfaces. Developing a library of reusable user interface components can also facilitate development of consistent interfaces both within and across applications. This is particularly useful in large corporations with multiple and distributed design teams, where different solutions may be applied for the same problems by different design groups, leading to inconsistent interfaces among designs produced within the same company. By cataloging and communicating design patterns, teams can increase consistency, predictability, and usability of their designs (Leacock et al., 2005) and can serve as a corporate memory of design expertise (Borchers, 2001).
A common, shared language. Patterns help support and improve communication among team members from diverse disciplines by developing a common language or vocabulary when explaining and discussing the design solutions (Borchers, 2001; Erickson, 2000). This is very important because user interface designers often work in an interdisciplinary team with developers, application domain experts, and users or user representatives, and these groups typically lack a common terminology to exchange design ideas and opinions.
Effective teaching aid and reference tool. Patterns also can be an effective way for experienced designers to offer design guidance to those without a formal background in design (Chen, 2003). Because of the approach used in documenting patterns, by providing visual and textual description, it is easier for novice interface designers to see examples of their successful usage.
Usable web applications. Finally, because patterns are based on a history of successful usage, their use can make the web application usable because interactions afforded by patterns would be familiar to users.

Documenting Patterns

It's important that patterns are documented to convey what they are, why they work, and how they should be applied to solve a design problem to reap the aforementioned benefits. Interestingly, however, there is no “pattern” for documenting patterns (see Chapter 13). Pattern authors have used a range of approaches, from those following a more descriptive Alexandrian notation (Borchers, 2001; Graham, 2003; van Duyne et al., 2002, 2006) to those following a more structured, albeit casual and minimalist, approach (Laasko, 2003; Tidwell, 2006; www.welie.com). 4
4To bring order to the varied and inconsistent forms pattern authors have used and to find a way to combine patterns and pattern languages from different authors into specific, thematic pattern collections, participants at the CHI 2003 (April 6–7) Workshop Perspectives on HCI Patterns: Concepts and Tools proposed an XML-based markup language called Pattern Language Markup Language (PLML; pronounced “Pell-Mell”). For more information, see Fincher (2003).
In this book, patterns are presented using a rather minimalist approach. Specifically, each pattern includes:
Pattern name. A short title describing the design solution. Following the convention used in other pattern collections, pattern names are written in CAPITAL LETTERS to make them stand out from the rest of the text.
Problem. A brief description of the design problem(s) the pattern solves and accompanying design challenges and trade-offs (referred to as “forces” by Alexander et al., 1977) faced by user interface designers.
Solution. The core design solution to the problem. This is a brief statement about the solution (i.e., the pattern) accompanied by an example (i.e., a sensitizing image) illustrating its use in a web application.
Why. Rationale for the design solution's effectiveness.
How. A list of best practices describing the application of the solution and possible variations. One or more illustrative examples are included for each variation to demonstrate how the pattern can be applied effectively in a variety of situations.
Related design patterns. Because it's so often the case that several patterns are used together to create a usable design solution, this section identifies related patterns that designers may want to consider either because they are used together or are relevant for the use of the given pattern.

Organization of the Patterns in this Book

The patterns in this book are organized by chapter, as follows.
Chapter 2: Forms. Forms are a distinguishing characteristic of web applications. It is through form elements such as text boxes, dropdown menus, radio buttons, checkboxes, and others that users provide information and interact with web applications. This chapter discusses patterns related to designing forms for web applications, to ensure that filling out forms is not cumbersome and that they help users accomplish their goals, including CLEAR BENEFITS, SHORT FORMS, LOGICAL GROUPING, LABEL ALIGNMENT, REQUIRED FIELD INDICATORS, SMART DEFAULTS, FORGIVING FORMAT, KEYBOARD NAVIGATION, INPUT HINTS/PROMPTS, ACTION BUTTONS, and ERROR MESSAGES.
Chapter 3: User Authentication. Web applications enable one-to-one interaction with users and store user-specific information. This requires that users create an account and access it using a unique set of credentials. This chapter describes design patterns related to accessing and exiting web applications, including REGISTRATION, CAPTCHA, LOG IN, LOG OUT, AUTOMATIC LOGOUT, and FORGOT USERNAME/PASSWORD.
Chapter 4: Application Main Page. Once users have logged in to the application, an important question for designers is what users should see or which page they should be taken to. This chapter discusses design patterns designers should consider as they take users to that “main” application page, including INBOX, CONTROL PANEL, DASHBOARD, PORTAL, PERSONLIZATION, CUSTOMIZATION, and BLANK SLATE.
Chapter 5: Navigation. Navigation is how users experience web applications. When designed effectively, navigation becomes transparent and users are able to accomplish goals quickly and without unnecessary backtracking. This chapter focuses on design patterns for navigation systems, including PRIMARY NAVIGATION, SECONDARY NAVIGATION, UTILITY NAVIGA-TION, FACETED NAVIGATION, SUPPLEMENTARY NAVIGATION, TAG CLOUDS, BREADCRUMBS, and WIZARD.
Chapter 6: Searching and Filtering. For most web applications, accessing information using only navigation systems can become cumbersome and compromise usability. Therefore, information within web applications is made searchable to get users to their desired items quickly and efficiently. Unless search terms are very specific, users are likely to be faced with a large number of results. Designers must offer users options to narrow down such a result list to a manageable set of choices by providing filtering mechanisms. This chapter discusses design patterns related to searching and filtering in web applications, including SIMPLE SEARCH, PARAMETRIC SEARCH, ADVANCED SEARCH, SEARCH TIPS, SEARCH RESULTS, SORTING, PAGINATION, CONTINUOUS SCROLLING, FILTERING, FACETED SEARCH, and SAVED SEARCHES.
Chapter 7: Lists. Lists are used to present a collection of items to users. Depending on the nature of items in the collection, the presentation approach varies. This chapter discusses design patterns for different types of lists, including SIMPLE LIST, TABULAR LIST, HIERARCHICAL LIST, EVENT LIST, TIMELINES, IMAGE LIST/GRID, MAPS, LIST ACTIONS, and LIST UTILITY FUNCTIONS.
Chapter 8: Rich Internet Applications. Rich Internet Applications (RIAs) can deliver responsiveness and interactivity comparable to desktop applications because users need not wait for pages to refresh for basic data and layouts to update; therefore, their actions' results can be seen immediately. This chapter discusses commonly used RIA design patterns, including RICH-TEXT EDITOR, RICH FORM, AUTOSUGGEST/AUTOCOMPLETION, EDIT-IN-PLACE, OVERVIEW-PLUS-DETAIL, DYNAMIC QUERYING, LIVE PREVIEW, DRAG-AND-DROP, SLIDER, ANIMATIONS/TRANSITIONS, DELAY/PROGRESS INDICATOR, SPOTLIGHT/YELLOW-FADE, and CAROUSEL.
Chapter 9: Social Applications. A recent trend in web applications is the development of social applications, which not only encourage users to contribute and share content (e.g., photos, videos, bookmarks, and so forth), but also promote interaction and help build communities. This chapter describes design patterns that have emerged from such social applications, including ADD/UPLOAD CONTENT, TAGGING, RATING, REVIEWS, VOTE TO PROMOTE, USER PROFILE, REPUTATION, DISCOVER NETWORK MEMBERS, FRIEND LIST, GROUPS/SPECIAL INTEREST COMMUNITY, MESSAGING, PRESENCE INDICATOR, SHARING, and COLLABORATION.
Chapter 10: Internationalization. Internationalizing web applications is an important step toward localization—that is, adapting them to a specific region or language. It helps reduce the effort required for localization later and eliminates the need to develop region- and language-specific versions of applications. This chapter discusses design patterns that help incorporate necessary flexibility and adaptability in web applications during initial design stages, including EXTENSIBLE DESIGN, DATE FORMAT, TIME FORMAT, NUMBER FORMAT, CURRENCY AND CURRENCY FORMAT, GLOBAL GATEWAY, and LANGUAGE SELECTOR.
Chapter 11: Accessibility. Design patterns that are discussed in this chapter help make web applications accessible and support recommendations and regulations for web accessibility, such as W3C's Web Content Accessibility Guidelines and Section 508 of the Rehabilitation Act; they include PROGRESSIVE ENHANCEMENT, SEMANTIC STRUCTURE, UNOBTRUSIVE STYLE SHEETS, UNOBTRUSIVE JAVASCRIPT, ACCESSIBLE FORMS, ACCESSIBLE IMAGES, ACCESSIBLE TABLES, ACCESSIBLE NAVIGATION, and ACCESSIBLE ALTERNATIVE.
Chapter 12: Visual Design. The visual design of web applications plays an important role in how usable an application is perceived and how credible it is considered by its users. In this chapter the emphasis is on design patterns that influence the overall look and feel of web applications, including LIQUID-WIDTH LAYOUT, FIXED-WIDTH LAYOUT, PROGRESSIVE LAYOUT, GRID STRUCTURE, VISUAL HIERARCHY, HIGHLIGHT, and ICONS.
Chapter 13: Pattern Libraries. Despite the popularity of patterns and pattern libraries, currently there is no consensus of how patterns should be documented, maintained, and shared with others. Therefore, this chapter presents a pattern library as a pattern and identifies its core elements, as well as offers best practices for its development.
Web Appendix: Help. Despite adherence to basic design principles, processes, and patterns that create an interface that users can learn easily and use efficiently, it is necessary to provide help and make it available at all levels of user interaction. The appendix, posted at www.elsevierdirect.com/9780123742650, lists design patterns related to providing help in web applications, including CONTEXTUAL HELP, FREQUENTLY ASKED QUESTIONS, APPLICATION HELP, GUIDED TOURS, HELP WIZARDS, HELP COMMUNITY, and CLICK-TO-CHAT.
Note
This book includes many web application screenshots taken over a period of nine months. Although a majority of them were valid as of November 2008, a few may have changed after this book went to press. This is expected, since companies building web applications change features, introduce new services, and discontinue older interfaces.

Using Patterns in this Book

This book provides practical user interface design guidance for developing web applications by offering a usable “working” starting point that designers can adapt and refine to develop creative solutions.
Consider patterns in this book as blueprints and not precise design solutions, and use them as they apply to your specific problem. Do not force a pattern to a problem just for the sake of using it! As pointed out by Graham (2003): “Patterns are abstract, core solutions to problems that recur in different contexts.… The actual implementation of the solution varies with each application. Patterns are not, therefore, ready-made ‘pluggable’ solutions” (p. 1). So, focus on the essence of a pattern and then consider how a problem might be solved with the pattern, as patterns do not dictate a single solution, but rather a strategy for solving the problem.

Companion Web Site

All the patterns in this book are also available on the book's companion web site (www.elsevierdirect.com/9780123742650). I will also use that site to list errata and additional information (and, perhaps more patterns) and use it as a way to answer your questions and respond to your comments.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.118.210.133