Best Mobile UI Practices - FITC Mobile 2010
Upcoming SlideShare
Loading in...5
×
 

Best Mobile UI Practices - FITC Mobile 2010

on

  • 4,364 views

Best Practices for Mobile UI Design talk from FITC Mobile 2010

Best Practices for Mobile UI Design talk from FITC Mobile 2010

Statistics

Views

Total Views
4,364
Views on SlideShare
4,362
Embed Views
2

Actions

Likes
7
Downloads
75
Comments
1

2 Embeds 2

http://www.linkedin.com 1
http://pinterest.com 1

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • The best UI you can find at Inspired UI http://inspired-ui.com. It is the biggest collection of mobile UI patterns.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • - why this talk is important: ubiquity of smartphones <br />
  • - software engineering, waterloo <br /> - but music/social media <br /> - producer/consumer <br />
  • Mobile Strategy & Development <br /> Award-winning apps for big brands <br /> Located here in Toronto <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • This is happening even sooner. <br />
  • Kunal on the mobile lifestyle <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • If you do it right... <br />
  • <br />
  • for mobile specifically... more specific during the talk <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • so all in all... <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />

Best Mobile UI Practices - FITC Mobile 2010 Best Mobile UI Practices - FITC Mobile 2010 Presentation Transcript

  • BEST MOBILE UI PRACTICES September 18, 2010 Boris Chan Xtreme Labs
  • ABOUT ME
  • ABOUT XTREME LABS
  • A QUICK SURVEY...
  • IF YOU’RE ON TWITTER #FITC @UNDERPUNCHES
  • WHAT WE’RE TALKING ABOUT • Know Your Users, Know Your Platforms • UI Guidelines • Best Practices
  • KNOW YOUR USERS
  • Phones are all becoming smartphones. (Even in Canada)
  • Phones are all becoming smartphones.
  • 100 MILLION MOBILE USERS IN FEB. 2010 (53% INCREASE IN 6 MONTHS) SOURCE: CHAMATH PALIHAPITIYA , VP USER GROWTH, MOBILE AND INTERNATIONAL
  • MORE PEOPLE ARE USING SMARTPHONES TO DO MORE COMPLICATED THINGS.
  • 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
  • Source: AdMob, May 2010
  • “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
  • LEARN HOW PHONES WORK.
  • LEARN HOW USERS WORK.
  • WIN YOUR HUNDRED BATTLES.
  • KNOW YOUR PLATFORMS.
  • 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...)
  • 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...
  • SMARTPHONES ARE ALL DIFFERENT.
  • WORSE, SMARTPHONES ON THE SAME PLATFORM CAN BE DIFFERENT! (JUST ASK A BLACKBERRY OR ANDROID DEVELOPER)
  • STICKING TO CONVENTION MEANS... SOMETHING COMPLETELY DIFFERENT ON EVERY PLATFORM. (SO RTFM)
  • WHAT WE’RE TALKING ABOUT • Know Your Users, Know Your Platforms • UI Guidelines • Best Practices
  • WHAT WE’RE TALKING ABOUT UI GUIDELINES
  • IN GENERAL... • Use consistent metaphors • Follow user’s mental models • Feedback • Forgiveness • Aesthetic integrity
  • ISN’T THIS JUST FLUFF? • Consider: • Consistent user experience • Learnability • Better reception, reviews
  • 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
  • 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.
  • 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
  • IPHONE GUIDELINES
  • “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
  • EACH SCREEN SHOULD DISPLAY ONE THING AT A TIME. (That “thing” may be a list, but it should just be a list.)
  • EACH SCREEN SHOULD DISPLAY ONE THING AT A TIME. (That “thing” may be a list, but it should just be a list.)
  • MINIMIZE THE NUMBER OF ON-SCREEN ELEMENTS.
  • 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.)
  • 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.)
  • ESCHEW PREFERENCES AS MUCH AS POSSIBLE (AND ASSUME THAT NEARLY ALL USERS WILL USE THE DEFAULT SETTINGS)
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • KNOW YOUR PLATFORMS.
  • WHAT WE’RE TALKING ABOUT • Know Your Users, Know Your Platforms • UI Principles & Guidelines • Best Practices
  • WHAT WE’RE TALKING ABOUT BEST PRACTICES
  • BEST PRACTICES • Making a Case for Native Elements • Applying UI Principles/Guidelines • Keeping Navigational State • Bonus: The Need for Speed
  • A CASE FOR NATIVE ELEMENTS
  • A CASE FOR NATIVE ELEMENTS (Where possible...)
  • 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
  • Standard Typefaces STANDARD TYPEFACES Standard Typefaces
  • 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
  • STICKING TO CONVENTION • Avoid over-designing • Don’t let branding get in the way • Follow Expectations
  • AVOID OVER-DESIGNING
  • 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
  • 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
  • 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...
  • 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.
  • Birdfeed - iPhone - Airfight Twitter Client Settings.app
  • RULES WERE MADE TO BE BROKEN... • Innovative interfaces • Extra polish • Poor native elements
  • BUT CONSIDER THIS... • remember that platforms are constantly evolving • if you handle things in a custom manner... • example: touch on BlackBerry
  • PLEASE... USE NATIVE ELEMENTS.
  • APPLYING UI GUIDELINES
  • APPLYING UI GUIDELINES • Exposing functionality • Building discoverability • Enabling customization • Mapping Functionality • Providing feedback • Building in forgiveness
  • EXPOSING FUNCTIONALITY • iPhone • 1:1 screen/functionality mapping • BlackBerry • context menu, keyboard shortcuts • Android • menu, drawer, notifications
  • DISCOVERABILITY • iPhone/Android • Gestures, context- switching buttons/screens • BlackBerry • Menus, keyboard shortcuts
  • 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
  • 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
  • PROVIDING FEEDBACK • iPhone - Direct Manipulation wherever possible • animation, sounds, hint with colours • Android • add vibrations, notifications • BlackBerry - Prompt for saving, LED, icons, dialog boxes
  • 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
  • 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
  • KEEPING NAVIGATIONAL STATE
  • 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
  • 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
  • WHAT WE TALKED ABOUT • Know Your Users, Know Your Platforms • UI Principles & Guidelines • Best Practices
  • 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
  • BONUS: THE NEED FOR SPEED
  • THE NEED FOR SPEED • Drawing efficiently • Do things at the right time
  • DRAWING EFFICIENTLY
  • 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.)
  • 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
  • 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
  • ANDROID: WHY IT WORKS Refer to http://developer.android.com/resources/articles/layout-tricks-efficiency.html
  • 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
  • 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
  • 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
  • BLACKBERRY: THE PROBLEM • Repainting a whole manager is expensive • Costs associated with: • add, delete, replace, etc.
  • 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)
  • 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
  • DO THINGS AT THE RIGHT TIME
  • “ALL THINGS ENTAIL RISING AND FALLING TIMING. YOU MUST BE ABLE TO DISCERN THIS.” — Mushashi Miyamoto
  • 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!)
  • 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
  • THE TIMELINE FOR GETTING LOCATION Refer to http://developer.android.com/guide/topics/location/obtaining-user-location.html
  • 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
  • LEARN THE PLATFORMS.
  • 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
  • “TRUE COMFORT IS THE ABSENCE OF AWARENESS.” – BILL STUMPF
  • THANK YOU!
  • QUESTIONS? Twitter: @underpunches Email: boris@xtremelabs.com