Forem: Emily Carlin

Hacking Auto-Layout to Make a Progress Bar in Figma

Emily Carlin — Fri, 17 Jul 2020 19:14:26 +0000

I recently watched a recording from Figma's "Office Hours" series.

The session was all about components. They covered a ton of great stuff. There's something for everyone -- from those in the early days of their component journey to advanced component creators.

One thing they mentioned offhandedly (a little too offhandedly, for how cool and useful it is!) is using auto-layout to hack an editable progress bar component.

This really caught my eye. I work on a budgeting tool called You Need a Budget (YNAB). As you can probably imagine, simple "progress bar" data visualizations are quite useful to help people quickly make sense of their money and how they're doing on achieving their financial goals.

In the past, if we wanted to add a "progress bar" component to our design system, we would have to create a bunch of different variants (e.g. 25% full, 50% full, etc.) to represent various states of completion, because you can't override the width of elements within a component.

This autolayout hack will allow us to create a single "progress bar" component that designers can adjust to whatever width they'd like. Pretty handy!

Here's how to do it:

1. Create a container frame

This will be the background of your progress bar component, so give it whatever dimensions and styling you'd like. I chose a simple bright yellow background with sharp corners:

2. Create a "progress bar" frame within the container frame

Style this however you'd like your progress bar to look. Don't have to worry about its width, for now -- we'll make that editable in the next steps.

3. Create rectangle in the center of the progress bar frame.

This is where things get weird but cool. Just do it - you'll see why in the next step :) Make it 1px wide and go from the very top to the very bottom of your progress bar frame.

4. Add auto-layout to the progress bar frame

You can do this by selecting the progress bar frame and hitting shift+a or by adding auto-layout from the right-hand properties panel.

5. Make the rectangle in the progress bar frame invisible

You can do this a number of ways -- I chose to simply remove the fill.

5. That's it!

You can now adjust the horizontal padding on the progress bar frame to increase/decrease the size of the progress bar, like so:

This works because auto-layout is applied to the parent container -- in this case, the progress bar. The only element within the parent container is the invisible rectangle.

So when you add horizontal padding to either side of the rectangle, that ends up increasing the parent container's (i.e. the progress bar's) overall width.

You can see this more clearly if I make the invisible rectangle visible; the padding on either side of it increases/decreases, which changes the overall width of the progress bar (i.e. the parent container):

And if we turn this into a component, the progress bar will remain editable because you can adjust auto-layout properties in component instances. Pretty handy!

Feel free to comment with any questions. I'd also be curious how other teams are using auto-layout and if anyone has discovered any other fun "hacks" like this one :)

The Practice: Semantic Colors for Developers

Emily Carlin — Wed, 12 Feb 2020 20:15:09 +0000

We've already covered the theory behind our semantic color system as well as how it works for designers. This post covers how it works when the rubber hits the road: In code!

We believe that a design system isn’t worth much if it’s only used by designers. So when we started working on this new approach to colors, we knew we wanted to make it simple and usable for developers, too.

So we built a Figma integration that takes all of the color information from our color file and outputs usable code (special thanks/shoutout to Kyle Robinson Young on the YNAB development team, who helped build the integration).

YNAB offers an iOS app, an Android app, and a web app. We rely on our design system to keep things consistent between each platform, so the integration outputs code for each platform.

Each platform has some idiosyncrasies as far as how colors are defined and how light/dark mode switching happens, so we’ll run through each of them.

iOS

For iOS, the integration outputs a color file that is broken into two sections. This is where all of our iOS app's colors are defined.

The first section of the file defines the palette colors. These are private because we never refer to them directly — instead, we refer to semantic colors. This keeps things consistent and guarantees that they look good in light and dark mode.

In the next section of the file, we have our semantic color definitions. These are what actually we use to apply color. Each and every semantic color points at a palette color for light mode and for dark mode.

