Designing UIs for phones and tablets - Android Developr Lab Q3 2011
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Designing UIs for phones and tablets - Android Developr Lab Q3 2011

on

  • 1,797 views

http://paug.fr

http://paug.fr

Statistics

Views

Total Views
1,797
Views on SlideShare
1,551
Embed Views
246

Actions

Likes
1
Downloads
27
Comments
0

3 Embeds 246

http://www.paug.fr 225
http://paug.tv 18
http://feeds.feedburner.com 3

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

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…
Post Comment
Edit your comment

Designing UIs for phones and tablets - Android Developr Lab Q3 2011 Presentation Transcript

  • 1. Q3 2011
  • 2. Q3 2011Designing UIs forPhones and TabletsQ3 2011
  • 3. Q3 2011Agenda1.  Honeycomb visual design2.  Tablet UI patterns + Honeycomb framework features –  Interaction design –  Implementation3.  Do’s and don’ts4.  Example — Google I/O 2011 App 3
  • 4. Q3 2011Honeycomb visual design
  • 5. Q3 2011Introducing the Holographic UI 5
  • 6. Q3 2011Early style explorations 6
  • 7. Q3 2011Widget styling – Theme.Holo.Light 7
  • 8. Q3 2011Simplify UI – Removing boxes 8
  • 9. Q3 2011Honeycomb UI patterns andframework features
  • 10. Q3 2011UI patterns§  General solutions to recurring problems§  Framework-supported§  Guidelines, not restrictions§  Topics we’ll discuss today: 1.  Action Bar 2.  Multi-pane Layouts 3.  App Navigation 4.  Beyond the List 10
  • 11. Q3 2011Action Bar 11
  • 12. Q3 2011Action Bar – Introduction§  Not a new pattern –  Presented as phone UI pattern at Google I/O 2010 –  Used in many apps through Android Market –  Honeycomb has greatly extended its usefulness§  Dedicated real estate at the top of each screen –  Generally persistent throughout application 12
  • 13. Q3 2011Action Bar – Introduction§  Used to make frequently used actions prominent§  Supports navigation, give users a sense of place§  Convenient means of handling Menu and Search 13
  • 14. Q3 2011Action Bar – General organization§  App icon — where am I?§  View details — what can I see?§  Action buttons — what can I do here? 14
  • 15. Q3 2011Action Bar – General organization§  App icon –  Can be replaced with logo or other branding –  Give the user a sense of place –  Used to support upward navigation within the app 15
  • 16. Q3 2011Action Bar – General organization§  View details –  Simple: non-interactive title bar replacement –  Richer: Tabs, drop-down menus, breadcrumbs 16
  • 17. Q3 2011 Action Bar – General organization17 §  Action buttons –  More important / frequently-accessed action at left –  Buttons can be icon-only, text-only, or icon-and-text –  Overflow menu 17
  • 18. Q3 2011Action Bar – Contextual actions§  Action bar can transform its appearance when items are selected –  Useful for single or multiple selection –  Typically invoking via touch and hold§  Like normal action bar, three sections: –  Done button (for releasing selection) –  Selection details –  Contextual action buttons§  Implemented using ActionMode! 18
  • 19. Q3 2011Action Bar – Implementation§  Basic action bar –  Theme.Holo (default if targetSdkVersion ≥ 11) –  Action items from res/menu/ with showAsAction!§  Customizing the action bar –  ActionBar class j.mp/customizing-action-bar 19
  • 20. Q3 2011Action Bar – Compatibility1.  Write a custom action bar implementation pre-Honeycomb –  iosched –  GreenDroid –  ActionBarSherlock2.  Alternatively, defer to the standard Options menu 20
  • 21. Q3 2011Action Bar – Phones and tablets 21
  • 22. Q3 2011Multi-pane Layouts – Introduction§  Take advantage of vastly increased real estate –  Avoids excessively long line lengths§  Consolidate multiple related phone screens into a single compound view§  Provide more context (e.g. Settings) 22
  • 23. Q3 2011Multi-pane Layouts – Tips§  Panes to the right should generally present more content or details for items selected in the panes on the left. 23
  • 24. Q3 2011Multi-pane Layouts – Implementation§  Fragment class§  Optionally use the <fragment> tag in layout XML§  But fragments are a lifecycle construct, not necessarily a visual construct 24
  • 25. Q3 2011Multi-pane Layouts – Orientation change Stretch Stack (e.g. Settings) (e.g. Calendar) Expand/collapse Show/hide (e.g. Google Talk) (e.g. Gmail) 25
  • 26. Q3 2011Multi-pane Layouts – Orientation change§  Orientation changes should preserve functional parity –  User shouldn’t have to rotate device to achieve a task§  Strategies apply per-screen, not per app§  For the show/hide orientation strategy, use UP navigation to show the master pane –  e.g. Gmail conversation view 26
  • 27. Q3 2011Multi-pane Layouts – Intents 27
  • 28. Q3 2011Multi-pane Layouts – Intents 28
  • 29. Q3 2011Multi-pane Layouts – Intents§  If implementing A à B with multiple activities, need a strategy to “connect” fragments –  Activity 1 (Phone, A) –  Activity 2 (Phone, B) –  Activity 3 (Tablet, A & B) 29
  • 30. Q3 2011Strategies for “connecting” fragments1.  Phone + tablet activities implement a common interface2.  Fragments hold references to each other, or use setTargetFragment! –  Defer to startActivity if no target fragment! …! 30
  • 31. Q3 2011Strategies for “connecting” fragments …3.  Fragments call startActivity, tablet activity intercepts/overrides it!4.  Fragments call startActivity, tablet activity is singleTask (or singleTop) + routes intent to correct fragment in onNewIntent.! 31
  • 32. Q3 2011App Navigation – Introduction§  One of the more dramatic changes in Honeycomb§  Increased variety of mechanisms for direct, deep navigation into an app 32
  • 33. Q3 2011App Navigation – HighlightsRicher notificationsRicher home screen widgets ‘Recents’ 33
  • 34. Q3 2011Navigation and user memory§  Android has traditionally relied on temporal memory: –  We’re good at remembering what just happened –  Not so good with order of events from a while ago –  Potential for error, surprise§  Users have strong structural memory –  Good at relationships between screens in an app –  Used to going “Home” in web apps –  Clearer expectations for behavior 34
  • 35. Q3 2011Back versus Up§  APPLICATION UP navigates hierarchy within a single app§  SYSTEM BACK navigates history between related screens 35
  • 36. Q3 2011Example FlowsContacts Task Contacts 36
  • 37. Q3 2011Example FlowsContacts Task Contacts Contact details 37
  • 38. Q3 2011Example Flows 38
  • 39. Q3 2011Example Flows 39
  • 40. Q3 2011Example FlowsContacts Task Contacts 40
  • 41. Q3 2011Example FlowsContacts Task Contacts Contact details 41
  • 42. Q3 2011Example FlowsContacts Task Contacts Contact Compose details email 42
  • 43. Q3 2011Example Flows 43
  • 44. Q3 2011Example Flows 44
  • 45. Q3 2011Beyond the List – Introduction§  Views for media-rich applications§  “Hero moments” to break the monotony of list views§  Encourage more engaged exploration, akin to flipping through a magazine 45
  • 46. Q3 2011Beyond the List – Examples 46
  • 47. Q3 2011Beyond the List – Implementation§  CarouselView (3D) –  Renderscript –  Intended for customization j.mp/io2011-carousel-sample§  ViewPager (2D) for showing one item or page at a time 47
  • 48. Q3 2011Do’s and don’ts
  • 49. Q3 2011§  DO aim for a single §  DO extract APK dimensions for phones and tablets§  DO use the –  values/
 compatibility library dimens.xml! –  values-large/
