Tài liệu Web Application Design Patterns- P6 docx

CHAPTER 5 Navigation
136
page. Because of their placement near primary and secondary navigations,
breadcrumbs shouldn’t visually compete for attention or distract users from
the main navigation mechanisms.
Related design patterns
Breadcrumbs should be given lesser emphasis than other important elements
on the page, such as the page title, PRIMARY NAVIGATION, and SECONDARY
NAVIGATION (see VISUAL HIERARCHY pattern in Chapter 12).
WIZARDS
Problem
Users need to complete several steps in a specifi c order to complete a task (e.g.,
checking out an item on an e-commerce site, making reservations, fi ling taxes,
and so forth). Because most users are going to perform the task occasionally,
they may not acquire enough familiarity or expertise to remember the steps
and their order for successfully accomplishing it.
Solution
Guide users through steps, one at a time, in a predetermined sequence ( Figure
5.32 ). Such interfaces are commonly referred to as wizards .

FIGURE 5.32
British Airways walks users through a wizard to help them make fl ight
reservations.
137
Why
Wizards are useful when users must go through a specifi c sequence of steps and
perform a set of individual tasks in succession (e.g., checkout for e-commerce
applications or opening an account with a fi nancial institution). They are also
useful for complex tasks with branches or dependencies among elements,
which require considerable domain knowledge to complete (Dryer, 1997).
By breaking such tasks into smaller steps and guiding users through each

step, wizards hide the complexity of the underlying task. They require users
to focus on only a few data elements at a time and let the application keep
track of what they have done and still need to do. Additionally, by guid-
ing users through each step, errors are minimized and the chances of users
successfully accomplishing the task are improved. Finally, wizards are also
useful when a task is critical for accomplishing users ’ goals (Wickham et al.,
2002). For example, in e-commerce applications, checkout is a critical task for
purchasing items.
How
As a fi rst step, identify all information or groups of information and the order
in which they need to be presented to users to complete the desired task. In
addition, identify any dependencies or branches between them to ensure that
the dependent tasks occur later in the sequence. For example, in an e-commerce
checkout process, shipping information usually comes before payment infor-
mation because the shipping address and shipping options (such as delivery
timeframe, tax-exempt status, and so forth) are used to calculate tax and ship-
ping charges, which contribute to the total price. Only after knowing the total
price should users be asked for billing and payment information. Once infor-
mation, grouping, and order are identifi ed, break them up into individual steps
so that logically related groups are together.
Once the steps, sequence, and branching decisions, if any, are made design
pages in a wizard style — that is, present each step on a separate page and allow
navigation between them with “ next ” or “ continue ” and “ previous ” or “ back ”
actions ( Figure 5.33 ).
Although typical wizard implementation has individual steps on separate
pages, a recent trend is to consider an accordion interface design approach
( Figure 5.34 ). This design shows all the steps on the same page but, like a wiz-
ard, makes only one step visible at a time. As users choose to go to the next
step, the current step is collapsed and information corresponding to the next
step is expanded and made available. Users may go to any previous step by

clicking the corresponding step heading, which then expands that step and
collapses the current step. This design approach is effective for wizards with
just a few steps because the headings that represent steps and facilitate naviga-
tion can take up excessive space on the page, leaving little room for content in
each step.
Wizards
CHAPTER 5 Navigation
138

FIGURE 5.33
The TurboTax wizard uses “ Back ” and “ Continue ” actions to guide users
to complete their taxes.

FIGURE 5.34
Adobe uses a wizard-style interaction, but as an accordian to show all the steps
on the same page. After a step is completed and users click “ Continue, ” the next step is
revealed.
139
LIMIT THE NUMBER OF STEPS IN THE WIZARD
When developing wizards, the number of steps needed must be balanced with
the amount of information asked from users on each step. Users should feel
that they are making good progress through the wizard and that each page
shows logically grouped information. At the same time, they shouldn’t feel that
most of their time is spent waiting for pages to refresh to go to the next step.
Nor should they feel they have to backtrack often to change information pro-
vided in previous steps. Typically, wizards shouldn’t require more than fi ve to
seven steps to accomplish a task (Wickham et al., 2002).
CLEARLY SHOW WIZARD STEPS
Show each step in the wizard as either a set of horizontal steps or tabs ( Figure
5.35 ) or vertically as a list or table of contents. The latter is preferred when

one or more steps may have substeps. Usability tests for desktop-application
wizards have shown vertical placement of steps to be more effective than hor-
izontal placement (Wickham et al., 2002). However, vertical placement does
require additional space and may have to be traded off against content to be
presented for each step.
BEGIN WITH AN OVERVIEW PAGE FOR VERY INFREQUENTLY
USED WIZARDS
For wizards used very infrequently (perhaps, only once), such as initial con-
fi guration or application setup, use an overview page to explain and introduce
the process and its steps ( Figure 5.36 ).
Wizards

