diff options
Diffstat (limited to 'docs/html/design')
42 files changed, 666 insertions, 62 deletions
diff --git a/docs/html/design/auto/index.jd b/docs/html/design/auto/index.jd new file mode 100644 index 0000000..aac79ab --- /dev/null +++ b/docs/html/design/auto/index.jd @@ -0,0 +1,35 @@ +page.title=Auto +@jd:body + +<style> +.auto-img-container-cols { + position:relative; + margin-bottom:25px; + margin-top:25px; +} +.auto-img-frame-cols { + z-index:2; + position:relative; +} +.auto-img-shot-cols { + position:absolute; + top:5px; + left:2px; + z-index:1; +} +</style> + +<div class="auto-img-container-cols" style="float:right; margin:0 0 40px 40px;width:460px"> + <img class="auto-img-frame-cols" src="/auto/images/assets/00_frame.png"> + <img class="auto-img-shot-cols" src="/auto/images/assets/03_a_musict.png"> +</div> + +<p>Android Auto is <strong>coming soon</strong> and brings apps to the car, +integrating with the vehicle's input controls and display.</p> + +<p>The future design guidelines provide templates that define the user interaction model for all apps and let you hook into a standard UI with touch and voice controls. The templates meet international best practices for reducing driver distraction while still letting you customize and brand them to properly deliver your content.</p> + +<p><a href="{@docRoot}auto/index.html">Learn more about Android Auto</a>.</p> + + + diff --git a/docs/html/design/design_toc.cs b/docs/html/design/design_toc.cs index 2bd0bf9..885f336 100644 --- a/docs/html/design/design_toc.cs +++ b/docs/html/design/design_toc.cs @@ -5,7 +5,26 @@ <ul> <li><a href="<?cs var:toroot ?>design/get-started/creative-vision.html">Creative Vision</a></li> <li><a href="<?cs var:toroot ?>design/get-started/principles.html">Design Principles</a></li> - <li><a href="<?cs var:toroot ?>design/get-started/ui-overview.html">UI Overview</a></li> + </ul> + </li> + + <li class="nav-section"> + <div class="nav-section-header"><a href="<?cs var:toroot ?>design/devices.html">Devices</a></div> + <ul> + <li><a href="<?cs var:toroot ?>design/handhelds/index.html">Phones & Tablets</a></li> + <li class="nav-section"> + <div class="nav-section-header"> + <a href="<?cs var:toroot ?>design/wear/index.html">Wear</a></div> + <ul> + <li><a href="<?cs var:toroot ?>design/wear/creative-vision.html">Creative Vision</a></li> + <li><a href="<?cs var:toroot ?>design/wear/principles.html">Design Principles</a></li> + <li><a href="<?cs var:toroot ?>design/wear/structure.html">App Structure</a></li> + <li><a href="<?cs var:toroot ?>design/wear/patterns.html">UI Patterns</a></li> + <li><a href="<?cs var:toroot ?>design/wear/style.html">Style</a></li> + </ul> + </li> + <li><a href="<?cs var:toroot ?>design/tv/index.html">TV</a></li> + <li><a href="<?cs var:toroot ?>design/auto/index.html">Auto</a></li> </ul> </li> @@ -67,25 +86,6 @@ </li> <li class="nav-section"> - <div class="nav-section-header"><a href="<?cs var:toroot ?>design/devices.html">Devices</a></div> - <ul> - <!-- wear design goes here --> - <li class="nav-section"> - <div class="nav-section-header"> - <a href="<?cs var:toroot ?>design/tv/index.html">TV</a></div> - <ul> - <li><a href="<?cs var:toroot ?>design/tv/principles.html">Design Principles</a></li> - <li><a href="<?cs var:toroot ?>design/tv/ui-overview.html">UI Overview</a></li> - <li><a href="<?cs var:toroot ?>design/tv/style.html">Style</a></li> - <li><a href="<?cs var:toroot ?>design/tv/patterns.html">Patterns</a></li> - </ul> - </li> - - </ul> - </li> - - - <li class="nav-section"> <div class="nav-section-header empty"><a href="<?cs var:toroot ?>design/downloads/index.html">Downloads</a></div> </li> diff --git a/docs/html/design/devices.jd b/docs/html/design/devices.jd new file mode 100644 index 0000000..0015d01 --- /dev/null +++ b/docs/html/design/devices.jd @@ -0,0 +1,37 @@ +page.title=Devices +page.viewport_width=970 +section.landing=true +header.hide=1 +footer.hide=1 +@jd:body + +<style> +#landing-graphic-container { + position: relative; +} + +#text-overlay { + position: absolute; + left: 0; + top: 420px; + width: 360px; + +} +#hero-image { +} +</style> + +<div id="landing-graphic-container"> + <div id="text-overlay"> + <p itemprop="description">The device-centric UI principles, overviews, and detailed guidelines + described here build on the core <a href="{@docRoot}design/get-started/principles.html">Android Design Principles</a> + to provide more specific design guidance for different form factors. + </p> + <p> + <a href="{@docRoot}design/handhelds/index.html" class="landing-page-link">Phones & Tablets</a></p> + </div> + <a id="hero-image" href="{@docRoot}design/handhelds/index.html"> + <img src="{@docRoot}design/media/device_family.png"> + </a> +</div> + diff --git a/docs/html/design/get-started/creative-vision.jd b/docs/html/design/get-started/creative-vision.jd index 1ce305a..9261c6e 100644 --- a/docs/html/design/get-started/creative-vision.jd +++ b/docs/html/design/get-started/creative-vision.jd @@ -6,10 +6,10 @@ page.title=Creative Vision <div class="vspace size-1"> </div> <p itemprop="description"> - We focused the design of Android around three overarching goals, which apply - to our core apps as well as the system at large. As you design apps to work - with Android, consider these goals: <em>Enchant me</em>, <em>Simplify my - life</em>, and <em>Make me amazing</em> + Starting with Ice Cream Sandwich, we focused the design of + Android around these three overarching goals, which apply + to our core apps as well as the system at large. + As you work with Android, consider these goals. </p> <div class="vspace size-1"> </div> diff --git a/docs/html/design/get-started/principles.jd b/docs/html/design/get-started/principles.jd index 0b7147b..73ec3a6 100644 --- a/docs/html/design/get-started/principles.jd +++ b/docs/html/design/get-started/principles.jd @@ -1,9 +1,16 @@ -page.title=Design Principles +page.title=Android Design Principles @jd:body -<p>These design principles were developed by and for the Android User Experience Team to keep users' -best interests in mind. Consider them as you apply your own creativity and design thinking. Deviate -with purpose.</p> +<p>These design principles were developed by and for the Android +User Experience Team to keep users' best interests in mind. +For Android developers and designers, they continue to +underlie the more detailed design guidelines for different +types of devices.</p> + +<p> +Consider these principles as you apply your own +creativity and design thinking. Deviate with purpose. +</p> <h2 id="enchant-me">Enchant Me</h2> diff --git a/docs/html/design/get-started/ui-overview.jd b/docs/html/design/handhelds/index.jd index 5f4c40f..882b070 100644 --- a/docs/html/design/get-started/ui-overview.jd +++ b/docs/html/design/handhelds/index.jd @@ -1,12 +1,20 @@ -page.title=UI Overview +page.title=Phones & Tablets @jd:body -<p>Android's system UI provides the framework on top of which you build your app. Important aspects -include the Home screen experience, global device navigation, and notifications.</p> -<p>Your app will play an important part in keeping the overall Android experience consistent and -enjoyable to use. At the end of this chapter we introduce the main elements for achieving this goal -in your app.</p> -<p>Read on for a quick overview of the most important aspects of the Android user interface.</p> +<p> +Android's system UI provides the framework on top of which you build your app, +whether you're designing for phones, tablets, watches, or other form factors. +Aspects of UI that are especially important for phones and tablets include +the Home screen experience, global device navigation, and notifications. +</p> + +<p> +Your app will play an important part in keeping the overall Android experience +consistent and enjoyable to use. This page introduces some of the main elements +that can help you achieve this goal. The main Android Design topics listed on +the left, after the Devices sections, provide detailed guidelines for phones +and tablets. +</p> <h2 id="home-all-apps-recents">Home, All Apps, and Recents</h2> diff --git a/docs/html/design/index.jd b/docs/html/design/index.jd index cb7dd4f..27e3169 100644 --- a/docs/html/design/index.jd +++ b/docs/html/design/index.jd @@ -13,7 +13,7 @@ footer.hide=1 #text-overlay { position: absolute; - left: 36px; + left: 0; top: 42px; width: 266px; @@ -34,5 +34,15 @@ footer.hide=1 <a id="hero-image" href="/design/get-started/creative-vision.html"> <img src="/design/media/index_landing_page.png"> </a> + +<div style="background: hsl(8, 70%, 54%); margin: 0; padding: 20px 20px 10px 20px;color: #fff; position: absolute;top: 255px;width: 179px;"> +<h2 style="color: #fff;margin:0 0 10px; font-size:18px" class="norule">L Developer Preview</h2> +<p> The next version of Android uses a design +metaphor inspired by paper and ink that provides a reassuring sense of tactility. Before it arrives for users, you can get an early +look at the new Material design. +</p> +<p><a class="white" href="{@docRoot}preview/material/index.html">Learn more about Material</a></p> +</div> + </div> diff --git a/docs/html/design/media/device_family.png b/docs/html/design/media/device_family.png Binary files differnew file mode 100644 index 0000000..7889884 --- /dev/null +++ b/docs/html/design/media/device_family.png diff --git a/docs/html/design/media/wear/1D_picker.png b/docs/html/design/media/wear/1D_picker.png Binary files differnew file mode 100644 index 0000000..46c6bf6 --- /dev/null +++ b/docs/html/design/media/wear/1D_picker.png diff --git a/docs/html/design/media/wear/2D_picker.png b/docs/html/design/media/wear/2D_picker.png Binary files differnew file mode 100644 index 0000000..82c766a --- /dev/null +++ b/docs/html/design/media/wear/2D_picker.png diff --git a/docs/html/design/media/wear/2D_picker_action.png b/docs/html/design/media/wear/2D_picker_action.png Binary files differnew file mode 100644 index 0000000..8560ef8 --- /dev/null +++ b/docs/html/design/media/wear/2D_picker_action.png diff --git a/docs/html/design/media/wear/Bluebird.png b/docs/html/design/media/wear/Bluebird.png Binary files differnew file mode 100644 index 0000000..447e643 --- /dev/null +++ b/docs/html/design/media/wear/Bluebird.png diff --git a/docs/html/design/media/wear/action_button.png b/docs/html/design/media/wear/action_button.png Binary files differnew file mode 100644 index 0000000..dfdffa3 --- /dev/null +++ b/docs/html/design/media/wear/action_button.png diff --git a/docs/html/design/media/wear/action_on_card.png b/docs/html/design/media/wear/action_on_card.png Binary files differnew file mode 100644 index 0000000..d0b0fff --- /dev/null +++ b/docs/html/design/media/wear/action_on_card.png diff --git a/docs/html/design/media/wear/assets_specifics.png b/docs/html/design/media/wear/assets_specifics.png Binary files differnew file mode 100644 index 0000000..35a3819 --- /dev/null +++ b/docs/html/design/media/wear/assets_specifics.png diff --git a/docs/html/design/media/wear/bridgednotifications.jpg b/docs/html/design/media/wear/bridgednotifications.jpg Binary files differnew file mode 100644 index 0000000..a9e57a4 --- /dev/null +++ b/docs/html/design/media/wear/bridgednotifications.jpg diff --git a/docs/html/design/media/wear/circle_message2.png b/docs/html/design/media/wear/circle_message2.png Binary files differnew file mode 100644 index 0000000..63b7839 --- /dev/null +++ b/docs/html/design/media/wear/circle_message2.png diff --git a/docs/html/design/media/wear/clear_bold_type.jpg b/docs/html/design/media/wear/clear_bold_type.jpg Binary files differnew file mode 100644 index 0000000..e4b742c --- /dev/null +++ b/docs/html/design/media/wear/clear_bold_type.jpg diff --git a/docs/html/design/media/wear/confirmation.png b/docs/html/design/media/wear/confirmation.png Binary files differnew file mode 100644 index 0000000..513b85f --- /dev/null +++ b/docs/html/design/media/wear/confirmation.png diff --git a/docs/html/design/media/wear/contextualnotification.png b/docs/html/design/media/wear/contextualnotification.png Binary files differnew file mode 100644 index 0000000..1ec7ac8 --- /dev/null +++ b/docs/html/design/media/wear/contextualnotification.png diff --git a/docs/html/design/media/wear/continue_phone.png b/docs/html/design/media/wear/continue_phone.png Binary files differnew file mode 100644 index 0000000..fed93b6 --- /dev/null +++ b/docs/html/design/media/wear/continue_phone.png diff --git a/docs/html/design/media/wear/copywrite.png b/docs/html/design/media/wear/copywrite.png Binary files differnew file mode 100644 index 0000000..78be0bd --- /dev/null +++ b/docs/html/design/media/wear/copywrite.png diff --git a/docs/html/design/media/wear/countdown.png b/docs/html/design/media/wear/countdown.png Binary files differnew file mode 100644 index 0000000..11b1504 --- /dev/null +++ b/docs/html/design/media/wear/countdown.png diff --git a/docs/html/design/media/wear/customlayout.jpg b/docs/html/design/media/wear/customlayout.jpg Binary files differnew file mode 100644 index 0000000..9573cfc --- /dev/null +++ b/docs/html/design/media/wear/customlayout.jpg diff --git a/docs/html/design/media/wear/dismiss_cards.png b/docs/html/design/media/wear/dismiss_cards.png Binary files differnew file mode 100644 index 0000000..2e2d53b --- /dev/null +++ b/docs/html/design/media/wear/dismiss_cards.png diff --git a/docs/html/design/media/wear/expandable_stacks.png b/docs/html/design/media/wear/expandable_stacks.png Binary files differnew file mode 100644 index 0000000..edc2456 --- /dev/null +++ b/docs/html/design/media/wear/expandable_stacks.png diff --git a/docs/html/design/media/wear/fitness.png b/docs/html/design/media/wear/fitness.png Binary files differnew file mode 100644 index 0000000..3cf2f3c --- /dev/null +++ b/docs/html/design/media/wear/fitness.png diff --git a/docs/html/design/media/wear/low_info_card.png b/docs/html/design/media/wear/low_info_card.png Binary files differnew file mode 100644 index 0000000..a3ebf16 --- /dev/null +++ b/docs/html/design/media/wear/low_info_card.png diff --git a/docs/html/design/media/wear/peek_card.png b/docs/html/design/media/wear/peek_card.png Binary files differnew file mode 100644 index 0000000..2b12297 --- /dev/null +++ b/docs/html/design/media/wear/peek_card.png diff --git a/docs/html/design/media/wear/selection_list.png b/docs/html/design/media/wear/selection_list.png Binary files differnew file mode 100644 index 0000000..dcb0745 --- /dev/null +++ b/docs/html/design/media/wear/selection_list.png diff --git a/docs/html/design/media/wear/separate_info_cards.jpg b/docs/html/design/media/wear/separate_info_cards.jpg Binary files differnew file mode 100644 index 0000000..d4cb386 --- /dev/null +++ b/docs/html/design/media/wear/separate_info_cards.jpg diff --git a/docs/html/design/media/wear/separate_info_cards_1.jpg b/docs/html/design/media/wear/separate_info_cards_1.jpg Binary files differnew file mode 100644 index 0000000..b987aea --- /dev/null +++ b/docs/html/design/media/wear/separate_info_cards_1.jpg diff --git a/docs/html/design/media/wear/separate_info_cards_2.jpg b/docs/html/design/media/wear/separate_info_cards_2.jpg Binary files differnew file mode 100644 index 0000000..1930cb8 --- /dev/null +++ b/docs/html/design/media/wear/separate_info_cards_2.jpg diff --git a/docs/html/design/media/wear/single_action_controls.jpg b/docs/html/design/media/wear/single_action_controls.jpg Binary files differnew file mode 100644 index 0000000..ef89da0 --- /dev/null +++ b/docs/html/design/media/wear/single_action_controls.jpg diff --git a/docs/html/design/media/wear/voice_commands.png b/docs/html/design/media/wear/voice_commands.png Binary files differnew file mode 100644 index 0000000..9839ed8 --- /dev/null +++ b/docs/html/design/media/wear/voice_commands.png diff --git a/docs/html/design/tv/index.jd b/docs/html/design/tv/index.jd index 2519e25..5534724 100644 --- a/docs/html/design/tv/index.jd +++ b/docs/html/design/tv/index.jd @@ -1,31 +1,15 @@ -page.title=Design for TV -header.justLinks=1 -footer.hide=1 +page.title=TV @jd:body -<style> -#landing-graphic-container { - position: relative; -} -#text-overlay { - position: absolute; - left: 0; - top: 402px; - width: 220px; -} -</style> +<img src="{@docRoot}preview/tv/design/images/atv-home.jpg" + width="460" height="283" style="float:right;margin:0 0 40px 40px" /> -<div id="landing-graphic-container"> - <div id="text-overlay"> - <span itemprop="description"> - Build beautiful apps for the biggest screen in the house.</span> - <br><br> - <a href="{@docRoot}design/tv/principles.html" - class="landing-page-link">Design Principles</a> - </div> - <a href="{@docRoot}design/tv/principles.html"> - <img src="{@docRoot}design/tv/images/atv.png" style="margin-left: 70px;"> - </a> -</div> +<p>Android TV is <strong>coming soon</strong> and lets you engage your users in a new, shared environment.</p> + +<p>Users bring a specific set of expectations to the experience of watching TV, versus interacting +with a phone or tablet. So find out how to get your app ready for its big-screen debut +later this year by reading the +<a href="{@docRoot}preview/tv/design/index.html">Android TV Design Guide</a> +in the L Developer Preview.</p>
\ No newline at end of file diff --git a/docs/html/design/wear/creative-vision.jd b/docs/html/design/wear/creative-vision.jd new file mode 100644 index 0000000..4530744 --- /dev/null +++ b/docs/html/design/wear/creative-vision.jd @@ -0,0 +1,36 @@ +page.title=Creative Vision for Wear +@jd:body + + +<p>Android Wear devices provide just the right information at just the right time, +allowing users to be more connected to both the virtual world and the real world. Great Android +Wear experiences are:</p> + + +<div class="layout-content-row"> + <div class="layout-content-col span-6"> + <h4>Launched automatically</h4> + <p>Most people are used to launching apps by clicking an icon. Android Wear is different. Wearable apps are aware of the user’s context - time, location, physical activity, and so on. The apps use this information to insert cards into the stream when they become relevant. This makes Android Wear timely, relevant and very specific.</p> + </div> + <div class="layout-content-col span-6" style="margin-left:75px"> + <h4>Glanceable</h4> + <p>A classic wrist watch is designed to let you see the time in a split second and get on with what you were doing. Designing for Android Wear is no different. The less time it takes to use your software, the more time the user can be present in whatever they are doing. Android wear is fast, sharp and immediate.</p> + </div> +</div> + + +<div class="layout-content-row"> + <div class="layout-content-col span-6"> + <h4>Zero or low interaction</h4> + <p>Staying true to the strengths afforded by a smaller form factor, Android Wear focuses on simple interactions, only requiring input by the user when absolutely necessary. Most inputs are based around touch swipes or voice, and inputs requiring fine-grained finger movements are avoided. Android Wear is gestural, simple, and fast.</p> + </div> + <div class="layout-content-col span-6" style="margin-left:75px"> + <h4>All about suggest and demand</h4> + <p>Android Wear is like a great personal assistant: it knows you and your preferences, it only interrupts you when absolutely necessary, and it’s always on hand to provide a ready answer. Android Wear is helpful, respectful, and responsive.</p> + </div> +</div> + +<p>By providing a smart connection to the rest of the world while respecting the user’s attention, Android Wear feels personal and global, simple and smart, unobtrusive and ever-ready. Applications that represent these principles will feel most at home in the overall Android Wear experience.</p> + +<p>Third party apps extend Android Wear to be more specialized and helpful throughout the day. Installing apps are a way for the user to tell the Android Wear how to do that.</p> + diff --git a/docs/html/design/wear/index.jd b/docs/html/design/wear/index.jd new file mode 100644 index 0000000..3536445 --- /dev/null +++ b/docs/html/design/wear/index.jd @@ -0,0 +1,67 @@ +page.title=Wear +@jd:body + + + +<p>Designing apps for wearables powered by Android Wear +is substantially different than designing for phones or +tablets: different strengths and weaknesses, different use cases, different ergonomics. +To get started, you should understand the overall vision for the Android Wear experience, +and how apps fit into and enhance this experience.</p> + +<p>A new form factor deserves a new UI model. At a high level, the Android Wear UI consists of two +main spaces centered around the core functions of <strong>Suggest</strong> and +<strong>Demand</strong>. Your app will have an important role to play in both of these +spaces.</p> + + + +<h2 id="Stream">Suggest: The Context Stream</h2> + +<div class="framed-wear-square" style="float:right;margin:0 -22px 60px 40px"> + <img src="{@docRoot}wear/images/screens/stream.gif"> +</div> + +<p>The context stream is a vertical list of cards, each showing a useful or timely piece of information. Much like the Google Now feature on Android phones and tablets, users swipe vertically to navigate from card to card. Only one card is displayed at a time, and background photos are used to provide additional visual information. Your application can create cards and inject them into the stream when they are most likely to be useful.</p> + +<p>This UI model ensures that users don’t have to launch many different applications to check for updates; they can simply glance at their stream for a brief update on what’s important to them.</p> + +<p>Cards in the stream are more than simple notifications. They can be swiped horizontally to reveal additional pages. Further horizontal swiping may reveal buttons, allowing the user to take action on the notification. Cards can also be dismissed by swiping left to right, removing them from the stream until the next time the app has useful information to display.</p> + + + + +<h2 id="CueCard">Demand: The Cue Card</h2> + +<div class="framed-wear-square" style="float:right;margin:0 -22px 60px 40px"> + <img src="{@docRoot}wear/images/screens/cuecard.gif"> +</div> + +<p>For cases where Android Wear does not suggest an answer proactively through the context stream, the cue card allows users to speak to Google. The cue card is opened by saying, “OK Google” or by tapping on the background of the home screen. Swiping up on the cue card shows a list of suggested voice commands, which can also be tapped.</p> + +<p>At a technical level, each suggested voice command activates a specific type of intent. As a developer, you can match your applications to some of these intents so that users can complete tasks using these voice commands. Multiple applications may register for a single voice intent, and the user will have the opportunity to choose which application they prefer to use.</p> + +<p>Applications can respond to a voice command in the same way as they can respond to a tap on a regular in-stream action button: by adding or updating a stream card, or by launching a full screen application. Voice input often takes the form of a command, such as "remind me to get milk," in which case a simple confirmation animation is sufficient to display before automatically returning to the Context Stream.</p> + + +<h2 id="Other">Other UI Features</h2> + +<ul> +<li>The <strong>Home screen</strong> is the default state of the device and features: + <ul> + <li>The background, showing either content relating to the first card or a custom watch face design, depending on the watch face the user has chosen. Tapping anywhere on the background or saying "Ok Google" starts a voice query. + <li>Status indicators, showing connectivity, charging status, airplane mode, and in some watch faces a count of unread items. + <li>The top ranked card in the Context Stream, peeking up at the bottom of the screen. The amount of the peek card that appears is determined by the current watch face. + </ul> +</li> + +<li><strong>Watch faces</strong> may be chosen by the user to appear in the background of the Home screen. Watch faces display the time and accommodate the top ranked peek card. The user can choose a different watch face by long pressing on the current one.</li> + +<li>Some devices may enter a low-power <strong>Ambient Mode</strong> when not being used. This usually involves dimming the screen in some way. The contents of a peek card will automatically be optimized for display in this state. Users can exit ambient mode by tapping on the screen, by tilting the screen towards them, or by pressing a hardware button if one exists.</li> + +<li>Swiping down on the Home screen reveals the <strong>Date and Battery</strong> display. Dragging further down toggles <strong>Mute mode</strong>, preventing interruptive notifications from vibrating and illuminating the screen.</li> + +<li>The <strong>Settings screen</strong> can be invoked from the cue card or on some devices using a hardware button. From here the user may shut down or restart their device, adjust screen brightness, toggle airplane mode, and access device information.</li> + +<li><strong>Full screen apps</strong> can be launched on top of the main stream where a wider range of interaction is called for. Although not stylistically limited to the context stream pattern, apps should respect the same design principles as the rest of the system. For more information, see the <a href="{@docRoot}design/wear/structure.html">App Structure</a> guide.</li> +</ul>
\ No newline at end of file diff --git a/docs/html/design/wear/patterns.jd b/docs/html/design/wear/patterns.jd new file mode 100644 index 0000000..8f4698c --- /dev/null +++ b/docs/html/design/wear/patterns.jd @@ -0,0 +1,150 @@ +page.title=UI Patterns for Wear +@jd:body + + + +<p>Android Wear is used for micro-interactions, and so adhering to consistent design patterns that users are already accustomed to is paramount.</p> + +<h2>Cards</h2> + +<p>Cards in the stream can take slightly different forms:</p> + +<div class="framed-wear-square-small" style="float:left;margin:0 20px 20px 0"> + <img src="{@docRoot}design/media/wear/Bluebird.png"> +</div> + +<div class="framed-wear-square-small" style="float:left;margin:0 20px 20px 0"> + <img src="{@docRoot}design/media/wear/single_action_controls.jpg"> +</div> + +<div class="framed-wear-square-small" style="float:left;margin:0 20px 20px 0"> + <img src="{@docRoot}design/media/wear/expandable_stacks.png"> +</div> + +<ul style="clear:both"> +<li>Standard cards for displaying information from a notification</li> +<li>Single-action controls (such as a play/pause toggle)</li> +<li>Expandable stack of cards, for grouping a set of related notifications together</li> +</ul> + + +<h2>App icons</h2> + +<div class="framed-wear-square-small" style="float:right;margin:0 0 20px 60px"> + <img src="{@docRoot}design/media/wear/clear_bold_type.jpg"> +</div> + +<p>App icons appear in a fixed position overhanging the edge at the top right of the card by default for all notifications in the Context Stream. This is an opportunity for cards to be recognized as coming from a specific source. Photo backgrounds should be used only to convey information, not to brand a card. App icons are necessary only on the leftmost card; it is not necessary to add the app icon to pages.</p> + +<h2 style="clear:both">Pages</h2> + +<div class="framed-wear-square-small" style="float:right;margin:0 0 20px 40px"> + <img src="{@docRoot}design/media/wear/separate_info_cards_2.jpg"> +</div> + +<div class="framed-wear-square-small" style="float:right;margin:0 0 20px 40px"> + <img src="{@docRoot}design/media/wear/separate_info_cards_1.jpg"> +</div> + +<p>Supplementary information should be displayed on additional cards to the right of a main Context Stream card. In most cases one additional detail card should be sufficient. For example, a weather card might show the weather for the current location today, with subsequent days listed in an additional card to the right. Keep the number of detail cards as low as possible. Actions (see below) should always come after pages; don’t change the order or interleave them.</p> + + +<h2 style="clear:both">Dismissing cards</h2> + + <img src="{@docRoot}design/media/wear/dismiss_cards.png" height="147"> + +<p>Swiping from left to right on a card causes it to be dismissed from the stream. Dismissed cards may return when they next have relevant information. State is synced between the Android Wear context stream and the notifications on the Android handheld device, so dismissing from one causes an automatic dismissal from the other.</p> + + + +<h2 style="clear:both">Action buttons</h2> + +<div class="framed-wear-square-small" style="float:right;margin:0 0 20px 40px"> + <img src="{@docRoot}design/media/wear/action_button.png"> +</div> + +<p>Where the user may need to take action on the information shown in a notification, you can provide action buttons. These are system-rendered buttons that appear to the right of detail cards. They consist of a white icon set on a blue system-rendered circular button and a short caption with a verb. Actions should be limited to three for a single card row.</p> + +<p>Tapping on an action button can cause an action to be executed; or an action to be continued on the companion handheld; or a full screen activity to be invoked for further input (see “2D Picker” section below).</p> + +<p>Refer to the UI Toolkit provided in the Downloads section for detailed specs regarding action icons.</p> + + +<h2 style="clear:both">Action countdown and confirmation</h2> + +<div class="framed-wear-square-small" style="float:right;margin:0 0 20px 40px"> + <img src="{@docRoot}design/media/wear/countdown.png"> +</div> + +<p>Where tapping on an action button results in an action being executed, one of the following can happen:</p> + +<ol> +<li>The action is completed immediately and the result of the action is shown (either by updating the relevant card contents immediately, or by showing a confirmation animation).</li> +<li>A short countdown animation to completing the action is played, which the user can interrupt to cancel. Once the timer has counted down, a confirmation animation is played. This animation can be custom-designed by developers.</li> +<li>A confirmation step is required. This is for actions that are potentially damaging if accidentally triggered. A generic confirmation template is supplied by the system. Once the user confirms, the standard confirmation animation is played.</li> +<li>The cue card can be invoked to continue specifying the action. For example in a messaging application, tapping a “Reply” action button invokes the Cue Card and prompts for voice input. In this case the prompt label (such as “Speak your message…”) and a set of sample voice suggestions can be specified by developers.</li> +</ol> + + +<h2 style="clear:both">Continuing activities on phone</h2> + +<div class="framed-wear-square-small" style="float:right;margin:0 0 20px 40px"> + <img src="{@docRoot}design/media/wear/continue_phone.png"> +</div> + +<p>Developers should attempt to perform actions on the wearable device wherever possible. In cases where the phone must be used, a generic animation should be played once the action button has been tapped and the corresponding Android app will open on the phone.</p> + + +<h2 style="clear:both">Actions on cards (such as media controls)</h2> + +<div class="framed-wear-square-small" style="float:right;margin:0 0 20px 40px"> + <img src="{@docRoot}design/media/wear/action_on_card.png"> +</div> + +<p>Some cards may benefit from having tappable actions directly on a card. Some guidance on when to use this pattern versus using an action button:</p> + +<ul> +<li>This pattern should be used when only one possible action could be reasonably expected. For example, tapping on an address with a car icon and ETA seems like it would very obviously launch directions. Conversely, if you see a contact's photo and name, it's not clear what tapping would do (call them? email them?), so the pattern shouldn't be used in this case.</li> +<li>On-card actions should not require a text label to be understood.</li> +<li>On-card actions should only result in something happening on the wearable (apart from web links to open them on the phone).</li> +<li>Only one action per card: no menus on a single card.</li> +</ul> + +<p>Good examples of using an action on card include: play / pause music; toggle light switch on and off; navigate to an address; call a phone number.</p> + + +<h2 style="clear:both">Card stacks</h2> +<img src="/wear/images/11_bundles_B.png" height="200" width="169" style="float:right;margin:0 0 20px 40px" alt=""> +<img src="/wear/images/11_bundles_A.png" height="200" width="169" style="float:right;margin:0 0 20px 40px" alt=""> +<p>Card stacks group related cards together and allow them to be progressively expanded vertically in the stream. A tap on a stack fans the cards out so that the top edge of each card can be seen. A subsequent tap on a fanned card reveals that card fully. Stacks of cards revert to a fully collapsed state once the user has swiped away from them.</p> + + + +<h2 style="clear:both">2D Picker</h2> + +<p>A 2D Picker component in your app can be invoked from the cue card or from an action button. It allows users to choose from a list of items, and optionally select an attribute of each item. For example, in response to a voice action to “buy tickets to a movie tonight,” you could show a 2D Picker with a vertical list of movies playing, with each movie having a horizontal list of showtimes.</p> + +<img src="{@docRoot}design/media/wear/2D_picker_action.png" width="500" alt=""> + +<p>In some instances, further information may be required. In these cases, the most probable default values for these choices should be chosen on the user’s behalf with the option to edit before completing the action. This pattern is in keeping with Android Wear’s core design principle of minimizing interactions required.</p> + + +<h2 style="clear:both">Voice commands</h2> + +<div class="framed-wear-square-small" style="float:right;margin:0 0 20px 40px"> + <img src="{@docRoot}design/media/wear/voice_commands.png"> +</div> + +<p>It is possible for apps to take action in response to Android voice commands that invoke intents. For example, an app can register for the “Take a note” intent and capture the subsequent voice input for processing. In the case where multiple apps registered for the same intent, user preference will be captured once and saved. Users can edit their intent preferences in the Android Wear app on their handheld.</p> + + +<h2 style="clear:both">Selection List</h2> + +<div class="framed-wear-square-small" style="float:right;margin:0 0 20px 40px"> + <img src="{@docRoot}design/media/wear/selection_list.png"> +</div> + +<p>Choosing an item from a list is a common interaction. The Selection List pattern (available as the WearableListView component) creates a simple list optimized for ease of use on a small screen: the focused item snaps to the center of the screen, and a single tap selects. This widget is recommended as a common pattern for selecting items. It is used throughout the system UI, including in the list that can be accessed by swiping up on the cue card.</p> + + +<p>Of course, it is possible for Android Wear apps to extend themselves beyond the familiarities of these patterns. For a deeper look at the options available, see the section on App Structure.</p> diff --git a/docs/html/design/wear/principles.jd b/docs/html/design/wear/principles.jd new file mode 100644 index 0000000..a214435 --- /dev/null +++ b/docs/html/design/wear/principles.jd @@ -0,0 +1,52 @@ +page.title=Design Principles for Wear +@jd:body + +<style> +p.try { + background:#e4e4e4; + padding:10px; +} +</style> + +<p>These design principles provide some simple heuristics about how you should plan and assess your +Android Wear app design.</p> + + +<h2>Focus on not stopping the user and all else will follow</h2> +<p>A watch is a perfect form factor for a device that you can use while doing something else, such as cooking, eating, walking, running, or even having a conversation. If using your wearable app causes the user to stop whatever they’re doing, it’s a good occasion to consider how to improve it using the principles in this section.</p> + +<p class="try"><strong>Try this:</strong> Time a typical use of your Wear app. If using it takes more than 5 seconds, you should think about making your app more focused. Also try using your app while you’re having a conversation, and see how it affects your train of thought and eye contact.</p> + + +<h2>Design for big gestures</h2> + +<p>When you swipe through photos on your phone you’re using a large area of the display, and you don’t have to be precise at all. That’s the best kind of interaction for a wearable device. Your users are going to use your app in all sorts of situations, the least frequent one might actually be sitting down at their desk.</p> + +<p class="try"><strong>Try this:</strong> Use your app in various everyday situations, such as walking, eating, talking to people, or ordering coffee. If you have to slow down while walking or stop the conversation to be precise, you should consider how your gestures could be bigger.</p> + +<h2>Think about stream cards first</h2> +<p>The best experience on a wearable device is when the right content is there just when the user needs it. You can figure out when to show your cards with sensors, or events happening in the cloud. For the cases where it’s impossible to know when the user needs your app, you can rely on a voice action or touch.</p> + +<p class="try"><strong>Try this:</strong> Make a list of all the situations a user would find your app useful. What do they have in common? Same location? Time of day? Certain physical activities? You will most likely come up with several different situations - that’s a good sign, because it means that you can specialize your cards to those situations. Remember that the user always has the option of completely muting your stream cards if they feel they aren’t relevant enough.</p> + + +<p>[image] </p> +<p class="img-caption">An app that offers to check in users could appear in the stream suggesting the most likely place nearby, after a certain amount of time.</p> + + +<h2>Do one thing, really fast</h2> +<p>While users will engage with your app for only a few seconds at time, they'll use it many times throughout the day. A well-designed stream card carries one bit of information and potentially offers a few action buttons when the user swipes over.</p> + +<p class="try"><strong>Try this:</strong> How many bits of information is there in your design? Is everything absolutely necessary, or could you split it up into separate cards? If you’re designing a card, don’t forget that you can use multiple pages.</p> + + +<h2>Design for the corner of the eye</h2> +<p>The longer the user is looking at your app, the more you are pulling them out of the real world. Thinking about how to design your app for glanceability can vastly help the user get full value from your app and quickly go back to what they were doing.</p> + +<p class="try"><strong>Try this:</strong> To view your app with your peripheral vision, try focusing on your knuckles while your watch is displaying the app. Do you get a sense of what it is trying to do? Is it distinguishable from other apps? Does the background image help conveying the message? Does it use photos or a distinct shape and color?</p> + +<h2> +Don’t be a constant shoulder tapper</h2> +<p>A watch constantly touches the user’s skin. Being this intimate, you want to buzz the watch fewer times than you’re used to on the phone.</p> + +<p class="try"><strong>Try this:</strong> Next time you’re in a conversation, imagine someone tapping you your shoulder, interrupting you with the information you want your app to deliver. If the information delivered did not justify suspending a conversation, you should not make the notification interruptive.</p>
\ No newline at end of file diff --git a/docs/html/design/wear/structure.jd b/docs/html/design/wear/structure.jd new file mode 100644 index 0000000..caeb119 --- /dev/null +++ b/docs/html/design/wear/structure.jd @@ -0,0 +1,116 @@ +page.title=App Structure for Wear +@jd:body + + +<p>As outlined in the <a href="{@docRoot}design/wear/creative-vision.html">Creative Vision</a>, +Android Wear apps do not adhere to the traditional mobile app model of touching an icon to launch into a self-contained experience. Rather, it is useful to think about the different spaces in the Android Wear UI and how your app might present itself across these spaces. For example, a typical app might begin by showing a notification card in the stream at a contextually relevant moment, then jump into a custom full screen UI for a micro-interaction, or maybe open the cue card to capture voice input that is then relayed back to the in-stream card.</p> + +<p>It’s important to make some fundamental decisions about how your users will interact with your app. There are a number of ways that functionality can manifest itself in Android Wear, and it is important to choose the places that provide maximum value and ease of use.</p> + +<p>For example, application functionality might show up in the following ways:</p> + +<ul> + <li>As a <strong>card in the main context stream</strong>: + <ul> + <li><strong>Bridged notifications</strong> are pushed to the wearable from the connected handheld (a phone or tablet) using the standard Android notifications framework. In general, bridged notifications mirror what’s happening on the handheld and use one of a predefined layout templates. Example: new message notification. + <li><strong>Contextual notifications</strong> are like smart notifications. They are generated locally on the wearable and appear at contextually relevant moments specificed by the app developer. Contextual notifications allow more freedom of control, allowing for custom layouts and dynamic updating of card contents. Example: live updating exercise stats. + </ul> + </li> + <li>As a <strong>full screen UI</strong> that temporarily overlays on top of the context stream: + <ul> + <li>The <strong>2D Picker</strong> is a simple design pattern (available in the SDK as a prebuilt component) aimed at asking the user to select from a set of items. This is a common interaction and a familiar pattern, so use of the familiar 2D Picker pattern is encouraged wherever possible. Example: choose from a set of artists and albums to play. + <li><strong>Custom layouts</strong> are also possible where apps need to extend beyond the basic card/stream metaphor. These apps should be distinctly separate from the core user experience in both appearance and interaction.</li> + </ul> + </li> +</ul> + + +<p>Apps can also open the cue card to capture voice input.</p> + +<p>Note that the different approaches above are listed in order of complexity. When designing your interactions, try to achieve them with the simplest approach possible. If your needs are more involved, move to the next level of complexity.</p> + +<p>Many applications will consist of a combination of these views, possibly with connections between them. For example, a contextual card may have an action that launches a more immersive experience. Inversely, an immersive experience may result in a card being added to the stream.</p> + +<p>Think of these different components as building blocks that can be snapped together into a single user flow. Avoid single monolithic full screen UIs that need to be launched and quit. Place simple notifications and ongoing information in the stream, and jump in and out of simple full screen activities to complete quick tasks before returning to the stream.</p> + +<p>In this section we will look at these different approaches and how combine them to create the best experience for your users.</p> + + +<h2 id="Bridged">Bridged Notifications</h2> + +<div class="framed-wear-square-small" style="float:right;margin:0 -22px 60px 40px"> + <img src="{@docRoot}design/media/wear/bridgednotifications.jpg"> +</div> + +<p>Bridged notifications are the simplest way of having content appear on an Android wearable. Since cards in the Android Wear stream are synced from the notifications on your connected handheld, any notifications created there automatically appear on Android Wear. Where appropriate, make sure to use the new APIs in the support library that enhance your app's notifications with features such as voice replies and notification pages.</p> + + + +<h2 id="Contextual">Contextual Notifications</h2> + +<p>Displaying information on contextual cards is at the core of the Android Wear user experience. Cards with focused trigger criteria appear at just the right time, delighting and assisting the user with timely, useful content. Refer to the Design principles section for details on how to think about triggering cards, and the UI overview section for a breakdown of the familiar system UI components that make up an entry in the context stream.</p> + +<p>An important aspect of creating contextual notifications is defining trigger conditions: what is the specific scenario in which your notification should appear? Think about using all sensor information available to you -- time, location, movement, identity, user habits and patterns, interaction with nearby devices, and more -- and describe the specific combination of sensor readings that should result in your app presenting itself.</p> + + +<img src="{@docRoot}design/media/wear/contextualnotification.png" width="500" alt="" /> + + +<p>For example, imagine you were building a running app. If the user is standing at the beginning of their regular running trail, at the time that they often go for a run, and we detect a running activity... they are probably going for a run! This would be a great time to present a contextual card that offers to track their run.</p> + +<p>Putting effort into getting your contextual triggering just right is one of the most impactful things you can do to create a delightful experience for your users.</p> + +<p>You may use the standard Android notifications framework to create cards using a range of provided templates, or draw your own ActivityView inside cards for a custom card layout. Make sure to refer to the Style section to make sure your custom ActivityView layouts are sympathetic to the overall design of cards in the stream. Use ActivityViews to create custom card layouts that are stylistically consistent with neighboring cards in the stream; do not invent entirely new or conflicting UI patterns inside cards.</p> + +<p>Contextual cards are ideal for situations where it may be useful to push information to the user, when the information may be useful on an ongoing basis or referred back to, or when context strongly indicates that the information is useful. Refer to the section on Respecting Users Attention in the Design Principles section for details on targeted triggering. Triggering too often or in unsuitable contexts will result in users being annoyed by your app.</p> + + + +<h2 id="Picker">2D Picker</h2> + +<p>The 2D Picker design pattern (available as the GridViewPager component) is useful for showing a range of options or asking a user to make a quick selection. Google search results on Android Wear are a great example of the GridViewPager pattern in action.</p> + +<p>A 2D Picker is called up as an overlay on the main UI by tapping a card or button, or through a voice action. It preserves the same look and feel as the main context stream, giving users a familiar and predictable set of interaction patterns to rely on.</p> + +<p>On Android Wear, the basic hierarchy is vertical-then-horizontal, never horizontal-then-vertical, with a recommended vertical limit of five cards. Each vertical slot may consist of one card, as in the Google results case, or multiple cards which may be swiped horizontally.</p> + +<img src="{@docRoot}design/media/wear/1D_picker.png" alt="" width="499px" /> +<p class="img-caption">This pattern can be used to present a single vertical list, or a “1D Picker”</p> + +<img src="{@docRoot}design/media/wear/2D_picker.png" alt="" width:760px" /> +<p class="img-caption">It can also be used as a 2D matrix of options, as a way of presenting categorized options.</p> + +<p>This flexibility means that developers can choose to present a one or two-dimensional set of options. For example, a music app could use a vertical list to present a list of albums by a given artist (one dimension of options), and it could additionally allow each album slot to be horizontally swipeable to also choose a song from each album (a second dimension of options).</p> + +<p>Do not add buttons or pages to horizontal 2D Picker rows; rows should only be used to present a list or grid of similar options in this context. Provide a clear call to action on the card using the Action cards pattern detailed in the <a href="{@docRoot}design/wear/patterns.html">UI Patterns</a> guide.</p> + +<p>2D Picker should be automatically dismissed when a selection is made. It may also be exited by swiping back down on the first card, or by swiping left to right on a leftmost card.</p> + +<p>The simplicity of individual cards within a 2D Picker is a feature. Remember that in many cases the user may be on the go or attempting to complete a task as quickly as possible. As such, micro-interactions and familiar input mechanism are paramount, and using the already-familiar pattern of vertically-then-horizontally oriented cards gives users exactly what they want with as little fuss as possible. Strive to minimize the number of results or options that you present. Show the most popular or repeatedly-used options at the top of the list of cards to avoid scrolling. Learn the user's preferences and use context detection to put the most likely option for any given situation at the top. In general, optimize for fast task completion over excessive customization.</p> + + + +<h2 id="Custom">Custom Layouts</h2> + +<p>Some interactions may require a broader range of input mechanisms than is possible within the limitations of a card-based UI. For example, an app that allows for location selection may require the user to swipe in many directions before tapping to drop a pin. In cases like this, it is recommended to momentarily launch out of the context stream UI and present an immersive, full screen app with a custom layout.</p> + +<p>Custom full screen apps provides the benefit of flexibility: you can launch your own Android activity that takes up the entire screen, and capture all touch events, making a wide range of UIs possible.</p> + +<img src="{@docRoot}design/media/wear/customlayout.jpg" alt="" width="760px" /> + + +<p>However, be cautious of making this the default way of accessing your app’s functionality. Users will thank you for presenting your content in the familiar, simple environment of the context stream if it is possible to do so. Only enter full screen mode when the interactions required are not possible using the card UI. Full screen is a modal state to be entered for the purpose of achieving a specific task, and in most cases should be easily and quickly exited. You should use full screen apps to achieve a single, quick task within a broader user flow that hinges off the Context Stream. A great full screen experience will present itself quickly, ask for some user input, and then self-quit back to the stream.</p> + +<p>To avoid confusion, avoid using the specific styles and idioms of the context stream when designing immersive experiences. If you find yourself replicating the structure of the card layout, your should probably be using a 2D Picker. Make your immersive experience visually distinct. However, still adhere to the <a href="{@docRoot}design/wear/principles.html">Design Principles</a>, which apply universally to Android Wear interfaces.</p> + +<p>Because Android wearables do not feature a home or back button, exiting the application at the appropriate time is the responsibility of the app developer. Exiting always leads back to the context stream. Where possible, exit automatically or present the option to exit at logical break points using acknowledge/cancel buttons. For example:</p> + +<ol> +<li>A map view that allows the user to slide a map to drop a pin on a location should automatically exit when the pin has been placed.</li> +<li>A short game should automatically exit back to the stream at the end of each game.</li> +<li>A drawing app should display the option to exit after 5 seconds of inactivity.</li> +</ol> + +<p>Even with logical exit points like these, some cases may exist where the user may want to immediately initiate an exit. This may be particularly common in apps of longer duration. In all cases, the developer should <strong>present the option to quit the app on long press</strong> using DismissOverlayView. Your design should long press for the sole purpose of prompting to quit.</p> + +<p>Seamlessly and fluidly moving between the context stream and immersive mode makes your app feel like an integrated part of the Android Wear experience.</p>
\ No newline at end of file diff --git a/docs/html/design/wear/style.jd b/docs/html/design/wear/style.jd new file mode 100644 index 0000000..ed39bd6 --- /dev/null +++ b/docs/html/design/wear/style.jd @@ -0,0 +1,102 @@ +page.title=Style for Wear +@jd:body + + +<p>Here are a number of design considerations to bear in mind that are particular to Android Wear.</p> + +<h2 id="ScreenSize">Screen Size</h2> + +<img src="{@docRoot}design/media/wear/circle_message2.png" height="200" + style="float:right;margin:0 0 20px 60px"> + +<img src="{@docRoot}design/media/wear/fitness.png" height="200" + style="float:right;margin:0 0 20px 60px"> + +<p>Be mindful of different device sizes and shapes. Wearable devices are a form of fashion and expression for their owners, and so Android Wear supports a variety of forms. Most of the complexities of supporting these different devices is taken care of at a system level, but bear in mind different screen types when designing custom full screen apps.</p> + +<p>Use the Android Wear emulator to test both square and round devices, and note that <code>WatchViewStub</code> is available to activities to detect whether a square or round device is being used.</p> + + + + +<h2 id="Assets" style="clear:both">Specific Assets Required</h2> + +<img src="{@docRoot}design/media/wear/assets_specifics.png" width="300" + style="float:left;margin:0 60px 20px 0"> + +<p>A core set of standard assets may need to be provided depending on your card design: app icon, background image or images, action icons, actions confirmation animation. Of course, your specific design may necessitate other assets. Background image should be provided in landscape format at least 600px width for notifications that include pages of cards, since the system automatically adds a parallaxing effect.</p> + + + +<h2 id="PeekCard" style="clear:both">Peek Card Readability</h2> + +<img src="{@docRoot}design/media/wear/peek_card.png" width="300" + style="float:left;margin:0 60px 20px 0"> + +<p>Test your card layout to ensure that useful information is conveyed in the peek state on the Home screen. The main message of the card should be readable in the peek state, particularly for contextual cards. Content that requires an interaction to be read, for example a long message, should be cropped appropriately to provide an affordance to the user to swipe the card to read more.</p> + + + +<h2 id="InfoDensity" style="clear:both">Low Information Density</h2> + +<div class="framed-wear-square-small" style="float:right;margin:0 0 40px 60px"> + <img src="{@docRoot}design/media/wear/low_info_card.png"> +</div> + +<p>Cards should be designed to be glanceable in a split second, just like reading the time on a traditional watch. In most cases a pairing of an icon and value, or a title and short caption should be enough to convey a meaningful message. Note that the background photo should also be used to convey information; backgrounds that change to reflect and support the primary message in the card work great. For example, in the case illustrated above a suitable background image is chosen to reflect severity of the current traffic conditions. This is not just a nice piece of attention to detail; the background actually reinforces the message and makes the content more glanceable.</p> + + +<h2 id="Chunks" style="clear:both">Separate Information into Chunks</h2> + +<img src="{@docRoot}design/media/wear/separate_info_cards.jpg" width="400" + style="float:left;margin:0 60px 20px 0"> + +<p>In cases where additional information is absolutely necessary, don’t crowd out a card layout to the point where glanceability is affected. Instead, add an additional page (or multiple pages, if needed) to the right of the main card in the stream to which the user can swipe for more information. See also “Continuing activities on phone”, below.</p> + + +<h2 id="KeepMinimum" style="clear:both">Keep Notifications to a Minimum</h2> + +<p>Don’t abuse the user’s attention. Active notifications (that is, those that cause the device to vibrate) should only be used in cases that are both timely and involve a contact, for example receiving a message from a friend. Non-urgent notifications should be silently added to the Context Stream. See also the general Android Notifications Guidelines.</p> + + +<h2 id="Typography" style="clear:both">Use Clear, Bold Typography</h2> + +<div class="framed-wear-square-small" style="float:right;margin:0 0 60px 40px"> + <img src="{@docRoot}design/media/wear/clear_bold_type.jpg"> +</div> + +<p>The system font is Roboto Condensed, with Regular and Light variants. Text should adhere to the size and color recommendations (see the UI Toolkit in the Downloads section). In general, text should be displayed as large as possible. Your goal should be to convey maximum information with minimum fuss.</p> + + +<h2 id="Branding" >Use Consistent Branding and Color</h2> + +<p>The app icon is used to identify and brand your application. The icon is optional but when present always appears in the same location, overhanging the top edge of the card at the right. Note that app icons or branding should not be displayed in the background photo, which is reserved to display an image relevant to the information on the card.</p> + + +<h2 id="Copywrite" style="clear:both">Copywrite Sparingly</h2> + +<div class="framed-wear-square-small" style="float:right;margin:0 0 60px 40px"> + <img src="{@docRoot}design/media/wear/copywrite.png"> +</div> + +<p>Omit needless text. Design for glanceability, not reading. Use words and phrases, not sentences. Use icons paired with values instead of text wherever possible. Text strings should be as concise as possible, and long pieces of text will be truncated to fit on a single card.</p> + + +<h2 id="BeDiscreet" >Be Discreet if Necessary</h2> + +<p>Wearables are personal devices by nature, but they are not completely private. If your notification serves content that may be particularly sensitive or embarrassing (such as notifications from a dating app or a medical status report), consider not displaying all of the information in a peek card. A notification could place the sensitive information on a second page that must be swiped to, or an application could show different amounts of detail in peek and focused card positions.</p> + + +<h2 id="ConfirmAnim" style="clear:both">Confirmation Animations</h2> + +<div class="framed-wear-square-small" style="float:left;margin:0 40px 40px 0 "> + <img src="{@docRoot}design/media/wear/confirmation.png"> +</div> + +<p>If your app allows the user to perform an action, it is necessary to provide positive feedback. Show a generic confirmation animation or create your own. A confirmation animation is an opportunity to express your app’s character and insert a moment of delight for your user. Keep animations short (less than 1000ms) and simple. Animating the confirmation icon is an effective way of transitions the user to a new state after completing an action.</p> + + + + + + |
