Thiết kế trải nghiệm người dùng iphone - p 25 ppsx

10 151 0
Thiết kế trải nghiệm người dùng iphone - p 25 ppsx

Đang tải... (xem toàn văn)

Thông tin tài liệu

ptg 208 CHAPTER 9 ● USER INTERFACE DESIGN FIGURE 9.28 USA TODAY uses tiered tabs (along the top) to access the newspaper sections. Grid Menu Grid menus can support more entry points than the standard Productivity style. is may be appropriate for apps that have a wide range of features or apps with visual navigation. For example, Facebook has a 3 × 3 grid home screen, and addi- tional pages can be added for Friends or Pages (FIGURE 9.29). is approach can be useful in many apps where more top-level features are wanted. But resist the temptation unless it’s absolutely necessary; every feature should be essential and contextually relevant. Also, keep in mind that the grid requires an extra step to move between sections. For example, it takes two steps to navigate from Facebook Photos to Events; it would be one step if a tab bar were used. Other apps that use the grid menu are LinkedIn and Viper. FIGURE 9.29 Facebook uses the grid style on the home screen. Download from www.wowebook.com ptg USER INTERFACE Q&A 209 Top Tabs Top tabs are si milar to t he sta nd ard one s, except t hey appea r along the top of t he app. Apps tend to use this approach to save vertical space, omitting the traditional navigation bar. For example, Yahoo! Finance devotes more real estate to stock information using this model (FIGURE 9.30). Although the approach can work well, don’t use it unless you have a strong reason. FIGURE 9.30 Yahoo! Finance displays tabs at the top of the screen. HOW SHOULD I PRESENT TASKS ON THE PRODUCTIVITY-STYLE DETAIL VIEW? Tasks on the Productivity detail view can be presented in-line, via the toolbar, or some combination of the two. Your approach will depend largely on the type of tasks and the desired navigation model. In-line Tasks should be presented in-line when they relate to a specic piece of content on the detail view, as is done on Foursquare (FIGURE 9.31). is is particularly eec- tive for compact designs since minimal scrolling is required to see all of the tasks. Showing tasks in-line allows you to display the tab bar in the detail view, provid- ing easy access to other sections of your app. Toolbar Showing tasks in the toolbar is eective when the tasks are associated with the entire detail view. For example, all of the tasks on AP News (Share, Favorite, and Save) apply to the entire article (FIGURE 9.32). at said, AP could have placed these tasks in-line; however, the design would be less successful. e tasks would be less WARNING! As mentioned earlier, diverging from the stan- dards may make your app more difficult to learn and use, plus it may be rejected by Apple. Download from www.wowebook.com ptg 210 CHAPTER 9 ● USER INTERFACE DESIGN visible if they were shown at the end of the article. And they might get lost at the top since the space is already crowded with an ad and other UI controls. Since the tab bar is not shown along the bottom, two taps are needed to access the other app sections. FIGURE 9.31 In the Foursquare app, related tasks are placed in-line. FIGURE 9.32 AP tasks are presented in the toolbar at the bottom of the screen. HOW DO I CHOOSE THE RIGHT CONTROL? e iOS has a number of standard controls for making selections. Choosing the appropriate one can be challenging since more than one may apply for a particu- lar use case. As you consider which one to use, evaluate the context and type of information, the number of items, and whether or not maintaining “state,” the previous selection, is required. Action Sheet Action sheets are primarily used to present options for completing a task, such as sharing content (FIGURE 9.33). ey may also be used to request conrmation before completing a potentially dangerous task. • Number of options: Two to seven options, including a Cancel button. • Maintains state: No. • Common mistakes: Excessive color coding. Unless it’s a potentially destructive action (which should be red and placed at the top), use white for all options except Cancel. e Cancel button should be dark gray or black and placed at the bottom. Download from www.wowebook.com ptg USER INTERFACE Q&A 211 FIGURE 9.33 Action sheet for Tweets on Tweetie Alert Alerts oat above the app screen and provide critical information. ey are shown when something unexpected or urgent has occurred that requires the user’s atten- tion, for example, when exiting an app, as shown in the iLike app (FIGURE 9.34). • Number of options: One to two. • Maintains state: No. • Common mistakes: Overuse. Alerts should be used sparingly since they take users out of context and are visually jarring. FIGURE 9.34 Alert on iLike Download from www.wowebook.com ptg 212 CHAPTER 9 ● USER INTERFACE DESIGN Picker ere are two types of pickers: the date and time picker, and the generic picker. e date and time picker provides an ecient way to select a specic date or time (FIGURE 9.35). e generic picker can be used to display any set of values (FIGURE 9.36). One of the downsides is that the user can’t easily see all of the options. If the content is well understood (e.g., a list of countries), this may be ne, but otherwise consider using a table view, which is discussed later in this section. • Number of options: Can show a large number of options. • Maintains state: Yes. • Common mistakes: Including a large set of items that are not well under- stood. In those cases, the list view may be more appropriate. FIGURE 9.35 Date picker on FlightTrack FIGURE 9.36 Meal type on Betty Crocker Segmented Control Segmented controls can display dierent views of similar content. ey are typi- cally used when ltering or sorting list views (FIGURES 9.37–9.38). • Number of options: Five maximum, though this is dependent on label length. • Maintains state: Yes. • Common mistakes: Placed out of context. e control should be close to the content being manipulated. Download from www.wowebook.com ptg USER INTERFACE Q&A 213 FIGURE 9.37 Segmented control used to change the view on the REALTOR. com app FIGURE 9.38 Segmented control used to sort movie lists on Flixster Slider Sliders allow users to choose from a range of values along a single dimension. ey are oen used in music- and art-related apps (FIGURES 9.39–9.40). • Number of options: Start and end points dened within the control. • Maintains state: Yes. • Common mistakes: Ambiguous end points. Best to provide cues on either end as in done in Sketches. FIGURE 9.39 Brush size selected with a slider on the Sketches app FIGURE 9.40 Volume selected with a slider on the Pandora app Download from www.wowebook.com ptg 214 CHAPTER 9 ● USER INTERFACE DESIGN Switch Switch controls present two mutually exclusive choices or states (FIGURES 9.41–9.42). • Number of options: Two. • Maintains state: Yes. • Common mistakes: Outcome of action unclear because of poor labels. FIGURE 9.41 Switch used to turn Auto Play on and off on HearPlanet FIGURE 9.42 Switch used to choose Celsius or Fahrenheit on iThermometer Table Views Table views present data in a list with multiple rows; the rows can be divided into sections or groups (FIGURE 9.43). • Number of options: Large number possible. • Maintains state: Yes. • Common mistakes: Too many items. Search may be preferable for extremely long lists. FIGURE 9.43 Table view used to choose a language for Yahoo! settings Download from www.wowebook.com ptg BACK-END UI CHECKLIST 21 5 Back-End UI Checklist In addition to creating sketches and/or prototypes of your app designs, consider documenting functional requirements that may impact the user experience. Some important ones include the following: • Number of list items e default number of items in a list will vary based on the app, the con- tent, and any parameters. For example, lists with images tend to include fewer items given the row height as well as the time required to display the images. On the other hand, the lists in most location-based apps are dynamically limited using distance parameters, though it’s still necessary to determine the default (e.g., show ten nearby restaurants). Whatever you decide, make sure you include these requirements in your documentation. • Distance parameters In order to display location-based “nearby” views, you need to specify what “nearby” means; is it one mile? Five miles? Ten miles? Does this denition vary if the current location is a city versus a suburb versus a rural area? To adapt to the locale variations, you may want to provide a default but still allow users to change this value via the user interface. • Truncation and string length More oen than not, the items in your list view will vary in length. For example, one title may t onto one line whereas another may require three lines. If you want to keep the title to one line, you need to specify this in your documentation. As you formulate your recommendation, consider experimenting with a variety of content scenarios: best case, worst case, and somewhere in between. • Loading content If not specied otherwise, each row within a list view loads one at a time. is approach is ne with text-only lists. However, there may be a delay if there are images. To improve the perceived speed, you may want to load the text rst, followed by the images. Additionally, make sure your images are optimized for fast downloading. • Caching strategy As discussed earlier, caching app content can help maintain the status quo when there are network connection problems. If this situation applies to your app, be sure to outline your caching strategy in your documentation and discuss it with your technical team. Download from www.wowebook.com ptg 216 CHAPTER 9 ● USER INTERFACE DESIGN Depending on the app and approach, caching could add signicant time to the development schedule. Some apps may also store content on the device. If you go with this approach, keep in mind that the download will be much larger. For example, Betty Crocker stores recipes on the device and takes up a whopping 18.6MB of space, whereas Epicurious accesses most content over the network and weighs in at 3.3MB. • Dealing with null results You r docu mentation should explain how to present t he UI when no content is found. For example, you may have headers in your nearby restaurant view that are within a 5-, 10-, and 15-minute walk. However, what hap- pens when there are no restaurants within a 5-minute walk? If you want to hide the header, you should note this in your specication. On a related note, if images are provided for each row in a list but certain list items don’t have images, be sure to include a “null” image (a representative placeholder image), as shown in FIGURE 9.44. • Recents Apps that include a Recents section should specify how many items to store and for how long. In addition, you can let users choose how many items to store and/or let them remove the content. FIGURE 9.45 illustrates how Yelp lets users remove Recents content. FIGURE 9.44 NY Art Beat shows a gray image when no image is available. FIGURE 9.45 Yelp lets users “clear” their Recently Viewed list. Download from www.wowebook.com ptg SUMMARY 217 Summary Rening your app’s UI may take several iterations before it feels “done.” As you work on your renements, keep this chapter’s best practices in mind. Although UI controls may evolve over time, these best practices should be applicable to current and future iPhone apps. 1.Be welcoming. 2. Know thy user. 3. Let the content shine. 4. Make selections fast and error-free. 5. Provide appropriate feedback. 6. Minimize the pain. In addition to these high-level recommendations, it’s important to review the iPhone HIG and make sure your app adheres to the guidelines. If areas in the iPhone HIG are unclear, such as when to use tabs versus the toolbar, review the tips oered in this chapter. And if you are still uncertain which design direc- tion is appropriate, conduct a usability test and make renements based on user feedback. To ensu re t hat your app is bu ilt as intended , don’t forget to spend some time doc- umenting both your “visible” and “invisible” requirements. ■ Download from www.wowebook.com . sta nd ard one s, except t hey appea r along the top of t he app. Apps tend to use this approach to save vertical space, omitting the traditional navigation bar. For example, Yahoo! Finance devotes. best practices should be applicable to current and future iPhone apps. 1.Be welcoming. 2. Know thy user. 3. Let the content shine. 4. Make selections fast and error-free. 5. Provide appropriate. DESIGN Depending on the app and approach, caching could add signicant time to the development schedule. Some apps may also store content on the device. If you go with this approach, keep in mind

Ngày đăng: 06/07/2014, 19:20

Tài liệu cùng người dùng

Tài liệu liên quan