Designing Usable Web Applications: Session Outline
Presented by
Wendy Owen, Director of Informatin Design and Usability, Guru.com
Nadav Savio, Independent User Experience Architect
Introduction
Who we are and why we're here
What we're going to talk about today -- designing usable Web applications
- What is a Web application?
- Five challenges to making Web applications usable
- How to overcome these challenges
- Specific solutions to the five challenges
- Wrap-up -- summary and the immediate future
- Q&A
What is a web application?
Here’s a simple, usable definition:
"A Web application is an application for which a Web browser connecting
over the Internet provides or contains the User Interface."
Let's talk about what this means to users and to developers...
From a user’s perspective
- A Web app is a tool-oriented site where I can go to "get something done."
- A Web app is a site that lets me create and save things.
From a developer’s perspective
Web apps are similar to Web pages
- Both are built from Web languages like HTML, CSS and JavaScript
- Both speak Web protocols like HTTP and FTP
- Both live on the network
Web apps are unlike Web pages
- For Web apps, the pages are an interface - a means to an end - rather than ends in themselves.
- Web apps are tool-oriented and (often) allow you to create, save and
manipulate data.
Web apps are similar to desktop apps
- Both are tool-oriented
- Both allow you to create, save and manipulate data
Web apps are unlike desktop apps
- Web apps speak Web protocols like HTTP and FTP as their primary tongue.
- Web apps live on the network and can be accessed anywhere, anytime (providing
that you have a net connection and the server isn’t down).
- Desktop apps are entirely made out of compiled programming languages
like C or Java, while Web app interfaces are built from Web languages like HTML, CSS and JavaScript.
- Desktop apps are directly integrated with the operating system, while Web apps live inside a browser
Notice that, in general, the ways Web apps are unlike desktop apps, are
the ways that they are like Web pages (and vice versa).
Many applications blur the boundaries.
Dreamweaver, for example, is largely built from HTML and JavaScript and
can talk over the network using HTTP.
We feel it’s pointless to try to pin down exactly what counts and what
doesn't, so we'll stick with the simple definition we started with:
"A Web application is an application for which a Web browser connecting
over the Internet provides or contains the User Interface."
Five challenges to making web applications usable
Overview
There are many very different types of Web applications, including
- Email clients (hotmail.com)
- Productivity apps (halfbrain.com)
- Dating services (xseeksy.com)
- Personal information managers (calendar.yahoo.com)
- Party invitation sites (evite.com)
- Job-hunting services (guru.com)
- Photo albums (zing.com)
- And on and on...
Even though these sites allow users to do really different things, many of the challenges to making them usable are similar from site to site.
We're going to take you on a tour of many of the trouble spots you'll
likely face as you design Web apps. First we'll run through a list of
challenges, then we'll suggest solutions.
Challenge 1: The Web and Web browsers weren't designed to be an
applications platform.
This is a biggie! So we’ve broken it down into several
related issues...
The layout controls in HTML (like tables and bulleted lists) were designed
for physics papers, not applications.
The interface widgets browsers use (like scrollbars and the ‘Back’ button)
were also designed for pages rather than applications.
It is awkward and confusing to have one set of navigation and controls
(the ones you design for your web app) inside another set (the default
browser controls).
Users are always one click away from jumping to something completely
different and potentially losing work or data. By contrast, a desktop
application typically has two exits (barring a crash!), both of which
preserve your data: you can switch to a new program (which doesn't shut
the current one) or you can choose to close the current one (which results
in a prompt to save the work you’ve done).
Even within a single application there are many separate web pages.
And every time a user moves from one page to another, her work will be
lost unless you explicitly save it. But when and how should you save it?
And how do you let her know when her work has been saved and when it hasn’t?
Challenge 2: Web apps are often based on varied and complex tasks.
Perhaps this is easier to understand in comparison with content-driven
Web sites where you often only have two tasks - to find and consume information
- so that a flat list of links or simple navigation bar (maybe augmented
by a simple search box) is sufficient. In contrast, consider an online
calendar, which includes a variety of tasks, including adding appointments,
checking your schedule, setting up reminders, synching with a PDA and
more. What’s more, each of these tasks is composed of multiple subtasks
(to add an appointment, for example, you need to choose a date and time,
give it a title, decide if it repeats, and so on). So, clearly, a Web
app of any complexity will require carefully structured navigational elements.
Challenge 3: Web apps often contain pages which must display a
lot of data.
This includes not only the user’s data (which can
be quite complex) and the application’s controls, but also links to other
parts of the site, branding messages, advertisements, and more.
Challenge 4: User input can significantly affect page design.
Challenge 5: People are often doing tasks that are stressful.
And
despite the significant advantages of networked applications they are often
doing them in a way that is more frustrating than they are used to.
Specific solutions to the five challenges
Overview
As we touched on earlier (and as most of you probably already know), the
Web was originally created to help academic researchers share information with each other. So the tools, protocols and browsers were created to allow
people to display data – not to create, save or manipulate it. Many of you probably
feel like you’re working with dull, malformed tools as you design
web apps. And you’re right.
Because the tools are so crude, nobody is designing perfect Web applications. So take your
guidance and inspiration from multiple sources:
- Look at traditional apps, but be careful: because these apps aren’t
limited to HTML, many of their conventions will be impossible to follow.
- Look at the HCI (human-computer interaction) literature (see the resource list for suggestions).
You don’t have to reinvent the wheel; many smart people have been thinking
about interface design for a long time. While much of the literature is
geared towards desktop apps and content Web sites, most is still quite applicable
to Web applications.
- Talk to other people who are doing this. Books and articles are great,
but they are no substitute for talking to people who face similar challenges
and problems. (We've included some suggestions for online lists for this
in the resource list).
- And finally, look at what other people are doing online.
In this section of our talk we will explore each of the challenges that we
talked about earlier by looking at some examples of Web application interface
design.
We’ll also suggest some specific solutions for each challenge.
Since all Web applications are different (and since each of you faces a series
of unique system, design and business constraints), some of these solutions
will not work for the unique system that you are designing or helping to create.
But even if a specific solution does not work for you, it will offer you
a way of thinking about a specific challenge which will hopefully lead you
to a solution that works within the series of constraints that you face.
Challenge 1: The Web and Web browsers weren't designed to
be an applications platform.
Solution(s):
1. Open a new window and strip out traditional browser controls (forward,
back, etc.) for navigational clarity.
This solution has some potential problems you should keep in mind:
- This is a relatively uncommon practice and some users may wonder
why the browser navigation has disappeared.
- If the spawned window is smaller than the original window or
doesn’t have standard browser navigation, users can experience
frustration if they shut the first window and then must use your
hobbled window to visit other sites.
- If you spawn a window that is the same size as the original
window, the original window may be covered up which can be disorienting.
- If not properly coded, JavaScript popup windows can lead to
errors.
But in some cases it's necessary to use this technique. What sense
does ‘Back’ or ‘Reload’ make in the context of a spreadsheet like
the one on halfbrain.com:
2. Instead of removing the browser’s navigation, you can clearly separate
the application visually from the browser and demarcate it visually as
a self-contained entity.
3. Differentiate the application from the browser and from other parts of the page.
Many sites create a “workspace” on the screen that is persistent
throughout the user experience.
This space is usually buffered – or visually set apart
– from the browser chrome and the rest of the site’s navigation.
Logos (and sometimes even ads) often form an effective boundary. In
general, users have been trained to look below this layer of images
and text for their experience on the site to begin.
Tell users they are about to enter an application space before they
get there to help them adjust their expectations and interaction style.
4. Provide clear navigation to the things people might want to do, when they want to do them.
For example, a "Continue shopping" button during a shopping cart
checkout process.
When users need to explicitly save their work, make that obvious:
Buttons like "Finish" and "Cancel" provide clear exits and reinforce
the distinction between app and browser navigation.
It’s important that your navigation and buttons are clearly labeled
and that the placement of them remains consistent throughout the application
experience.
5. Try to code your app so that nothing catastrophic will happen if users
do use browser navigation.
The Bank of America Website will log you out if you hit back and
then not let you in for at least 10 minutes. They warn you in text
on the site, but that's really not good enough:
6. Where appropriate, create Wizard-like loops rather than offering all
options on one page.
Wizards group a series of discrete tasks which progress linearly
towards a single goal.
In a typical wizard, users will fill in forms, preview data and
post that data.
When a user enters a wizard, their navigational choices should be
severely limited. This helps them stay on track and successfully complete
the task they are trying to do.
7. Wherever possible and appropriate, eliminate exits (i.e. links that
take users away from the application). Typical exit links include ads,
cross promotion of other sites and links to other sections of your own
site.
A good example is new user registration. Many companies choose not
to put ads within their registration process, deciding that signing
up new users is more valuable than the lost advertising revenue. If
your company relies on multiple revenue sources, it may be helpful
to prioritize them.
Challenge 2: Web apps are often based on varied and complex tasks.
So, clearly, a Web app of any
complexity will require carefully structured interactivity elements.
Solution(s):
1. Identify essential tasks and the actions that make them up.
You’ll need to do this for subtasks as well.
2. Choose an appropriate interface control for each action.
Actions can be thought of as:
- Moving to a different section - or page - within an app
- Sorting/reordering
- Moving things around
- Revealing/hiding information
- Searching
- And so on
3. Organize the controls.
Group related controls.
Tie controls to the objects they act upon.
Sometimes all the controls for a task naturally fall on one page.
Sometimes you'll want to break out subtasks along a series of
different pages or steps
4. Make sure that your application navigation is clearly
distinguished from your browser navigation or your site’s meta navigation.
5. Eliminate any unnecessary user choices or interactivity elements (ads,
links, tasks, etc.)
Challenge 3: Web apps often contain pages which must display a
lot of data.
One of the most basic challenges to Web app design is creating these
pages so that the data is as easy and convenient as possible for the user
to digest and use.
Solution(s):
1. Be sure to limit the number of choices (such as links) on each page.
2. Vary the way actions are displayed. Where appropriate, use:
3. Choose how much and what data to display.
In this example, there's no reason to display the ID number since it's
not relevant to the people using the site:
4. Other visual techniques or conventions can help here as well, such as:
- Color or shading
- Boxing or strokes
- Banding
Challenge 4: User input can significantly affect page design.
Solution(s):
1. Define the page or page module. Start by asking yourself the following
questions:
- What data goes on this page?
- How is it organized?
- What actions can be accomplished here?
2. Next, imagine what the design will look like with :
3. If the page or module has no data, determine whether you want to present
a different page or module to the user.
4. Mock up all variations of the page so that there are no surprises.
5. Sometimes it makes sense to give users control over the layout
On evite.com, for example, when there are a large number
of people invited, only one of several sections is displayed. The person
using the site can then choose to display a different section, in which
case the first ("Undecided" in the example) will be collapsed:
6. In general, plan to stack your information vertically if you don't have
control over the text length of each unit.
Challenge 5: People are often doing tasks that are stressful.
Solution(s):
1. At the beginning of the project, take the time to analyze the essential
tasks associated with the application.
Look for (or, better yet, ask real users about) common sources of frustration
Consider individual tasks as part of the overall process people will
be going through. Something might not seem stressful unless you see it
in context.
2. Use visual design and writing to make using your site as pleasant as
possible
- Color choices
- Iconography
- Layout
- Tone of instructional text
- And so on
3. Provide a clear path to help text
This example uses prominent placement and a noticeable
icon to make it easy to find help:
4. Carefully craft your error handling
- Visual treatment
- Tone
- Choice and location of information displayed
Remember that you're talking to a person, not a machine. "Error code
#1123" is not a helpful error message. On the other hand, more is not always better if it keeps people from reading the message.
This example has a pleasant (but efficient) tone, and
visually points out the specific problems, although an iconic visual cue might make it even better:
5. Nothing's as frustrating as waiting, so:
Design pages that download and render quickly .
Don't skimp on the backend (bandwidth, software and hardware).
6. Wizards can help reduce stress by helping to focus users' attention
and by breaking large tasks into manageable pieces.
The future of web applications
Next-generation Web apps (where this space is going, how it'll make design
easier/harder):
XUL (Mozilla)
The good... allows you to control the entire UI, so
your site no longer has to exist “inside” a “browser.” (In other words,
Mozilla is an applications platform; Netscape Navigator is a browser built
on top of Mozilla).
The bad... currently about 5 people will be able to
see your cutting edge web application. Even when Netscape 6 launches, far
less than 50% market share.
The ugly... skins.
XMLHttp
XML-RPC and SOAP (Simple Object Access
Protocol)
You can call server-side methods remotely, so Web apps can talk to each other and exchange data.
Example 1: When I make a reservation using Expedia
it could first check, then update, my Yahoo calendar.
Example 2: I use Atomz.com as my weblog’s search
engine and Blogger to post to it. When I post something new with Blogger
it could tell Atomz to reindex the site.
No doubt cross-site scripting is way cool, but it
has a ways to go (security is a concern, among other things).
WAP (Wireless Application Protocol)
The possibilities are endless.
But it makes our head hurt to think about designing applications on teeny-tiny cell phone screens!
