A common issue for any front-end developer is layout and spacing. How dense should your user interface be? Can a design system really account for all the different layouts in a product? Material is here to help.

The latest update to our density guidelines includes a new systematic approach to applying density and spacing in digital products. Now, you can change the spacing of your product to suit layouts for different use cases, such as data-heavy layouts vs. a layout with a single call-to-action.

Just as you use Material Theming to systematically apply color, typography, and shape to your UI, now you can systematically apply density.

Global density changes affect the spacing between all elements at a macro level. However, you can also apply bespoke density values to any individual component.

Material Design’s density scale includes three levels of density: default, comfortable, and compact.

The Rules of Applying Density

Compact density can be great in data-rich applications that need to display a lot of information in a small amount of space. For example, data tables or long forms may benefit from an increase in density. This would allow more information to be seen on the page, giving the user important relational context at any given time.

However, an increased density display may be less useful in layouts that involve focused tasks or small user inputs. For example, date pickers need ample space for the user to be able to accurately make a selection. High density spacing can also make alerts and messages difficult to notice and read.

An increase in density can also decrease the accessibility of your UI in some cases, so make sure you’re applying density in places where user feedback is not affected. This dense calendar UI is an example of how increasing density could make it harder to use an application.

It’s important to keep accessibility in mind when you’re applying density to your UI. No matter the density, all touch targets should be at least `48px` in size.

For the buttons in dense layouts, we’ve applied external padding so that even when they appear smaller and condensed, they still have an accessible touch target size.

It’s important to maintain a good design equilibrium in dense layouts, so when increasing component density you should also decrease your layout or grid density. This means that the more dense your components become, the larger your margins and gutter widths should be. This helps keep your UI legible.

Using Density on the Web

The Density Scale

Density is defined by a scale starting at 0 for default density. The scale moves to negative numbers (-1, -2, -3) as the space between components decreases, resulting in a higher density layout. Each increment also decreases the height of a component by 4px. But it does not affect the horizontal spacing within the component. For example, in an icon button, increasing the density will not make the icon appear closer to the text.

The height or size of a component is calculated with the following formula:

$height: $mdc-button-height + $mdc-density-interval * $density-scale
/// @example 36px + 4px * (-3) => 24px

Let’s See Some Code

When you update to the latest version of MDC (4.0.0 or greater), density is included as mixins within the components. You can apply a density of `-3` (the most dense option) to a button by applying the following code:

In your terminal, install an MDC button via :

npm install @material/button

In your HTML, Add the following button markup:

<button class=”mdc-button”>
  <div class=”mdc-button__ripple”></div>
  <span class=”mdc-button__label”>Button</span>
</button>

Note: this markup is different than the previous version of MDC (3.0.0)

In your Sass file, Import the button mixins and apply the density as a mixin to your custom button:

@import “@material/button/mdc-button”;
@import “@material/button/mixins”;

.my-button {
  // This is where you set your density value
  @include mdc-button-density(-3);
}

The following components currently provide density Sass mixins:

• Button
• Checkbox
• Chip
• Data Table
• Icon Button
• List
• Radio
• Switch
• Tab Bar
• Text Field

We recommend customizing density using the provided density mixins rather than arbitrarily applying component height.

That’s pretty much it! You can check out the updated design guidance for more details, but applying the density scale is a breeze with the new MDC 4.0. If you added density to your application, leave a comment below. We’d love to see it.

Using Material Density on the Web was originally published in Google Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

You probably already know Material Design — Google’s open-source design system for quickly building beautiful interfaces. But you might not know that one of Material’s most popular use cases on the web is being the “front-end of the back-end.” Oodles of Material web apps are essentially admin panels, data displays, and tools for content manipulation. In fact, this use case is so prevalent that, according to a survey by Material-UI (a 3rd party open-source React implementation of Material Design) 70% of respondents said they used that product to build admin panels and dashboards.

We recently revamped Material’s data table component (read about the updates from designer Karen Ng) and released the web code and documentation for quickly integrating this component into your own web product. Now, you can easily and instantly (after installing the component) leverage and theme data tables with some default behaviors, such as row selection, utilizing Material’s animation and design system. Here’s how:

To get yourself a data table, you only need the following three steps:

1. In a terminal:

// Install checkbox styles for the row selection variant
npm install @material/checkbox

// Install data table styles
npm install @material/data-table

2. In your Sass file:

