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 [...]... Unless indicated by users (e.g., when using ADVANCED SEARCH), ignore the search terms’ case when presenting search results For example, return the same results for the search keywords WEB DESIGN, ” Web Design, ” and web design. ” FIGURE 6.20 Dell’s “Search Results” page shows what users searched for and shows users’ query in the search box FIGURE 6.21 NexTag shows both the number of results on the current... supports the ADVANCED SEARCH functionality (Figure 6.7) Parametric Search FIGURE 6.7 Nabble, a web application for forums, offers a specific 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 Related design patterns If searching can be structured or directed, consider the use of PARAMETRIC... the application using high-level categories within the application, and offer suggestions to improve search results 163 164 CHAPTER 6 Searching and Filtering FIGURE 6.28 NexTag indicates that no results were found for the search query “kindella” and shows search results for the closest term, “kinsella.” In addition, they show a few related items such as “kinsella” and “sophie kinsella.” Related design. .. (see the UNOBTRUSIVE JAVASCRIPT pattern in Chapter 11) For web applications offering ADVANCED SEARCH, ensure that sorting options match information presented on the SEARCH RESULTS page This will make it possible for users to understand the results quickly, since they will be able to match them with the content presented in search results Related design patterns If search results are presented as tabular... search criteria Solution Offer users easily accessible search tips and explain different ways of specifying search criteria and formulating precise search queries (Figure 6.16) Why Search engines used by web applications vary in how they combine keywords and build precise search queries Users cannot be expected to know the nuances of every search engine they encounter Search tips can describe to users in... recognize and differentiate items better than their textual descriptions (e.g., e-commerce and media applications) However, offer an alternate text-only version for the search results as well (Figure 6.23(b)); users may not be interested in images because of slower connection speeds (e.g., when accessing the application from remote areas or on mobile devices) or because they prefer to see a text-only view... tips below the search area and shows examples of how specific search queries relate to search results (b) Search Results Related design patterns SEARCH TIPS should be considered a part of help Therefore, it’s important they answer users’ FREQUENTLY ASKED QUESTIONS (see the Web Appendix at www.elsevierdirect.com/9780123742650) SEARCH RESULTS Problem Once users have specified and submitted their search... Google uses the Ͻ h2 Ͼ tag, which improves the accessibility of the page by making it easy for screen reader users to jump from one search result to another For more information about creating accessible web applications, see Chapter 11.) 157 158 CHAPTER 6 Searching and Filtering confuse users or they would have to resort the results by relevance to get to the most appropriate matches In addition, most users... 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 criteria, it does not eliminate the possibility of large numbers of search results Allow users to narrow down their search results... (a) (b) FIGURE 6.12 The IRS offers an “Advanced Search” link near the simple search box (a), whereas MSN’s Live Search offers the “Advanced” link on the search results page (b) Why No matter how well designed the search engine, users are likely to be faced with irrelevant results Although FILTERING helps reduce the number of irrelevant search results, it helps only after the initial search query is . (see Chapter 2). INTRO DUCTION For web applications of a reasonable size, accessing information only by navi- gating the application hierarchy can become. 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