On March 20, 2019 we brought together the Material Design team at Google together with Automattic Design for a “part dieu” of our collaboration to “go deep” into Material. We made a quick little website together to collect the key ideas in the exhibition space. Thanks for visiting! —Rachel and John

John Maeda: So why is typography an important element in Material Design?

Rachel Been: A majority of digital products and websites consist of typography. Type represents a high percentage of everything you see on the Internet. In order to make both the web and digital products more legible and enjoyable, it’s really important to get type right for the entire world.

JM: Which typeface do we have on display here in Saint-Étienne?

RB: We’re looking here at Roboto. Roboto is the system typeface for Android devices, and it’s also one of the most ubiquitous typefaces in use all over the world.

JM: I really love Noto because it covers so many languages, and I was wondering why Roboto doesn’t do the same?

RB: Noto is our answer for internationalization. That’s exactly what we made it for.

JM: Please tell me about typographic scales in Material.

RB: Typescales bring order to the interface, and there is an abundance of choices that you can make concerning different styles of typography. So what Material Design tries to do is create a curated set of typographic styles, and then teach the user how to understand what styles are appropriate for which user’s contexts. And it’s a really lovely thing to see when it gets well-constructed. We want to constrict the user to a smaller, curated set that can be used across a digital product while still having a wide variety of visual diversity available at the same time.

JM: In traditional book design you can use a grid, and the grid can match the typescales. On the Web, it gets a little dicey in how a 2D grid can operate. How do you solve that?

RB: We use a 4 DP scale for that. It’s used for our baseline grid so we can align the type elements vertically. It can be challenging the way that multiple platforms are constructed; it can be difficult across Android, across iOS, and across the Web just trying to maintain the same harmony with varying engineering constraints that differ depending on the platform.

JM: For older folks like me who can’t see as well … when I was younger, I used to set things in five points. I don’t do that anymore, and now I’ll up the accessibility settings for type sizes. But the behavior is often inconsistent across applications.

RB: System-wide accessibility settings allow you to dynamically change the type sizes. That’s why we need typography technology in the future that is really malleable, flexible, and reactive to different sizing needs. We want the operating system to react and changes in an intuitive, intelligent, and legible way. So hopefully in the future, things like variable typefaces will lead to more beautiful augmentation and dynamic sizing.

Kunal Patel: “Elevation” expresses in a two-dimensional interface what we like to think of the interface as existing in three dimensions. The z-space becomes a really good canvas within which to tell what’s important in an application with regards to what can move and what can stay fixed in position.

Operating the table as it first came up the day before the grand opening.

JM: Why “24 DP” and what does “DP” stand for?

KP: DP (pronounced “dip”) stands for Density Independent Pixel unit. Instead of referring to the actual pixel itself, DP is a flexible unit that scales to the resolution of the screen so that your UI stays consistently sized across devices. It’s a way for designers to work without understanding exactly what hardware their application is going to be running on. “24” is the maximum level of elevation in our design system. It is the maximum height that an item can be placed at. A DP of 24 is reserved for the most important elements — like an alert for something that requires the user’s attention before they can proceed with using the rest of the app.

KP: In our elevation system, zero represents the base level of the application. It is your ground floor. It is the background, so most often anything you are adding to your interface is going to exist on top of that background level. Very few things actually exist at DP = 0.

JM: What are examples of things that exist at DP = 0?

KP: Things that can exist at DP = 0 are titles or subheadings that are secondary elements. Sometimes you may want a card to be elevated but where should the title go in that case? Or in a case where you have “no results” for a search result. Or you lose connection. Sometimes it helps to have that content sit on the background directly, so that you are further indicating to the user the difference between the active state of the application and an inactive state.

The table displays the different components sitting at different “DP” levels in real time on the screen.

JM: If that’s the case, then you’re trying to inform the user of something at DP = 0 as meaning not important, but that sounds important. Huh?

KP: Yeah. DP is used to indicate what’s important. But often times when most of your content is at DP = 0, there is not much on the screen like in a no-results case. Or in an onboarding case you may have a large flat illustration, or some other graphic so the UI is not overloaded with elements.

