In our world of iPads, iPhones, Android, and application-centric devices, it's now passé to say, "I have a static Web site." If you don't have advanced search, at least three purchasing options, and two different pages with advanced Ajax interaction, you're viewed as "so 1998." Many developers are scrambling to meet management requests: Get some more interactivity going! Keep up with Amazon.com or Bing or IBM! Make the Web site... a Web application. But, if you make things up as you go, the result can be an unfocused, and sometimes less functional, Web presence.
In this article, learn how to make informed decisions that support your Web goals. Learn the difference between a Web site and a Web app and how the two concepts are largely distinct and different. After you understand the major differences, you'll be well prepared to decide—or at least influence—what your Web presence should be.
You might encounter a situation where you've got an existing Web site and there's not a good reason to convert to a Web app. Or, a situation where folks are spending a lot of time on Web apps but are really just spinning their wheels. It might be better to skip all that work and go with a fairly simple Web site. This section outlines the differences between Web sites and Web apps.
The easiest definition of a purely static Web site is: informational. A classic example is Wikipedia, which is meant to be almost entirely informational. Wikipedia is not flashy, not exciting, and not littered with image pop-ups and full-scrolling maps. It's just raw information, presented in little more than a hyperlinked dictionary, as shown in Figure 1.
Figure 1. Wikipedia example
Information is often best communicated with simple static Web sites. If your goal is to disseminate information about a product, a service, or even about information itself, a Web site is a good starting point. Of course, there's a great resistance to Web sites. They're not flashy, and they're not lighting up the Twitter-verse. Most people still go to Wikipedia as their first stop to explore a new topic, though, so there's clearly real value in static sites.
Most blogs are really Web sites. Even though blog sites are driven by programs such as WordPress or Movable Type, the result is information-driven sites that are basically flat, non-interactive pages. This points out an important distinction: A Web site is not defined by how the site is generated; a Web site is defined by how the information and functions of the site are consumed by its users. Understanding this distinction can help you focus on your users' experience with your Web presence.
In the early stages, you should focus on the user experience. A user doesn't care whether your site is back-ended by HTML and CSS, or ColdFusion, or PHP, or Perl. Users simply make an evaluation of the site based on what they see. To get a handle on what sort of site you're building or looking at, take a step back from programming. Just fire up a browser, navigate to your site, and make an evaluation.
If your site isn't primarily informational, it is most likely interactional. This simply means that the user is not a passive consumer, but an active participant. The user is searching, clicking buttons, filling out forms, making purchases, and generally keeping his or her hands on the keyboard and the mouse.
Think of a computer game as the high-water mark for interaction. In a game, users are completely active and interacting constantly. Whether they're shooting zombies or navigating through a minefield, users are busy pushing buttons and making decisions that lead to more button pushes. Of course, most sites don't rise to that level of interaction.
The majority of Web sites are, to some degree, hybrids. For example, look at the home page for Amazon.com shown in Figure 2. Amazon.com is a hybrid, but still an information site.
Figure 2. Amazon.com
A lot of information is presented on the screen above. Books, authors, prices, and categories are all forms of information. However, a user's primary goal on this page is to interact. Users are going to navigate to a more specific category. Or, they may drill into a specific book and then make a purchase. The user might search, or see what's in his or her cart. All of this is interaction.
Given that any Web site is going to present some information, the goal is to determine the balance. Are you largely interacting, or are you largely reading? Are you spending 30 seconds on a page, or 10 minutes? If you're largely interacting, and spending less time on pages, you're visiting an interactive site.
Thus far we've discussed a fairly simple, binary approach to evaluating sites. A site is informational or it's interactional. Black or white.
Most interactional sites are actually hybrids. If there's no information, then there's nothing with which to actually interact. Imagine Amazon.com with nothing but buttons—no books, no DVDs. It's nonsensical. You have to have some information to which you respond. Thus, even interactional sites are really hybrids: a combination of information and interaction.
You might wonder why you need to focus on the distinction, or divide, between interactional and informational. There is real value in thinking differently about a site that mainly wants to deliver information and a site that mostly wants to generate interaction. That divide in thinking, in fact, will drive most of your major design decisions. Even though you'll rarely build a site that is purely informational, or purely interactional, identifying your site as strongly leaning toward one or the other is key.
If your site leans toward being informational, that also identifies your use case: Give your audience information. The question then becomes a matter of implementation. Given that users want information, how can that information best be delivered? How can you best convey data, usually expressed in large quantities, intended for reading online?
At this point, folks working on e-books, enhanced editions, and the next generation of publishing begin to anxiously wave their raised hands. Information should be represented for the next generation of media-savvy readers, right? We have new ways to present information: floating annotations, clickable pop-ups with extra information, and embedded videos.
The problem with this sort of thinking is that it seems to suggest history is not weighty, and there is not some degree of inertia in users. People are used to reading books, reading dictionary entries, reading Wikipedia. And the way they read from these sources is by moving their eyes largely from the top of a page down, and in many languages, from left to right. They read large quantities of text and, in general, read the text without interruption. In fact, they want to read that information largely without interruption.
Informational sites shouldn't try to be the flashiest, sexiest, most fully-featured sites around. While there is a good case for using images to illustrate things, you should look to existing popular sites for examples: dictionary.com, Wikipedia, and other highly-textual sites. You can certainly consider visual elements, try different fonts, and work toward easily accessible and well-understood navigation. You're serving information, and anything that detracts or distracts from that is going to ultimately work against your use case.
If you're trying to build interaction, what is different from delivering information? If information sites seek to minimize interruption, interactional sites seek to maximize interruption. Your site is constantly creating in its users a desire to click, or drag, or highlight. You're creating an environment that is not one-way, but two-way. It's no longer enough for users to passively read text or look at images; they have to do something to progress their experience.
They key to interaction, then, becomes forcing those interrupts. You need to intentionally create points of interaction. If there are paths by which your site can be navigated purely through hyperlinks, you've probably not done a good job of information and interaction design. On the other hand, if users need to click a button and fill out a form and then whirl out a collapsed informational section, then you're very likely in the right ballpark.
Another way to approach the issue of building interaction into your site is to build a sequence map of your site. Take a screen shot of a particular page, and then figure out what you want the next page or view of your site to look like. Then take the next, and the next, and so on until you have four or five or ten screen shots of sequential steps to get your user from point A to point B.
Determine how the user moves from one screen to the next. Does he click a simple link? Does he click a button? How much is he moving the mouse? How much action is occurring on the screen? What is the user doing? This is a great way to figure out your interrupts. How often must the user get involved to keep things going? How many interruptions do you provide if the user doesn't get involved?
To see how a sequence map can be helpful, let's go through a case study. Look at the sequence of screens from a high-end automobile manufacturer's Web site. Because it represents a very expensive purchase, the site must draw in and "wow" the user.
Figure 3 shows the opening screen when you visit the Audi.com Web site. The site is slick, even before you interact with it.
Figure 3. The Audi.com opening screen
Users can immediately interact with the site. The next screen, in Figure 4, involved nothing more than a single mouse click. Clicking any of the color patches just below the vehicle immediately changes the color of the car. Without any menu searching, or any hunting around, the user can immediately interact with the page.
Figure 4. The Audi front image responds to user clicking
At this point Audi.com starts to do a lot with relatively old technology. Drop-down and mouse-over menus are nothing new, and anyone with DreamWeaver has been using them forever. But Audi is trying to be interactive. So, instead of forcing a drop down, then a click, they're showing full-blown images, spec sheets, and the equivalent of a nested page.
Figure 5 looks more like an interior page than a front page. Audi.com takes menus far beyond purely navigation. Mousing over menus brings up not just options to click, but full-blown images and option lists.
Figure 5. Mousing over menus brings full-blown images and option lists
This is a clever approach to interaction. Users aren't clicking a lot, but the site is giving them a lot of feedback—and it's visual feedback. It feels like a lot is going on. Interaction doesn't always involve complicated Flash animations or a joystick. Sometimes a well-placed image, as on the Audi site, is just perfect.
Figure 6 reveals another key aspect of the interactivity: simplicity. This is a text-based menu, so nothing looks extraordinary. But the menu drops down cleanly, and the current option is highlighted. It's not revolutionary, but in light of everything else on the site, you're spending minimal time reading or figuring things out. Instead, you mouse over a menu, move to your option, and click it. There's no room for confusion. All the time, you know you're getting what you want.
Figure 6. Navigation menus are simple and beg to be clicked
Figure 7 is an interior page. The well-oiled front page isn't paired with a weaker, less-immersive interior page. There are a lot more options, all clickable, and all affect the central image. Each model's page has many images that respond and change based on user input. Colors, wheel types, and interior patterns all cause instant changes.
Figure 7. Visual interior pages involve more clicking than reading
Clearly, a lot of work, design, and programming went into the site. It's not the model of interaction many sites will adopt. However, the sequence is the key: Users are forced to interact to progress throughout the site. Increased interaction yields increased information and eventually response from the site.
Printing screen shots makes it very easy to see how users interact and what their interactions create in terms of their experience. Take the time to walk through this exercise. It might seem silly to have printouts of screen shots all over your floor, but that's better than your users getting bored with your site and leaving it.
With the interactional approach, a prime consideration is where the interaction is on the screen. This is not just a discussion of "Does the widget go on the top-left? Or along the right?" There are two basic approaches (one of which is simply not good):
- Interaction is not necessarily front-and-center physically, but is in the way of the user's progress. He or she must interact to proceed.
- Interaction is sprinkled around information. The interaction is sensational but not required for site progression.
The first is the preferred approach. Interaction isn't something that can be bolted on top of an existing site. The reason? Interaction doesn't fit around information. Rather, it's intrinsic to the information itself. Figures 5, 6, and 7 above show that the interaction is tied into the information itself—the menu options. You can't have one without the other.
Getting back to the idea of hybridization, even the most interactional site must at some point present information. Consider video games, which aren't even sites at all: Here and there, the games are forced to resort to cut scenes or interludes where the player is passive while getting necessary information.
On the flip side, the most informational of sites at some point must allow you to click or search. Imagine the entire information store of Wikipedia on a single page! Even then, though, the user must scroll; at its most basic, scrolling is interaction. All sites are hybrids. Most sites aren't an extreme of one way or the other, with 90% information or interaction and only 10% the converse. Most sites are somewhere in the 75/25 range. You're going to have to make decisions about information in your interactional site, and decisions about interaction in your informational site. And you want those to be good decisions.
You may be fantastic at interaction, but you're still going to need to be good at information. You may be a wonderful information designer, but you'll have to build interaction, to some degree, at some point.
The crux of the problem is: No matter how good you are at interaction, you've also got to be pretty good at information design. If you're a world class information designer, you've still got to learn how to build meaningful interaction. It's not easy to do well in both of these disciplines. Most people are good at one or the other, and their sites lean toward their strengths. The oddity and irony here is that sites that do one thing really well (interaction or information) often do the other thing poorly. The goal, of course, is to do both things well so you end up with a very strong site or app.
First and foremost, working on interaction to the exclusion of information design, or the converse, is a bad idea. You'll likely be strong at one and weak at the other. Your goal should be to work very hard at one, then work at the other on an ad hoc, as-needed basis. If you buy into the 75/25 ratio of one type of content to another type of content on a single site, then you might want to work on the 75 part of that ratio three times as much as the 25 part. That certainly is a baseline with which you can begin.
The next step is to do the task repetitively. Design sites and build interaction constantly. Designers who spend their free time tinkering with Web sites will, on average, be better designers than the designers who spend their free time learning the guitar.
You might roll your eyes at this point and decide you're being told something so obvious that the author can't know what he's talking about. Avoid eye rollage for a few more minutes.
Use your sites. A lot.
Sounds simple, doesn't it? But, just as many actors don't want to watch their performances, and many musicians won't listen to their own CDs, many Web designers spend next to no time on the sites they develop. They code, design, upload, and forget. They then have no idea how the sites are being consumed. They're working off of an imagined use case, with an invisible and non-existent user. That's not a good habit.
So use your site. If you hate it, your users may hate it. Don't dismiss your problems with a hasty, "Well, I just know the system," or "None of the users are anything like me." A better response is, "How can I improve this site for the users, whether they're like me or not?" That extra bit of thought could dramatically change your view of your site.
In this article you learned principles to use to determine whether your Web presence currently functions more like a Web site or a Web app. Whether you decide your presence needs to be more informational, or more interactional, or if it's fine the way it is, the important thing is to think about what you're doing. You're now making informed decisions that are conscious, rather than tiny uninformed subconscious decisions.
Now, go break some rules, or argue with the writers you read. That means you're figuring out what works best for you. Your context isn't the same as mine, or anyone else's. You're going to need to "write your own article" with what works for you. That's a good thing. In the meantime, I hope this article kicks off some good thinking. Let me know in the comments at the bottom of this article what I'm right about and what I'm wrong about. I look forward to hearing from you and learning about your context—and how your Web presence is evolving to match that context.
- Any discussion on Web usability
has to start with Jakob Nielsen's
Web site, which is full of articles and great resources.
- Usability is closely related to
accessibility. A usable site is almost always highly accessible. Learn
more about accessibility at the Web Accessibility Initiative (WAI).
- "User-Centered Design and Web Development" (July
1998) is old, but it explores the important issues detailed in this article's
design in Wikipedia has a lot of good references and links to further
- Head First HTML with CSS & XHTML (Robson and
Freeman, O'Reilly Media, Inc.) has a terrific introduction and
concept-rich instruction in XHTML and CSS.
- Head First Web Design (Wattral and Siarto, O'Reilly
Media, Inc.) is a learner-friendly book
on Web design that goes in depth into usability, color, layout,
navigation, and even intellectual property.
- The developerWorks Web development zone specializes in articles covering various Web-based solutions.
- IBM technical events and webcasts: Stay current with developerWorks' technical events and webcasts.
- developerWorks on-demand
demos: Watch demos ranging from product installation and setup for beginners, to
advanced functionality for experienced developers.
- Get answers quickly: Visit the Web 2.0 Apps forum.
Get products and technologies
- Prototype: A best-of-breed
- script.aculo.us: Another must-have,
script.aculo.us is an effects library for moving, morphing, animating, and
adding GUI wonderment to your Web page. This is ideal for adding on to a
- MooTools: Lightweight and pretty
slick, moo.fx adds to MooTools what script.aculo.us adds to Prototype.
This is screen effects at its finest.
Insight: Fundraiser Insight provides several Web-appropriate
thermometers in case you're looking to add fundraising-style widgets to
- PHP Fundthermo: This
PHP image generator is geared toward fundraising, but can easily be
tweaked to give you any sort of progress indication.
Evaluate IBM products in the
way that suits you best: Download a product trial, try a product online,
use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to
implement Service Oriented Architecture efficiently.
- Create your My developerWorks profile today and set up a watchlist on Web development.
Get connected and stay connected with My developerWorks.
- Find other developerWorks members interested in Web development.
- Web developers, share your experience and knowledge in the Web development group.
- Share what you know: Join one of our developerWorks groups focused on Web topics.
- Roland Barcia talks about Web 2.0 and middleware in his blog.
- Follow developerWorks' members' shared bookmarks on Web topics.
Brett McLaughlin is a best-selling, award-winning author of non-fiction. His books on computer programming, home theater, and analysis and design have sold in excess of 100,000 copies. He has been writing, editing, and producing technical books for nearly a decade. Brett is as comfortable in front of a word processor as he is behind a guitar, chasing his two sons around the house, or laughing at reruns of Arrested Development with his wife. His last book, Head First Object Oriented Analysis and Design, won the 2007 Jolt Technical Book award. His classic Java and XML remains one of the definitive works on using XML technologies in the Java language.