 from the material design team. My name is Zachary Gibson, a senior designer. This is you and Chen, also a designer on the material design team. And Addie from Polymer. We're going to 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. Five times five 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 problem, so 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 of the patterns and all of the stuff that exists that allows us to design for everywhere. So in the next 30 minutes, Ewan and Addie and I are going to show you some of the stuff that were hard at work to define how material design works everywhere. I'll keep going. We have a couple little clicker fumbles here. Go ahead, Ewan. If you're unfamiliar, material design is a visual language created by Google that unifies 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 and volume 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 a 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. 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 element set or the neon animation set. You guys have downloaded the paper element set. You've looked at it over 2 and 1 half 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 across device. You want to be able to build something that looks like a native app on mobile, but when you go to desktop, it adapts and uses the best of your hardware abilities and all of your screen real estate. You also want it to look fantastic on tablet. Now, the Polymer material design teams have been working really closely to try making sure that the paper element set works great across device, and we've got tons of examples and demos that we're going to talk about in just a bit, showing you how you can apply adaptive UI principles to your Polymer apps. 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 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, like varying from fingers to mouses to 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. And 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 UN 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. Paper drawer panel. I think he knew the answer at a time. This is the paper drawer panel. But here's what we did. We described the behavior. We described the structure. It's a panel. And we gave it certain descriptors. 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. It's the paper toolbar. Yeah. So this is like the paper toolbar or what we call the app bar in material design. So we did the same thing. Followed the same pattern. There's structure, behavior, and certain descriptors. We can define pretty complex UI following this pattern. So you have 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. It's in front of, 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 it's 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. So what is a grid? The main purpose of a grid is to set up limitations to layout. But with those limitations comes many great qualities, like style, familial placement of items and content, and a cohesive feeling across product. 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 layout. Here you can see we're combining components like a toolbar, a list, and a card. The list takes out four column of the grid. We have one column of negative space, six column card, and another column of negative space. This next example is very similar, but that we have an extended header and a card that goes over the ad bar. 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 you can see squids the grid to the right. Notice that we still have a six column card. The grid 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. There's an extended ad bar 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 fertility of laying out various material design apps using the same grid system. We've also defined guidance for common margins and gutters. Here you can see we're using age, 16, 24, and 40 dips, margins, and gutters. If you are unfamiliar, a dip is a unit of measurement in which the numbers are dependent 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 type 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 variant of the temporary behavior. Here you can see a left panel can simply overlay content. Successful handoff. So 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. 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 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. They're small, medium, large. Small is like your Android One devices. Medium is like an Nexus 5 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 Ewan was showing with the grid, we've also defined a few key points at which that default grid starts to change based on the screen size. So you can see above 840 here, it's a 12-column grid system always. Sometimes more when it gets bigger above 1,600, but for the most part, 12 columns. And then below that, 840 to basically 480. It's an 8-column grid. And then below 480, we use a 4-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 1,600. 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. And 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. 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 stoop waffles. 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. So this is even Zach's use CSS media queries. God. So media query is really powerful. Now all of the breakpoints that Zach was walking you through in his beautiful illustration are currently available in Polymer Starter Kit. So you don't have to go wondering, okay, what number is that? How do I fit this in? It's all already available. And the other primitive that we think you'll find useful for building adaptive UI is iron media query. Now 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. You're in charge. HTML. Yeah, you're in charge. You guys say HTML or HTMS? I'm just gonna assume I'm right. Okay. 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 a particular media query's been matched. And then we have an event that lets you hook into whether that media query's been reached called on query and 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 super cool blog, which is, that's the right way to pronounce it. That's the right way. That's the right way, great. I get my paycheck this month, fantastic. So here we've got super cool blog 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. 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 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. Anytime you select an album, we show you this view. But let's say that you switched context and you moved over to 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 thumbs to be able to touch these items. And we also, when you select an item, we just show and hide UI to make best use of that screen real estate that we've got available. So, as we mentioned, when defining adaptive UI, 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, like the past couple months, the next couple months, we're 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 gonna walk you through some of those and Addy and I are gonna try to trade the clicker without fumbling it, which we've done 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've 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 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 reviews. 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 like 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 here's the new location of it, but it can 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 in spec 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 here. 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 gonna 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. 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 we've got a lot of available screen real estate. But if you switch context 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, change its position from the top part of the screen to the very bottom. It will 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. 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 when that same navigation is a responsive web app 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 very small amount, like 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, 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. 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 then if we switch context over to mobile, you'll see that we now have 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 changed event to hide the drawer if the user happens to be, 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. Computer 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. 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 gonna walk through is grid lists. Grid lists are, you know, well, I'll let Addy walk through it. But first, let's look at this clock here. Okay, so Zach was just talking about a clock example. We're in 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 you can switch from horizontal to vertical. Depending on whether you know you're on a small screen, like a phone or tablet, or you're on desktop. Let's take a look at another example. So most of you have probably visited the Polymer Summit sites 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 were 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 implanted 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 we're now displaying all of 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 age access to power the data behind this. So let's focus in on just the grid part of this. So we've got our schedule grid here and it's got media query definitions for all of the breakpoints 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 we're going to collapse this card or keep it expanded. So a couple more patterns that I'll get through a little quicker here. There's, you know, we're familiar with this pattern of revealing UI as screenspaces grow, but here's a small example. Let's say I have this sort of CMS or text editor on mobile and as screenspace grows, we reveal more powerful UI, maybe because we went from finger to a mouse or just because we had 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 reveal 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 you and showed earlier, those are a lot of component mashups 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. Yeah. The other thing that we're looking at is just respecting natural scrolling directions. So on mobile, we scroll vertically and we scroll horizontally. And on tablets, especially, I scroll like this. And, 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 breakpoint? 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, I'll just go. Cool. So we've been working on another example of adaptive UI and 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. 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 corner, 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. Every time you guys talk about UI patterns, I want it to pee. We took all of your time. So where 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, the densities and other matrix they need. The latest tool in the works is the recizer. By previewing web app in FamilyShot, you can examine and compare if any UI elements adapt appropriately across devices. You can input any URL or choose some of the preselected size in the side drawer. If you wanted to preview per device, you can navigate through the key breakpoints that we'll introduce today for desktop, mobile and tablet. Should I go back? 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 the web app looks really amazing. And we're looking forward to all of the stuff that you guys are gonna 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 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 design, all things designed to 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 you and 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 material design. So with that, thank you all for coming out. Yeah.