FIGURE 5.35
Washington Mutual shows the steps for opening an account horizontally
above the form.

FIGURE 5.36
Citibank provides an overview page that outlines steps included in the
wizard for opening an EZ Checking account.
CHAPTER 5 Navigation
140
SUMMARIZE INFORMATION ON THE WIZARD’S LAST PAGE
On the last page of the wizard, summarize users ’ information and actions and
explain what will happen when they press “ Finish. ” Whenever possible, make
the fi nal action indicative of the task being completed — for example, “ Place
Order ” or “ Create Blog ” ( Figure 5.37 ).
INCLUDE AS MANY DEFAULTS AS POSSIBLE
Like any good web form, include as many defaults as possible (see the SMART
DEFAULTS pattern in Chapter 2), especially in situations where users may have
entered information in previous steps or during previous interactions. For

example, in a checkout wizard, the billing address could be prepopulated with
the shipping address from the previous step, or users can be offered an option
to indicate that their billing address is the same as the shipping address.
CLEARLY INDICATE USERS ’ PROGRESS THROUGH
THE WIZARD
Provide users a clear indication of where they are in the wizard, what steps they
have completed, and how many remain. This way, users know what to expect
and do not become impatient about the time it’s taking them to complete the
task ( Figure 5.38 ).
REMOVE UNNECESSARY LINKS AND BUTTONS IN THE WIZARD
Users should not be distracted with extraneous links and buttons when com-
pleting a task using wizards. Therefore, remove all extraneous links, navigation,

FIGURE 5.37
Amazon offers a summary page that asks users to review information before
placing orders. In addition, it offers users the option to set defaults for current delivery and
payment options, to minimize the number of steps they need to go through in future checkouts.
141
search bars, and buttons except those required for branding, privacy policy, and
legal disclaimers.
ALLOW USERS TO SAVE INFORMATION AND RETURN
TO WHERE THEY LEFT OFF
When an entire application uses a wizard-style interface or includes several
“ subwizards ” within it, allow users to save their information so that in subse-
quent visits, they may start from where they left off and complete their tasks
in multiple sessions. A good example is TurboTax Online, which allows users
to do their taxes online using a wizard interface. Depending on the complex-
ity and ready availability of information required to fi le the tax return, users
may require interaction over a period of time to complete their taxes. To ensure
usability of such applications, it’s important that the information entered by

users is saved and they are returned to the step where they left off when they
return to the application at a later time ( Figure 5.39 ).
Wizards

FIGURE 5.38
Progressive’s site shows where users are in the quoting process, the steps
they have completed, and the remaining steps.

FIGURE 5.39
TurboTax Online allows users to save their information and offers them the
option to return to the wizard from where they left off.
CHAPTER 5 Navigation
142
Related design patterns
Because WIZARDS are just a way to present long and/or multistep forms, form-
related patterns such as SMART DEFAULTS, REQUIRED FIELD INDICATORS,
FORGIVING FORMAT, INPUT HINTS/PROMPTS, ERROR MESSAGES, and oth-
ers are relevant (see Chapter 2).
INTRO DUCTION
For web applications of a reasonable size, accessing information only by navi-
gating the application hierarchy can become cumbersome and compromise
usability. Therefore, it’s important that information within web applications be
made searchable to get users to desired items quickly and effi ciently.
Searching can be done either in an unrestricted manner, where users enter their
query as a set of keywords or key phrases in a search fi eld (SIMPLE SEARCH),
or in a directed and structured manner, where users specify desired values of
the item attributes they are searching (PARAMETRIC SEARCH). Simple searches
are usually suffi cient for most users, but those who have more experience and
prefer specifying their search precisely may benefi t from using ADVANCED
SEARCH, which allows the formulation of complex search queries. Regardless

of the search mechanism offered, users can always benefi t by getting some
guidance on how they can improve their searches and formulate better queries
(SEARCH TIPS).
After users have submitted their criteria, web applications show matched items
ordered by relevance (SEARCH RESULTS). Although ordering by relevance is
the most appropriate way to present search results, users may prefer to reorder
them using other criteria (e.g., price when purchasing items) to get to desired
items (SORTING).
For performance reasons and to not overwhelm users with too many items,
search results are usually presented in subsets of 10 to 20 such that users can
navigate through results using controls such as next, previous, fi rst, last, and
so forth (PAGINATION). An alternative emerging approach is CONTINUOUS
SCROLLING, which also presents users a subset of search results at a time, but
instead of pagination controls, it presents additional search results as users
scroll to the bottom of the current set of results. Both approaches attempt to
address a common problem with searching — too many search results.
Users are typically offered mechanisms such as FILTERING or FACETED
SEARCH to narrow down the list of search results to a manageable number.
Searching and Filtering
CHAPTERCHAPTER 6 6
143
CHAPTER 6 Searching and Filtering
144