§  DO customize visual dimens.xml! design completely, if straying from Holo §  DO use theme/style/ theme etc. to reduce redundancy§  DO support both landscape and portrait 49
  • 50. Q3 2011DO marry OS visual stylewith your brand/identity§  drawable-hdpi!§  drawable-large-mdpi-v11! 50
  • 51. Q3 2011§  DON’T assume API level ≥11 == tablet§  DON’T assume xlarge == tablet –  7" tablet is large§  DON’T use small font sizes§  DON’T overuse fill_parent; avoid excessively long lines of text 51
  • 52. Q3 2011DON’T think that tabletsare just big phonesTablets fulfill a verydifferent need. 52
  • 53. Q3 2011Example:Google I/O 2011 App
  • 54. Q3 2011The image cannot be displayed. Your computer may not have enough memory to open the image, or the image may have been corrupted. Restart your computer, and then open the file again. If the red x still appears, you may have to delete the image and then insert it again. 54
  • 55. Q3 2011 55
  • 56. Q3 2011 56
  • 57. Q3 2011 Get the code atcode.google.com/p/iosched 57
  • 58. Q3 2011 For more, visitdeveloper.android.com
  • 59. Q3 2011Copyrights and trademarks§  Android, Google are registered trademarks of Google Inc.§  All other trademarks and copyrights are the property of their respective owners. 59