One of our iOS developers wrote a simple function, that looks at the user’s display mode and determines which color variant to display. That way, things will “just work” between modes. We also built in a safe fallback, in case users aren’t running iOS 13 yet.

We use the description field of the semantic colors from Figma to populate the proper references to the base palette for each semantic color.

Android

For Android, the integration outputs to three color-related files.

First, there’s palette.xml. This is the base color palette where all possible colors are defined.

Next, there’s colors.xml and colors.xml (night). These each have each semantic color listed, with the proper reference to the base palette for each mode — light mode definitions go in palette.xml and dark mode definitions go in colors.xml (night).

When we’re applying colors, we simply refer to colors defined in colors.xml and the right variant renders based on the user’s mode.

Web

We use Stylus for our web app, so we output a palette.styl, colors.styl, and dark-theme.styl file.

As you can probably anticipate from the structure of iOS and Android, palette.styl contains the base palette colors. ‘Colors.styland ‘dark-mode.styl contain CSS variable definitions that reference the proper base palette colors.

So when we are applying colors, we use the CSS variables we define in colors.styl and dark-mode.styl and render the right variant based on the mode the user has selected.

We haven’t released dark mode for the web, so this approach is still experimental, but we’re confident it will work just as well as the system has been working for iOS and Android.

Communication between designers and developers

The fact that we output color definitions directly from Figma means that when a developer looks at a design, they can use the exact same name as the designer and the code will “just work.”

The Figma integration makes it easy and lightweight to keep the system up-to-date; relying on manual updates and communication for a system like this would be a surefire way for it to quickly get out-of-date, messy, and to start to diverge between different platforms.

With this system, we simply run the integration any time colors change in Figma (which is our “source of truth” for all things color). Then developers immediately get access to the latest and greatest colors.

But the technical specificities here are less important than the fact that the philosophy and the language around colors are shared between designers and developers. This system gives us a shared language for talking about colors, and empowers everyone on the team to pick the right color for the job.

Questions? Comments? Get in touch!

That’s all for our series on how we built a semantic color system for designers and developers at YNAB! Feel free to reach out if you have any questions or suggestions. Our hope is that this system can be as useful to other teams as it has been to us!

The Practice: Semantic Colors for Designers

Emily Carlin — Wed, 12 Feb 2020 19:58:24 +0000

In this post, we’ll cover how the semantic color approach we described in the first post works for designers, in practice.

Setting colors up in the design system

Our team’s design tool of choice is Figma, but most of what we describe here could also be accomplished in Sketch (and perhaps other design tools).

Out of the box, Figma only supports one layer of abstraction for colors. You define a style, and that’s that. Here’s how we set things up to support our additional layer of abstraction:

First, we create a file in our Design System project called Colors.

On one page, we set up our base palette. These base palette colors constitute each and every color that can possibly appear in our apps. We make these colors private to the file by prepending a .to the style name. That way, the base palette colors won’t even appear when we publish the color file as a library.

On a new page, we define our semantic colors.

For each semantic color style, we define one light mode version and one dark mode version. In theory, we could define as many as we’d like (maybe we want a “super dark” mode, etc.)

We name these colors with the following convention:

Group Mode/Specific

Groups are things like “Label” “Background” “Header” etc. Mode corresponds to whether the given color is for light or dark mode. And Specific corresponds to the particular usage of the color within the group. This produces colors like:

The semantic color for primary actions, Primary Action is defined with the styles Primary Light/Action and Primary Dark/Action
The semantic color for accents within headers, Header Accent is defined with the styles Header Light/Accent and Header Dark/Accent
The semantic color for our default labels, Label Default is defined as Label Light/Default and Label Dark/Default

As you can see, the light/dark style variants of each of our semantic colors is where we have to hack our way past Figma’s single-layer concept of color.

We further push Figma’s approach to color by denoting the base palette color that each semantic color references in the style’s description field. In the example below, you can see that Primary Action points to primary600 in light mode and primary500 in dark mode.

