15. “If you know the enemy and know yourself,
you need not fear the result of a hundred
battles... If you know neither the enemy nor
yourself, you will succumb in every battle.”
- Sun Tzu, The Art of War
20. READ THESE!
• Apple’s iPhone Human Interface Guidelines
• RIM’s BlackBerry Developer Docs.
• Windows Phone 7 Series UI Design and Interaction Guide
• Android Best Practices - UI Guidelines
• (and in general...)
21. USE THE PHONES
• Who should? artists, designers, product managers, developers,
bizdev (everyone)
• You will see what’s wrong and what’s right very quickly
• Dog food...
28. IN GENERAL...
• Use consistent metaphors
• Follow user’s mental models
• Feedback
• Forgiveness
• Aesthetic integrity
29. ISN’T THIS JUST FLUFF?
• Consider:
• Consistent user experience
• Learnability
• Better reception, reviews
30. CONSIDER THE FORM
FACTOR
• smaller screens
• slower processors
• slower wireless/carrier networks
• have less available memory
• display one screen at a time
source: BlackBerry UI Guidelines, 2009
31. BLACKBERRY HIGHLIGHTS
• Use or extend given UI components • Minimize the number of times that users
need to click the trackwheel, trackball,
• Follow the standard navigation model as trackpad, or touch screen to complete a
closely as possible to produce consistent task.
results across applications.
• Design your UI to allow users to change
• Stay focused on users' immediate task. their mind and undo commands. (Not
Display what the user needs. direct manipulation)
• Verify that the actions that are available in
the menu are relevant to users' current
context.
32. ANDROID HIGHLIGHTS
• Place most frequently used actions first
• Context Menus should be shortcuts
• Separate specific from global commands
• Don’t take over the BACK key
• Use the notifications system
39. MAKE UI ELEMENTS LARGE ENOUGH TO BE
EASY TO TAP
(Place them far enough apart that there is little risk of tapping the wrong target by mistake.)
40. MAKE UI ELEMENTS LARGE ENOUGH TO BE
EASY TO TAP
(Place them far enough apart that there is little risk of tapping the wrong target by mistake.)
41. ESCHEW PREFERENCES AS MUCH AS
POSSIBLE
(AND ASSUME THAT NEARLY ALL USERS WILL USE THE
DEFAULT SETTINGS)
42. AS YOU SHOW MORE DETAIL,
CONCEPTUALLY YOU MOVE FROM LEFT
TO RIGHT —
but it’s best to minimize how deep you can get while
drilling down to the right.
43. AS YOU SHOW MORE DETAIL,
CONCEPTUALLY YOU MOVE FROM LEFT
TO RIGHT —
but it’s best to minimize how deep you can get while
drilling down to the right.
44. AS YOU SHOW MORE DETAIL,
CONCEPTUALLY YOU MOVE FROM LEFT
TO RIGHT —
but it’s best to minimize how deep you can get while
drilling down to the right.
45. AS YOU SHOW MORE DETAIL,
CONCEPTUALLY YOU MOVE FROM LEFT
TO RIGHT —
but it’s best to minimize how deep you can get while
drilling down to the right.
46. AS YOU SHOW MORE DETAIL,
CONCEPTUALLY YOU MOVE FROM LEFT
TO RIGHT —
but it’s best to minimize how deep you can get while
drilling down to the right.
47. AS YOU SHOW MORE DETAIL,
CONCEPTUALLY YOU MOVE FROM LEFT
TO RIGHT —
but it’s best to minimize how deep you can get while
drilling down to the right.
54. A CASE FOR NATIVE
ELEMENTS
(Where possible...)
55. WHERE TROUBLE STARTS...
• Wireframes and Mocks
• Wrong fonts/UI elements
• Implying impossible flow
• Not appropriate for resolution
• Somock using correct elements, correct flow, and check it on
a phone
61. DEVELOPER’S PERSPECTIVE
• Features instead of custom UI elements
• necessary evils exist
• Users are getting a familiar a.k.a. not broken experience
• Have to deal with issues like localization
62. DESIGNER’S PERSPECTIVE
• Need to work with UX/UI folks to create a design and a
layout that is doable
• Might
have design compromised by limitations of native
elements
• Managing expectations about branding and identity
63. DON’T LET BRANDING GET
IN THE WAY.
• Brand colors
• If red is integral to your design...
• Particular wording...
• If
you don’t want to use the word search, favorites/
bookmarks...
64.
65.
66. FOLLOW EXPECTATIONS
• Existing
mental models– they will already have intuition before
they use your application
• Provides expected affordances and hinting
• So use and extend UI elements when possible.
76. CUSTOMIZATION
• Provide intelligent defaults
• iPhone: avoid if possible and use the Settings.app
• Two schools of thought on this...
• BlackBerry/Android/Other: provide Options/Settings if
possible
77. MAPPING FUNCTIONALITY
• iPhone/Android - to onscreen elements/buttons
• BlackBerry/Symbian
- limit onscreen clickable items, map to
menu items where appropriate
• Android - to onscreen elements/provide context menu as
shortcuts/drawer items as appropriate
78. PROVIDING FEEDBACK
• iPhone - Direct Manipulation wherever possible
• animation, sounds, hint with colours
• Android
• add vibrations, notifications
• BlackBerry - Prompt for saving, LED, icons, dialog boxes
79. FORGIVENESS
• Blackberry/Symbian: prompt for saving/deleting, layout
focusable items intelligently
• iPhone/Android:
• keep DM actions easily reversible
• layouttouch elements + provide smart padding when
necessary,
• spend time tweaking touch
80. STAYING CONSISTENT
• Back button should do what you think it does
• Your UI elements should behave like standard UI elements
• Providing keyboard shortcuts/gestures
• Use menus, action sheets, drawers, etc. appropriate and place
in expected locations
82. NAVIGATIONAL STATE
• sometimes it makes sense to keep track of the states for what
users are doing in your application
• Example: Facebook app...
• Bonus: betterinformation organization, device integration,
users can’t get lost
83. HOW?
• Android: Activity config (i.e. android:alwaysRetainTaskState)
• iPhone: URL mapping for Controllers, persisting last state on
application termination, handling multitasking methods
• BlackBerry: think about how your application is invoked, but
less important
84. WHAT WE TALKED ABOUT
• Know Your Users, Know Your Platforms
• UI Principles & Guidelines
• Best Practices
85. SUMMARY: BEST PRACTICES
• use native elements
• apply UI guidelines/principles according to platform
• make the app learnable from existing mental models
• don’t let the user get lost
89. IN GENERAL
• Avoid unnecessary nesting of views
• when the OS tries to figure out what to draw, it has to do a
lot more work
• Solution: flat hierarchies
• what does this mean?
• what happens? (faster layout code, faster blending, etc.)
90. ANDROID: THE PROBLEMS
• Using an inefficient layout can lead to complex layout trees
• inflation is also a problem
Refer to http://developer.android.com/resources/articles/layout-tricks-efficiency.html
91. ANDROID: WHAT TO DO
• use the right layout
• i.e. use RelativeLayout instead of LinearLayout if applicable
• inflate where optimal
• i.e. use a ViewStub if it makes sense
Refer to http://developer.android.com/resources/articles/layout-tricks-efficiency.html
92. ANDROID: WHY IT WORKS
Refer to http://developer.android.com/resources/articles/layout-tricks-efficiency.html
93. IPHONE: THE PROBLEMS
• Blending of UIView layers is very slow on the iPhone
• (anything with alpha)
• Typical layouts need to blend multiple stacked layers
• either through manually adding subviews
• or through Interface Builder
Refer to http://blog.atebits.com/2008/12/fast-scrolling-in-tweetie-with-uitableview/ or Apple’s TableSuite demo
94. IPHONE: WHAT TO DO
• Fordrawing views that require high-performance, (i.e. drawing
thousands of table view cells in a list) use one custom view
where you do all the drawing, instead of adding subviews
• Pre-blend this view using CoreGraphics
Refer to http://blog.atebits.com/2008/12/fast-scrolling-in-tweetie-with-uitableview/ or Apple’s TableSuite demo
95. IPHONE: WHY IT WORKS
• One layer means no blending (or pre-blending)
• just “one big, opaque texture”
Refer to http://blog.atebits.com/2008/12/fast-scrolling-in-tweetie-with-uitableview/ or Apple’s TableSuite demo
96. BLACKBERRY: THE PROBLEM
• Repainting a whole manager is expensive
• Costs associated with:
• add, delete, replace, etc.
97. BLACKBERRY: WHAT TO DO
• Paint only what’s visible (override subpaint(), etc.)
• Minimize the nesting of layouts (paint if it makes sense)
• Minimize calls that trigger sublayout
• i.e. don’t add lots of items to visible managers
• instead: override add/sublayout (hard) or use a temporary
manager (easy)
98. BLACKBERRY: WHY IT WORKS
• Mostly working around the default behaviour of Managers/
Fields on BlackBerry
• Tip: use a profiler to see where the time is spent in your code
• chances are sublayout is being called a lot
100. “ALL THINGS ENTAIL RISING AND
FALLING TIMING. YOU MUST BE ABLE
TO DISCERN THIS.”
— Mushashi Miyamoto
101. DO THINGS AT THE RIGHT
TIME
• If
you can hide complexity from the user, or do things while
out of sight, then things will feel fast
• If you can avoid extra work, that’s also great
• be smart in the interaction design
• (but caching is a whole separate talk!)
102. EXAMPLE: GETTING A USER’S
LOCATION
• Why does this benefit the most from doing it at the right
time?
Refer to http://developer.android.com/guide/topics/location/obtaining-user-location.html
103. THE TIMELINE FOR GETTING
LOCATION
Refer to http://developer.android.com/guide/topics/location/obtaining-user-location.html
104. SUGGESTIONS
• Start getting a location as the app starts
• Use a cached location if it is a recent/good location
Refer to http://developer.android.com/guide/topics/location/obtaining-user-location.html
106. ALL IN ALL...
• Learn your platforms, phones
• Design to platforms, guidelines
• Stick to convention, conviction
Refer to http://developer.android.com/guide/topics/location/obtaining-user-location.html