JM: How many elements should be sitting at DP = 24 at any given time?

KP: DP = 24 is really reserved for dialogues — which are a blocking interface component that are used for high priority messages or alerts that a user needs to address before they continue using the application.

The original proposal for the elevation table at the Saint Étienne Design Biennale.

JM: So a FAB isn’t at DP = 24?

KP: No, it is not at DP = 24. And that’s partially an emphasis question and a aesthetic choice as well. You know, part of what our elevation system does is try to rationalize the use of shadows to indicate with precision the level of priority. But you also want all your elements to be working together. So if most of your UI is resting at DP = 4 or DP = 6 or DP = 8, then having a FAB at DP = 24 will throw it out of balance with the rest of the UI aesthetically.

John Maeda: So there’s a lot of life-size things here in this exhibition. How does that feel for you overall as more of a screen-based designer?

Kunal Patel: Scale as a method for creating emphasis. Right? It’s interesting to see what blowing something up to a larger-than-life scale does to make you pay attention to the building blocks of an application that most of the time we don’t think about.

JM: What components are on display here? And why are components important?

KP: The components on display here are some of the most commonly used elements of applications. So things like text fields for input or navigation drawer tabs to help people get around an application. Or lists and cards to display content for all the things you would encounter in most of the applications you use.

As for why components are important, it’s because as the fundamental building blocks of applications, we don’t want to put users in a position where they’re constantly relearning how to use the things they’re going to interact with every day. We want there to be standards for ease-of-use and for consistency across applications. They speed up user understanding and make the unique elements of your app stand out even further

JM: A developer might find a component and realize it doesn’t do everything that they need. So their immediate action will be to make a new one. True or false?

KP: Part of being a developer, I think, is wanting to tinker to be creative. We can easily fall in love with our own solutions in search of other problems. So instead, what we have tried to do with our code is make it open source, so that for the people who want to extend or remix components for their needs, we make that process easier for them. And we try to offer actionable design guidelines when they end up extending a component so they know what kinds of things to avoid.

JM: So it sounds like instead of your looking for the perfect set of components for every possible case, you’re totally open to people taking what you have and changing. That breaks the stereotype of a “control-my-system” approach designer. What’s that about?

KP: I think solving every possible case, even for a single large company, is impossible. It’s a bit Sisyphean to attempt to do that. So what we strive for instead is having a really clear set of guidelines and principles for how we intend components to be used. And we try to set appropriate guardrails for modifications while allowing for customization of visual style or extending the functionality to meet the needs of particular applications.

JM: Sorry to push further on this point, but I imagine that the design of these components has been extremely well thought out and researched and covers maybe 80% of the possible use cases. When people deviate from shopping that could be used, how do you feel?

KP: Personally I am all for deviations to come into existence for the right reasons. For example, if there is a certain type of brand expression that’s not coming across from the baseline component we provide. If a deviation does not interfere with the usability of said component, I am all for the customization. But we don’t want to see just different for different sake in a way that ultimately negatively impacts the user’s experience.

JM: Sometimes I see both designers and developers wanting to do “different for different sake” because that’s a kind of expression of creativity. What’s your recommendation as someone who has probably seen this happen time and time again?

KP: I think what we consistently fail to underestimate when doing “different for different sake” is the cost of then maintaining the difference. We have limited time, you know. Designers, developers, and product teams don’t want to be maintaining a difference in a button or a tab that’s not providing real functional value to a user. It would be much better to maintain that difference for a key custom feature of an application. So to me, that really comes down to a prioritization of your own team’s time and resources. Is it really time well spent rethinking a text field or rethinking a checkbox? Or is it better to spend time rethinking your checkout flow instead?

John Maeda: There so many icon libraries out there either for free or for pay. What makes this icon library different?

Rachel Been: We use a very specific grid to create incredible consistency across thousands of different icons. And one of the most special parts of this icon system is that we had some of the most talented icon designers create that iconography. So the talent combined with consistency and adherence to both detail and a specific grid makes these icons usable across a variety of different use cases.