This description is what connects the semantic color to the base palette color, via a custom plugin that we wrote. Whenever we change our base palette colors, our plugin will automatically update the semantic colors for us, so that we never have to do anything manually.

This description also comes in handy later when we export these colors from Figma to usable code — more on how that works in part 3, where we discuss how this system works for developers.

Using the colors file as a library in other files

When we publish the color file, designers have access to all of the semantic colors.

Each and every color has a light mode and a dark mode variant that are in the same position and have the same name within the color inspector.

So to get a dark mode version of a screen, you can simply toggle each color to use the dark mode variant. This means we don’t have to maintain different components for different modes — everything happens at the level of individual colors.

To make this even easier for designers to use, we plan to build a plugin that automatically flips colors from light to dark (Brian Lovin at Github already built something that does exactly this, though it isn’t available for public use at this point).

We also plan to make a plugin (or use one that someone else has made!) that allows for type-ahead search to make color selection more ergonomic. But for now, we’ve organized semantic colors alphabetically so that designers can quickly find what they’re looking for.

A flexible and efficient system

That’s all there is to it — we build our semantic color file, include it in other files, and go forth and design!

Questions? Want to try out our plugins?

If you have questions about how to set this system up for designers, please feel free to ask! There’s nothing “secret” about this and we’d love for something here to be useful to other designers.

We plan to publish the “semantic color updater” plugin as well as the Figma integration that outputs code (more on that in the next section) — let us know if your team is interested in trying out early versions of either one of these.

The next post covers how this system works for developers — both in the code and in terms of collaboration with designers.

The Theory: A Semantic Color System

Emily Carlin — Wed, 12 Feb 2020 19:35:01 +0000

This post is the first in a three-part series about how our team at You Need a Budget (YNAB) thinks about color in our design system. We'll go over the principles of how our system works, what inspired us to build it, and why we're excited about it.

The other posts cover how the system works for designers and for developers.

Introduction

Over the past few months, the team at YNAB revamped how we approach colors in our design system.

Colors are deceptively simple. They are a foundational element of interfaces but all-too-frequently end up becoming a sprawling mess of inline definitions, different naming conventions across different platforms, confusion around when to use what color, and issues with updates when things change. And dark mode support, which is becoming the norm, introduces yet another dimension of complexity to colors.

Our new system addresses these challenges head-on by using a combination of semantic naming and an additional “layer of abstraction” (more on what exactly this means later) in both our designs and in code.

This series is all about what we might call the “form” of colors in our design system: How we structure the system and how it works for designers and developers.

This series won’t cover the “content” of colors in our design system: Things like how we selected the actual color values we use, how we ensure adequate contrast, our color decisions in designing for dark mode, etc.

Okay, let’s get into it!

What’s in a name?

If you’re a designer or a developer, chances are you’ve seen the words “semantic” and “color” in the same sentence before. It usually refers to a way of naming colors based on how they are used as opposed to their hue. This is one of many theories on the best way to name color.

With a semantic name, you might name a color “destructive” or “negative” — something that connotes what the color means in your interface, as opposed to something like “red” (or even something more fun, like “tomato”).

Naming colors semantically has two benefits:

It helps designers and developers decide what color to use. Instead of needing to memorize or check documentation to decide what color to make a “delete” button, you simply grab the color that relates to destruction.
It makes your color system more efficient and flexible. If you decide you want to update your primary color to be purple instead of blue, you simply update the value for the primary color (assuming you’re using color styles in a tool like Figma or Sketch and color variables in code). If the colors were named based on hue, you’d need to go change every single place the color is used from “blue” to “purple.”

Our new approach to color introduces an additional layer of abstraction to address some of the problems that are left unsolved by simply naming each of your colors semantically.

The base palette

A color palette is, of course, an integral piece of any design system. The palette represents the universe of possibility for color in an interface.

