Revisiting the Rendering Tier

Have you ever created a well-intentioned, thoughtful design system only to watch it grow into an ever-increasing and scary codebase? I’ve been working in sort of the opposite direction, inheriting the scary codebase and trying to create a thoughtful system from it.

Here’s Alex Sanders on the topic, explaining how his team at The Guardian has tackled the task of creating design systems while combating complexity:

Systems that try to contain complexity over long periods of time by convention will inevitably tend toward entropy, because one significant characteristic of convention is that it is trivially simple to break one.

You do not even need to be malicious. A convention is not a line in the sand. You can have a very good case for breaking or stretching one, but once a convention is no longer fully observed, subsequent cases for breaking or stretching it are automatically stronger, because the convention is already weakened. The more this happens, the weaker it gets.

Complexity and entropy can be two outcomes in the same situation, but need not be mutually exclusive. Interesting to think that our best intentions to guard against complexity can be somewhat destructive.

I also love how Alex explains why it’s not possible for their team to use a Tachyons-esque approach to writing styles because of the way that their development environment is kinda slow. It would be painful for the team to make that switch, despite how it could solve some other problems. This reminded me that measuring problems in this way is why there can never be a single way to write CSS. We need that inherent flexibility, even at the expense of introducing inconsistencies. Hence, conventions being less of a line in the sand and more of a guide post.

On a separate note, I really like how Alex describes styles and attributes as the reasons why his team is writing those styles. It’s about aligning with business objectives:

…tens of thousands of rules that are intended to describe a maintainable set of responses to business and design problems.

That’s interesting since I don’t think we spend much time here talking specifically about the business side of CSS and the functional requirements that a styled user interface needs to accomplish.

And perhaps thinking about that can help us write better styles in the long term. Is this line of CSS solving a problem? Does this new class resolve an issue that will help our customers? These are good questions to keep in mind as we work, yet I know I don’t spend enough time thinking about them. I often see the design I’m turning into code as a problem to be solved instead.

Perhaps we should expand the way we styling a webpage because maybe, just maybe, it will help us write more maintainable code that’s built to solve a real business objective.

Direct Link to ArticlePermalink

The post Revisiting the Rendering Tier appeared first on CSS-Tricks.

Design Systems and Portfolios

In my experience working with design systems, I’ve found that I have to sacrifice my portfolio to do it well. Unlike a lot of other design work where it’s relatively easy to present Dribbble-worthy interfaces and designs, I fear that systems are quite a bit trickier than that.

You could make things beautiful, but the best work that happens on a design systems team often isn’t beautiful. In fact, a lot of the best work isn’t even visible.

For example, most days I’m pairing up with folks on my team to help them understand how our system works; from the CSS architecture, to the font stack, to the UI Kit to how a component can be manipulated to solve a specific problem, to many things in between. I’m trying as best as I can to help other designers understand what would be hard to build and what would be easy, as well as when to change their designs based on technical or other design constraints.

Further, there’s a lot of hard and diligent work that goes into projects that have no visible impact on the system at all. Last week, I noticed a weird thing with our checkboxes. Our Checkbox React component would output HTML like this:

<div class="checkbox"> <label for="ch-1"> <input id="ch-1" type="checkbox" class="checkbox" /> </label>
</div>

We needed to wrap the checkbox with a <div> for styling purposes and, from a quick glance, there’s nothing wrong with this markup. However, the <div> and the <input> both have a class of .checkbox and there were confusing styles in the CSS file that styled the <div> first and then un-did those styles to fix the <input> itself.

The fix for this is a pretty simple one: all we need to do is make sure that the class names are specific so that we can safely refactor any confusing CSS:

<div class="checkbox-wrapper"> <label for="ch-1"> <input id="ch-1" type="checkbox" class="checkbox" /> </label>
</div>

The thing is that this work took more than a week to ship because we had to refactor a ton of checkboxes in our app to behave in the same way and make sure that they were all using the same component. These checkboxes are one of those things that are now significantly better and less confusing, but it’s difficult to make it look sexy in a portfolio. I can’t simply drop them into a big iPhone mockup and rotate it as part of a fancy portfolio post if I wanted to write about my work or show it to someone else.