JM: These icons are for free. Do you really mean free?

RB: Yes, they really are free. I think one of the reasons why Material believes in free resources is to make the entire ecosystem better. We found that in the Android platform by achieving consistency in iconography that people have a lower cognitive load when they’re navigating through applications by seeing the same icons.

JM: Why were these icons chosen?

RB: Laughing. Because they were some of Michelle’s favorites! Michelle is one of our senior visual designers at Material Design. She specializes in typography and layout.

JM: These icons are available in four styles, is that right? In addition to base.

RB: Yes. We introduced four additional styles to the baseline style in 2018 to create more flexibility for brands. So, for example, if a brand identity is more aligned with the outline style, then they have the opportunity to use the iconography in those styles without having to recreate them.

John Maeda: So I know you were excited to embody the idea of the colour scale as stairs. Can you tell me why?

RB: Well we’ve informally referred to some of the colours within the colour palette as “steps” before because our palette consist of tonal gradients that are very interconnected. So this idea of stepping from one colour to another in a really natural progression metaphorically made sense when thinking about the way that we created our colour palettes within Material Design.

The team arrives to inspect the installation just before it goes live to the public. The Color Stairs are visible in the far back corner.

JM: So I noticed that the scale doesn’t go to 1000. Why is that?

RB: We had the 50 to 900 scale and then we had accent pallettes in the original Material Design palette. We created a proprietary naming system that isn’t associated with any existing colour standard. Frankly, we made up the terminology in the names for our system.

Original sketch for the color staircase as exhibited at the Saint Étienne Design Biennale in France.Rachel Been being photographed on the Color Stairs as exhibited at the Saint Étienne Design Biennale in France.

JM: Why does the scale start with 50, and the steps afterwards count in 100s?

RB: I think that any proprietary system doesn’t necessarily always have to have a logic that people would assume to figure out. That’s the beauty of being able to name something proprietary — because you get to choose the rules.

7-minute overview of Material Design.

JM: When people hear the word “proprietary” I’m sure a few of them wonder: “Does Google own all this and I can’t have it?”

RB: No it doesn’t. It’s not about ownership at all. It’s more about creation in the sense that we have created this system that is unique to our own internal system. But it doesn’t mean that we own it. We’re still trying to be transparent and free to everyone.

John Maeda: So I’ve noticed that when people see drop shadows they start to freak out. A lot of folks I know hate drop shadows.

Kunal Patel: I think drop shadows do deserve some hatred from the design community. Laughing. I think one thing that’s really great about our usage of shadows, I believe, is the rationalization we’ve applied to them. Often times when people react negatively to drop shadows, it’s because they are unexpected elements. Or, the emphasis that’s being applied to those elements seems incongruous with what they’re expecting. Shadows for us are really tied to elevation and for emphasis in a UI. So we’re very restrained in our usage of shadows. I think relative to the web industry’s expectation of drop shadows, maybe you know the way they were used 5 or 10 years ago, I believe the model that we have in use for Material is a lot more logical and constrained for how and when shadows should be applied.

JM: So you think we’ll use blinking text because it’s made useful some day? Laughing.

KP: You mean the blink tag? Laughing. Yes. I predict that blinking text will become useful some day.

JM: What do you think is good about how this display expresses shadows. And what is missing?

KP: So the shadow exhibit that we have here is effective at indicating importance. And the effects that adding a lighting source to objects with communicates the basic concept. I think what’s missing is the sort of precision inherent to the shadows of our system. We were designing the shadows for Material Design in full detail and with a complicated, fixed-lighting rig to get the effect that we wanted. That was with two light sources, and a lot more control over the environment. For this exhibition we wanted it to be a little more hands-on for people who can experience moving the light source and seeing what it does to objects and the shadows that they cast. But it’s not true to our system at all and instead makes a good education tool.

JM: In an early sketch of this table there were specific DP values on the various blocks. Why were they removed?

KP: Because this is more of a sculptural representation of the idea versus anything that we could have made to be more accurate and interactive this way. It’s a simple activity available for visitors to easily learn the thinking behind our shadows.