Web Sites versus Web Applications

Web browsers were originally conceived of as a means of sharing and linking documents without the need for cumbersome protocols and file transfer tools such as FTP, Gopher, and Archie. Few people anticipated the popularity of the Web — at initially, for both personal communication and community-building and, a bit later, for commercial communication and services. Thus Web protocols have grown from rather humble beginnings, and the relatively low level of interactivity supported by both browsers and these protocols is an artifact of the limited original purposes for which the Web was conceived.

Web sites

In this chapter, we refer to Web sites as information-centric services on the Web whose level of interaction primarily involves searching and following links. Most Web sites consist either of static pages or of complete articles or documents served up by a database. Web sites, as described, can easily be conceived of as sets of pages or documents organized sequentially, hierarchically, or in some other directed graph, with a navigation model to take users from one page to another, as well as a search facility to provide more goal-directed location of specific documents. Plenty of Web sites exist out there, in the form of personal sites, corporate marketing and support sites, and information-centric intranets. In Web sites, the dominant design concerns are the content, the organization (information hierarchy), and clarity. The behavior consists of little more than a coherent navigational schema (not to make light of this; getting navigation right is critical for Web site ease of use) and proper use of affordance and idiom to telegraph to users which elements are active.

Web applications

Web applications, on the other hand, are heavily transactional in nature. Most (if not all) screens are served up dynamically, and different information and forms appearing on the screen simultaneously may come from several different databases. Some regions of the screen may also be occupied by applets delivering data in real time, or allowing real-time manipulation of data on the client side. Web applications may live inside a browser, or they may run as standalone applications. Because the nature of Web applications is transactional, behavior rather than content becomes the primary concern. This said, the two must actually be considered hand-in-hand, because for most Web applications — e-commerce sites like Amazon.com, for example — the content drives the transaction. However, as we have seen with many e-commerce applications, even if the content (the merchandise) is presented well and there is a demand for it, if the transaction remains difficult, unsatisfying, or worrisome, users will abandon their efforts. The world of e-commerce is full of shopping carts abandoned by potential customers as soon as they saw the 800-pound gorilla at the checkout counter.

Web applications exist in many other domains than e-commerce. Enterprise resource planning and customer-relationship management systems like those offered by SAP, Oracle, and Siebel have moved to Web platforms in recent years. Many financial planning, online banking, and personal information management systems are available in Web version, their advantage being that they are accessible to users from any computer (or even PDA) with an Internet connection.

Enterprise and other specialized Web applications can be presented to users like desktop applications that happen to run inside a browser window, with little penalty as long as the interactions are carefully designed to reflect engineering constraints. For the time being, commerce sites located on the Internet must more closely resemble traditional Web sites because some portions of these sites may well consist of mostly static, informational pages.

TRANSIENT POSTURE WEB APPLICATIONS

Web applications, much like desktop applications, can have sovereign or transient posture. Transient posture Web applications typically take the form of interactive applets embedded inside of standard HTML Web pages. A good example of such a transient Web application is MSN Money Deluxe Portfolio Manager, an interactive stock-tracking tool available on Microsoft's MSN Web site. Transient Web applications are most often utilities, used occasionally to frequently, but which are not sovereign applications that users spend hours at a time in front of. Transient Web applications should follow the same guidelines as transient desktop applications (see Chapter 8), as well as these additional guidelines:

• Transient Web applications should clearly telegraph their functionality. Because users of Web sites are accustomed to limited interactivity, and transient Web applications are embedded in such a context, take extra care needs to make affordances obvious and to supply hints, if necessary, in the form of brief instructions designed integrally into the application.

• Transient Web applications must be simple, direct, and to the point. Transient, embedded Web applications are no place to allow scope creep. Make sure that your utility is doing only the minimum necessary to successfully meet user goals.

• Transient Web applications should fit into the user's mental models and flow in the context of the rest of the Web site. You should develop your transient application paying close attention to user mental models and workflow, not only in the context of their domain, but also in the context of Web site use. If your application can't be implemented in line with other content, don't make the link to your utility seem like an advertisement. Users are conditioned to ignore anything resembling a banner or inline ad, especially animations.

• Carefully consider the problem of access to user data. Because most transient Web applications can't, for technical reasons, save user data at the client side, users may need to sign in to retrieve or manipulate their data. Similarly, you must ask users to manually save data they have entered. These operations should be presented as seamlessly and straightforwardly as possible.

E-COMMERCE WEB APPLICATIONS

E-commerce represents a special case when considering transactional site posture. The use of e-commerce sites is definitely a transient activity for most users; they come to the site, do a widely variable amount of research (depending on the individual and context) on purchase items, and then either purchase or leave empty-handed, not returning for days. E-commerce sites are interesting because they combine the informational elements of a Web site (in the form of an online catalog) with the elements of a business transaction. In many cases, the Web site is also taking the place of a human sales clerk, with all the implications of brand identity and the value proposition surrounding customer service that this might entail. E-commerce transactions must be carefully designed because users can easily be dissuaded from an online purchase if the process is the least bit onerous or confusing.