Take another example: I spent an entire day making an audit of our illustrations to help our team get an understanding of how we use them in our application. I opened up Figma and took dozens of screenshots:

It’s sort of hard to take credit for this work because the heavy lifting is really moderating a discussion and helping the team plan. It’s important work! But I feel like it’s hard to show that this work is valuable and to show the effects of it in a large org. “Things are now less confusing,” isn’t exactly a great accomplishment – but it really should be. These boring, methodical changes are vital for the health of a good design system.

Also… it’s kind of weird to putm “I wrote documentation” in a portfolio as much as it is to say, “I paired with designers and engineers for three years.” It’s certainly less satisfying than a big, glossy JPEG of a cool interface you designed. And I’m not sure if this is the same everywhere, but only about 10% of the work I do is visual and worthy of showing off.

My point is that building new components like this RadioCard I designed a while back is extraordinarily rare and accounts for a tiny amount of the useful work that I do:

See the Pen
Gusto App – RadioCard Prototype
by Robin Rendle (@robinrendle)
on CodePen.

I’d love to see how you’re dealing with this problem though. How do you show off your front-end and design systems work? How do you make it visible and valuable in your organization? Let me know in the comments!

The post Design Systems and Portfolios appeared first on CSS-Tricks.

The Elements of UI Engineering

I really enjoyed this post by Dan Abramov. He defines his work as a UI engineer and I especially like what he writes about his learning experience:

My biggest learning breakthroughs weren’t about a particular technology. Rather, I learned the most when I struggled to solve a particular UI problem. Sometimes, I would later discover libraries or patterns that helped me. In other cases, I’d come up with my own solutions (both good and bad ones).

It’s this combination of understanding the problems, experimenting with the solutions, and applying different strategies that led to the most rewarding learning experiences in my life. This post focuses on just the problems.

He then breaks those problems down into a dozen different areas: consistency, responsiveness, latency, navigation, staleness, entropy, priority, accessibility, internationalization, delivery, resilience, and abstraction. This is a pretty good list of what a front-end developer has to be concerned about on a day-to-day basis, but I also feel like this is perhaps the best description of what I believe my own skills are besides being “the person who cares about component design and CSS.”

I also love what Dan has to say about accessibility:

Inaccessible websites are not a niche problem. For example, in UK disability affects 1 in 5 people. (Here’s a nice infographic.) I’ve felt this personally too. Though I’m only 26, I struggle to read websites with thin fonts and low contrast. I try to use the trackpad less often, and I dread the day I’ll have to navigate poorly implemented websites by keyboard. We need to make our apps not horrible to people with difficulties — and the good news is that there’s a lot of low-hanging fruit. It starts with education and tooling. But we also need to make it easy for product developers to do the right thing. What can we do to make accessibility a default rather than an afterthought?

This is a good reminder that front-end development is not a problem to be solved, except I reckon Dan’s post is more helpful and less snarky than my take on it.

Anywho, we all want accessible interfaces so that every browser can access our work making use of beautiful and consistent mobile interactions, instantaneous performance, and a design system teams can utilize to click-clack components together with little-to-no effort. But these things are only possible if others recognize that UI and front-end development are a worthy fields.

Direct Link to ArticlePermalink

The post The Elements of UI Engineering appeared first on CSS-Tricks.

Creating the “Perfect” CSS System

My pal Lindsay Grizzard wrote about creating a CSS system that works across an organization and all of the things to keep in mind when starting a new project:

Getting other developers and designers to use the standardized rules is essential. When starting a project, get developers onboard with your CSS, JS and even HTML conventions from the start. Meet early and often to discuss every library, framework, mental model, and gem you are interested in using and take feedback seriously. Simply put, if they absolutely hate BEM and refuse to write it, don’t use BEM. You can explore working around this with linters, but forcing people to use a naming convention they hate isn’t going to make your job any easier. Hopefully, you will be able to convince them why the extra underscores are useful, but finding a middle ground where everyone will participate in some type of system is the priority.

I totally agree and the important point I noted here is that all of this work is a collaborative process and compromise is vital when making a system of styles that are scalable and cohesive. In my experience, at least, it’s real easy to walk into a room with all the rules written down and new guidelines ready to be enforced, but that never works out in the end.

