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

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 bi

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

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

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 pleting a task using wizards Therefore, remove all extraneous links, navigation,

com-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

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 availabilcomplex-ity 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, 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

CHAPTER CHAPTER 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

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

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 ” 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

cat-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)

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

CHAPTER 6 Searching and Filtering

148

Since users may not know what they can search on, offer a prompt and/

or examples of what they can enter in the search fi eld Because of the ited space available near most search areas, a common practice is to embed the search prompt within the search fi eld ( Figure 6.5 ) However, remove the prompt as soon as users focus on the search fi eld so that they do not have to delete the prompt text before entering search terms

SUGGEST EFFECTIVE KEYWORDS

Prompt users with appropriate keywords and search terms as they start typing

in the search box to reduce typing errors and increase the relevance of search results ( Figure 6.6 ; see also the AUTOSUGGEST/AUTOCOMPLETION pattern

FIGURE 6.6 Answers.com suggests matching search terms as users enter information in the search box Users can click an item from the suggested list and go to the corresponding page

FIGURE 6.5 Home Depot puts the prompt within the search fi eld to indicate to users what they can enter

Related design patterns

If searching can be structured or directed, consider the use of PARAMETRIC

SEARCH because it allows users to specify search criteria more precisely For

expert users, offer a separate ADVANCED SEARCH option and include SEARCH

TIPS that explain ways in which users can improve search effectiveness

PARAMETRIC SEARCH

Problem

Users may not know the best way to formulate their search queries as keywords

or key phrases when looking for items with several attributes (e.g., prices of

red-eye fl ights from Denver to San Francisco departing the following Wednesday

and returning Friday) This may lead them to specify a search that is either too

general, requiring them to wade through a large number of irrelevant results, or

too specifi c, thereby eliminating many useful results

Solution

Allow searching for items based on their characteristics (i.e., parameters) For

example, when searching for fl ights, ask users to specify departure city, arrival

city, departure and arrival dates, and so forth In addition, where applicable,

restrict users ’ search query by requiring them to choose from a predetermined

set of options presented as dropdown lists, radio buttons, or checkboxes

( Figure 6.8 )

Why

Allowing users to specify their search in a structured manner makes it easy for them

to formulate search queries and prevents them from making assumptions about

which attributes are searchable In some instances, searching by a set of parameters

seems more natural than doing a free-form keyword search — for example, making

fl ight, hotel, or car reservations; fi nding driving directions; fi nding homes to buy

or sell; fi nding people with specifi c profi les and interests; and so forth

Parametric Search

FIGURE 6.7 Nabble, a web application for forums, offers a specifi c search language to its

members to allow them to enter precise queries For example, to search in the “ Apache ” forum

only, users can include “ forum:Apache ” in their query

CHAPTER 6 Searching and Filtering

150

How

Ask users to enter search criteria in a form with clearly identifi ed search eters Where appropriate, segment the form into multiple sections so that only appropriate search fi elds are shown to users ( Figure 6.9 )

HIDE NOT-SO-COMMON SEARCH PARAMETERS

Even when using a parametric search, it’s important to keep the search simple and not overwhelm users by offering search parameters they are unlikely to use Hide infrequently used options under “ advanced options ” or “ more options ” and make them available only when users request them ( Figure 6.10 )

Related design patterns

Although a PARAMETRIC SEARCH can help capture precise search ria, it does not eliminate the possibility of large numbers of search results Allow users to narrow down their search results by using either FILTERING or FACETED SEARCH

crite-FIGURE 6.8 Match.com, like many other dating service sites, allows users to formulate their search by asking for their gender, “ seeking ” gender, ages, and ZIP code They also offer advanced options to allow users to indicate interests, income level, and so forth

FIGURE 6.9 Yahoo! Travel shows users search parameters relevant only for the selected tab