E-commerce sites such as Amazon.com have incorporated many application-like features into their sites, while retaining a standard Web-page appearance. Some of these features include providing links to recently viewed items in a session and a semi-persistent shopping cart showing subtotals (but unfortunately, no estimated tax/shipping charges yet). These types of features, which capture and reflect the user's context, and thus ease and enrich the online-shopping experience, provide compelling reasons for users to return for future purchases.

The bottom line for an e-commerce site is its checkout process, which is (not coincidentally) the same part of the site that ends up frustrating and confusing the largest percentage of users. Designers should make use of principles of transient application posture when creating checkout interfaces. Simple input, clear affordances and instructions, clear visual feedback, an obvious flow from start to finish of the process, and a clear means for the user to correct mistakes are all critical to the success of e-commerce transactions and user satisfaction.

SOVEREIGN POSTURE WEB APPLICATIONS

Sovereign posture Web applications should and do strive to be nearly indistinguishable from their desktop cousins. A good example of such a Web application is the Microsoft's Outlook Web Access (OWA) client, which seeks to replicate as much as possible the look and feel of the desktop version, but from inside the browser. As Figure 37-1 shows, OWA replicates most of Outlook's interface within the constraints of browser technology and dial-up bandwidth constraints.

Figure 37-1: Microsoft Outlook Web Access, a good example of a sovereign Web application running in a browser. In the case of OWA, use of a browser as a container makes perfect sense because the purpose of the product is to allow access to Outlook from a computer with an Internet connection. Enterprise applications for which this need is not important or practical for users may consider using Internet-enabled technologies outside the browser. These might better support the rich interactivity and client-side processing and storage that are difficult or impossible to support with browser-based applications. Designers of browser-based sovereign Web applications should also consider hiding the standard browser controls. Use of the browser's Back and Forward buttons can produce unpredictable results in Web applications, and eliminating them from the user's view helps reinforce the mental model of an application versus a Web page. Creating a link on the user's desktop or the browser's Links toolbar can help solve the problem of initial access.

Unlike the design of page-oriented Web sites, the design of sovereign Web applications is best approached as if these applications are desktop applications. Designers also need a clear understanding of the technical limitations of the medium and what can reasonably be accomplished on time and budget by the development organization. Like sovereign desktop applications, sovereign Web applications should be full-screen applications, densely populated with controls and data objects, and they should make use of specialized panes or other screen regions to group-related functions and objects. Users should have the feeling that they are in an environment, not that they are navigating from page to page or place to place. Redrawing and re-rendering of information should be minimized (as opposed to the behavior on Web sites, where almost any action requires a full redraw).

The benefit of treating sovereign Web applications as desktop applications rather than as collections of Web pages is that it allows designers to break out of the constraints of page-oriented models of browser interaction to better address the complex behaviors that these client-server applications require. Web sites are effective places to get information you need, just as elevators are effective places to get to a particular floor in a building. But you don't try to do actual work in elevators; similarly, users are not served by forcing them to attempt to do real, transactional work using page-based Web sites accessed through a browser.

BROWSER-BASED VERSUS INTERNET-ENABLED APPLICATIONS

There are two possible approaches to creating sovereign Web applications. The first is to create a browser-based application that, in essence, takes over the browser window, hiding all browser controls and providing rich interaction within the browser-content area. The technologies used in the window can be a combination of HTML, DHTML, JavaScript, Flash, and Java applets, as best fits the circumstance. This approach gets you some layout and rendering for free, but also constrains the interaction to what is supported by the browser. It also creates compatibility headaches if multiple browser platforms need to be supported because each browser has its individual quirks that must be taken into account. This makes a lowest-common–denominator approach a tempting engineering solution, even if it isn't a good solution from the user's perspective. (This lowest-common–denominator approach is not always necessary, as we will discuss later.) Browser-based applications also encourage the idea of limiting the interface to a single primary window because browsers lack any real support for independent child windows (such as modeless dialogs).

The second approach for sovereign Web applications is to abandon the browser entirely and, instead, create a non-browser–based, Internet-enabled application. An Internet-enabled application is a desktop application that is Web-aware and makes use of technologies like Flash, Java, ActiveX, TCP/IP, or Microsoft .Net, along with or in place of traditional desktop GUI libraries. By taking the application outside the browser, you can provide rich, clean, sophisticated interactions without losing the ability to access data on the Web. You can improve interactions, not only by more robust GUI support and lack of collision with browser controls, but also because Internet-enabled applications are not restricted to the thin-client model of the browser. The client can save program state and data in volume, allowing the program to remember and react to user actions, store frequently used information, and provide all the other interaction benefits of sovereign desktop applications.

Not sure which approach to take? Here are some pointers:

• If access from any computer (with an Internet connection) is a feature required by your personas, a browser-based application is appropriate.

• If your customers are standardized on a specific browser (especially IE 5 or greater) and/or plug-in, it becomes much easier to create a rich experience with a browser-based application.

