From Web sites to Web applications, Part 1: Web site or Web app?

Make good decisions by analyzing your Web presence

Are you building a Web site or a Web application? The line between Web sites, which are largely informational, and Web apps, which are more interactive, has blurred. There are best practices for building good informational sites, and those practices aren't the same for building a good application. In this article, learn the real, tangible differences between Web sites and Web apps, and then analyze your own sites. Explore the kind of sites you're managing, designing, and coding in a way that helps you improve their design and usability. Learn to make informed decisions that support your Web goals.

Brett McLaughlin (brett@oreilly.com), Senior Editor, O'Reilly Media Inc.

Photo of Brett McLaughlinBrett 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.



01 June 2010

Also available in Chinese Russian Japanese

Introduction

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.

Web sites are fundamentally different from Web applications. If you're building Web applications, you need to know what distinguishes you from the Web site bourgeois. On the other hand, if you're used to building static, JavaScript-less pages, you'll probably be pressured to convert your site to a Web app.

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.


Web sites aren't (necessarily) Web apps

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.

Web sites are primarily informational

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
Screen shot of a Wikipedia page. The page is almost all text.

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.

Web sites can be dynamically driven

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.

Web apps are primarily interactional

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
Screen shot of Amazon.com. The page has links, images, and text.

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.


How informational and interactional sites differ

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.

Information works best raw

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.

Yes, there's a place for enhanced information

I'm not saying you should avoid enhanced editions, or shouldn't push the envelope with a Web 2.0/3.0 approach to information. The use case served by this sort of experience is not the same as "getting information" quickly and efficiently. Most next-generation approaches to information are creating immersive and even entertainment applications. They're not trying to just transmit information, but to change an entire experience.

An informational site is ultimately not trying to be experiential. If that's your goal, then you're looking at an interactional site.

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.

Interaction is interruptive

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?


Interactional case study: Audi.com

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
Screen shot of the Audi.com home page. The page is slick, even before you interact with it. There's a picture of a car in the middle, with smaller thumbnail pictures at the bottom and more navigational links across the top.

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
The same screen shot as the figure above, but this time the car in the picture is red, showing that users can immediately interact with the site.

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
Screen shot showing a menu overlay, with more pictures, text, and options.

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
Screen shot showing an expanded drop-down menu with the current option highlighted.

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
Screen shot of an interior page on Audi.com. Each car model's interior page has numerous images that respond and change based on user input.

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.

Interaction doesn't just happen

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.


Blending interaction and information

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.

Hybrids are a lot harder

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.

Finally, you need to push into the areas where you're weak. If you spend your days working on sites that are chock full of information, then find some areas where you can interject a bit of extra interaction. Add JavaScript and jQuery to add collapsible areas. Push the boundaries of your informational site so it looks more like a 60/40 split between information and interaction. And the converse is also true: Find ways of increasing the information flowing through your interactional site. Build sidebars and panes of text that are revealed at just the right time, but convey more information than you'd usually provide. Improve your weaknesses.


Use your sites

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.


Conclusion

The path toward great Web design doesn't consist of you quoting this article—or any other—over and over as you build comps and code JavaScript. Instead, you should evaluate and internalize the principles outlined in this article, and then use them as a springboard for making your own principles. Your sites and apps should be better because you thought about this article, not just because you blindly put it into practice.

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.

Resources

Learn

Get products and technologies

  • Prototype: A best-of-breed JavaScript framework for working with your page, automating tedious JavaScript actions, and integrating screen effects.
  • 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 Prototype-driven site.
  • MooTools: Lightweight and pretty slick, moo.fx adds to MooTools what script.aculo.us adds to Prototype. This is screen effects at its finest.
  • Fundraiser Insight: Fundraiser Insight provides several Web-appropriate thermometers in case you're looking to add fundraising-style widgets to your site.
  • 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.

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Web development on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Web development
ArticleID=491393
ArticleTitle=From Web sites to Web applications, Part 1: Web site or Web app?
publish-date=06012010