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

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