A palette is a great start for building visually consistent apps — a defined set of colors mitigates the chance that a rogue hex value will sneak its way in.

Here’s what our palette looks like at YNAB:

Each of the colors has a semantic name (e.g. primary, accent, etc.) as well as a number that corresponds to its lightness (e.g. 900 for the darkest variants; 100 for the lightest variants). But if we stopped here, a lot would still remain up for interpretation as far as when to use what color. And not in a good “this leaves space for creativity!” way; more in a “What primary color variant do we use for buttons again?” way.

The semantic colors

Our semantic colors go further than simply naming colors based on the general realm of their usage. They are a second layer of abstraction that sits on top of the base palette.

Our color system consists of two layers:

The base palette, which defines every possible color value in our app.
The semantic palette, which defines colors based on how they are used. Each and every semantic color points to a color from the base palette.

For example, we have a semantic color for our primary action color and another one for the background of headers. Each of those semantic colors references a color from the base palette.

Now, you may be thinking, “This seems like a bunch of extra work for something that we get for free with symbols/components.” And in the case of something like a button or a header, that may very well be true — when you design the primary button component, you pick a color from the palette and then others simply use that component in their designs without needing to think about the specific color.

But as things get more complex, the benefits of this two-layer system become clear.

Visual Consistency

YNAB is budgeting software, which means that we frequently use color as a visual signal for positive and negative account balances (we never rely only on color, but color and accessibility would be a whole separate post).

For example, the budget view features “pills” that display the amount remaining in a given category of a user’s budget. There is also a bar at the top of the screen that displays overall budget status.

To keep things consistent, we want both of these elements to use the exact same color. That way, users can start to learn that when they see this particular red color, it always means the same thing — a negative balance!

In our semantic color system, we name this color statusNegative and set it to reference a color from our base palette. So if we want to update this color, we simply point it at a different palette color and the change propagates to all elements that are meant to convey a negative status. And if we update a base palette color, the change will ripple through all of the semantic colors that reference that color (and then all of the elements that use those semantic colors).

This is what we mean by introducing an additional layer of abstraction. Semantic colors act as an intermediary level of specificity, between the raw value of colors in the base palette and the usage of those colors in specific components.

And here’s the best part: Semantic colors make it easy for designers to create new elements that are visually consistent with the rest of the app. If we wanted to create a graph on a dashboard that is in a negative state, we’d simply drop in statusNegative instead of arbitrarily searching through our red hues.

Dark Mode

Beyond visual consistency, a major benefit of this system is how easily it supports dark mode. In fact, adapting our apps to dark mode is what inspired this approach to color in the first place.

Let’s consider the color we use for primary elements — primaryAction. This color references primary600 from the base palette.

Great. But what about dark mode?

Well, all we have to do is create an additional mapping for primaryAction.

For dark mode, we map it to primary500, a lighter blue, because we want primary elements to “pop” more on dark backgrounds (like accessibility, choosing colors for dark mode could be a whole separate article. We won’t get into the specifics here, but check out this article by the team at Superhuman for a great primer).

Each of our semantic colors points to two base palette colors: one for light mode and one for dark mode.

That way, we can just apply a primaryAction style to our buttons and the right palette variant will render based on the user’s mode.

You may be thinking: “Why can’t you just define a dark mode variant of primary600? This doesn’t work because there are some colors that should get darker in dark mode (think backgrounds) and some colors that should get lighter in dark mode (think labels and accents).

Long story short ...

The two-layer semantic approach to colors allows us to flexibly update colors, keep our app visually consistent, and efficiently design for dark mode.

The next two posts in this series will cover the ins and outs of how this system actually works — for designers and for developers.

Thanks to Alan Dennis (who came up with the structure of this approach) and the rest of the YNAB design and development teams for helping to bring this system to life.

Additional thanks to Alan Dennis, Dylan Mason, and Tristan Harward for giving feedback on the first draft of this post.