// Import checkbox styles for the row selection variant
@import "@material/checkbox/mdc-checkbox";

// Import data table styles
@import "@material/data-table/mdc-data-table";

3. In your HTML, include the correct classes in the following structure:

<div class="mdc-data-table">
  <table class="mdc-data-table__table" aria-label="Dessert calories">
    <thead>
      <tr class="mdc-data-table__header-row">
        <th class="mdc-data-table__header-cell" role="columnheader" scope="col">Dessert</th>
        <th class="mdc-data-table__header-cell" role="columnheader" scope="col">Carbs (g)</th>
        <th class="mdc-data-table__header-cell" role="columnheader" scope="col">Protein (g)</th>
        <th class="mdc-data-table__header-cell" role="columnheader" scope="col">Comments</th>
      </tr>
    </thead>
    <tbody class="mdc-data-table__content">
      <tr class="mdc-data-table__row">
        <td class="mdc-data-table__cell">Frozen yogurt</td>
        <td class="mdc-data-table__cell mdc-data-table__cell--numeric">24</td>
        <td class="mdc-data-table__cell mdc-data-table__cell--numeric">4.0</td>
        <td class="mdc-data-table__cell">Super tasty</td>
      </tr>
      <tr class="mdc-data-table__row">
        <td class="mdc-data-table__cell">Ice cream sandwich</td>
        <td class="mdc-data-table__cell mdc-data-table__cell--numeric">37</td>
        <td class="mdc-data-table__cell mdc-data-table__cell--numeric">4.3</td>
        <td class="mdc-data-table__cell">I like ice cream more</td>
      </tr>
    </tbody>
  </table>
</div>

If you want to include the default interaction demonstrated in this blog post, you will need to instantiate the data table in your JavaScript file. This can be built upon with your own system, and MDC-Web provides a base as a jumping-off point:

// Import the component
import {MDCDataTable} from '@material/data-table';

// Instantiate the data table based on the `.mdc-data-table` class
const dataTable = new MDCDataTable(document.querySelector('.mdc-data-table'));

Material Data Tables provides basic interactions including selecting of table rows and returning an array of selected row items. The baseline functionality builds in accessibility, but if you are extending the table, please refer WAI-ARIA Authoring Practices for table for ARIA recommended role, states & properties required for table element.

In the example below, you can find the data table interface being used to calculate the total calories. The table is built via a web component template using JSON-based data.

let totalCal = 0;

// Add "row selection changed" event on the data table

dataTableEl.addEventListener('MDCDataTable:rowSelectionChanged', (event) => {
  const {rowIndex, selected} = event.detail;
  
  const calories = sampleData.rows[rowIndex][CALORIES_COLUMN_INDEX];
  if (selected) {
    totalCal += calories;
  } else {
    totalCal -= calories;
  }
  
  ...
});

You can also combine components within a table. In this example, we’re using Material chips as quick-selection shortcuts for selecting items in the table. We can combine interfaces like so, to make this possible:

// Add "chip selection" event on the data table