• Often the chief reason for considering a browser-based approach is ease of installation and maintenance. However, Internet-enabled applications (Microsoft Windows XP and RealNetworks' RealOne Player are two examples) are perfectly capable of updating themselves over the Web. The key is in designing this process to be as transparent as possible to the user.

• Browser-based applications are not easily capable of automatically saving data, or storing data on the client system. If your application's design demands these behaviors, an Internet-enabled desktop application is preferable. Supporting local data storage also means that servers are hit less often, improving application response time considerably.

• Personas and scenarios are key techniques that help push the boundaries of the constraints imposed by Web technology. By modeling your users and stepping them through their work contexts to determine their needs, you gain greater insight into which technical approach best suits your users' and your customers' situations.

INTRANETS, EXTRANETS, AND THE INTERNET

As discussed in Chapter 8, the appropriate behavior of Web sites and applications is heavily dependent on the context of their use. One primary factor that influences this context is whether the site is designed for consumer Internet use or for use within the enterprise.

As mentioned earlier in this chapter, informational and e-commerce sites need to maintain a design that balances sovereign and transient elements. These sites should display information at a density appropriate to a sovereign application. The primary navigational elements and transactional elements, however, should maintain the simplicity and clarity of a transient application that is infrequently used and whose behaviors and controls the user does not necessarily remember from session to session.

On the other hand, enterprise-oriented software that accesses corporate intranet or e-business information and transactions can take a more definitely sovereign posture. Users of these applications are likely to be frequent and long-term users who quickly become perpetual intermediates. Information and function density can be increased to better make use of full-screen real estate. If the enterprise in question standardizes on browser or other Internet-enabled application technologies, it can better take advantage of rich, visual, modeless feedback and other GUI idioms.

One exception to this rosy interaction picture is extranet design: Because it is more difficult to anticipate the configuration of your customers' customers, design of extranets must either resort to an Internet-style design approach or a full Internet-enabled application approach that skirts the issue of browser compatibility entirely. Because many customers have been taught that browser-based access is desirable (which, as we discussed, is true only in some circumstances), the latter can be, at least for now, a tough sell.

Here are a few further design tips that will help you to create satisfying Web applications for intranets, extranets, and the Internet:

• Internet Web sites and applications must almost always serve multiple primary personas, which typically fall into two categories: people who are regular visitors and people who are new or one-time visitors. Hence, there is always a tension between sovereign and transient posture in sites and applications created for broad Internet access. The balance depends on the precise domain and context of the service. It can be established through the research and modeling techniques outlined in Part I. Clear, consistent navigation and well-designed search help considerably.

• Because browser-based applications require hits to the server to load data, try to design your application to download related data in batch when the user selects some portion of it. You must be careful to balance the tension between optimizing the amount of data downloaded at a time and the response time of the system during the batch downloads. Testing will likely be required to determine the size of an acceptable (from a response-time standpoint) chunk of data.

• Be careful to use language on the site that matches user mental models, not implementation models or hackneyed language from the old days of the Web. Buttons with titles like Submit are not only demeaning, they are also not informative.

• When designing for browsers, be aware that users will often have multiple browser windows open at a time. Try to keep all the interaction limited to a single window.

• Because you can't guarantee (server side) automatic save of data in browser-based applications, you need to have users do so manually. The more your application resembles a desktop application, the more awkward this may seem to users. Therefore, you must try to smoothly integrate such manual saves into the flow of the application in a way that is not at odds with user mental models.

WEB APPLICATIONS AND VISUAL DESIGN

Because of the Web's history, in which many commercial Web sites began as marketing vehicles, a high value is placed on the messaging component of the Web. For Web applications, however, this market messaging needs to be executed primarily through the interaction and behavior of the system, which should reflect the brand value. There may be a temptation to use rich visuals in Web applications, but for the most part this results in slower load times and distraction from the real purpose of the application: to meet end goals of the users. Clean, simple color palettes and clear typography are much more important than visual sizzle in Web applications. Fancy graphics are not only distracting, but users have been well trained to ignore anything that seems like an advertisement or marketing ploy on the Web.

During the course of the design process, interaction designers and visual designers need to collaborate closely to effectively communicate the behavior and function of Web sites and Web applications using visual language that works within the context of the brand. Similarly, information architects and designers need to collaborate closely with interaction designers to match content with behavior.

IT TAKES BOTH DESIGN AND ENGINEERING EFFORT

One final caveat is in order before your organization embarks on a Web application: To successfully execute a sovereign Web application requires seasoned, professional programmers and software engineers — at both the front end and the back end — who can not only tackle the engineering issues with aplomb, but who also understand and support a rigorous design and engineering process. Web sites can be built quickly and relatively simply; Web and Internet-enabled applications require great attention to software architecture, as well as information architecture and interaction design. Be wary of any haphazard attempts to design or engineer a complex Web application. Doing so is asking for trouble, just as it would be for any other kind of software application.

Although Web applications are far more complex both interaction-wise and engineering-wise than page-oriented Web sites, the value they bring to users trying to do real work on the Web or through the Internet is worth the sweat. Web applications and Web services, powered by technologies like .NET, are the future of the Web. As with any complex software, the risks are considerable; but methods and principles of interaction design that are well planned and executed mitigate that risk and provide users with a higher level of online experience.