What Is a Web Application?
This chapter attempts to answer two questions:
What’s the Difference Between a Web Page and a Web Application?
Are any of these web sites “web applications”?
• Information-only web sites such as “Conference Presentation Judo” (Figure 1-1). (No, but it’s still very good.)
FIGURE 1-1 Is this an application?1
• A fill-in form such as the one on ehealthinsurance.com (Figure 1-2). (Maybe.)
FIGURE 1-2 How about this?2
• A web applet such as the Morningstar stock comparison tool (Figure 1-3). (Maybe.)
FIGURE 1-3 Maybe this?3
• A back-end mortgage lending application such as Palisades Technology Partners’ Eclipse (Figure 1-4), accessed via an intranet or extranet rather than the Internet or the company network. (Definitely.)
FIGURE 1-4 This definitely is.4
• An add-on, cross-branded miniapplication embedded in a web site. “Cross-branding” occurs when one site uses an application from another company to fill a specialized niche—for example, bill paying is handle
by PayPal on eBay; university sites use Google or Yahoo to run their internal searches. (Maybe.)
• A business application such as Dreamweaver that is written in HTML or Java, is installed on a desktop computer, and that looks and acts no differently from an application written in C++. (Definitely.)
To complicate matters, most web sites have multiple subapplications embedded within them. For example, LLBean.com contains search applications, information-only pages, an order form, cross-branding with Park Searchsm, and a credit card application page (Figure 1-5).
Figure 1-5 seems to indicate that a web site can contain many small programs without necessarily being a web application. However, there is an explanation for this paradox in Alan Cooper’s notion of “posture.” These ancillary programs have different postures—daemonic, parasitic, and transient.
Applications that do not normally interact with the user are “daemonic” programs. They serve quietly and invisibly in the background without much need for human intervention. A typical daemonic program would be a process that checks the server every 15 minutes for new alarms or alerts.
Parasitic applications are continuously present but perform only supporting roles. For example, a parasite may monitor the amount of system resources available, put a clock in every program’s caption bar, or show how much memory is free. They are physically small and are superimposed on other applications.
A transient application does only one simple function. It comes when needed, does its job, then leaves, letting the user continue with his or her normal activity. The comparison chart in Figure 1-3 is an example of a transient application. Another transient is the calendar button next to Date of Birth on Figure 1-4.
The fourth type of posture is “sovereign.” Cooper describes a sovereign application as the only one on the screen, monopolizing the user’s attention for long periods of time. Users tend to keep them up and running continously. Figure 1-4 is a good example of a sovereign application (Cooper and Reimann 2003, 103–116).
In general, however, the examples seem to indicate that a web application mostly lets you do and save something, whereas a web page mostly provides information. Applications and pages are similar, however, in that they both are graphical, both show logos and other corporate identity information, and both are information-rich.
So, although the examples point out some similarities and differences between web pages and web applications, the division between the two is still not clear. In an attempt to find a simple answer, here is another question: Can you separate web applications from web sites by the development platform?
What Difference Does the Platform Make?
Java, JavaScript, ActiveX, Flash, and similar development options let developers write programs in more or less traditional ways, and the difference may only be in how the application is delivered—via the web rather than on installation CDs or over the corporate network.
However, if your programs must be written using HTML, DHTML, XML, or other W3C standards, your programming platform will be significantly different from standard client—server and desktop platforms. Here are some of the most irritating differences.
HTML controls aren’t “strong” enough. HTML buttons and boxes are flaky, or they don’t have the flexibility of their Windows, Macintosh, etc.,
counterparts. If they are flexible, they break down on certain browsers or in different versions of the same browser.
There aren’t enough prebuilt controls and code segments. This will come in time, however—when desktop-program developers were first porting applications from DOS to Windows, they had the same problem.
Some of the rules for window design just can’t be followed. The one hard-and-fastrule in window applications is that you use menus for actions on windows and buttons for actions on dialog boxes. This rule is immediately broken in web applications. There are no real menus, just links in frames that mimic menus. Save and Cancel actions are buttons, not menu items.
Another rule in Windows desktop applications is that only windows—no dialog boxes—show up in the task bar. Since the “dialog boxes” that appear on web sites are usually browser windows, this rule is also broken (for the better, in our opinion).
Boundaries between application and web become blurred. If the designers aren’t careful about which browser controls to use and which to replace with application controls, users sometimes look for functionality in the browser menus when they should look instead at the application controls.
Security is more of a concern. Any time that one of your servers is open to the outside, you create a risk that unauthorized people might get into your systems. However, this has been a problem for client—server systems as well.
Damage is a concern. Any time your users are linked to the Internet via email, viruses can get into your computers. Nevertheless, for most organizations, easy access to the World Wide Web and to customers balances the increased risk.
Network failure may be a risk. If your network is incapacitated because of spam attacks, equipment breakdowns, configuration mistakes, or other problems, everyone who uses the application over the web is stopped dead. However, this is a problem for client—server systems as well. The difference is that the clients will be distributed much more widely and the damage, therefore, is distributed more widely as well.
Performance can be slow. Large tables take too long to load, and checking input immediately causes major performance hits. Also, since the programs on the back end don’t know what’s happening on the front end, validation and error checking can be time consuming.
Browser incompatibilities and extensibility issues make it counterproductive to create new controls or to set up special alignments. Things won’t act the same on different browsers or on different versions of the same browser, so the developers are sometimes forced to program for the lowest common denominator.
But there are compensations. Here are two of the most remarkable differences.
Home, Back, Forward, and Favorites are some of the most powerful ideas to come along in decades. They’re so good that developers and designers are retrofitting desktop applications with Back, Forward, Favorites, and other “webbish” ideas. The notion of a “home” page or window is also powerful—having an explicit starting and ending window in any type of application provides a satisfying sense of closure for many users.
The Internet provides a level of collaboration and communication unprecedented in computing history. We can now build email, instant messaging, collaborative editing of documents and presentations, online meetings, and even voice communications into our software. Online collaboration was the original impetus for the Internet, and now we see its fulfillment.
Web applications can provide rich information resources, with links to intranet, extranet, and outside libraries, application help and FAQs, troubleshooting databases, industry best practices, company archives, policies and procedures documents, and whatever anyone can imagine to add to the system. Web applications can provide more inline help or just-in-time help than most desktop applications can; help on the web can be updated at any time, whereas help on desktop applications has to be compiled, attached to, and distributed with the program.
A very useful hybridization is possible. Programs like the RealOne and iTunes players live on the desktop but pick up music and videos from the web. Desktop applications like Quicken and QuickBooks link to their corporate web site to get software updates automatically, and they let users jump into their online credit card accounts and backups on request. Symantec’s Norton AntiVirus regularly downloads new virus definitions to all registered computers.
Log files let you get a sense of who’s accessing your site, what they’re looking for, and even where they’re having problems. Log file analysis isn’t a substitute for quality or usability testing and may be more relevant to web sites than to web applications. However, it will point you to problem spots. For information about how to use log files this way, see Jeff Lash’s “Three Ways to Improve External Search Engine Usability” (2002), Hal Shubin and Erik Bator’s white paper, “Transaction-based Web design: Increasing revenue by using site traffic as a design tool” (2001), and TecEd’s white paper “Assessing Web Site Usability from Server Log Files” (1999).
The web is visual. Although we call our interfaces “graphical,” most GUI software designs don’t take advantage of visual and esthetic form at all. But the Internet is such a visual (and aural and kinesthetic) medium that it has raised the esthetics bar much higher. For this reason, Web Application Design contains much more information about visual forms—graphs, diagrams, maps—than would be typical of any GUI design book.
The browser platform is significantly different from desktop platforms when looked at from a business point of view.
Applications don’t have to be compiled to run. When you use Java, JavaScript, HTML, or XML, you don’t have to compile the code to see if it works. Instead, you just run it—a real boon for those who prefer immediate gratification.
Applications delivered through a browser don’t have to be installed on individual computers. For large corporations with hundreds to thousands of employees, installing and upgrading applications is a very expensive, time-consuming headache.
Applications can be purchased and delivered electronically. Packaging, CD or diskette imprinting, paper documentation, and shipping are expensive. Electrons sent over the Internet are cheap.
Browser-based applications are portable, even mobile. Corporate systems require high levels of security and verification, but the costs can be offset by better access to corporate information and business applications from the road.
The web is international. Instead of being forced to distribute copies of databases throughout the world and then to update all of them each evening, multinational corporations can maintain a single central database.
Users from Australia to Vienna to Canada can inquire, update, and add to the database at any time, from anywhere, over their intranet.
But, as you can see from the discussion above, the development platform doesn’t mark a web site as an application. Nor is there any such thing as “developing in Internet time.” Even Alan Cooper, the inventor of Visual Basic, says so: “HTML allows for fast prototyping …. However, a transactional web application with complex behavior entails the same kind of engineering challenge as the development of native code, and inevitably it needs to be approached using a similarly robust design and development methodology” (2003, p. 481). Development cycles are no shorter for web applications than for desktop applications. Collecting requirements and thinking problems through takes just as long in the web world as in the desktop world.
The Tentative Answer
So here’s the answer to “What is the difference between a web application and a web page?” It’s not that some programs are web applications and some are web pages. It’s a continuum.
User expectations and application purpose are the keys to the design problem. Both usability and technical problems occur when expectations do not match the actual reason for the application. For example, if you design your windows with Fisher-Price colors and spinning globes, users will expect a web page style–Back and Forward button and simple searches.
But if the application is used to enter reinsurance claims, you can have Back and Forward buttons, but you’d better find a way to meet data-integrity requirements—by automatically saving user entries if anyone presses Back or Forward, for example. In this case, it may make more sense to use a web-application style and remove the address bar and the Back and Forward buttons rather than try to capture and redirect those actions.
What is the same is this: It’s not the platform, it’s the activity.
A heavy-duty data-input application is a heavy-duty data-input application no matter what the platform, and should follow production-level data-entry rules. A tool used occasionally should follow the rules for occasionally used tools. Game applications should follow game rules.
Once you know the type of activity, then you can follow the look-and-feel guidelines for that type. For example, if the new web application is a port of a Windows bond-pricing data-entry tool, then follow the Windows style guide as far as you can. If it’s a fun game for teaching bond-pricing algorithms, then follow games rules.
Where Does My Program Fit?
Following is a table of ranges that may help you identify how “webbish” your applications are. Table 1-2 is the overview. Information about the individual ranges or dimensions follows the overview.
You can plot your own applications against the ranges here and in Appendix A, then select the style guidelines most appropriate for your situation.
Since web applications cover a wide range of interaction and visual styles, there can be no one standard web style. Rather, you can reuse existing web and desktop standards as you need them and as they fit the situation.
The table is designed to help you match the purpose of your application to its appropriate look and feel. Sometimes this look and feel will follow web page standards like the ones from Yale University (Lynch and Horton 2002). Sometimes they’ll follow desktop standards like the ones from Microsoft (1999) and Sun Microsystems (1999). Sometimes the look and feel will be a combination of advertising and marketing guidelines with GUI or web guidelines. It depends where on the spectrum between web page and web application the system falls.
Note that this approach goes beyond the platform GUI standards into application-type standards.5 But the rules aren’t hard and fast, and like many things in software design, the best answers will appear over time through iteration, experience, and experimentation.6
What Is the Nature of the Relationship?
The first dimension is the application’s relationship with its user. In other words, is this activity something the user chooses to do or is it something he or she must do, because it’s part of the job?
Here are some questions that may help you decide on the nature of the relationship.
1. Do the users select the application, or does the application select the users? Do the users have to use this program? If they do, then it’s on the application end of the spectrum.
2. Must users identify themselves? Do they have to log in to be able to do anything? If yes, then it’s an application. Or does logging in simply give them access to more information than they would receive if they remained anonymous? See Figure 1-6 for an example of a web page that offers users extensive online resources if they sign up. It’s not an application, but validation and security are as important here as they would be to access a corporate database.
FIGURE 1-6 Have a more intimate relationship with a web site.7
3. Does the application not know or care who the users are? Then it’s on the web page end of the spectrum. Does it remember users’ credit card information and their purchases? Then it’s in the middle. Does it remember work from earlier sessions? Then it’s probably an application.
4. How reliable must the application be? Does it matter if it’s not available sometimes? Some web sites can go down and no one will notice, while application failures are usually noticed immediately.
What Is the Conversation Like?
The next dimension is the conversation style—informal, neutral, or formal (in some cases, coercive). Here are some questions you can ask to decide on the type of conversation.
1. What is the perceived relationship between the application owner and users? Does the application owner control the users (by employing them, for example)? If yes, the tone may be imperative: “Jump!” If not, the tone will be friendlier: “Would you like to jump now?”
2. What kind of language (informal, formal) and terminology (standard English, industry jargon) is used? Jargon is a problem if the users won’t understand it; it’s usually not suitable for a public site. For technical users, however, jargon may be a necessary shorthand.
What Is the Nature of the Interaction?
The nature or result of the interaction is key to separating web pages from web applications.
1. How do users interact with the application? Are they just looking up information, or are they entering data into forms? If they’re entering data, are they entering large amounts of data? Are they doing complex tasks? If yes, the site is an application.
2. Do they expect to permanently change data? Applications let users create, manipulate, and permanently store data; web pages don’t.
3. Do they expect to find milestones in the middle of the task (“You have selected your car—continue to checkout?”) and a clear endpoint (for example, “Your order has been placed” or “The customer complaint has been added to the file”). If there are checkpoints and endpoints, the site is an e-commerce or transactional application.
What Are the Technical Requirements?
Ask these questions to decide on the technical requirements.
1. Is it possible that users have old versions of browsers? If yes, you may need to restrict the design to controls that are available on older browsers.
2. Is it possible that users have old hardware and small screens? If yes, be careful about screen sizes.
3. Must your pages meet Section 508 accessibility standards? If yes, use W3C tools like HTML, SVG (scalable vector graphics), and CSS (cascading style sheets).
4. Can your organization require all users to have certain hardware and software? If so, you can get as fancy as you like after considering accessibility issues.
How Often Is It Used?
The intensity of the interaction is another dimension. “Just looking” is on the web page side of the spectrum; “doing” is on the application side.
Here are questions you can ask about time spent on task.
1. How often is this application used? If only occasionally, then it’s on the web page side. If it’s used daily, then it’s probably an application.
2. How long is it used per session? If it’s used for only a few minutes at a time, it may be a web page. If a session takes four to eight hours, it’s probably an application.
3. What circumstance triggers its use? If it’s only used to find out about something, it’s probably a web page. If it’s used to help resolve an emergency, it’s probably an application.
What Is the Expected Response Time (or the Perceived Distance)?
The expected response time may tell you something about people’s ideas about the application. Here are questions you can ask about perceived distances.
1. Where do users think this application “lives”? Do they think it comes from a server somewhere in the country or even overseas? Do they not know, have no opinion, or not care? Or do they think it comes from a server in the building where they work? Web pages are generally viewed as being in the ether; no one knows where they come from. Applications are generally viewed as being local, whether they are or not.
2. Who do they think controls the data—an organization somewhere? the owners of an online store? or the data administrators in their company? If the answer is “our data administrators,” the site is an application.
Are These Interactions in Real Time?
You can look at the interaction speed to decide whether a program is more of a web page than an application. For example:
How Much Help Will the Users Need?
The amount of help needed for a web site indicates where the site falls on the spectrum.
1. Is every visit a one-time session—for example, a museum kiosk? If yes, this is a web page. Design the site carefully so that no help is needed; if that’s not possible, make sure that all the help anyone might need is right there on the screen.
2. Is the application something for which users need a minimum amount of experience or information? If yes, this application is probably in the middle of the spectrum. Help on controls, on filling in forms correctly, and so on can be put right on the screen and appear in error messages.
3. Must users go through long training programs and apprenticeships before they can become experts? If yes, this site is definitely an application. Help files should support business or domain expertise; help on forms and controls is also appropriate but not as important.
What Is the Interaction Style?
What should this site feel like? For example:
1. How flexible is the navigation? Can users easily reverse actions with the Back button? Or has the Back button been removed from the screen? Application designers often wipe out the toolbars and URL address area so that the users don’t lose entries by mistake.
2. How complex are the controls? Well-designed web pages use only plain controls: single click to follow links, simple navigation strategies, no object selection, no drag-and-drop. Web applications, on the other hand, may mimic nearly all of the GUI controls—tables, buttons, wizards, drag-and-drop, double-click selection, and so on.
3. How does the user get out of the site? To exit from a web page, users can just close the window or type in a different URL. To exit from a web application, however, they may have to log off. In fact, the application may interrupt and capture the browser’s close options, as shown in Figures 1-7 and 1-8.
FIGURE 1-7 You can’t close this application immediately by clicking the Close button.8
What Should It Look Like?
The look of a site will have more to do with the industry for which it’s designed and the organization’s own visual branding than with its spot on the spectrum. However, although the answers to these questions might not help you decide where a site fits, they’re still good questions to ask.
1. What is the graphic style of earlier or competitive user interfaces (if any)?
2. How obvious and self-explanatory are the controls? Web pages have to be more obvious than application pages, simply because people don’t spend much time on web pages. They won’t notice the subtleties and details that someone who uses an application daily will see.
3. What colors and designs are appropriate to the content? For example, a site for teenage girls should look different from a site for the National Cancer Institute.
Does It Follow Any Standards?
Web pages may meet World Wide Web Consortium, accessibility, and web-safe color standards, but not much else. However, users may expect that web applications will also match Windows, Apple, Java, or other GUI standards.
1. Does this application replace or supplement a desktop application? Then the closer it matches the GUI standards, the better.
2. Is it used with other applications that set expectations? If not, it’s probably a web page. If it is, then it’s an application and you should try to match the style of the other applications.
How Intense Is This Interaction?
Another way to decide whether your program is a web page or a web application is to look at relationships and the intensity of the interaction. When you do, you get Table 1-3.
What Should This Application Look Like?
The last piece of the puzzle is the overall look and feel. Table 1-4 indicates, in a general way, what the applications in the various categories (“Reports,” “Games,” and so on) should look and feel like.
Keep in mind that these recommendations are not foolproof. To find out if you’ve made the right choices, test for usability throughout the development life cycle.
1From “Conference Presentation Judo,” © 2002 by Mark Jason Dominus, http://perl.plover.com/ yak/presentation/samples/slide023.html (accessed 11 August 2003).
2From “Small Businesses Group Medical,” © 2003 by eHealthInsurance Services, Inc., http://www.ehealthinsurance.com/ehi/Welcome.ds (accessed 11 August 2003).
3Prom “Stock Compare Results:’ © 2003 by Morningstar, Inc., http://screen.morningstar.com/Compare/Stock/StockCompareResults.html (accessed 11 August 2002).
4From Eclipse System, © 2003 by Palisades Technology Partners, Inc., Englewood Cliffs, NJ.
5Application standards—for example, form-based data-entry, conversational (also called “interactive”), and inquiry (“result” and “read-only”)–were first addressed by Wilbert O. Galitz in his series of GUI design books. See his current book, The Essential Guide to User Interface Design (Wiley, 2002). Also see Van Duyne, Landay, and Hong for the idea of web design patterns (2002).
6Many thanks to UsabilityNJ for letting Whitney Quesenbery and Susan Fowler test these continuums on them in June 2002. The charts are better for their input.
7From “Why Join H.o.p.e.?” © 2003 Novartis Pharmaceuticals Corporation, http://www.healthandhope.com/info/join/why/join.jsp (accessed 13 August 2003).
8From CitiBusiness Online, © 2002 by Citibank. https://citibusinessonline.da-us.citibank.com/ (accessed 13 August 2003).