dataTableEl.addEventListener('MDCChip:selection', (event) => { 
  ...
}

You can use the Sass mixins as a styling API, or use custom properties to apply theming with MDC-Web, and serve that theme change by using the prefers-color-scheme media query, or provide users with their own option using the Material switch component, for example.

We also added the data table to the Material Theme Builder, so you can see how your global theming styles will affect this component along with the others, and how all of those styles interact.

Now that you know how to use, extend, style, and explore Material data tables on the web, go forth and experiment! Don’t forget to share your data tables down in the comments section below 👇

How to Use Material Data Tables on the Web was originally published in Google Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

Design systems are so hot right now — and for good reason. They promote a modular approach to building a product and ensure organizational unity and stability via reusable code snippets, UI components, and utility styles. They make prototyping a breeze and provide a common language for both designers and developers.

A design system is a culmination of several individual components, which can include any or all of the following:

• Style guide or visual pattern library
• Design tooling (Sketch library, for example)
• Component library (where the components live in code)
• Code usage guidelines and documentation
• Design usage documentation
• Voice and tone guidelines
• Animation language guidelines

Design systems are stand-alone (internal or external) products and have proven to be a very effective means of design-driven development. However, in order for a design system to succeed, everyone needs to get on board.

I’d like to go over a few factors that can help ensure — or hinder — the success of your design system. Some of these concepts will be more developer-focused, but most are adaptable across disciplines.

Organizational support

Put simply, any product, including internal products, needs support. Something as cross-functional as a design system, which is used by every vertical project team, needs support from the top and bottom levels of your organization.

Top-level support means everyone from project managers up through VPs understands the value of a design system, provides resources for its implementation, and advocates for its use company-wide. This is especially important in companies where such systems are being put in place on top of existing, crufty codebases, because it may mean some effort needs to be scheduled for refactoring work.

With design systems, small incremental investments over time lead to big gains overall.

Support from the bottom up means that designers and engineers of all levels support this system and feel responsibility for it. A design system is an organization’s product, and everyone should feel confident contributing to it. If your design system supports external clients as well (such as contractors), they too can become valuable teammates.

Investment

A design system needs support and love to grow. It also needs continuous investment of effort and resources. I like to compare this to working out.

You can work out intensely for three months and see some gains, but once you stop working out, those effects will slowly fade away. If you continue to work out, though, even if it’s less often than the initial effort, you’ll see yourself maintaining your fitness.

Similarly, if you spend three months overhauling your design system but neglect to keep it up, you’ll face the same situation. The impact will fade as the system gets out of sync with new designs and you’ll end up with disconnected bits of code and design elements that nobody is using. Your engineers and designers will stop using it as the patterns become outdated, and then you’ll find yourself dreading another round of substantial investment.

With design systems, small, incremental investments over time lead to big gains overall.

With this point, I also want to note that because of how they scale, design systems can make a considerable impact across the platform, making it extremely important to invest in things like accessibility and solid architecture from the start. You don’t want to scale a brittle system that’s not easy to use.

Take care of your design system, and keep working on it to ensure its effectiveness.

Responsibility

One way to do this is to have a dedicated team working on the design system, managing tickets and styling updates that trickle out to the rest of your company. With a specific team to act as owner of the design system, whether it be the design team, engineering team, or a new team made up of both designers and engineers (the best option), your company is more likely to maintain a relevant, up-to-date system that doesn’t break.

This team is responsible for a few things:

• Helping others get set up on the system (support)
• Designing and building components (development)
• Advocating for overall UI consistency and adherence (evangelism)
• Creating a rollout plan and update system (product management)

That’s a lot of roles, so it helps to have multiple people on this team, at least part time. One thing I’ve found to be effective is to hold office hours to help everyone get set up and to answer any questions about using the system. Having an open Slack channel also helps with this, as well as with bringing up bugs/issues/ideas and making announcements like new releases.

Communication

Once you have resources and a plan to invest in a design system, it’s really important that the person or team responsible acts as a bridge between design and engineering. Continuous communication is crucial here, and the way you communicate is even more important.

Remember that nobody wants to be told what to do, especially designers and developers, who are often used to a lot of autonomy. Despite how much or how little control the other stakeholders have over the process, they need to feel like they have input and feel heard.

Building and maintaining a design system is surprisingly a lot of people-ops work. To get buy-in, you need to make people want to use your design system.

This can be challenging, especially since ultimately, some party needs to be making a final decision on direction and execution. Because it’s a hard balance to strike, having open communication channels and being as transparent as possible as early as possible is a good start.

Buy-in

Good communication is also important for getting buy-in from your users (the engineers and designers), as well as from product management.

Building and maintaining a design system is surprisingly a lot of people-ops work.

To get buy-in, you need to make people want to use your design system.

Gather examples and usage wins, because showing is much more powerful than telling.

If you can, have developers use your product in a low-stakes situation where it provides clear benefits. “Hackathons” are a great place to debut your design system. Our internal hackathon at DigitalOcean was a perfect opportunity to:

• Evangelize for the design system
• See what people were using the component library for and what they were struggling with (excellent user testing there)
• Get user feedback afterward on how to improve it in future iterations
• Let people experience the benefits of using it themselves

These kinds of moments, where people explore on their own, are where you can really get people on your side and wanting to use the design system, because they can get their hands on it and draw their own conclusions (and if they don’t love it, listen to them and improve it so that they do). We don’t always get so lucky as to have this sort of instantaneous feedback from our direct users.

Architecture

To make sure your design system is scalable, it’s important to develop a solid architecture early on in the process. Build your design system with growth in mind. What happens if your company acquires a new product? What happens when it develops a new market segment? How can you make sure there’s room for customization and growth?

A few things we’ve found helpful, from a development standpoint, include:

Namespacing

Use namespacing to ensure that the system doesn’t collide with existing styles if applied to an existing codebase. This means prefixing every element in the system to indicate that it’s a part of the design system. To make sure that you don’t break parts of the existing build (which may have styled base elements), you can namespace the entire system inside of a parent class. Sass’s nested structure makes this easy.

This kind of namespacing wouldn’t be necessary per se on new projects, but it is definitely useful when integrating new and old styles.

Semantic versioning

I’ve used semantic versioning on all of the design systems I’ve ever worked on. Semantic versioning uses a system of Major.Minor.Patch for any updates. You can then tag releases on GitHub with versioned updates and guard against someone’s app breaking unintentionally when there is an update, if they are anchored to a specific version (which they should be).

We also use this semantic versioning as a link with our design system assets (our Sketch library) to keep them in sync, with the same version number corresponding to both Sketch and code.

You have to make your design system the path of least resistance, lowering the cognitive overhead of development and design, not adding to it.

Our design system is served as a Node module, but it’s accessible via our CDN as a series of built assets for quick prototyping and one-off projects. For these built assets, we run a deploy script that automatically creates folders for each release, as well as a “latest” folder if someone wants the always-up-to-date version of the design system.

So, semantic versioning is what links our design system Node module assets, Sketch library assets, and statically built file assets. Providing multiple ways of consuming our design system makes adoption easier and reduces friction.

Friction

A while ago, I posed the question of why design systems become outdated and unused, and a major conclusion I drew from the conversation was: If it’s harder for people to use than their current system, people just won’t use it.

You have to make your design system the path of least resistance, lowering the cognitive overhead of development and design, not adding to it. This is vital. A design system is intended to make development and design much more efficient, enforce a consistent style across sites, and allow everyone to worry less about small decisions like font sizes and HTML semantics. These are already sorted out for them, meaning they can focus on building the product.

But if your design system is complicated and over-engineered, they may find it frustrating to use and go back to what they know, even if it’s not the best solution. For instance, if you’re a Sass expert and you base your system on complex mixins and functions, you better hope your developers are also Sass experts, or want to be. This is often not the case, however. You need to talk to your audience and learn about how they work and how they’ll want to use your system.

Reducing friction for adoption should be a major goal of your design system rollout.

Conclusion

Having a design system is enormously beneficial to any product, especially as it grows. In order to have an effective system, it’s important to always keep your user in mind and garner support from your entire company. Once you have support and acceptance, this system will flourish and grow. Make sure someone is responsible for it, and make sure it’s built with a solid foundation with a plan for careful maintenance. Good luck!

Originally published on the 24Ways blog, modified slightly for a Modus audience.

Set Your Design System Up for Success was originally published in Modus on Medium, where people are continuing the conversation by highlighting and responding to this story.

Communication is essential to human survival. It’s what allowed us to work together, build tribes, and survive the elements to pass on the genetic code. And now, with the growth of the web — the most accessible, widespread, and powerful communication tool we have today — our tribe has become global. Our ideas have merged, and the web has allowed for some incredible collaborations across borders that have continued to move us all forward.

The emergence of this communication network brought with it the emergence of the world of big data, multi-player online games, and personal blogging. You can pretty much learn anything or get anything you can imagine online today (for better or for worse). Politics aside, the technologies with which we can access the web are evolving.

From Google’s physical web project to the (very) beginnings of more affordable virtual reality and augmented reality systems, it’s time to take a serious look at how the web is changing, and the exciting possibilities for it in various mediums. This means really rethinking responsive design because the future of the web exists beyond screens.

Web VR

This an exciting time to work on the web because the platforms on which we can communicate are growing quickly. VR (virtual reality) has a really exciting future. It can change how we receive information and communicate with people around the world, making distance feel like less of an obstacle. Recently, Mark Zuckerberg showed a demo at Oculus Connect of what they’ve been working on lately in terms of VR chat. It’s an incredible tool for communication and story-telling, especially when applied to journalism, as it really immerses the viewer an environment to help them to absorb a story.

WebVR can create immersive experiences too, and maybe one day, bring the ease of communication that a website provides into a 3D context. This can be great for understanding ambiance of a restaurant, or hotel, or even a design agency’s aesthetic. WebVR opens a world of possibilities in an entirely new medium in which to present information.

This is all very groundbreaking; however, what’s even more game-changing to me will occur when we finally have affordable AR (augmented reality) and can simultaneously interact with the web and the world around us. This means we can look up information while continuing to go about our day, having a seamless experience, and true ease of communication / knowledge sharing.

While there’s nothing that allows us to experiment with AR on the web just yet, experimenting with WebVR is an exciting precursor. A-Frame by Mozilla is a web framework that acts as a great kickoff to experimenting with integrating the web in a 3D context.

The more I think about virtual and augmented web, the more excited I get about the possibilities.

The Physical Web

Another thing I’m really excited about is the core idea behind Google’s physical web project.

The premise of the project, led by Scott Jenson, is simple: using a URL bar as the only means of communication with the vast resources of the web is outdated. It brings the web to the physical world via beacons — these are, in their current state, little devices that can be attached to anything: movie posters, restaurants, entrances to theme parks, which send out signals inviting you to the web.

Instead of the URL bar as the initiator of an online experience, you have a physical object initiating the exchange in the real world. Getting a ping to open a URL feels much more natural than the added step of opening a browser and typing one in to reach the same outcome.

Rethinking Responsive

What does this all mean for responsive design? It means that we need to consider the user’s experience in terms of their surroundings. How can we use new browser technology to leverage that? We now have a plethora of options. Just to name 3:

• Geolocation (which opens up so many possibilities alone, like getting information on weather, news, events, etc.)
• Battery-Level Detection (meaning the developer can determine when to send decorative content like animations based on system resources)
• Ambient Light Queries (allow the browser to detect how dark or light the surroundings of the user are, enabling style adjustment accordingly)

All of these Web APIs and future specs can be combined to give the user a truly responsive experience. Something that isn’t just responsive to the screen size of the device being used, but is responsive to the user in their current context.

A user’s context, not their device, is the future of responsive design

I first started thinking of responsive in this way while working at a startup called nvite. The idea was to build a product responsive to an event in terms of both physical location to and time until the event. That was nvite’s definition of a responsive experience. And it really has stuck with me because simply put, it’s the future of responsive experiences.

It’s exactly kind of thinking, combined with the emerging opportunities we’re uncovering for the web, that we need to nourish, and to consider when building products. We need to recognize that screens are ephemeral, and that making something responsive will no longer be about screens. It’ll be about experiences.

Okay, Let’s be Real

Things change quickly in this industry. If that’s news to you, then you must have started yesterday. Welcome to the chaos. And yes, you can call the current state of web development a bit chaotic, but that’s because there are more people than ever contributing ideas and sorting through those ideas by implementing them! Imagine that. User testing, prototyping, and iterating.

Obviously a library like React was built for a specific business need, for a huge company. What do you expect? It’s new, it’s experimental, things are going to break. It was written insularly in a company with brilliant engineers that needed to move quickly to stay ahead of their competition. And now that it’s being used by more and more people, clearly there are growing pains.

Open Source Entitlement

One thing that irritates me more than anything is the expectation people have to other people’s time, specifically open source project maintainers. They are not your tech support. They built a product you are using for free. You’re welcome.

Hey, OSS maintainers, you don’t owe anybody anything.

You have a problem? Submit a Pull Request. You don’t know how to fix it? Spend some time in the codebase and learn how — or you can do what Michael Mifsud did and learn a programming language to contribute to an open source project he loved and used. Don’t have time to do that? Cool, they don’t have time for you either.

Sam Saccone on Twitter

write OSS they said. travel the world they said, meet exciting people they said.

Developers are people. I don’t understand why this is so hard to remember. Think about this the next time you email someone on a weekend and get angry at a response that takes a while. Your work time might be their off time (time zones are a thing), they also have things to do.

Etiquette does not end where your keyboard begins.

Criticizing Software is a Good Thing

There is a very important line between criticizing a software and attacking the individuals who built that software. Often, “bad” software comes out of circumstance, and bad managerial decisions, and things that are out a developer’s control. Saying “IE sucks” is very different than saying “The IE team sucks.” You (probably) weren’t there. You don’t know the decision chain and history.

No developer tries to build a bad product on purpose.

Criticism is a good thing. Actionable criticism is even better. But personally attacking each other out of frustration is just sad. The next time you make a comment or write a blog post, ask yourself if it’s actually productive.

The Sad State of Entitled Web Developers was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.