Google I/O 2014 - マテリアルデザイン。構造とコンポーネント (Google I/O 2014 - Material design: Structure and components)

字幕表動画を再生する

RICH FULCHER: Good morning.
Thank you all for joining us today.
We'll just start with a couple of introductions and then dive
right into the material.
So I'm Rich Fulcher.
DAVE CHIU: I'm Dave Chiu.
ZACH GIBSON: Zach Gibson.
BETHANY FONG: And I'm Bethany Fong.
RICH FULCHER: And we're all designers
working from across Google, from Android to Chrome,
concentrating on bringing Material Design to Google's
apps.
And just personally, we're really
thrilled to be here this morning to really get
to show off this work that we've been working on
for quite a while now.
So thanks for coming.
Yesterday's keynote introduced Material Design,
which is a new visual language focused
on creating bold, graphic interfaces.
It takes the principles of typography, position, scale,
and color, and uses those to build
really wonderful interfaces.
Material Design combines these classic print design principles
with the kind of innovation that you
can achieve through the application of technology.
It takes elements that were formerly static and makes
them reactive and responsive.
It receives energy from the user, from the user's finger,
from their mouse click, and it directs that energy
to power transformation and animation
of the material itself.
Material Design is also one adaptive design.
So it's a single design system that
covers handheld and web devices.
It covers a variety of different form factors.
Now, this is important because it enables the user
to leverage the mastery they gain in one context
and apply it to another to get that sense of intuitiveness
that comes from being able to do that.
In this session, we're going to discuss
how Material Design affects the way you design
the interaction of your applications.
We're going to cover three major topics today.
We're going to start by talking about the materials themselves
and the properties of those materials
that guide how you use them.
That will lead into a discussion of structure, which
will cover both the level of how do I structure
individual scenes or views within my application,
and then up to how do I structure my entire app.
And finally, we'll end by looking
at some of the standard components that
are kind of novel for Material Design
and go into a bit of detail about how you can apply them
that are particularly important.
So since Material is the metaphor that
powers this entire system, let's start by talking about two
of the fundamental ones-- paper and ink.
DAVE CHIU: In Material Design, every pixel drawn by an app
is a dot of ink on a piece of paper.
Paper is, on its own, colorless.
Ink can be any color.
Each piece of paper wants to be a simple shape with rounded
corners-- a rectangle, a square, or a circle, which
is, after all, just a square with extremely rounded corners.
Paper does not want to be a star or a triangle
or the shape of your app icon.
Ink is much less restricted.
It can flow into any shape.
Measured in the x- and y-axes, both paper and ink
can have any size.
Paper can fill the entire display such
that you can't see the edges, or it
can be the size of a single button.
The size of ink is limited only by its need to stay on paper.
But paper has an absolute fixed thickness
equal to one DIP, or Density Independent Pixel.
Now, why is that important?
Because we must now consider the z-axis when laying out content.
As a quick refresher, the z-axis is perpendicular to both the x-
and y-axes, allowing us to position surfaces in front
of or behind other surfaces.
Paper surfaces are intuitive and natural.
But to maintain that materiality, we layer
and move them in ways that could plausibly
fit within these devices.
This means we constrain paper's behavior
based on the perceived z depth of the device.
So for a phone, that's the distance
between your thumb on the screen to the back
of the phone against the palm of your hand.
Monitors and television support perceived
z depth greater than their physical dimensions in part
because we don't physically handle the devices.
The position of a piece of paper gives the user
hints about how it relates to other paper.
The dimensionality invites interaction.
When the user sees a realistic shadow,
they think there is a gap-- we call it a step-- between two
pieces of paper, and they will behave and move independently.
When there is no shadow between two coplanar pieces of paper,
the edge they share is instead a seam.
And the movement of those pieces of paper
will be linked together.
Paper always occupies a single z position.
It is always flat, never tilted so that one edge is
closer than another to the user, and it does not
flip over to show the other side.
The z position of paper is also a reflection
of content hierarchy.
Paper with a z position closer to the user
typically contains content you want the user to focus on,
such as a dialog box, or when you
select a date in the calendar and it expands
and moves forward from the grid.
Paper with a z position that's higher
also tends to affect underlying content.
An obvious example is a navigation drawer,
which appears above everything else
because it changes the displayed content.
App bars are another obvious example.
With Material Design, rather than
thinking of depth as ornament-- so adding a few drop
shadows here and there and calling it a day--
use depth to help users understand how your app works,
how content is organized, and the scope of actions.
So let's talk about layout.
How do we take all the possibilities of this system
and present them in a coherent and consistent fashion?
ZACH GIBSON: In all of our Material Design layouts,
we strive for consistency, a cohesive experience
across all of our apps.
This starts with the fundamental structure
of how we build our applications and layouts.
The history of graphic design has given us
tools like key lines, baseline grids, aspect ratios,
and the use of incremental spatial relationships
in our designs.
These tools are the building blocks that we use
and we need to create consistency in our designs
across mobile tablet and desktop.
Historically, the best graphic design work
has come from a deep understanding of a grid
structure, so that when it's used to its full potential
or even when something breaks this grid structure,
it can be done in exciting and innovative and delightful ways.
So there's a visual design talk that's happening later today.
And it's going to cover a bit more details about the grid
structure.
But for this presentation, it's just
important to note that our grid system is
based on an 8-DIP increment.
So it's nothing new, really.
If you've been working for the web,
these are very familiar and friendly numbers.
You'll find that our headers, icons, paper elements, padding,
margins, buttons, et cetera are all numbers like 16, 24, 32,
96, 960, 1,024.
You get the idea.
They're all familiar and friendly numbers to us.
We're just baking this into the system
for the sake of consistency and visual harmony across all
of our screens.
So with our grid now in place, I think
we're ready to start designing some apps.
RICH FULCHER: OK, so how do the properties of paper and ink
affect the way that you actually structure your app?
So when you construct any particular screen,
we've found it best to start from paper.
That's the material that's really
going to define the architecture of any scene
or view that you're going to construct.
And it's going to call out what elements
are surfaced above or below or can move independently.
You can always come back and do ink as kind of a second pass.
You've got your paper laid out.
Then you can fill in as you would just kind of draw it in,
all of the controls, all of the content, as a later action.
We've spent a lot of time actually
cutting out pieces of paper and layering them and moving them
till we came up, within the system,
with views that made sense.
I really got to hone my scissor and glue
skills working on this project.
We even used things like little wooden discs
here to track the Floating Action Button, which
is a highlight component within Material Design
that Bethany will go into more detail
about in just a couple of minutes.
So playing with paper is a great practice
for just getting a sense of how this design system works.
It really gives you a feel for how
the surfaces will interact with each other.
When they approach each other, does one
lift to get out of the way of the other?
Do they move together as a group?
And just kind of shuffling the paper around physically
helps you just very quickly get an understanding of that.
It's a really fast, really cheap, even kind
of fun way of designing.
So when we're talking about just the structural possibilities
for your app at the high level, all of the possibilities
that you're used to seeing are still there.
If your app wants to use tabs, that's great.
We support that.
No worries.
If you occasionally indulge in using a left side navigation
drawer, that's covered, too.
That pattern's there.
If your app is all about search, we like search, too.
That's a pattern that you can support, as well.
As a designer or developer of your application,
you are responsible for picking the most appropriate pattern
that's going to best serve your users and their goals.
So be sure to consider all the possibilities.
Now, each of those will have its own set
of advantages and disadvantages.
I'll pick on the left navigation drawer for just a moment here.
This is a really suitable pattern
if you have a large number of high-level views.
It becomes, effectively, this very convenient table
of contents to your application that the user can quickly
access and scan and jump to a section.
It can also be really valuable if your app has deep paths
through its hierarchy, where the user can go down,
down, down to deeper levels, because they
can use the drawer as a rapid mechanism
for pivoting back and going to a different top level
without having to go up, up, up first to do that.
On the other hand, there are drawbacks to the drawer.
It's clearly not as obvious as something
like tabs, which are immediately visible on the screen all
of the time.
It also may not be ideal if the contents of the drawer
are heterogeneous, if it's not a standard list of categories
or labels, because, in that case,
the user is going to need to spend a little bit more
time using your app to familiarize themselves
with what the content of that drawer
is, because they're not seeing it all of the time.
On the other other hand, that could be valuable
if you're trying to demote some of that content,
if those are less frequently visited destinations
that you want to politely steer the user away from,
but make accessible in certain situations.
So as every designer always says, it depends.
ZACH GIBSON: So the previous examples
that Rich showed and a lot of the screens that we've
been looking at are all mobile.
But the basic structure of our applications
applies to mobile tablet and desktop layouts.
The tools that we have at our disposal are all here.
There's an app bar, there's a canvas area with a Floating
Action Button, there's an occasional bottom bar and side
navs that can be accessed temporarily.
From a structural standpoint, we keep this stuff
around no matter what the screen size is.
So as we move up in the tablet, the app bar
can absorb elements that couldn't
fit into the mobile screens, and the side nav bars can still
be accessed temporarily as they were in mobile,
or they can be pinned.
Additionally, in our desktop structure,
the side nav bar as well as content canvas area
can have secondary toolbars for things
like tabs or palettes or just secondary actions.
As you'll notice in Material Design,
these structural elements are all extremely flexible.
They can move and react to screen sizes
and different contexts in magical ways.
So let's take a look at some of the family shots
that we have to see what's happening.
In this example of a file browser,
you can see a lot of the stuff that we talked about in action.
The header is extended based on a default height of the app
bar.
And this is really just to create
a little bit of visual hierarchy in the layout
for the tiles and the list.
As you can see on the desktop screen here,
the right nav is pinned while browsing.
In the mobile screen here, we add intentional negative space
between the line items just to separate the items
with something other than a rule.
And a similar app structure is maintained
throughout our layouts.
And you can see that here by the left nav being opened.
Our responsive solutions combine fixed, fluid,
and sticky elements that should be able to adapt to the way
that people use their devices.
You can see that here by the mobile screen.
The density of information that's being shown
relates to the amount of information
that people want to interact with on their phone.
On tablet, we can add illustrations,
we can add photographs, to make a more immersive and playful
experience.
And then, when the screen grows, we
can add intentional negative space again
to separate content areas.
The toolbar that's being shown here
is also extremely flexible.
It can rest on a background, it can
be transparent over an image, or it
can fit within any defined space.
Our designs show a lot of variations in the toolbars
to make them generally more useful and flexible.
Sometimes, we extend the top bar just to add a splash of color
to our screens.
We can use cards to keep text line lengths
at digestible sizes when the screen gets bigger.
Primary content can be higher in z depth or closer to the glass.
In this contacts screen, you can see that a left nav also
might be pinned and scroll under the toolbar,
while primary content in a card might scroll over the toolbar.
You can also see here that what was
full width on a mobile screen is now
a floating card or a floating surface on desktop.
You can also see one of our designers.
In this music example, we're using
a bottom bar for the player.
We're using large photographs in the background
and dynamic color choices.
We're also using a Floating Action Button,
this little blue Play button in some of the screens
here, just to add a pop of color to screen.
Bethany's going to talk a little bit more about that.
There's a lot of structural nuance
that's happening in this screen.
Our toolbars can have all types of content
in them, from photographs to input fields.
And we can use typographic scale by having dynamic type.
Menus that generate from toolbars,
they can come above other elements in z depth.
And this plays into our story of real materials in real space
that can do magical things.
And not all of our toolbars are pinned
to the top in a colored bar.
They can be associated with a surface that's
currently in focus.
So if you imagine this toolbar here associated
with this list view, when it scrolls down,
that toolbar might come with it.
So how does all of this content move?
There's going to be a lot more details covered in the motion
talk that's happening later today.
But let's talk a little bit about scrolling.
This is a common scrolling pattern that's happening here.
Content moves up, the app bar scrolls off.
And the status bar picks up a little bit
of the color of the application and sticks around,
which is something new with Material.
Also, when a user scrolls back here,
the toolbar can come back at a little bit
of a different pace than the content.
In this example, you can see how we
think of the top toolbar in blocks.
There's one block that contains the search field and another
that contains tabs.
On scroll, these are handled independently.
So here, we're pushing off the top search bar
and keeping the tabs.
And this is dependent on the context of the application.
You can also see that, on the slightest downward pull,
the search bar comes back.
This is where things get really exciting.
We can have photographs that morph
into colored bars on our toolbars.
We can have dynamic UI that removes itself
from the screen in different ways.
Our typography can scale and move.
Scrolling and the way that things move
is very much dependent on content and the context
and the containers that hold our content.
So with that in mind, Dave's going
to talk more about components.
DAVE CHIU: So now that we've covered Material
and how it's structured, let's take a closer look
at some of the bits and pieces that make up
an interface and some of the best practices
for implementing them.
At a high level, one key thing you typically want to do
is organize information to help your users make decisions.
We support the expected forms of content organization-- lists,
grids, and now, formally, cards.
Lists and grids are familiar and well understood.
Lists are great for text, and grids are great for images.
But the question of why and when to use cards
has been a point of some uncertainty in the past.
So here's some more concrete guidelines.
Cards are great for displaying a set of data
with different content types.
Google now is a perfect example-- stock quotes,
weather, directions, World Cup scores--
as a little aside here, any spontaneous booing or cheering
during our talk will not be taken personally.
Each card can have a dramatically different
presentation, so making them separate pieces of paper
makes sense.
Cards are malleable and can easily handle data sets
where content varies in length from item to item.
In comparison, lists and grids have a natural bias
towards regularity, making them best
for consistently structured data.
Each card can contain a heterogeneous mix
of media, text, controls, and actions
related to a single subject.
Cards give you the flexibility to combine and create complex
compositions of content and actions, such as +1 buttons,
sliders, and comments, in a way that lists and grids
aren't simply designed to handle.
But just because you can use cards
does not mean you should use them.
When deciding between lists, grids, or cards,
first ask yourself, how can I best support my user's goals?
Are they trying to find a specific thing,
like a photo or a file?
Grids and lists have a consistent rhythm
and composition that makes them easy to scan
and well suited for quick comparison.
In contrast, cards are harder to scan through
because of their irregular cadence.
But they are great for browsing diverse content and layouts.
As these examples show, adding more pieces of paper, more ink,
and more shadows to the screen increases noise and distraction
without increasing clarity.
Remember, you can always split an item
into its own piece of paper the instant it's needed.
So that's a brief overview of containers and some guidelines
around when to use each type.
Bethany will now cover more of the components and best
practices to use when building Material Design interfaces.
BETHANY FONG: So we looked at all the standard UI elements,
like buttons, text fields, and switches,
from a Material Design perspective
so that they, too, will help you create
one adaptive design for your app.
And these goals of moderating complexity
and of reacting appropriately extend
into all of our elements.
Our controls are designed to be consistent with the larger
visual story.
We use simple geometric shapes to build
more complex, but still cohesive, components.
And by building with paper and ink,
our components have an enhanced ability to react to the user.
For example, as elements come into focus,
they become alive, hinting at what's
to come by ebbing and flowing between the rest
and the pressed state, through diffusing ink
and traveling through the z space.
Element states have been simplified to help
as you design across form factors.
All of the element states are coordinated
so that the same element will function correctly
in a design that is being used with different input methods.
You can see that each input method works nicely
with the others without having to duplicate your control
states.
And as you create custom controls for your own app,
you may want to follow a similar approach for quicker
adaptability.
I'm going to talk in more detail about buttons.
There are three styles of buttons,
and each is appropriate for different circumstances.
The Floating Action Button is known
by its shorthand, the FAB.
The FAB is the newest and has the most unique
characteristics, while the others are more familiar.
Both the FAB and the raised buttons
are made of paper in Material Design,
and the flat button is made of ink.
This pyramid illustrates the frequency
of use of different button styles.
The FAB is the strongest in the visual hierarchy
and is most rarely used.
It's special.
The raised button is used more commonly, but still sparingly.
It's quite visible, but because it doesn't float
means it doesn't respond to z space changes in the same way
that the FAB does.
And finally, there is the flat button,
a very commonly used control.
So I heard in the session yesterday there's
a really good question that was, basically,
what are all the circles on the screen?
And here it is.
It's the FAB.
So it represents the single hallmark action for a screen.
It's a tool for you to call out the key parts of your app's
product story.
It should be used for actions that
are strongly characteristic of your app.
Pausing or resuming playback tells me
that this is a music app.
Or driving directions tells me that this is a maps app.
Not every screen should use a FAB,
because not every screen has an action with this importance.
It doesn't really have the right type of data.
It's a natural cue for telling users what to do next, also.
So in user research, we found that users understood it
as a way-finding tool.
Research shows that, when faced with an onslaught
of unfamiliar screens, as many users do on a regular basis,
like when they install your app for the first time,
they started using the FAB to navigate.
And users discovered that it was really
useful as a signpost of what's important.
And here, the FAB is being used in a variety
of different types of apps.
You can see how it highlights a hallmark action for each app--
compose for a messaging app, add files for a storage app,
and so on.
And you've probably noticed that it
can be placed around the screen.
And we have a few recommended places
that work pretty well, like in the lower right-hand corner.
The FAB is also the first element
that is allowed to straddle a seam
or allowed the hang over a paper edge,
such as in the screen for people.
And also note that there's only one FAB per screen.
There should never be multiple on screen at one time,
as that confuses our visual hierarchical goal.
You can use your app's accent color for your FAB.
Just make sure that you retain adequate contrast
from the background.
Because the FAB is character-ful,
it's generally a positive action,
like create, favorite, share, navigate, explore, and so on.
And unless it's truly the hallmark of an app,
FAB shouldn't be destructive actions, like archive or trash.
They also shouldn't be unspecific
or alerts, limited actions like cutting and pasting text,
or stuff that should really been in a toolbar,
like changing the volume.
Basically, the function should be
an action that makes your user feel really
positive about using the FAB and never
worried it's going to do something wrong.
So it's not just a round button.
It has some transformative properties
that you'll be able to use to help ease
your users from screen to screen.
It can expand, morph, and react.
The FAB can replace itself with a sequence
of more specific of actions.
This helps surface a set that don't really belong at the top,
but are still important.
And you can design them to be contextual to your users.
Imagine a user tapping the FAB and their favorite people
expanding out as contacts.
And these do need to be tightly related actions, as well
as ones which can be understood through the simple initial
icon.
So for example, if an add FAB hides the search function,
users won't naturally think to look there for search.
And lastly, don't turn your FAB into an action overflow.
Those still belong in the app bar.
So because the FAB is made of floating paper,
it can morph into a new surface that
allows for richer interactions.
For example, you can have a new Post
FAB, which enlarges directly into a composition field
or into an open camera viewfinder.
It's not just a fancy or dropdown menu.
You're making your hero action even more heroic
and reinforcing the sense that this
is a core usage of your app.
As you recall, FABs can be positioned
along steps or seams of paper.
And as that paper moves, the FAB can transfer its anchor point.
Reactions can be simple as shifting
a FAB's position in response to other paper moving,
like in Zach's example.
Or as a user scrolls down a page,
the FAB can hop locations from scene to scene or even off
to a floating position so that users
don't lose sight of that important FAB function.
So with that, you should have a picture
of what the new Material Design elements are like
and what the FAB can do for your app.
RICH FULCHER: So we've covered kind
of the basics of Material Design, how
the materials behave.
We've talked about layout, we've talked about structure,
we highlighted a couple of key components.
But as developers and designers who already have apps,
the question on your mind is probably, what's next?
How do I take these Material Design principles,
this new system, and apply it to my apps?
The good news is we haven't thrown out
anything you already know.
So all of the components that you're used to using,
they're still there.
They're still supported.
We've given them a little bit of a refresh
to make them more reactive, more alive.
But they're still there, and you can still count on them.
As announced yesterday, there is a preview release of our new UI
guidelines available at www.google.com/design.
And this covers all of the standard components
that we didn't address today that haven't changed.
So you can see all of those elements.
You can get all the updated guidance on those.
It's also packed with examples.
So you may see in those examples something that
inspires you to think about the design of your app
or part of your app in a slightly different way.
Here's a screenshot from the spec covering the layout
chapter, just showing a few wire frames.
And it clearly shows the application of the 8-DIP grid
that Zach talked about.
And you can see some of the key lines called out.
All of these guides have been responsibly designed
so that they'll work well on desktop, on tablet, on phone.
You can check them on any of the devices
that you're designing for.
I wouldn't read them on your new fancy Android Wear.
But everything else we've got covered.
So this site will continue to evolve
as our frameworks update.
There are also a lot of really helpful resources,
particularly for interaction designers, on this site.
So we offer a bunch of layout templates
for the standard views.
We have sticker sheets of all of the component types.
And if you're thinking Android, they're
in light and dark theme available there.
And then there are also color palettes, icon sets, advice
or animation, lots and lots of content there.
But we'd like to leave you with a challenge.
And that is to think about not just
how you can make your app more attractive, more delightful
by applying Material Design to it.
But how can you use these principles to actually make
your app easier to use?
And one way to start on that is to question some of the design
decisions you may have already made.
So let's start with the biggest one, the question of,
how do I structure my application?
We talked about structuring based
on hierarchy in this talk.
But another way of thinking about it
might be to structure based on motion,
planning for all the different surfaces
that you want to have moving between the different views
within your application.
And what are those elements that should be lifted up,
that are important, that want to get that signature treatment?
Motion provides meaning to the user.
It is a form of feedback which focuses the user's attention.
And it builds a sense of continuity
between different states within your application.
So relatedly, how do you move to a model that
is-- the old model we've been building in
is this kind of screen, screen, screen style
of design, where I start at the top of my app,
and then I build all the intermediary screens
till I get to the bottom of the app.
And we just kind of realize those one at a time.
We can do something much more fluid now.
We can use transitions to give the user the sense that they
can do more work in fewer places within the app
by just transforming the context slightly for them.
So we can use animation to guide the user here,
rather than just dropping them into some new context where
they have to reorient themselves after they've
landed from the teleport.
You can guide them more easily, build up
more of that sense of direction and connection
between these different conditions.
And think about what you would do for the FAB
if it's appropriate for your screen.
What is that hallmark application or that hallmark
action that you'd want affiliated
with your application?
Or think of it this way-- what's that action
that you want to clearly show in the screenshot promoting
your app that shows up in the detail page of a store listing?
What's the thing anybody looking at that should take away
and say, oh, this app does this?
And in general, how can you lean into the frameworks more?
Are there things that you're doing currently
in a custom way that no longer need
to be custom, that can take advantage of some
of the new APIs that are present?
Can you make your code base faster, smaller,
easier to maintain by relying on the framework more?
There are three more excellent sessions today
covering different aspects of Material Design.
There's one starting at the top of the hour.
And then, later today, we have sessions specifically
on visual design and on motion design.
We also have the Sandbox space.
If you've come by there, you've seen the new UI guidelines
projected on giant touch screens.
We'll have a couple of small, short talks there.
I'll give a talk at 2:00 on a little bit more detail
about using paper and ink and how those work.
But all of the designers here, as well as others,
will be in that space.
It's a really great opportunity to ask any questions you might
have and just come by and say hi.
We're happy to meet you.
And with that, thank you very much for your interest
and for your attention today.
[APPLAUSE]
And we'll happily take a few questions
in the time that remains.
MALE SPEAKER: Hello, I'm [? Akeel ?]
from the University of Maryland.
And I just had a question about the navigation drawer.
What were the reasons behind moving the hamburger icon
from halfway beyond the edge to into the screen?
RICH FULCHER: OK.
I think this question maybe relates most to Android.
So formerly, in Android, you'd have the application icon
and then a hint of the drawer indicator icon beside it.
Part of Material has moved away from using the app icon
as the visual identifier of where you are.
And we tried to encourage developers to express the app's
identity more through those standards of color
and typography and treatment to make each view more
character-ful and more immediately recognizable.
So as we moved away from using the application icon,
we want to give a full width affordance
in that space for opening the drawer.
MALE SPEAKER: Thank you.
RICH FULCHER: Sure.
MALE SPEAKER: Hi.
This is essentially paper, but I haven't seen any folding.
Is there any specific reason for that?
DAVE CHIU: So one of the things I
talked about was this notion of perceived z depth.
And so, when you're handling a phone,
you have a sense of the thickness
of that between the glass and the back of the phone.
So we want to preserve the notion
that there is a finite amount of space to use.
And so, if you start folding things,
then that would sort of break the plane.
That's something potentially you could explore maybe
on deeper z depth environments, like televisions, when
you start thinking about three dimensions.
But for now, we're really focusing on keeping things
in a single z position and sort of moving things laterally.
MALE SPEAKER: OK, makes sense.
Thanks.
MALE SPEAKER: Hi.
So the I mainly was wanting to ask
about, for backwards compatibility, to getting
these new patterns into as far back as, like, Gingerbread.
Is that possible?
And also, for low-end devices with all these new animations,
what are things that-- is it just better not to use those?
Or what are good guidelines?
RICH FULCHER: Sure.
I think my take on the best practice
is you want to kind of design for Material Design,
first and foremost.
We've found that the translation exercise of taking something
that's designed for Material and kind of simplifying it downward
has been a reasonably straightforward one.
I mean, most of the same elements are still there.
You still have things like action bars and toolbars.
You can make them less transformative
as the design goes down to earlier versions.
And some of these changes will actually
be supported through Support Library, as well.
So I think you just start with the highest end,
you simplify to pare it down, and then
you still have a design that feels very coherent.
Material has a unique theme on Androids.
You can target that theme and build against it.
And you can kind of see what happens on that right away.
The second part of your question was-- sorry,
just remind me quickly.
MALE SPEAKER: Low-end devices.
RICH FULCHER: Low-end devices, yes.
So the animation framework will actually
be aware of the capabilities.
It will basically shorten or remove animations in some cases
to make sure that, instead of just getting
a very junky or stuttery animation,
you just sometimes get a clean cut or cross-fade instead
of a more elaborate one.
So it's not as full of an experience,
but it still feels kind of complete for that device.
MALE SPEAKER: OK, thanks.
RICH FULCHER: Sure.
MALE SPEAKER: Hi.
I have the skeuomorphism question.
I'm wondering how that went internally.
And do you guys consider the skeuomorph?
DAVE CHIU: So skeuomorphism.
So that's the notion of introducing
kind of ornament and unnecessary elements into design.
And I would say that, in this case,
we're trying to use paper as an inspiration.
It's an interesting question, because I guess the most amount
of skeuomorphism that you could potentially
call skeuomorphism is, effectively, shadowing,
because, effectively, they're just pieces of paper that
are moving about.
There's no additional ornament beyond it's
a blank piece of paper that you're adding ink to.
The idea there is that we're trying
to add additional affordances so people can more intelligently
understand what's going on.
Conversations have given the design
world talk about flat design and post flat design.
Arguably, this is kind of post flat design, because we're
trying to take the direction of flat design, which
is the answer or response to skeuomorphism-- that's
one extreme end of the spectrum-- we're trying to pull
it back and say, we do kind of need
to introduce a little bit more affordance here and give users
guidance as to how things work, how
they relate to each other, what to expect.
ZACH GIBSON: Yeah.
Just to add to that, I think we're
at a place that's kind of in between the flat
and skeuomorphism.
A lot of our stuff is flat on first appearance,
but it's tangible and you can touch it.
And when you do touch it and interact with it,
it feels real.
And I think that that's a kind of place that's
in between pure, flat design and skeuomorphic stuff.
MALE SPEAKER: Cool.
Thank you.
ZACH GIBSON: Yeah, sure.
MALE SPEAKER: Hi.
You'll have to forgive me if this is a basic design
question, because I'm a developer.
But you mentioned that it's important to have the FAB's
primary color work well with the image content behind it.
I'm just wondering if there is sort of a way
that you determine what that is dynamically
based on the content.
And if so, is that available in Polymer and Android?
RICH FULCHER: Yeah.
So the library is called Palette.
It is a way of extracting the dominant color
value from an image and then using
that to select the complimentary color that's appropriate.
I think there are a few cases where
the FAB would want to do that.
I think the FAB in particular often
wants to be a known, fixed color for easy identifiability
within your app.
That said, there are a couple of contexts
where it makes sense to do that.
But it is supported.
And Palette is the name of that library.
MALE SPEAKER: Thank you.
RICH FULCHER: Sure.
FEMALE SPEAKER: Hi.
FAB definitely stands out for me in this talk.
And I think through the whole conference,
designing for your cross platform is
one of the main themes this year.
So I'm just wondering, any thoughts
on how to apply FAB in TV space, like in a TV UI?
Because for most of TV, the remote
doesn't have a touch screen, and it still operates on D-pad.
So I'm just wondering, any thoughts on that?
BETHANY FONG: Yeah.
So the FAB is a raised button which still has a focus state.
And I know that a lot of our TV UI
relies on moving the focus state around the screen.
And a lot of our apps on Android TV,
we've actually used the FAB very successfully using focus
to pull it out.
So it still works.
FEMALE SPEAKER: OK, thanks.
FEMALE SPEAKER: Hi.
My question is kind of related.
So I love what you've done to, I guess,
facilitate design cross-platform.
So I'm wondering, if you're working on a product that
is still primarily desktop-- is still kind of becoming
responsive, but is still desktop-- do you feel like some
of these things, like the new animations or the metaphors
of paper and ink, is that still appropriate for a primarily
desktop application?
Or does it require interaction via touch?
ZACH GIBSON: Yeah, I think it's still appropriate.
A lot of the Polymer stuff that we've been working on
implements some of these touch ripples and animations.
And you can kind of get some of that stuff for free
by using Polymer elements in desktop.
But yeah, I think it totally still applies.
On mobile, there's no hover states.
And there's definitely differences.
And I think we're trying to respect those differences
in the different form factors.
But just from a structural standpoint,
keeping all of the same stuff around
is how we're keeping consistent across form factors.
DAVE CHIU: And as Bethany and I have both sort of discussed,
the notion of the FAB transforming and also
just paper hierarchy, some of those things
still apply to desktop.
So you can start talking about how
the FAB transforms a to-do paper.
And that helps cue users that there's
a new activity or a new action being-- when you're composing
a new email or note or something,
that can turn into a new piece of paper and helps
give them some sense of relationship
with that new surface, with the work
that they've been previously doing.
FEMALE SPEAKER: Have you found that users,
that their relationship with the mouse in the screen
is kind of similar with their relationship
to just clicking on the screen?
Have you kind of explored that?
RICH FULCHER: There's a bit more difference.
I don't think any of us are too close to that work
specifically.
But I know from the development of the pixel
that users sometimes move between those modes
of engagement.
Like when a touchscreen is available,
that's appropriate for some lighter
browsing-oriented activities.
But the more precise targeting and more work active,
I'm alternating between keyboard and mouse,
they tend to bias towards that affordance.
FEMALE SPEAKER: OK.
Thank you.
RICH FULCHER: Sure.
All right.
Well, thank you all again.
DAVE CHIU: Thank you.
ZACH GIBSON: Thanks, guys.
[APPLAUSE]