Alexis Moussine-Pouchkine: Hello, everyone.
We're here at Devoxx 2014, and I'm here with Chet and-- wait,
you're not Romain.
CHET HAASE: Nick.
NICK BUTCHER: Pourquoi?
MALE SPEAKER: Oh, good, good.
CHET HAASE: Croissant?
MALE SPEAKER: And with Nick, and you guys came out recently
of the keynote that you did and this was about material design.
So people might have heard of it,
but why don't you tell us how we got to material design, what
problem is it trying to solve, and why do developers even
need to care about this?
NICK BUTCHER: Well, let me take a swing at this first.
CHET HAASE: Yep.
NICK BUTCHER: Yeah.
Let's take it from the top.
What is material design?
So material design is Google's attempt at providing a design
language, I guess you could call it, like a holistic design
thing, to solve designing for the range of platforms
that are out there.
So everyone is trying to access your services
from little tiny screens like your watches, phones, tablets,
TVs, cars, and whatever else they end up
putting some smarts into, so we needed some way
to make those experiences kind of consistent
so you can learn how to use them on one screen
and use it elsewhere.
And that's material design.
MALE SPEAKER: And that's not just Android, right?
This is trying to--
NICK BUTCHER: Absolutely.
Yeah, yeah.
So not just a variety of form factors, but different
platforms as well.
MALE SPEAKER: So Android and the web, basically?
NICK BUTCHER: Yeah.
MALE SPEAKER: And Polymer would be the project that
addresses that in terms of the implementation?
CHET HAASE: Right.
So in the keynote today we were talking
about both of those platforms and saying
what material design is overall, what
are the design factors going into it and the things
that we're going for with the design,
and then talking about the specific implementations
on both Polymer and Android.
MALE SPEAKER: So before we get to why developers should care
about this and what it means to them, how did we get there?
I mean, you mentioned it's not the first time
we talked about themes.
We were actually talking about something similar
in previous years here.
So how does this change, and talk to us
about maybe Holo or maybe about Kennedy on--
NICK BUTCHER: Yeah, yeah.
MALE SPEAKER: I mean, this is a multi-year effort and--
NICK BUTCHER: Yeah this didn't just
come down from the mountain on a tablet
saying here is material design.
This has been an ongoing kind of evaluation, I guess.
So I guess if you kind of rewind a couple of years, four or five
years maybe, a lot of products in Google,
and other companies I think, kind of evolved on their own.
So you might have a team who are building your Android app
and a team who are building the web app
and a team who are building whatever
your iOS app [INAUDIBLE].
And they always were kind of like existing in isolation
so we just evolved to this point where all these experiences
were their own things, and they kind of
weren't really coherent.
So that was, you know, across platforms.
And the same between apps even from one company.
So even from Google, if you use something like YouTube
and then something else like Gmail,
it might not look and feel the same.
They have their own kind of foibles and interaction
patterns and so on so you couldn't learn on one
and then apply it to another.
So you mentioned Kennedy.
That was an initiative we had, I think back in 2011,
where Larry Page kind of like set a mandate saying,
hey, this is a problem.
We need to kind of make our properties more consistent.
So we set about a big kind of redesign,
I guess, of updating all of our web properties
to look and feel the same.
So that's when you got the kind of lots more white space
and big red buttons saying Compose and so on.
That was the Kennedy look and feel,
but that mostly applied to the web properties.
It didn't really apply to some of the other things.
Like at the same time, Android was evolving its own Holo
design language so they're kind of
like going in their own direction.
So I think material design is like an evolution
of that kind of Kennedy effort to grow up and try and provide
a kind of complete design language
for all the different platforms.
MALE SPEAKER: So is material design done?
I mean, are we working just on the implementation details?
NICK BUTCHER: You guys are done now, right?
It's done-- let's say the framework's finished?
CHET HAASE: We're done for now.
Is design ever complete?
No, I think a lot of the fundamentals
are there in terms of the design aspects,
like what the consistent approach that they have
to these things are, the fundamentals of we
have the ideas of paper and ink and how
things interact with the user.
And then the implementation, sort of the V1 implementation
of that and the Lollipop, envisioning
a lot of the fundamentals, the plumbing
layer of actually making this stuff work.
I think we can continue to iterate over it,
but those I would see is being refinements on top of material
design as opposed to implementing other core pieces.
MALE SPEAKER: So you've been trying very hard not
to use gibberish from designer world.
NICK BUTCHER: Designer speak.
MALE SPEAKER: Designer speak.
Maybe you can give us an example of what that would be?
NICK BUTCHER: Yeah.
I think, if you look at the spec, as we call it,
if you go to google.com/design/spec,
there's this whole big document detailing these rules
of material design, these organizing principles.
And it uses quite a lot of designer--
I think it's focused at designers.
It says things like, "a coherent design system,"
and uses things like, "rational uses of space."
What was the one you pulled me up on before?
Using?
CHET HAASE: Visual rhythm?
NICK BUTCHER: Visual rhythm, I think, yeah.
So words like that.
MALE SPEAKER: Right.
So do I need to read that?
I'm a developer.
Don't get me wrong, I want to have engaging apps and people
to understand what the app's supposed
to do and not look around.
I understand design is important,
but do I really need to go through all that?
NICK BUTCHER: We might have different answers here.
I say yes.
CHET HAASE: I would say yes.
NICK BUTCHER: I think you're touching
on a really important point.
I think you get a much better product when
you have designers and developers working close
together and you have these tight feedback loops.
It shouldn't just be like design happens here
and it gets thrown over the wall and then development
tries to work out what it actually means
and develop something.
I think you get a better product when you work closely together,
and I think working closely together
needs a shared vocabulary so you're actually
talking about the same thing.
So, yes, it's important to read it.
You can laugh at the kind of terms
and the touchy-feely concepts sometimes,
but getting some of the vocabulary
to say, hey, what do you mean by this thing?
What are you trying to actually do here?
MALE SPEAKER: Well, vocabulary's key.
NICK BUTCHER: Yeah, I think it helps in that.
And I think vice versa.
I think designers should peruse the developer documentation
and then try and understand the limitations of what people
are trying to build so they know when to push
and what's just not possible and so on.
I think it's got to be a conversation.
MALE SPEAKER: So maybe let's get into some
of the details for the developers.
So do you maybe want to talk about Android
and how some of the main principles
actually are implemented and things that are changing?
Is it just an evolution, like, brand new APIs?
This is the new material design package and the backup APIs?
How does that work?
CHET HAASE: It's not fundamentally new stuff.
It's still standard Android program.
What we did was add capabilities to the platform
to handle things like real time shadows.
API is to handle opting into those capabilities
so if you want to actually boost a view in [? Z ?]
to give it real time shadows, we added APIs for you to do that.
The way that I envision what we did in the Toolkit team
in this release was that we looked at the design team
sort of waving their hands and saying, material design.
We want all these sort of general grand capabilities
and this consistent design language, blah, blah, blah.
And then we would go in and tease out the bits
that that meant for the platform.
OK, when they're talking about this, what they really mean is
they need the rendering system to be
able to handle real time shadows at 60 frames a second.
When they're talking about this, what they mean
is they need the theming system to be able to dynamically
colorize assets so that we can brand applications.
And so then our job in the release
was to then implement those capabilities
and add those APIs for a developer
to then opt into those capabilities
in their applications.
I think that was all I was doing with that one.
NICK BUTCHER: And I think one of my favorite things
about it is that I think we've enabled
a lot of backwards compatibility behavior as well.
MALE SPEAKER: Oh, exactly.
I wanted to get to that.
NICK BUTCHER: So there's some awesome, awesome, awesome, new
work in the framework to do things like real time shadows
and so on, but you can still do a lot of the material
stuff on all the platforms as well.
So I think we put a lot of effort
into things like-- the app compat library, in particular,
I think did a really good job for helping
you to build material UIs.
So you can get this kind of graceful degradation, right?
You can then only have a single design,
because you don't want to have to maintain two designs, two
code paths, and just have it kind
of like do one thing on a newer platform which
might do fancier shadows.
And it might fall back to using a baked in background
or using something like card view,
also in the support library, which will give you
the real shadow implementation on a new Lollipop device.
But then it'll give you a reasonable approximation
on an older device.
So I really like the way that that kind
of backless compatibility is being
thought about when making the new APIs.
MALE SPEAKER: So as part of Lollipop,
a number of applications that come with the system actually
were rewritten, or upgraded, to material design.
NICK BUTCHER: All of them?
All of them, I think.
MALE SPEAKER: Any one you want to point out
or are these good examples of things
that should serve as inspiration for developers?
NICK BUTCHER: OK.
So I think one of my favorites, it's not an app, per se,
but I think the system UI.
I think the way that Notifications work, especially
on the Lock Screen, I think is brilliant.
I find it really fun where you see the notifications
on the lock screen, and you can instantly
expand them and get them into different states
and interact with the action straight away.
CHET HAASE: There's a lot of subtle things, too,
in your interaction.
As you move the shade up and down,
you're seeing things sort of subtly fade and move around.
If you look really closely, you can actually
see the shadows reacting in real time,
because as you move things around on the screen,
they're changing their position relative to the light source,
the virtual light source that's casting the shadows.
But you see other subtle things like animated icons
actually moving around as you're moving the shade up and down.
Just a lot more rich interaction of the user about what's
actually going on in the system.
NICK BUTCHER: Yeah.
Also, I think the new Play Newsstand application
did some really, really nice animations.
Chet's favorite topic.
CHET HAASE: Yeah.
Activity transition stuff.
MALE SPEAKER: Do you want to talk
about animations in general?
CHET HAASE: I always want to talk about animations.
MALE SPEAKER: Yeah, I know you do, but just--
NICK BUTCHER: How long do we have?
MALE SPEAKER: You have 30 seconds, that's about it.
But, no, seriously, again, why should you have them?
And why should you not abuse them probably?
CHET HAASE: So I like animations,
but mostly targeted towards a specific reason, which
is helping the user understand what's going on.
I think there's two main uses of that.
One is to highlight something to the user of information
they need to be aware of.
So like a pulsating button on the screen
when they need to be aware that this is the default
action that's going to take place.
The thing that you're going to see more of in this release
is transitioning the users.
So helping them understand a flow
through an otherwise very complicated system of UIs,
right?
So as they go from window to window or from activity
to activity or fragment to fragment in their application,
you can be exposing them to seriously complicated user
interfaces.
How can you help them understand how they got here,
where they came from, what they're
supposed to do about it now.
And one of those ways is by using animations
to transition them.
Not just pop that old UI out and pop the new one
in, but actually share elements between the UIs
so they understand what their shared elements are
and what happened to the elements that no longer are
there, what happened to the new elements that just faded in.
So that, I think, is the really powerful use of animations.
Not just to make things look blingy on the screen,
but to actually help the user be more connected
to the application experience.
MALE SPEAKER: And how does that fit into Lollipop specifically
and the APIs and--
CHET HAASE: So one of the big new API
areas that we enabled was Activity Transitions.
The idea in material design of being able specifically
to do these transitions so that-- let's take an example.
You're in a music application, you have a list of albums,
and you want to click on one of the albums
and then see the songs associated with the album.
Obviously you're probably going to have
similar artwork for the album in both of those pages there,
in both of those activity windows,
so as you click on the album, maybe we
can actually share that element between them,
and we can share some text, as well.
Whatever the shared elements are between those two UIs and then
fade in and out the other elements that go away
or come into being.
The Activity Transitions API builds on the Transitions API
that we had in KitKat, but makes it
available for overall activities.
So now you can say, OK, when I watch the following activity,
here's the animation that I want you to run
and here are the shared elements that you're
going to automatically animate into place for me.
MALE SPEAKER: Do you wan to talk about the theming?
NICK BUTCHER: Yeah.
MALE SPEAKER: I think I love the idea of having
all of that being handled by a [INAUDIBLE].
Do you want to tell us real quick about how it works?
NICK BUTCHER: The coloring zone?
MALE SPEAKER: Yes, the coloring.
NICK BUTCHER: Yeah.
Yeah.
So for a long time we've been talking
about how you can use color to have a branding
and have your identity, personality,
in the application, but it was kind
of a pain in the ass to implement.
You kind of had to go to these websites and input
this in My Colors and download a couple of hundred
assets and XML files and dump them into your app and so on.
And if you wanted a couple of colors
and different looks of the screen,
you'd have to repeat that.
So it was kind of a lot of work for developers.
So, yeah, the framework team has done a huge amount of work
to basically take grayscale assets in the system,
bake them into the system, and then at run time tint them.
So you just provide the coloring information
as simple attributes in your theme,
and we'll take care of doing all the coloring for you,
which is really, really cool.
CHET HAASE: And then, similarly, you
can also tint things at run time.
So you can bake them into your theme
and say, here's what I want my overall theme to look like.
Here's the colors that you should
use for my overall application.
But let's say you go into some subactivity
in your application, and you want
this screen to be colorized according
to the information that's in that bitmap,
then you'd go to something like the Palette Library that's
now in Support Library in Lollipop,
and you'd extract information from bitmap
to get certain dominate colors, and then
you can dynamically tint the assets along the way.
So not in your theme, because this is at runtime,
but dynamically actually call Set Tint
and say, use this color for the current background color.
NICK BUTCHER: A good example of that
is I think the Contacts app on Lollipop where I think we just
launched the new SMS messaging app for other devices as well,
and that's kind of like a utility app.
It doesn't really have a strong brand,
so it kind of gets itself out of the way
and just picks a color from the contact.
So your contact, their photo, it will pick out a distinct color,
and it will colorize all the icons and so on.
So you get this kind of like immersive kind of rich feel.
Like each contact feels different.
By glancing at it, you get a different kind
of feeling, which is really, really a rich UI.
I like it.
MALE SPEAKER: Great.
So as Lollipop is being shipped to a number of devices
as we speak, what should developers do now?
I mean, should they be worried that their app's going
to be obsolete and it will show real soon because there's
a big difference?
Or should they gradually upgrade,
and then what resources should they be looking at?
NICK BUTCHER: Yeah, this is an interesting one,
because it's an evaluation of Holo.
But it looks quite different to Holo
so it's going to be quite hard, I think,
to implement half your app in material
and half your app in an older design.
So I think it's going to be a kind of thing
where you take your time and sit back and work out
the major wins.
Like how do we adopt the visuals,
and then how do we use the idea of services
in our UI to get the right shadows and so on.
CHET HAASE: And then implementing more animations.
But I think there is a sliding scale of activity
that they could do in their activities.
In terms of, OK, so first thing is you opt into the theme.
If you're only running on L, you opt into the material theme,
and you get a bunch of stuff for free.
If you're using the Support Library,
you opt into the app compat theme.
And, again, when you're running on L,
then you would get all the material theme stuff for free,
and that's going to give you the standard widgets and colors,
and then you can build on that from there.
You can say, well, which of my assets
looks slightly out of place in the new world?
What do I want to do about those assets?
What animations can I use so I no longer
have jump cut experiences in the user flow?
NICK BUTCHER: Yeah.
So I'd say now is the right time to start
working on your material app, because I guess
there's going to be an expectation bar.
When users get Lollipop on their device
and they start seeing the smooth animations and the subtle use
of the shadows, it's going to raise their expectation bar.
Like, this is what an app should look and feel like.
So I say definitely developers should get on it now.
MALE SPEAKER: And with compat libraries and frameworks
that existed before, if you're not targeting L,
you can still pretty much do almost all of it.
It's probably harder, but it's not impossible
if you really want to get to that look at feel.
NICK BUTCHER: You can get a lot of the way there.
MALE SPEAKER: OK.
NICK BUTCHER: As for resources, as to where they should go.
MALE SPEAKER: Yeah.
NICK BUTCHER: Yeah, on our develop site, so d.android.com,
click through to the blog.
There's been a series of posts about implementing
material assign of late.
And also under the training section
there's a section on implementing material design
and so on.
MALE SPEAKER: OK.
So all developers should learn, probably, about it.
Read this.
I haven't read it, I'll be honest, but I will.
And everybody should just probably try Lollipop as a user
and get inspired and start building for it.
CHET HAASE: Enter the material world.
MALE SPEAKER: Enter the material world?
Oh, got it.
Cheers, everyone.