1
Boolean queries are expressed in words or phrases, combined using the Boolean operators such
as
AND
,
OR

,
NOT
,
XOR
, and so on.
Both mechanisms remove items within the search results that do not match
the selected fi lters or facets. The difference, however, is that in FILTERING,
users are offered narrowing options that remain the same irrespective of the
presented search results. FACETED SEARCH, however, is dynamic and the nar-
rowing options offered to users are derived from search results themselves and
continue to update as users narrow their result set.
After users have searched, fi ltered, and sorted results to their liking, consider
allowing them to save their queries (SAVED SEARCHES) and set up alerts so
that they can rerun saved queries and stay informed of new matches.
SIMPLE SEARCH
Problem
Navigating deep application hierarchies can be cumbersome and an ineffi cient
way to get to known items in web applications. In addition, it may be unclear
to users where the desired item is in the hierarchy given the available naviga-
tion options.
Solution
Allow users to search for items using keywords or key phrases and place the search
feature in a consistent location throughout the application ( Figure 6.1 ).
Why
When users know exactly what they are looking for, searching is easier and
more effi cient than navigating the application hierarchy; this is also referred
to as a known-item search . Even when a search doesn’t get users directly to the
desired item, it may allow them to skip several levels of navigation to a point
where they can navigate the rest of the hierarchy and get to the desired item
quickly. Additionally, most users are not familiar with search concepts such as

Boolean operators
1
(Nielsen, 1997) and feel more comfortable using simpler

FIGURE 6.1
A simple search box on Digg allows users to search information using keywords.
145
keyword searches than advanced searches (Spink et al., 2001; see the
ADVANCED SEARCH pattern later in this chapter).
A simple search may also benefi t users in quickly determining if an item exists
in an application. For example, users may want to know if an e-commerce
application offers item X. Searching for item X to determine whether it is
offered by the application can be far more effi cient than navigating through
the information hierarchy.
How
Allow users to search by entering one or more keywords into a search text fi eld.
In addition, let users search for key phrases by enclosing keywords within
quotes; when searching for key phrases, users are shown results containing the
exact phrase. In addition, avoid forcing users to click the “ Search ” button or tab
to the “ Search ” button; rather, let users submit their search using the “ Enter ” or
“ Return ” key.
PLACE SEARCH IN A CONSISTENT LOCATION
Place the search feature in a consistent location throughout the application to
make it easier to fi nd. Typically, it is placed in or near the page header ( Figure 6.2 )
in one of the following locations:

■
The top-right of the page.

■

The center of the page in the header area or just below it (this is quite
common in portals such as Yahoo!, MSN, and iGoogle).

■
The top-left above browsing options (e.g., above product categories in
e-commerce applications).
The top-right and top-left regions are preferred locations for placing search,
since they closely match users ’ expectations of its placement on a page (Shaikh
and Lenz, 2006).
With search available on all pages, users do not have to return to the home
page or a dedicated search page to conduct their search. This allows users to
begin new searches and reach specifi c content quickly from anywhere in the
application.
SET THE SEARCH SCOPE
For applications with hundreds and thousands of items and several item cat-
egories, allow users to restrict search to a category by letting them specify the
scope of their search. Depending on the number of scoping options available,
use radio buttons, a dropdown list, images, or tabs ( Figure 6.3 ). However, it’s
important that the page does not refresh when users choose a scoping option.
Do not scope search by default or require users to select a scoping category.
Users may not know the category to which an item belongs, which may be the
Simple Search
CHAPTER 6 Searching and Filtering
146
main reason they are searching. Therefore, default the search scope to “ all ” cat-
egories. As users navigate specifi c categories within the application (e.g., books,
music, etc.), change the default search scope to that category but still allow
users to change the scope.

FIGURE 6.2

Common placement of search areas are (a) top-right corner, (b) in the center near
the header area, and (c) top-left corner above the browse categories.
(a)
(b)
(c)
147
USE FAMILIAR LABELS FOR THE SEARCH BUTTON
Common options for action-button labels to execute a search are: “ Search, ”
“ Find, ” “ Go, ” and some form of an arrow graphic. When using “ Go ” or an
arrow graphic, it’s important that the search input box is prefaced with a
“ Search: ” label. When using “ Search ” and “ Find ” as button labels, using sepa-
rate fi eld labels is unnecessary ( Figure 6.4 ).
Simple Search

FIGURE 6.3
Amazon uses a dropdown menu to allow users to limit their search scope to a
category (a). Ask and Yahoo! allow users to scope their search by showing categories as icons
(b) or tablike links (c).
(a)
(b)
(c)

FIGURE 6.4
CNET uses a “ Go ” button to execute a search and uses the label “ Search: ” before
the search input fi eld.