Yarden Eitan, Software Engineer at Google’s Material Design team. He is an iOS engineer. He helps build an maintain Google’s iOS components, also leads the engineering in Material’s share sysem.

(Sourced from – https://developers.googleblog.com/2018/12/building-shape-system-for-material.html)

Image source- Pixabay

Shape: It’s kind of a big deal

You can’t have a UI without shape. Cards, buttons, sheets, text fields—and just about everything else you see on a screen—are often displayed within some kind of “surface” or “container.” For most of computing’s history, that’s meant rectangles. Lots of rectangles.

But the Material team knew there was potential in giving designers and developers the ability to systematically apply unique shapes across all of our Material Design UI components. Rounded corners! Angular cuts! For designers, this means being able to create beautiful interfaces that are even better at directing attention, expressing brand, and supporting interactions. For developers, having consistent shape support across all major platforms means we can easily apply and customize shape across apps.

My role as engineering lead was truly exciting—I got to collaborate with our design leads to scope the project and find the best way to create customize each component individually.

From an engineering perspective, adding shape support held the bulk of the work and complexities, whereas theming had more design-driven challenges. In this post, I’ll mostly focus on the engineering work and how we added shape support to our components.

Here’s a rundown of what I’ll cover here:

• Scoping out the shape support functionality
• Building shape support consistently across platforms is hard
• Implementing shape support on iOS
• Shape core implementation
• Adding shape support for components
• Applying a custom shape on your component
• Final words

Scoping out the shape support functionality

Our first task was to scope out two questions: 1) What is shape support? and 2) What functionality should it provide? Initially our goals were somewhat ambitious. The original proposal suggested an API to customize components by edges and corners, with full flexibility on how these edges and corners look. We even thought about receiving a custom .png file with a path and converting it to a this complex new system. Compared to systems for typography and color (which have clear structures and precedents like the web’s H1-H6 type hierarchy, or the idea of primary/secondary colors) shape is the Wild West. It’s a relatively unexplored terrain with rules and best practices still waiting to be defined. To meet this challenge, I got to work with all the different Material Design engineering platforms to identify possible blockers, scope the effort, and build it!

When building out the system, we had two high level goals:

Adding shape support for our components—giving developers the ability to customize the shape of buttons, cards, chips, sheets, etc.

Defining and developing a good way to theme our components using shape—so developers could set their product’s shape story once and have it cascade through their app, instead of needing to

shaped component in each respective platform.

We soon found that having no restrictions would make it extremely hard to define such a system. More flexibility doesn’t necessarily mean a better result. For example, it’d be quite a feat to define a flexible and easy API that lets you make a snake-shaped FAB and train-shaped cards. But those elements would almost certainly contradict the clear and straightforward approach championed by Material Design guidance.

This truck-shaped FAB is a definite “don’t” in Material Design guidance.

We had to weigh the expense of time and resources against the added value for each functionality we could provide.

To solve these open questions we decided to conduct a full weeklong workshop including team members from design, engineering, and tooling. It proved to be extremely effective. Even though there were a lot of inputs, we were able to hone down what features were feasible and most impactful for our users. Our final proposal was to make the initial system support three types of shapes: square, rounded, and cut. These shapes can be achieved through an API customizing a component’s corners.

Building shape support consistently across platforms (it’s hard)

Anyone who’s built for multiple platforms knows that consistency is key. But during our workshop, we realized how difficult it would be to provide the exact same functionality for all our platforms: Android, Flutter, iOS, and the web. Our biggest blocker? Getting cut corners to work on the web.

Unlike sharp or rounded corners, cut corners do not have a built-in native solution on the web.

Our web team looked at a range of solutions—we even considered the idea of adding background-colored squares over each corner to mask it and make it appear cut. Of course, the drawbacks there are obvious: Shadows are masked and the squares themselves need to act as chameleons when the background isn’t static or has more than one color.

We then investigated the Houdini (paint worklet) API along with polyfill which initially seemed like a viable solution that would actually work. However, adding this support would require additional effort:

• Our UI components use shadows to display elevation and the new canvas shadows look different than the native CSS box-shadow, which would require us to reimplement shadows throughout our system.
• Our UI components also display a visual ripple effect when being tapped—to show intractability. For us to continue using ripple in the paint worklet, we would need to reimplement it, as there is no cross-browser masking solution that doesn’t provide significant performance hits.

Even if we’d decided to add more engineering effort and go down the Houdini path, the question of value vs cost still remained, especially with Houdini still being “not ready” across the web ecosystem.

Based on our research and weighing the cost of the effort, we ultimately decided to move forward without supporting cut corners for web UIs (at least for now). But the good news was that we have spec-ed out the requirements and could start building!

Rest in Next….