Adaptive UI with Material Design and Paper Elements (The Polymer Summit 2015)

Adaptive UI with Material Design and Paper Elements (The Polymer Summit 2015)

How’s everyone doing? Welcome back from lunch. We’re here from the
Material Design team. My name is Zachary Gibson,
the senior designer. This is Yuin Chien, also a
designer on the material design team, and Addy from Polymer. We’re going talk a little bit
about adaptive UI with Material Design and what’s happening
with Paper Elements. So let’s just jump right in. I am no mathematician. I’m a designer. But I can tell you that
the trick to arithmetic is not simply to solve problems. 5 times 5 will always be 25. The trick is to understand
all of the various rules and systems and
stuff that exists that allows us to solve
any mathematical problems of height, width, area. And the same thing is true
when we design adaptive UI. We can design for any screen. We can make things
for any screen. But the trick is to understand
the systems, and all the patterns, and all of the
stuff that exist that allows us to design for everywhere. So in the next 30 minutes,
Yuin and Addy and I are going to show
you some of the stuff that we’re hard at work
to define how Material Design works everywhere. YUIN CHIEN: [INAUDIBLE]. ZACHARY GIBSON: I’ll keep going. A couple little
clicker fumbles here. You go ahead. You go. YUIN CHIEN: If
you’re unfamiliar, Material Design is
a visual language created by Google that
unified classic principles of good design with innovation
and possibility of today’s technology. By sharing a conceptual
metaphor, a visual style that’s bold and graphic
involving motion design, it is a single
underlying system that allows for a unified
experience across platforms and different screen sizes. First launched at
Google I/O in 2014, which is a year and
half ago, Material has received great press. We really like this
quote from Armin. “Material has the
potential of being one of the most significant
visual improvements to the web.” Nearly a quarter
million Android apps have gone Material
since we first launched. While Android is
Google’s vehicle for bringing Material Design
to native apps on mobile– ADDY OSMANI: Polymer is Google’s
reference implementation for Material Design
on the web, including things like
components and layout and other components– things
like the Iron Elements set set or the Neon Animation set. You guys have downloaded
the Paper Elements set. You’ve looked at it over
2 and 1/2 million times. It’s kind of crazy, right? And you’re using Paper
Elements in over 100,000 pages at the moment. And this number is
going really fast. Now, we think that adaptive
UI Material Design and Polymer are a really great fit because
when you’re developing a web app, you want to make
sure that it works really great cross-device. You want to be able
to build something that looks like a
native app on mobile, but but when you go to
desktop, it adapts and uses the best of your
hardware abilities and all of your
screen real estate. And you also want it to
look fantastic on tablets. Now, the Polymer and
Material Design teams have been working
really closely to try to make sure the Paper Elements
set works great cross-device. And we’ve got tons
of examples and demos that we’re going to
talk about in just a bit about showing you how you can
apply adaptive UI principles to your Polymer apps. ZACHARY GIBSON: So what
is adaptive design? We’re all familiar with
responsive design– blocks, reshuffling, mostly
based on media queries. But I think adaptive design
takes this a little bit further. We are enabling the containers
to fit in the right form and are just appropriate
to the right content. And adaptive design
is based on context, like how a person is using
a certain screen or device. It’s based on content,
just respecting why a user is looking
at something when they’re looking at it. Input methods varying from
fingers to mouses to– or mice? Is it mice or mouses? Mice. Mice, keyboard, and voice. A lot of just various
input methods. We also have user needs
like accessibility and internationalization,
and even device limitations like
processor or bandwidth constraints. So obviously, that’s
a lot of stuff to take into consideration
when we’re trying to make a web app, right? And, you know, the
web is pretty wild. It’s not a controlled ecosystem
like designing something for Android. So it becomes difficult to
just standardize UX patterns across form factors. But we’re trying to tackle
this issue, the Material Design team and Polymer. And I’m going to walk you
through some of the stuff that we’re trying to do. And I really think that
it starts with naming. We need to be able to codify
our UI’s nomenclature. So to show you how
we’re doing this, I’m going to play
a little game here. I’m going to describe a
Material Design component and we’re going to see
if Addy or Yuin knows which component I’m
describing without showing it. So this is a temporary panel. It’s on the left
side of the screen and it contains navigation. ADDY OSMANI: Paper-drawer-panel. ZACHARY GIBSON: Yeah, I think
he knew the answer at the time. ADDY OSMANI: Shh! ZACHARY GIBSON: This is the
paper-drawer-panel, right? But here’s what we did. We described the behavior,
we described the structure, it’s a panel. And we give it
certain descriptors like, it’s on the left,
it contains navigation. So let’s go again here. This is a toolbar. It’s at the top of the screen. It’s in front of
all other content, so things might come
behind it, and it contains actions and a title. YUIN CHIEN: It’s
the paper-toolbar. ZACHARY GIBSON: Yeah. So this is the
paper-toolbar– what we call the app bar in Material Design. So we did the same things,
followed the same patterns. Their structure, behavior,
and certain descriptors. We can define pretty complex
UI following this pattern. So you have, you know,
a group of surfaces, it’s displayed in
three vertical columns, the group is centered on stage. And each surface contains
a summary of content that can expand
and other surfaces might reflow around this. So this is something like,
it might make G+ or Pinterest or Google Keep. So you can see that, by
defining certain structures, like our Material
Design components, you have a toolbar,
a sheet, a panel. With various descriptors– it’s
on the left, it’s on the right, in front, or behind,
or above, below. With various behaviors,
like something is persistent or temporary. We’ve created a matrix
so we can just accurately talk about our UI. So you have a toolbar. It’s at the top,
and its permanent. That’s our app bar. You might have a sheet that’s at
the bottom, and it’s temporary. We call this a bottom sheet. So with a consistent
nomenclature to be able to describe
the structure and what might be in that structure,
and how we should expect it to behave with
certain behaviors– both verbally, just like
how we talk about our UI, and in code– we can
accurately define how our UI should get built. YUIN CHIEN: So what is a grid? The main purpose of a grid is to
set up limitations to a layout. But with those limitations
comes many great qualities like style, fa familial
placement of items and content, and a cohesive feeling
across products. Let me walk you through some
of the rules and patterns that our grid follows as we
create a structure of Material Design interfaces. Our 12-column grid system allows
for a wide variety of layouts. Here you can see we’re
combining components like a toolbar, a
list, and a card. The list takes up four
columns of the grid. We have one column of negative
space, a six-column card, and another column
of negative space. This next example
is very similar. We have a extender
header and a card that goes over the [? edbar. ?]
And it follows the same grid. Now let’s remove the list. Here we have a six-column card. We can introduce something like
a left panel, which we can see squeeze the grid to the right. Notice that we still
have a six-column card. The system isn’t just
limited to layout with cards. Here we have a left panel,
a list, and a detail view, and it follows the same
grid as we just mentioned. This last example–
there’s a left panel that overlays the grid, gr there’s
an extended [? edbar ?], and a persistent right panel. Notice that the left
panel has no effect on the grid or the content. I’ll talk more in detail about
behaviors in just a moment. For now, the most
important thing is the versatility of laying
out various Material Design apps using this same grid system. We’ve also defined guidance
for common margins and gutters. Here you can see we’re using
8, 16, 24, and [? 48 ?] DIPs margins and gutters. If you’re unfamiliar, a DIP
is a unit of measurement in which the numbers are
independent of the density of the screen. DIP, Density Independent Pixel. The most important
thing here is that we’re focusing on the
margins and gutters to create consistency
in our layout rather than defining
the column width. There are more grid
patterns at our disposal. Here, the first example,
the grid is full width, and it squeezes content block
as the screen size changes. In the second
example, the grid is centered where blocks reflow. When a navigation is very
important to the flow of an app, a left panel can
be permanently on screen. I’m going to talk about two
types of behaviors here. The first one is persistent,
the second one is temporary. In the first example,
there is a persistent panel coming from the left. Here I can still
interact with the content and choose to remove the panel. The second example,
the panel is temporary. Here I’ll need to snap out in
order to get my content back. This last example
is another variance of the temporary behavior. Here you can see a left panel
can simply overlay content. ZACHARY GIBSON:
Successful handoff. So, you know, we have this
idea of a consistent grid. And now we need to
know what happens to that grid as
different parameters, adaptive parameters change. So to do that, in
Material Design, we’ve started to align around
certain breakpoint systems that work across material
products, right? It looks pretty complex–
a little like this. it’s kind of complex,
but what we’ve done here is we’ve done a detailed
study of our device landscape, ranging from small phones to
super large desktop displays. Let me break this down
a little bit here. So, you know, on desktop,
we looked at window sizes. So you have an
extra small window and that goes all the way
up to an extra large window. On mobile, we have
three basic sizes. There’s small, medium, large. Small is like your
Android One devices, medium’s like a Nexus
5K or an iPhone 6, and large is, yay, Phablets. We also looked at tablet sizes. So we have small tablet
sizes, like a 7 inch, and large is like
a 10 inch tablet. And then for landscape, we
calculate the smallest width in either orientation
as the defining value. So here’s how landscapes look. And getting to some
of the stuff that Yuin was showing with
the grid, we’ve also defined a few key points at
which that default grid starts to change based on screen size. So you can see above 840 here,
it’s a 12-column grid system, always. Sometimes more when it
gets bigger, above 1600. For the most part, 12 columns. And then below that,
840 to basically 480. It’s an eight-column. And then below 480, we
use a four-column grid. This helps us create
consistency in our layouts and consistency in UI patterns. There’s two other things
being pointed by this one here and the two on 1600. So basically at 600,
what we found was it’s quite a small size. So what we try and say there
is that you can sort of have one level of
content hierarchy on the screen at a time. So you have a list or
a detail, and those need to be sort of layered
at that screen size. So once you go above
that screen size, those can share the
same screen space. So you have your list,
which might be emails, and your detail, which might
be looking at one email. And above 600, those can
share the screen space, because we have enough space
for things like typography line length. So that’s just
some of the things that this is helping us define. Also noted, at 1600, the grid
can sort of hit a max width. And it can either
become centered, or it can stay
left-aligned, or it can continue to grow as
the screen space grows. ADDY OSMANI: So, I know
what you’re thinking. You’re thinking, wow, that is
the most beautiful illustration of breakpoints I’ve ever seen. I want to buy this
man many stroopwafels. But please, dear God,
show me the code. So implementing
breakpoints with Polymer is actually pretty
straightforward. And there are two core
concepts behind this. One that you’re probably
already familiar with, and one that you might
have played with before. The first is CSS media queries. How many people here have
used CSS media queries before? Basically everyone. Even Zach’s used
CSS media queries. God! [LAUGHTER] So, media queries. Really powerful. Now, all of the break
points Zach was walking you through in his beautiful
illustration are currently available in
Polymer Starter Kit. So you don’t have
to go, you know, wondering, OK, what
number is that? How do I fit this in? It’s already available. And the other
primitive that we think you’ll find useful for
building adaptive UI is iron-media-query. And we’ve had this
around for a while, but iron-media-query basically
gives you data binding on top of CSS media queries. It’s an element that’s built
on top of the HTML match media API, which lets us
parse out media queries and do intelligent
things with them. Did I pronounce that, correct? HTML? ZACHARY GIBSON:
You’re in charge. ADDY OSMANI: HTML. ZACHARY GIBSON: Yeah. You’re in charge. ADDY OSMANI: You guys say HTML? Or HTML? I’m just going to
assume I’m right. OK, right. So you can see the API here. We’ve got a few tributes. So we’ve got query, which
is a bare CSS media query. We’ve got query-matches, which
is a Boolean for just letting you know whether or not
on a particular media queries has been matched. And then we have an event that
lets you hook into whether that media query’s been
reached called on-query-matches-changed. Now together with
these two primitives, we can actually build
pretty powerful things. This is a new
template that we’ve been working on for blogs. And we call it Zuperkulblog. Which is, that’s the
right way to pronounce it? ZACHARY GIBSON:
That’s the right way. ADDY OSMANI: That’s
the right way. Great. I get my paycheck this month. Fantastic! So here we’ve got Zuperkulblog. And basically what we
just saw was a grid of lots of different types
of content adapting to fit the context that it’s now in. So we’ve adapted from a desktop
view over to a mobile view, and we’re now just, like,
stacking these cards on top of each other. Because we’re using
our media query, we’re also able to achieve
more complex effects like this kind of fancy header
that you see at the very top. Another thing that I’ve
been working on lately is a material music
prototype that looks a little bit like this. It’s basically built
using Neon Animated pages, so you get these, you know,
these nice little transitions every single time you
select a different album. But the idea is that you have
a slightly more complex looking grid on desktop. We have a lot more
screen real estate here. Any time you select an
album, we show you this view. But let’s say that you switch
context and you moved over to, you know, a mobile
device, perhaps. Here we’ve adapted this grid to
make better use of the space. It’s a slightly
different type of grid. Slightly simpler. Makes more sense for your thumb
stable to touch these items. And when you select an item,
we just show and hide UI to make best use of that
screen real estate we’ve got available. ZACHARY GIBSON:
So as we mentioned when defining
adaptive UI, you know, sometimes the best
user experiences take more than just
reshuffling blocks on a page. And so what we’re currently
in the process of doing on the Material Design team
the past couple months, the next couple months– we
are in the process of doing this stuff right now–
is defining UI patterns and working with Polymer to help
us build some of these patterns into components. So I’m going to walk you
through some of those, and Addy and I are
going to try to trade the clicker without fumbling it,
which we’ve done good so far. But we’ve been pretty hard at
work on the Material Design team reviewing hundreds of
apps before they’ve launched their material reviews. And what we found is that apps
share common architecture. A lot of apps are lists and just
different variations of lists. So what we’re trying to do is
to define this as a pattern and be able to
provide those things baked in with our guidance so
you can use it a lot easier. So there’s just a lot of themes
that we found that reoccur in the review. So the first theme is
basically position. The position of elements can
be core to the discoverability and the usability of an app. When screen sizes
change or we change from using a big clunky
finger to a mouse, our expectations change
with where we expect to find certain UI elements. So here’s a good
example of that. In Material Design we
have this big pink button. Sometimes it’s not pink. But we call it the
Floating Action Button. And sometimes it’s the most
hierarchically important button on a screen. It’s also called the FAB, so
you might hear me say that. On mobile, this is
pretty discoverable because you’re not that
far away from it, right? But when we move up
to a larger screen, sometimes that thing, if it
stays in the bottom right corner, is a million pixels
away from everything else on the screen. So what we’re saying is,
you can move that thing. It doesn’t need to stay in
the bottom right corner. And I’m not trying to say
here that, like, here’s the new location of it. But it could be
relative to UI that is appropriate to the context
of the app that you’re showing. So things can reposition. There’s other things
that reposition. So basically we take
that theme and we’re looking through all of the
various components and specs and saying, what else moves? So there’s things like
snack bars and menus and a lot of other components. So let’s take a look at
how this was possible. ADDY OSMANI: Cool. So if you’ve ever
worked with a designer, you’re probably
used to them coming to you with some mocks or
some motion design videos and saying, is this is going to
look as good when you code it up? And when someone does that
to me I usually say, Yeah. Yeah, sure. If by “as good as”
you mean not at all. [LAUGHTER] Thankfully, when you’re building
adaptive apps with Polymer, it’s not really
like that at all. Here we’ve got desktop view,
where we’re positioning our FAB in the very top-hand corner. And we’re achieving this
just using CSS, just using some position absolute. When we change our context
and we switch over to mobile, we can actually display
this closer to your thumb, again, just using a very
simple CSS media query. I’m using one of the break
points from the material spec and I’m just
positioning it closer to the bottom
corner of the screen so that it’s actually closer to
somewhere that you can reach. Let’s take a look
at another example. So here we have a menu. We’ve got a paper
menu that you can go and you can select
to have it expand. Now, this type of UI probably
makes sense on desktop, because you’ve got a lot
available screen real estate. But if you switch contexts,
once again, to a mobile device, maybe you want to make sure
that that’s a little bit closer to your user’s fingertips. And to do that we can use a
media query that will just stretch that menu, will
change its position from the top part of the
screen to the very bottom. It’ll stretch its real
estate so it’s taking up all the available space. And this is an
example of us reusing the same content in a component,
but just changing its container around a little bit. Just making sure that
it’s in the right position for your users. ZACHARY GIBSON: So that’s a
good transition here, right? When we change containers,
we find this happening a lot in Material Design apps. Especially when things just
change drastic form factors, right? So transformation patterns
can also be technically the most complex
adaptations of UI, and also from a UX
perspective, it’s sometimes difficult
to understand when to do certain things. But we believe that
components sometimes need to transform from one
form factor to another. So here’s an example of that. We have a left nav on mobile. Because of Android,
our users are familiar with this
pattern of navigation coming from the left on mobile. It’s been built
into a lot of apps. But we need that same
navigation as a responsive web apps that scales up to desktop. We can transform what
was in that left nav into something like tabs. Because it’s more discoverable. It’s not a hidden menu
when it doesn’t actually need to be hidden. So there’s a lot of
things like this, of components transforming,
that we’re looking at. We have things called bottom
sheets in Material Design. And it’s basically
like a menu that comes from the bottom
of the screen on mobile. And when you touch
something here and something moves up
a very small amount, that’s not that far. But when you’re on
a big desktop screen and you touch
something way up here and a small bottom sheet
comes from the bottom, it doesn’t work. So that needs to transform
into something else that’s relative to the
context of an app. And there’s a lot
of other stuff. ADDY OSMANI: So here we have
an example of this pattern implemented using Polymer. On desktop, we’ve got
some horizontal navigation that are using tabs and
have that sweet in effect. And if we switch
contexts over to mobile, you’ll see that we now moved all
the navigation into the drawer rather than repeating our
different forms of nav. Now, this makes sense because
of the context that we’re using. We accomplished this
using iron-media-query. It’s really, really powerful. So here we can use the
on-query-matches change event to hide the drawer if the user
is a developer, basically, and they’re resizing the screen. But we can also make sure that
we’re using computed properties in this case. Computed properties
look a little bit like this, which basically allow
us to trigger tabs to be hidden if we’re on a smaller screen. So here we’re just doing a
little bit of class switching. ZACHARY GIBSON: So
reflowing is commonly what we think of when we
think of responsive design. Things move as our
screen size moves. If you’ve ever
resized a window, you know what UI looks
like when it reflows. But we’re just trying to bake
this theme into the system. So for example, we have this
little Polymer clock widget. And on the top is
this digital header, and on the bottom
is an analog clock. And it’s a small
vertical screen, but when we go to a larger,
more horizontal screen, the architecture changes. And we have the
clock on the left and the analog
part on the right. So lots of reflowing will
just naturally happen. Another common
occurrence of this that Addy’s going to walk
through is grid lists. Grid lists are– well, I’ll
let Addy walk through it. But first let’s look
at this clock here. ADDY OSMANI: OK,
so Zach was just talking about a clock example. It adapts from being
horizontal to vertical depending on your context. Now, the good news is
that the adaptive UI portion of that example
is pretty trivial to implement using Polymer. The clock itself took me
many, many hours to do, and we’re no longer
on speaking terms. But in Polymer, we can
achieve this effect once again using iron-media-query. And we’re using it
to sort of trigger a change in layout once again
using Polymer’s layout classes or layout attributes, so that
we can switch from horizontal to vertical, depending
on whether you’re on a small screen, like
a phone or a tablet, or you’re on desktop. Let’s take a look
at another example. So most of you have probably
visited the Polymer Summit site and you’ve taken a
look at the schedule. If all of this is
completely foreign to you and you’re wondering what
you’re seeing on screen, you are probably at
the wrong conference. But stay around,
and maybe you’ll learn something about Polymer. Let’s focus in on this
grid for a moment. So we’ve got a grid here,
implemented using Polymer. And this actually reflows. So on desktop, we have
these really thick cards that have a lot of
information, lots of interesting stuff going on. But as soon as we switch to a
device with smaller screen real estate, we actually reflow
this so that we’re now displaying all these
cards not just vertically, but we’ve also sort
of collapsed them. So if you’re scrolling
on your device, rather than having to scroll
through the full length card for every single
session, the users can control deciding
whether or not that expands. So we have three
elements that power this. We have our
iron-media-query, of course. We have our schedule-grid. And we’re using iron-ajax to
power the data behind this. So let’s focus in on just
the grid part of this. So we’ve got a
schedule grid here, and it’s got media
query definitions for all of the break points
that we’re trying to target. And it basically will
change the maximum width of each of the cards
as we decide to switch between viewport sizes. Also defines defaults
for margin and padding, because those things
might also change depending on the type of
context that you’re in. Now we’re taking
advantage of narrow layout over here, which
basically allows us to use a useful pattern. So rather than having an
iron-media-query definition inside of every one of our
elements, we’re just using one. And we’re passing its
state down the whole way through our data binding system. It’s kind of neat. And that just lets us
decide whether or not going to collapse this
card or keep it expanded. ZACHARY GIBSON: So a
couple more patterns that I’ll get through
a little quicker here. We’re familiar with this
pattern of revealing UI as screen spaces grow, but
here’s a small example. Let’s say I have this sort of
CMS or text editor on mobile, and as screen space grows,
we reveal more powerful UI. Maybe because we went
from a finger to a mouse, or just because we have
the additional screen space to reveal more UI. So here you can see we
added the font editing and a few parameters
for justifying text. Revealing can also apply
to a lot of things. Like, imagine you have a
small card that there’s a lot of content behind a click
or behind a touch on mobile, but on desktop, we
revealed more information in that same card container. Looking at divide,
which is another theme, this starts to get to the
structure of our applications. So here’s a good
example of the divide, where you have this thing on
the left here is basically three layers to an app. You have a left
nav that’s hidden, you have a list, and a detail. Imagine this as Gmail. But when this grows,
you might have something that’s like
a left nav, and a list, and a detail just
dividing into the space. And these kinds
of things that we know how these
patterns work, we’re trying to wrap
these as components. And a lot of the stuff
that Yuin showed earlier, those were a lot of sort
of component mash-ups that we’re trying to provide as
responsive, adaptive elements to all of you. Because, as we heard
earlier from Rob, I heard that you’re
a little lazy. So we’re trying to give
you that stuff for free. [CLAPPING] Yeah. The other thing that
we’re looking at is just respecting natural
scrolling directions. So, you know, on mobile
we scroll vertically and we scroll horizontally. And on tablets, especially,
I scroll like this. But when you go to
a larger desktop and you’re using a scroll
wheel, that doesn’t feel right. So we’re just in the process
of asking the question, like, can we make an
adaptive component that changes scrolling direction
based on a break point? And then just very simply,
and lastly, surfaces expand. So you have a card on
mobile, and that card might expand to
either a column width or it might expand to
an incremental width. So, yeah. ADDY OSMANI: Cool. So we’ve been working
on another example of adaptive UI in Polymer. This is the greenest
application in history, but basically the idea is
that we’re demonstrating a few different patterns here. We’re demonstrating
transformation, reflow, and position. So if I switch up and
say that I’m on a tablet, like a Nexus 7, you’ll
see that we started off with a slightly thicker
header bar at the very top. But we still kept that
same effect on scroll. When we switch up
to a Nexus 6, you’ll see that we’ve changed
the position of that FAB so it’s in the very bottom. The user can easily access it. And we’ve also got a slightly
different paper-drawer-panel in place as well. Both of these
things are possible thanks to CSS media queries
and iron-media-query. YUIN CHIEN: Every time you
guys talk about UI patterns I wanted to pee. [LAUGHS] ZACHARY GIBSON: We
took all of your time. YUIN CHIEN: So were we? It is our goal to make making
Material Design apps easy. Let me introduce some of
the tools and resources that you might find useful
in building your apps. The app layout collection
created by the Polymer team is available on
GitHub for people to explore and build
their own templates. And if you haven’t checked
out the Paper Elements in the Polymer catalog,
you really should. We also created a
device matrix reference. Using this reference,
designers can quickly get key dimensions,
like densities and other matrix they need. The latest tool in the
works is the resizer. By previewing web
app in family shot, you can examine and compare
if any UI elements adapt appropriately across devices. You can input any URL or choose
some of the pre-selected sites in the [? site ?] drawer. If you wanted to
preview per device, you can navigate through
the key breakpoints I will introduce today for
desktop, mobile, and tablet. Should I go back? Or– ZACHARY GIBSON: Yeah, we also
have the Material Design spec. You can feel free to
check that out too. We’re constantly
updating and refining the Material Design spec. So what’s next? The future of web apps
looks really amazing. And we’re looking forward
to all of the stuff that you guys are going to make,
and the Material Design team and Polymer are just
trying to make it easier for you to build things
that we already know about, and we already feel like we
have a good system for defining. So with Polymer, we’re
creating lots of demos, like Addy was showing. We’re creating more
templates so that you can inspect these things and
pick them apart and understand why we’re doing
certain things that we consider to be best practices. You can also follow the Material
Design team and just all things design happening at Google. Talk about design at a
developers conference, but we’re doing a
lot of stuff here. And we have events coming up. There’s one coming up in London
and one coming up in New York. There’s a lot of new articles. There’s one that’s a great
read about the new Google logo that we just launched,
and some new resources like the one that Yuin
was just showing there. And these tools and
all this reference and guidance and
stuff, we’re trying to make it easier for designers
and engineers working together to build really awesome
things with Materials Design. So with that, thank
you all for coming out.

11 thoughts on “Adaptive UI with Material Design and Paper Elements (The Polymer Summit 2015)

  1. Great talk, even better on the second watch.

    Does anyone have a link to the repository for the demo app? I'd love to pick the code apart.

  2. Can you put resources in description? where do i find this resizer

  3. I really like Material design! Very innovative!
    Just a possible improvement regarding a flaw in having the Paper-drawer-panel in the top left is that it creates obstruction for right-handed user reaching to the top left with their hand.

  4. I don't see any on-quey-matches-changed in the doc's.
    Is this still working as it is writing on the video?
    By the way, long life Polymer !!!!

Leave a Reply

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