Ethan Marcotte riffed on Lindsay’s post in an article called Weft and described why that’s not always a successful approach:

Broad strokes here, but I feel our industry tends to invert Lindsay’s model: we often start by identifying a technical solution to a problem, before understanding its broader context. Put another way, I think we often focus on designing or building an element, without researching the other elements it should connect to—without understanding the system it lives in.

Direct Link to Article — Permalink

The post Creating the “Perfect” CSS System appeared first on CSS-Tricks.

Developing a design environment

Jules Forrest discusses some of the work that her team at Credit Karma has been up to when it comes to design systems. Jules writes:

…in most engineering organizations, you spend your whole first day setting up your development environment so you can actually ship code. It’s generally pretty tedious and no one likes doing it, but it’s this thing you do to contribute meaningful work to production. Which got me thinking, what would it look like to make it easier for designers to design for production?

That’s what Jules calls a “design environment” and she’s even written a whole bunch of documentation in Thread, Credit Karma’s design system, for designers on their team to get that design environment up and running. That’s stuff like fonts, Sketch plugins, and other useful assets:

These problems have certainly been tackled by other teams in the past but this is the first time I’ve heard the phrase “design environment” before and I sort of love the heck out of it. Oh, and this post reminds me of a piece by Jon Gold where he wrote about Painting with Code.

Direct Link to Article — Permalink

The post Developing a design environment appeared first on CSS-Tricks.

designsystems.com

The team at Figma has created a new resource for “learning, creating and evangelizing design systems” called Design Systems that already has a good collection of interviews and articles by some folks thinking about these things.

I particularly liked Jeroen Ransijn’s post on how to convince your company it’s ready for a design system, where he writes:

Building a design system is not about reaching a single point in time. It’s an ongoing process of learning, building, evangelizing and driving adoption in your organization.

Design systems are a popular topic. Ethan Marcotte recently looked at instances where patterns get weird, Lucan Lemonnier shared a process for creating a consistent design system in Sketch, and Brad Frost debunked the perception that design systems are rigid. Seems like Figma’s new site will be a nice curated repository of this ongoing discussion.

Direct Link to Article — Permalink

The post designsystems.com appeared first on CSS-Tricks.

Creating Themeable Design Systems

Brad frost picks up the ongoing conversation about design systems. Where many posts seem to center on how to create one and how to enforce it, the big takeaway here is that design systems are not synonymous with constraints. They’re only as strict as we make them and new CSS features like custom properties actually open up new creative possibilities—something Andres Galante and Cliff Pyles recently pitched right here on CSS-Tricks.

Brad:

The aesthetic layer is often the most malleable layer of the frontend stack, which means that we can create systems that allow for a lot of aesthetic flexibility while still retaining a solid underlying structural foundation.

This not only sounds right, but puts a strong punctuation on why we love CSS: it’s a set of styles that can be applied an infinite number of ways to the same HTML markup. A new layer of paint can be slapped on at any time, but the beams, walls and ceiling of the building can remain constant. Dave Rupert’s personal site is a prime example of this and he details his approach to theming.

Ah, CSS Zen Garden…

Direct Link to Article — Permalink

The post Creating Themeable Design Systems appeared first on CSS-Tricks.

Vue Design System

We talk a lot about Vue around here, including some practical applications of it, but haven’t gotten deep into designing for it. In this post, Viljami Salminen describes his Vue design process and the thinking that led him to build the Vue Design System:

A design system can help establish a common vocabulary between everyone in an organization and ease the collabo­ration between different disciplines. I’ve seen it go the other way around too when important decisions have been made in a rush. To avoid that, Vue Design System introduces the following framework for naming that I’ve found working well in the past…

Viljami lists Design Principles, Tokens, Elements, Patterns, and Templates as the way in which he structures a system and I think it’s a pretty interesting approach and a parallel to Lucas Lemonnier’s post on creating design systems in Sketch, using Atomic Design as the structure. I particularly like how Viljami fits everything together in the example style guide that’s provided.

Direct Link to Article — Permalink

The post Vue Design System appeared first on CSS-Tricks.