Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Best Mobile UI Practices - FITC Mobile 2010

4,437 views

Published on

Best Practices for Mobile UI Design talk from FITC Mobile 2010

Published in: Design
  • The best UI you can find at Inspired UI http://inspired-ui.com. It is the biggest collection of mobile UI patterns.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Best Mobile UI Practices - FITC Mobile 2010

  1. 1. BEST MOBILE UI PRACTICES September 18, 2010 Boris Chan Xtreme Labs
  2. 2. ABOUT ME
  3. 3. ABOUT XTREME LABS
  4. 4. A QUICK SURVEY...
  5. 5. IF YOU’RE ON TWITTER #FITC @UNDERPUNCHES
  6. 6. WHAT WE’RE TALKING ABOUT • Know Your Users, Know Your Platforms • UI Guidelines • Best Practices
  7. 7. KNOW YOUR USERS
  8. 8. Phones are all becoming smartphones. (Even in Canada)
  9. 9. Phones are all becoming smartphones.
  10. 10. 100 MILLION MOBILE USERS IN FEB. 2010 (53% INCREASE IN 6 MONTHS) SOURCE: CHAMATH PALIHAPITIYA , VP USER GROWTH, MOBILE AND INTERNATIONAL
  11. 11. MORE PEOPLE ARE USING SMARTPHONES TO DO MORE COMPLICATED THINGS.
  12. 12. THE GAME IS CHANGING • iOS (4.1/4.2) • Android (2.2 Froyo/3.0/Tablet/GoogleTV) • BlackBerry (OS 6.0/new models) • Symbian3 • Windows Phone 7
  13. 13. Source: AdMob, May 2010
  14. 14. “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
  15. 15. LEARN HOW PHONES WORK.
  16. 16. LEARN HOW USERS WORK.
  17. 17. WIN YOUR HUNDRED BATTLES.
  18. 18. KNOW YOUR PLATFORMS.
  19. 19. 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...)
  20. 20. 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...
  21. 21. SMARTPHONES ARE ALL DIFFERENT.
  22. 22. WORSE, SMARTPHONES ON THE SAME PLATFORM CAN BE DIFFERENT! (JUST ASK A BLACKBERRY OR ANDROID DEVELOPER)
  23. 23. STICKING TO CONVENTION MEANS... SOMETHING COMPLETELY DIFFERENT ON EVERY PLATFORM. (SO RTFM)
  24. 24. WHAT WE’RE TALKING ABOUT • Know Your Users, Know Your Platforms • UI Guidelines • Best Practices
  25. 25. WHAT WE’RE TALKING ABOUT UI GUIDELINES
  26. 26. IN GENERAL... • Use consistent metaphors • Follow user’s mental models • Feedback • Forgiveness • Aesthetic integrity
  27. 27. ISN’T THIS JUST FLUFF? • Consider: • Consistent user experience • Learnability • Better reception, reviews
  28. 28. 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
  29. 29. 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.
  30. 30. 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
  31. 31. IPHONE GUIDELINES
  32. 32. “Figure out the absolute least you need to do to implement the idea, do just that, and then polish the hell out of the experience.” – John Gruber
  33. 33. EACH SCREEN SHOULD DISPLAY ONE THING AT A TIME. (That “thing” may be a list, but it should just be a list.)
  34. 34. EACH SCREEN SHOULD DISPLAY ONE THING AT A TIME. (That “thing” may be a list, but it should just be a list.)
  35. 35. MINIMIZE THE NUMBER OF ON-SCREEN ELEMENTS.
  36. 36. 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.)
  37. 37. 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.)
  38. 38. ESCHEW PREFERENCES AS MUCH AS POSSIBLE (AND ASSUME THAT NEARLY ALL USERS WILL USE THE DEFAULT SETTINGS)
  39. 39. 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.
  40. 40. 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.
  41. 41. 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.
  42. 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. 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. 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. 45. KNOW YOUR PLATFORMS.
  46. 46. WHAT WE’RE TALKING ABOUT • Know Your Users, Know Your Platforms • UI Principles & Guidelines • Best Practices
  47. 47. WHAT WE’RE TALKING ABOUT BEST PRACTICES
  48. 48. BEST PRACTICES • Making a Case for Native Elements • Applying UI Principles/Guidelines • Keeping Navigational State • Bonus: The Need for Speed
  49. 49. A CASE FOR NATIVE ELEMENTS
  50. 50. A CASE FOR NATIVE ELEMENTS (Where possible...)
  51. 51. 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
  52. 52. Standard Typefaces STANDARD TYPEFACES Standard Typefaces
  53. 53. TABLE OF STANDARD FONTS American Typewriter, American Typewriter, Condensed iPhone Arial, Arial Rounded MT Bold, Courier New, Georgia, Helvetica, Marker Felt, Times New Roman, Trebuchet MS, Verdana, Zapfino BBAlpha Sans, BBAlpha Serif, BBCapitals, BBCasual, BBClarity, BBCondensed, BBMillbank, BBMillbankTall, BBSansSerif, BlackBerry BBSansSerifSquare, BBSerif, BBSerifFixed, System Droid Sans, Droid Serif, Droid Sans Android Mono WinMo MS Tahoma, Courier, MS Segoe, MS Nina
  54. 54. STICKING TO CONVENTION • Avoid over-designing • Don’t let branding get in the way • Follow Expectations
  55. 55. AVOID OVER-DESIGNING
  56. 56. 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
  57. 57. 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
  58. 58. 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...
  59. 59. 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.
  60. 60. Birdfeed - iPhone - Airfight Twitter Client Settings.app
  61. 61. RULES WERE MADE TO BE BROKEN... • Innovative interfaces • Extra polish • Poor native elements
  62. 62. BUT CONSIDER THIS... • remember that platforms are constantly evolving • if you handle things in a custom manner... • example: touch on BlackBerry
  63. 63. PLEASE... USE NATIVE ELEMENTS.
  64. 64. APPLYING UI GUIDELINES
  65. 65. APPLYING UI GUIDELINES • Exposing functionality • Building discoverability • Enabling customization • Mapping Functionality • Providing feedback • Building in forgiveness
  66. 66. EXPOSING FUNCTIONALITY • iPhone • 1:1 screen/functionality mapping • BlackBerry • context menu, keyboard shortcuts • Android • menu, drawer, notifications
  67. 67. DISCOVERABILITY • iPhone/Android • Gestures, context- switching buttons/screens • BlackBerry • Menus, keyboard shortcuts
  68. 68. 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
  69. 69. 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
  70. 70. PROVIDING FEEDBACK • iPhone - Direct Manipulation wherever possible • animation, sounds, hint with colours • Android • add vibrations, notifications • BlackBerry - Prompt for saving, LED, icons, dialog boxes
  71. 71. 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
  72. 72. 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
  73. 73. KEEPING NAVIGATIONAL STATE
  74. 74. 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
  75. 75. 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
  76. 76. WHAT WE TALKED ABOUT • Know Your Users, Know Your Platforms • UI Principles & Guidelines • Best Practices
  77. 77. 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
  78. 78. BONUS: THE NEED FOR SPEED
  79. 79. THE NEED FOR SPEED • Drawing efficiently • Do things at the right time
  80. 80. DRAWING EFFICIENTLY
  81. 81. 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.)
  82. 82. 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
  83. 83. 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
  84. 84. ANDROID: WHY IT WORKS Refer to http://developer.android.com/resources/articles/layout-tricks-efficiency.html
  85. 85. 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
  86. 86. 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
  87. 87. 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
  88. 88. BLACKBERRY: THE PROBLEM • Repainting a whole manager is expensive • Costs associated with: • add, delete, replace, etc.
  89. 89. 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)
  90. 90. 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
  91. 91. DO THINGS AT THE RIGHT TIME
  92. 92. “ALL THINGS ENTAIL RISING AND FALLING TIMING. YOU MUST BE ABLE TO DISCERN THIS.” — Mushashi Miyamoto
  93. 93. 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!)
  94. 94. 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
  95. 95. THE TIMELINE FOR GETTING LOCATION Refer to http://developer.android.com/guide/topics/location/obtaining-user-location.html
  96. 96. 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
  97. 97. LEARN THE PLATFORMS.
  98. 98. 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
  99. 99. “TRUE COMFORT IS THE ABSENCE OF AWARENESS.” – BILL STUMPF
  100. 100. THANK YOU!
  101. 101. QUESTIONS? Twitter: @underpunches Email: boris@xtremelabs.com

×