Dirk Dougherty | 3e529b4 | 2013-10-19 11:43:41 -0700 | [diff] [blame] | 1 | page.title=Full Screen |
Joe Fernandez | 33baa5a | 2013-11-14 11:41:19 -0800 | [diff] [blame] | 2 | page.tags=full screen,immersive,leanback |
Dirk Dougherty | 3e529b4 | 2013-10-19 11:43:41 -0700 | [diff] [blame] | 3 | @jd:body |
| 4 | |
| 5 | <p> |
| 6 | Some content is best experienced full screen, like videos, games, image |
| 7 | galleries, books, and slides in a presentation. You can engage users more |
| 8 | deeply with content in full screen by minimizing visual distraction from app |
| 9 | controls and protecting users from escaping the app accidentally. |
| 10 | </p> |
| 11 | |
Dirk Dougherty | 2a91ecb | 2013-11-05 19:06:27 -0800 | [diff] [blame] | 12 | <div style="margin:auto;padding:auto;text-align:center;"> |
Dirk Dougherty | 3e529b4 | 2013-10-19 11:43:41 -0700 | [diff] [blame] | 13 | <img src="{@docRoot}design/media/fullscreen_landing.png" style="margin:1em auto 2em auto;"> |
Dirk Dougherty | 2a91ecb | 2013-11-05 19:06:27 -0800 | [diff] [blame] | 14 | </div> |
Dirk Dougherty | 3e529b4 | 2013-10-19 11:43:41 -0700 | [diff] [blame] | 15 | <p> |
| 16 | In version 4.4, Android offers two approaches for making your app go full |
| 17 | screen: Lean Back and Immersive. In both approaches, all persistent system |
| 18 | bars are hidden. The difference between them is how the user brings the bars |
| 19 | back into view. |
| 20 | </p> |
| 21 | |
| 22 | <div class="layout-content-row"> |
| 23 | <div class="layout-content-col span-6"> |
| 24 | <h4>Lean Back</h4> |
| 25 | <p>Touch the screen anywhere to bring back system bars. </p> |
| 26 | <img src="{@docRoot}design/media/fullscreen_leanback.png" style="width:311px;"> |
| 27 | </div> |
| 28 | <div class="layout-content-col span-6"> |
| 29 | <h4>Immersive</h4> |
| 30 | <p>Swipe from the any edge of the screen with a hidden bar to bring back system bars. </p> |
| 31 | <img src="{@docRoot}design/media/fullscreen_immersive_swipe_bottom.png" style="width:160px;float:right"> |
| 32 | <img src="{@docRoot}design/media/fullscreen_immersive_swipe_top.png" style="width:160px"> |
| 33 | </div> |
| 34 | </div> |
| 35 | |
| 36 | <h2 id="leanback"> |
| 37 | Lean Back |
| 38 | </h2> |
| 39 | |
| 40 | <p> |
| 41 | The Lean Back approach is for full-screen experiences in which users won't be |
| 42 | interacting heavily with the screen while consuming content, like while |
| 43 | watching a video. |
| 44 | </p> |
| 45 | |
| 46 | <p> |
| 47 | In this type of experience, users are leaning back and watching the screen. |
| 48 | Then, when they need to bring back the bars, they simply touch anywhere. This |
| 49 | gesture is easy and intuitive. |
| 50 | </p> |
| 51 | |
| 52 | <img src="{@docRoot}design/media/fullscreen_leanback.png" style="width:311px;"> |
| 53 | |
| 54 | <h2 id="immersive"> |
| 55 | Immersive |
| 56 | </h2> |
| 57 | |
| 58 | <p> |
| 59 | The Immersive approach is mainly intended for apps in which the user will be |
| 60 | heavily interacting with the full screen as part of the primary experience. |
| 61 | Examples are games, viewing images in a gallery, or reading paginated |
| 62 | content, like a book or slides in a presentation. |
| 63 | </p> |
| 64 | |
| 65 | <p> |
| 66 | In this type of experience, when users need to bring back the system bars, |
| 67 | they swipe from any edge where a system bar is hidden. By requiring this more |
| 68 | deliberate gesture, the user's deep engagement with your app won't be |
| 69 | interrupted by accidental touches and swipes. |
| 70 | </p> |
| 71 | |
| 72 | <div class="layout-content-row"> |
| 73 | <div class="layout-content-col span-6"> |
| 74 | <img src="{@docRoot}design/media/fullscreen_immersive_swipe_bottom.png" style="width:160px;float:right"> |
| 75 | <img src="{@docRoot}design/media/fullscreen_immersive_swipe_top.png" style="width:160px"> |
| 76 | </div> |
| 77 | </div> |
| 78 | |
| 79 | <p> |
| 80 | The user learns about the gesture to bring back the system bars through a |
| 81 | message that appears the first time the app goes full screen. |
| 82 | </p> |
| 83 | |
| 84 | <p> |
| 85 | If your app has its own controls that aren't needed when a user is immersed |
| 86 | in content, make them disappear and reappear in sync with the system bars. |
| 87 | This rule also applies to any app-specific gestures you might have for hiding |
| 88 | and showing app controls. For example, if touching anywhere on the screen |
| 89 | toggles the appearance of an action bar or a palette, then it must also |
| 90 | toggle the appearance of system bars. |
| 91 | </p> |
| 92 | |
| 93 | <p> |
| 94 | You might be tempted to use this approach just to maximize screen real |
| 95 | estate. But be mindful of how often users jump in and out of apps to check |
| 96 | notifications, do impromptu searches, and more. This approach will cause |
| 97 | users to lose easy access to system navigation, so a little extra space |
| 98 | should not be the only benefit they're getting in return. |
| 99 | </p> |
| 100 | |
| 101 | <h2 id="variation_using_edges"> |
| 102 | Variation: Swiping from edges with bars also affects the app |
| 103 | </h2> |
| 104 | |
| 105 | <p> |
| 106 | In the Immersive approach, any time a user swipes from an edge with a system |
| 107 | bar, the Android framework takes care of revealing the system bars. Your app |
| 108 | won't even be aware that this gesture occurred. |
| 109 | </p> |
| 110 | |
| 111 | <p> |
| 112 | But in some apps, the user might occasionally need to swipe from the edge as |
| 113 | <strong>part of the primary app experience</strong>. Examples are games and |
| 114 | drawing applications. |
| 115 | </p> |
| 116 | |
| 117 | <p> |
| 118 | For apps with this requirement, you can use a variation on the Immersive |
| 119 | approach: when a user swipes from an edge with a system bar, system bars are |
| 120 | shown and the gesture is passed to the app so the app can respond to the |
| 121 | gesture. |
| 122 | </p> |
| 123 | |
| 124 | <p> |
| 125 | For example, in a drawing app that uses this approach, if a user wants to |
| 126 | draw a line that begins at the very edge of the screen, swiping from the edge |
| 127 | would reveal the system bars and also start drawing a line that begins at the |
| 128 | very edge. |
| 129 | </p> |
| 130 | |
| 131 | <p> |
| 132 | In this approach, to minimize disruption while a user is deeply engaged in |
| 133 | the app, the system bars are semi-transparent. The bars automatically |
| 134 | disappear after a few seconds of no interaction or as soon as the user |
| 135 | touches or gestures anywhere outside the system bars. |
| 136 | </p> |
| 137 | |
| 138 | <h2 id="lightsout">What About Lights Out Mode?</h2> |
| 139 | |
| 140 | <p> |
| 141 | Before Android 4.4, the design guideline was to use Lights Out mode, a mode |
| 142 | in which the Action Bar and Status Bar fades away and becomes unavailable |
| 143 | after a few seconds of inactivity. The Navigation Bar is still available and |
| 144 | responds to touches but appears dimmed. |
| 145 | </p> |
| 146 | |
| 147 | <p> |
| 148 | Replace previous implementations of Lights Out mode with the Lean Back or |
| 149 | Immersive approaches. Continue to use Lights Out mode for implementations of |
| 150 | your app targeted for earlier releases. |
Joe Fernandez | 33baa5a | 2013-11-14 11:41:19 -0800 | [diff] [blame] | 151 | </p> |