Android Wear 2.0: Building Apps with Material Design – Google I/O 2016

JP GIL : Hi everyone. I’m JP Gil, and I’m a designer on the Android Wear team. And I led.


JP GIL : Hi everyone. I’m JP Gil, and I’m a designer
on the Android Wear team. And I led the design for
bringing Material Designs to wearables. PAUL SOULOS: Hi,
I’m Paul Soulos. I’m an engineer on
the Android Wear team. And I built some of the Material
Design library features. JP GIL : Material Design is
a key aspect of Wear 2.0. Today we’re going to talk about
how you can design and build apps for Android Wear, using
Google’s design guidelines called Material Design. PAUL SOULOS: After we go
through some design principles, I’m going to show you
how to build an app using some of the new components. JP GIL : Material Design is
Google’s visual language. It’s been designed to work
across multiple platforms, devices, and screen sizes. It provides a toolkit for
designers and developers, along with a comprehensive
set of guidelines and design principles. This image on the screen is
an abstract representation of different screen sizes,
going from the big TV on the screen– on the back,
to desktops, tablets, phones, and the white little small dot
there, that’s a watch screen. Today we’re focused
on the little screen. And we show you how we
extended Material Design to work on wearables. And how it will help
with design apps. If you want to know more
about Material Design, please visit design.google.com. Material Design
for wearables can be describing three key areas. A focus on vertical
layouts to improve simplicity and usability. The use of dark colors,
which are less interruptive and can save battery
on OLED displays. And a set of new UI components
and app design patterns that help designers
create great looking apps, developers build
apps more quickly, and users have a more
consistent app experience. Material Design on Android
Wear 2.0 isn’t just for apps, and it extends
across the system. The principles used in apps
are observed in other system components like notifications,
the App Launcher, input mechanisms on the device,
and other parts of the system. Here you can see a
few app illustrations designed with these principles. Layouts are vertical,
they use darker colors, and also have some UI components
and app design patterns. Let’s talk about
vertical layouts. Originally, we left things
really open in Android Wear. We saw developers and users
get confused with the freedom to scroll left, right, up,
down, in all directions basically in apps and the OS. We found that restricting
the primary axis to just the vertical axis just
helps people orient themselves and get things done. The notifications stream
in Android Wear 2.0 is one of the core examples
of this vertical principle. Users navigate vertically,
starting from the watch face to check their
incoming notifications. Once they open a notification,
as you see on the right image, the notification
expands vertically to reveal more content
and more actions. Sometimes your app may need
a horizontal container, and that’s also OK. For example, if you
have an inline photo carousel in your app. What is really
important in this case is that users understand
the hierarchy of your app. They need to understand that
this horizontal container is contained within a vertical
container, the parent container, and that’s OK. So it’s important for
users to understand that the main axis of
the app is vertical. Dark colors are a central
part of Material Design for wearables. Previous UIs on Android Wear
used a light color scheme. We found that brighter
colors use more battery and can be interruptive
when the screen is active. This app example uses
a light colored scheme, like you typically see on phone
apps using Material Design. The primary color chosen
here is purple 500 from the Material
Design color palette. This color is used to
highlight content and actions in different
sections of the app, and it does already give a
distinctive look to the app. Light colors have two
main issues, however. One is that light
colors are less energy efficient in OLED
displays, because they need to light the pixels
with brighter intensity. For example, white pixels
need to light up the RGB diodes in your pixels at 100%. So the more white
and light colors you have in your app, the less
battery efficient your app will be. The other issue is more
of a social nature. Imagine you are in a restaurant
having a pleasant candlelight dinner, probably in this
restaurant they run out of candles, it’s really dark. And you receive a message
notification from a friend. Because watches are visible
on your wrist at all times– or most of the times. If you have long
sleeves, they’re not going to be visible. Your display may disrupt
the pleasant atmosphere when you get a notification. This situation would probably
not happen with dark colors. Here’s the same app
example using a dark theme. Using the same primary
color, purple 500, we arrived at all the
colors in this example. Differently to light
colors, dark colors make the screens less
bright when they’re active and save battery
in OLED displays. We’ve also designed our
system notifications to automatically adapt
to your app color. So it creates a
unified experience. For your app though,
that I show here, we derived these colors using
a method that we developed. And they are derived from
the purple 500 manually. And I’m going to
show how we did it. So this is our primary
color, purple 500 from the Material
Design palette. This color can be expressed
in different color notations like RGB, red, green, blue. Here we’re showing the
decimal values for RGB. Another common way to
show the values of RGB is with hexadecimal values. It’s usually very common in web
apps and Android apps as well. Yet there is another notation
called hue, saturation, and brightness, and that’s
the notation we used to develop our color system. If you look at the
app, we have hue, which is expressed in
degrees, brightness in percentage–
excuse me– saturation in percentage and brightness
also in percentage. To create the
colors, we manipulate the brightness
values of this color. And we’re going to
show you how we did it. So let’s imagine our color would
just move from a color world to a black and white world,
and that every sub-color could be expressed by just
the brightness value of the sub-colors. As you see here in the
image below, purple 500. If you bring this color back
to the happy, colorful world, that’s how its sub-color
would look like. We named five
different sub colors that we think can cover
most of your app’s needs. Here they are from
light to dark. Accent. So as I mentioned
before, we just moved the brightness
values on the color. So accent– we moved the
brightness up to 100%. Then you have
lighter UI elements, where you moved
down from 74% to 65. And you go down to
40% to UI elements, then 30% for
lighter backgrounds, and 50% for dark backgrounds. Now let’s see how these colors
are applied in our example. We used accent color
sparingly throughout the UI. In this example, we’re just
highlighting the user name and the time stamp. We used the lighter
background color in most of the UI’s background. And to section off certain
areas of the background, we decided to use the
dark background color. Active elements in the UI, like
elements where you take action, like the action drawer or
the primary action button, they use a lot of UI elements. And to separate the
primary action button on the left screen,
we used a UI element. It’s almost like a
intermediary background. Luckily, this color,
purple 500, isn’t alone in this happy color world. They have a lot of friends. We also updated the
complete Material Design color palettes to
help you choose darker colors for your applications. We needed however, to
make a few adjustments to make the palette more
readable and more accessible. So we optimized the saturation
for some of the sub-colors in the blue range,
as you see here on the image, and
the yellow range. If you want to know
more about colors, please visit our
Material spec site, and the URL here is
on the bottom corner. OK. We talked about vertical
layouts and darker colors, two of the key areas of
Material Design for wearables. Let’s talk now about the
last one, UI components and patterns. We walk you through the basic
anatomy of a Material Design app for Wear 2.0. Imagine this circle in
isometric perspective is the screen of your watch. The app will have a
vertical container with a vertical layout. And this layout will use
a dark color palette. And it uses two components
that Paul will show you how to build in your app today. Wearable Action Drawer and
Wearable Navigation Drawer. Let’s see how they work. A Navigation Drawer
helps users navigate between sections of your app. It sits vertically on the
top of the content containers outside of the viewport. So if you look at this
image here of a fake mail app that we call Mailbox. You see the containers– the
main containers of the app, they’re all vertical. And the Navigation
Drawer sits on top of it. The navigation in the Drawer
is actually horizontal, and it’s on purpose,
because the only way to move between different
horizontal containers– vertical containers
is horizontally. Because I know someone is going
to ask that question later. This horizontal motion helps us
enter different vertical views in your application. For example, if you want
to switch between mailbox to settings to contacts
page to your drafts. This is how the Navigation
Drawer works in action. The users pull from the top,
navigate between left and right to arrive at the view. It’s pretty simple. We’ve also implemented
a peek behavior to remind users that
the Drawer actually exists outside of the viewport. Sometimes users may forget
there is something there. The Drawer peeks as soon
as the user scrolls back to the top of the current view,
as you see on the animation, and the Drawer just peeks in. Users don’t have actually to
scroll all the way to the top to get to the
Drawer, the Drawer’s available at all times. You just have to pull from
the top edge of the screen, and the Drawer will be there. And Action Drawer,
it’s the one that sits on the bottom of the screen. And Action Drawer allows
users to access actions for specific usage contexts. Let’s look at the example of
the conversation in a messaging app. There are a few possible
actions here, could be more, but I’m just showing a few. Replying to the message, adding
a photo, sharing a location, adding more people
to the conversation. So to access the actions, users
just have to pull up the Drawer and tap it in the overflow icon. And as we did with
the Navigation Drawer, uses can open that
Drawer at any time by pulling from the
bottom edge of the screen. In fact, we found
in usability studies that once users
discovered that behavior, they don’t even wait
for the peek state. They know the Drawer is there,
they just open the Drawer and perform the actions. So what happens if you have
only one action in your Drawer? So if you have only
one action, you don’t need an overflow icon. So the overflow helps you figure
out there’s more actions there, but we only have one. We debated whether we should
have a Drawer and just the peek state with that icon in it. And we found out
that, sometimes, if you use an icon that
users have never seen before, it’s useful to have a
Drawer with just one action, so they can actually associate
the action with the icon. So tapping on the
action as you’re going to see in
the animation now, instead of opening the Drawer,
it will perform the action directly. So in this case, when the
user taps on the action, he would just reply
to the conversation. To prevent unnecessary
spin obstruction, the Drawer also has a
peek and hide behavior. In this animation, you see
how the Drawer disappears and it reappears when
the user’s trying to go back to the bottom
of the conversation. That means, let’s say, you
receive a message from a friend and they ask you a question. You want to go back into
the conversation history, you find out what you want. As you go back down,
we assume that you’re trying to actually
reply to the action. So we peek the Drawer in
for you as a convenience. In this case, maybe you just
want to go from the bottom as well. Now I’ll hand it
over to Paul, who will show you how to
build these components PAUL SOULOS: Thanks, JP. Now, you learned about
the design behind Drawers, I’m going to show you
how to implement them. The Drawers are a new feature
in the wearable support library. And if you’re familiar
at implementing Drawers on a phone, then you
pretty much already know how to implement them
on a wearable as well. So first, we’re going to go
through some more generic, easy to implement use cases:
the wearable Action Drawer and wearable Navigation Drawer. And afterwards, we’ll
take a little deeper dive and show you how to
build some custom Drawers if your
application should be a little more tailored
to the user experience. So wearable drawer
layout is the container that everything goes within. Here you’re going to
define your content. This is going to be the
vertically scrolling thing that JP spoke about. And within it, you’re
also going to define an Action Drawer and a
wearable Navigation Drawer. To get the peeking
behavior, you need to enable nested scrolling. What this does is it allows
the wearable drawer layout to understand the movement
that’s occurring deeper within the view hierarchy, so
that it knows when to peek. For instance, when
you scroll to the top, the wearable drawer layout needs
to peek the Navigation Drawer. So you can do this by enabling
nestedScrollingEnabled on standard Android
view, such as ListView. Some of the Android
Support views like RecyclerView and
NestedScrollView implement this by default. On the left is a Navigation
Drawer on a phone. It’s generally pulled from
the left side of the screen, or you tap the hamburger menu. And it allows the user to
navigate the application. On the right, you can
see the same thing, the wearable Navigation
Drawer for use on watches. It’s pulled down from
the top of the screen. And it allows the
users to navigate between different columns
of vertical content. Navigation Drawers are populated
through the same adopter construct that you’re already
familiar with on Android. There’s only a few
methods to implement. It’s really easy. Let’s go through building one. So you pull down the
Navigation Drawer from the top of
the screen, and you see that you’re in
the mailbox section. The user knows that there
is one section to the left and two the right
from the indicators at the bottom of the screen. You define this by filling
in the getCount method from the adapter. And in particular, the section
that the user is currently on is highlighted by
a larger circle. To set the label,
getItemText is called, and that’s what sets
the label for it. And then there’s
also getItemDrawable which sets the icon. And that’s all that’s
needed to populate the view for a Navigation Drawer. It’s really simple and quick. There are two other methods
to discuss: onItemsSelected and notifyDatasetChange. onItemSelected is called
when the user navigates left or right within the Drawer. And this gives you
the opportunity to change the underlying view. For instance, if the user
goes in the mailbox section to the settings section,
that gives you an opportunity to change the underlying content
to reflect the new settings screen. notifyDataSetChanged
is called when the data backing the adapter
changes after the adapter was set. This notifies the Navigation
Drawer that the data behind it is no longer valid, and it
needs to redraw the view, so that I can get the
new icons and labels. Actions Drawers are
a great compliment to wearable Navigation
Drawers, and they allow the user to
quickly perform actions on the content and the screen. On the left, you can
see an action menu as it is implemented on
the phone, generally opened by clicking the overflow menu. And on the right, is a
wearable Action Drawer, open by pulling up from
the bottom of the screen. Actions on phones and
wearables are both implemented using the Android menu API. If your action menu is static,
and it does not change, the easiest way to fill it in
is to specify a menu resource in your XML. Here you can see that we created
an action_menu attribute, and we’re just pointing it
to a menu resource file. Alternatively, your
actions may need to be a little more dynamic. And you can populate
them in code as well. Here we’re using a menu inflator
to put a menu resource file into the menu that we retrieved
from the Action Drawer. This is exactly what happens
behind the scenes when you specify an attribute with XML . So if that’s what you’re
planning on doing, then it’s a little
easier to point XML. So here we’re going to
clear the Action menu and go through building one in
code without using a resource file. So you can call on the menu
object, the add method, where you’re going to pass on the item
ID as well as the text to use. And once that menu
item has been created, you can set an icon on it. Later on, if you no
longer need the menu item and want to remove it
from the Action Drawer, you just call removeItem on the
menu and pass in the item ID. There are two ways to
interact and retrieve events that are occurring
with an Action Drawer. First, you can set
a ClickListener on the entire menu. When you do this, and whenever
anything in the Actual Drawer is clicked, this
method will be called. And then, from within here,
you can get the item ID and then act accordingly once
you know where it was clicked. Alternatively, you can set
an individual ClickListener on a specific menu item, this
will intercept the click event. So if the user
clicks on something that had– if a general menu
has a defined ClickListener, and a specific item
has one as well, the specific one
will be called first, and you can respond accordingly. And if you return
true, the event will be considered consumed,
and will never propagate to the general ClickListener. One thing in
particular to note is that there are two instances
of onMenuItemClickListener. The first comes from the
wearable Action Drawer class, and this is the one
that you’re going to set on the entire menu. The second one comes
from the MenuItem class. This is what you’re going to
use for setting a ClickListener on a specific menu item. The standard navigation
in Action Drawers, if they don’t see
your application, you don’t need to use them. You can create a custom one. That gives you the
peeking and drag behavior that users have come to expect
on the operating system, but it allows you to put
in some peek and drawer content that’s more specified
for your application. Let’s take a look at
how Spotify uses them. In the first
example, you can see that they’ve replaced the
peek overflow icon with a play and pause button. And this means, whenever the
user’s using an application, they can change the
state of the music right there, without
having to open the Drawer. And if they decide to
pull the Drawer up, you can see the custom
drawer contents on the right. The custom drawer
shows a full set of media controls and
some song information, such as the title,
the artist, as well as the duration and time left going
around the edges of the screen. Now Spotify could have used
a regular Action Drawer and had all of these controls
and information listed vertically, but we’ve
come to associate moving to the next song to
the right of the pause button. So in this case, it
really made sense for them to create their
own custom drawer and used a UI that people
are already familiar with. Wearable Action Drawer and
wearable Navigation Drawer both extend from the
wearableDrawerView class. So when you create
a custom drawer, you’re going to want
to use that base class and place your
content within it. You need to set layout_gravity
on the DrawerView, so it knows whether
it exists on the top or bottom of the screen. In this example, we’re
using a drawer on the top. If the content within
your drawer also scrolls, you’ll need to enable
nested scrolling again. This just helps
wearableDrawerLayout understand the movement that’s
occurring beneath so that it can make everything fluid. In your code, there are two
methods in wearableDrawerView. There is setPeekContent
and setDrawerContent. And both of these methods
take Android view arguments, and they follow all the
standard view conventions. So you can set a
ClickListener on a peak state if you want to
respond differently. In some cases, your
app may need to respond depending on the drawer state. So you can use a
DrawerStateCallback, which lets you know when a
drawer has been opened, closed, or the state changes. We’ve also defined a few
states, such as dragging, when the user drags
the drawer up. And if they let go a little
early before they finish dragging and it has
a little bit more to move before it
settles in place, it’ll be using the
settling state. And once it’s finally
stopped moving either, in an open or closed state,
the state will switch to idle. Here are a few of our
partners using the drawers. On the left is Lifesum. They track your food intake,
and they use an Action Drawer that you can open up to add
an extra meal whether it’s breakfast, lunch,
dinner, or a snack. They also implement
a Navigation Drawer to help you move between
food, water, and exercise. On the right is ToDoist, and
they’re using an Action Drawer to let you take actions and add
new to do items in your list. Wearable drawers are but
a few of the components available in Android Wear 2.0. If the drawers
don’t suit your app, and they’re a little too much UI
for what you need to get done, feel free to use some
other principles. Here is primary action button. And this allows the user to
take an action immediately upon entering a
view or activity. This is similar to offloading
action button on a phone. So in the case of an email
app, besides reading emails, users may want to frequently
compose a new one. So here using a
primary action button to define that right at the
top of the screen and help them build that immediately. Inline action buttons should
be used when it’s important that the user gets to
the bottom of the content before taking an action. So in this example, we
put the share button at the bottom of the content,
because it’s really important that people read what they’re
sharing before they share it. Right? Confirmation overlays
display a temporary message to express a state change. So in this case, the user has
successfully sent a message. So you’re going to pass in a
success confirmation overlay, now we’ll use the green arrow. And if you look
at the API, there are a few other states defined
to use different icons there. And finally, there are
progress indicators which let the user
know that something is happening behind the scenes. It’s important to use
these if anything is not going to be instant, so
that the user doesn’t think your app stalled, and they
know that something’s coming, they just have to
wait another second. All of these pieces
can be combined to create a rich and tailored
experience for your application on Wear. Android Wear 2.0 has a new
wearable support library that includes all the components
we’ve discussed today and more. To get this support
library, you need to add a dependency to
the wearable support library in your
Gradle build file. This Gradle file is depending on
the developer preview version, so it uses the suffix alpha1. The exact dependency will change
throughout the preview period, and we’ll finally
settle on 2.0.0. To find the exact
dependency, please visit the Wear developer site, where
you can also find guides, tutorials, and reference. We put a lot of thought into
Material Design on Wear. And we’re only able to touch
on a small portion of it during the session. The guidelines we’ve spoken
about today, as well as others, are available in the Material
Design for Wear spec site. And with that, I’ll
hand it over to JP to discuss some best practices. JP GIL : Thanks Paul. Now that we’ve learned
how to design apps with Material Design
on Wear 2.0 and how to build some of our
components, let’s briefly talk about some general
best practices for creating smartwatch app experiences. Smart watches have unique
limitations and capabilities. And many of the design
patterns and principles developed for
smartphones should not be directly applied to watches. The first thing is to
understand use cases. When designing apps
for smartwatches, focus on use cases
that makes sense for the watch environment. Watches allow users
to get information at a glance, such as the
arrival of the next bus. And to take actions quickly,
like responding to a message. Avoid complex applications
that require a lot of input and have too much
information density. The best wearable
apps are glanceable, that means when you look at
your watch at your wrist, you know what they are
trying to tell you. They’re easy to tap. You don’t want to fumble on
the UI to try to take action. And help users
complete tasks quickly. So help your users go
from A to B quickly, don’t add unnecessary
steps in between. They keep you connected
to both the real and the virtual worlds. And we look forward to
see what you come up with. Wear apps should be designed
to support your app’s core functionality. Don’t include unnecessary
features, actions, or content in your app’s UI. So if you look at the example
of the email app, the Mailbox fake app, you probably
want to include the ability to reply to messages or
to compose new messages. And maybe on a watch, you
don’t want to print your email. I mean who does
print, email anyway? But you don’t want to print
email from your watch. Right? Or add a label or a show
original HTML content, probably that’s not the kind
of functionality you want to have on a watch app. The last thing is when
you design for watches, design for round devices first. Unlike phones that have
rectangular screens, the majority of Android
Wear devices in the market have a round screen. A circle fits within a square
and has a 22% smaller surface area. With that, you make sure that
your layouts were both on round and square devices. Round screens have a
smaller usable surface. So remember, a circle
fits inside of a square, and if you put another square
inside of that circle– I know this will be crazy, but– the
square inside that circle, that’s your safe area. So don’t put important
information outside of that square
inside the circle. So the edges around
that circle, those are probably the parts
of the UI that you want to put your
secondary information. They’re also pretty small,
so you don’t want to, for example in the top edge
of the circle– if you squeeze a title there, it’s
going to be very small. So for primary information,
use the center of the circle. The same is for text. For laying text in
a circular device, you also have to observe
the same margins. And margins for
circular devices have to be a little bit wider to
have a more pleasant experience. PAUL SOULOS: So how do
you build for both round and square devices? Well, we added some new resource
qualifiers to help you do this. On the top, we have, under our
resources, a values-notround. So here we’re going
to find things that we want to use
for our square screens. So in the dimensions file,
we have a left padding defined with 12dp. So this just moves the content
in a little bit from the bezel, and gives a little white
space to make a better user experience. As JP just discussed,
on round screens, you’re going to want to move
content in a little more. So on the bottom, we’re
defining a values-round folder. And within that, we’re creating
another dimensions file. Here we’re overriding the
left padding to use 36dp. So here, if you’re using a
round device, at runtime, the application will
choose which to use. So it in this case, it’ll
use 36 and push the content in a little further
away from the edge. This doesn’t just apply
to the values folder, but anything in the
resource directory. For instance, you
can have layout-round if you want a completely
different layout for a round device. It’s important to use
your apps as a user would. You may develop docked at
your desk or on an emulator, but watches are worn on a wrist. For this new form factor,
it’s very important that you do some real world
testing, which you may not be as used to with a phone. A great way to test is to
get up, put your watch on, go outside, and maybe take a run. Imagine you’re building
a fitness application, and everything works
great at your desk. You follow the Material
Design principles, everything is really
fluid and snappy. It’s great. But before you ship it to users,
you put it on and go for a run. Once you’re exercising
and breathing heavily, you may notice that
the buttons that were really easy to
click at your desk are a little bit more difficult
when your wrist is moving around and creates
a moving target, because you’re
breathing heavily. So now you go back
to your desk, create the buttons a little larger,
and by the time you ship it, the users are going to
have a great experience. PAUL SOULOS: Thank you for
attending this session. JP and I really
hope you enjoyed it. We want to teach you not
only how to design and build wearable apps, but also why
the design decisions we made are practical for small
and various form factors. You can start building
apps today by going g.co/wearpreview. The next session in this
room is on watch faces and complications. And if you missed any
of the sessions today, they’ll all be available
on YouTube shortly. One of the reasons
we’re doing this preview is to get your feedback. So please use the
Wearable Preview, and if you have any API
suggestions or find any bugs, you can let us know at
g.co/wearpreviewbug. JP GIL : Thank you very much. PAUL SOULOS: Thank you [APPLAUSE] [MUSIC PLAYING]

3 thoughts on “Android Wear 2.0: Building Apps with Material Design – Google I/O 2016”

  1. this is exciting! I like this new vertical navigation. males more sense. I wonder how a news app like IGN could use a wear app? A list of headlines with the ability to save for reading later?

  2. Google seems to be pretty good at learning from previous iterations. Wear 1.0 > 2.0, Cardboard > Daydream, etc.

Leave a Reply

Your email address will not be published. Required fields are marked *