[Robin]: This week I’ve been working on a number of refactoring projects at Sentry, where I work as a designer/front-end engineer person. The first job was focused entirely on our colors, as over the years a certain amount of debt had been accrued until we had a ton of random hex values everywhere and horrid variable names such as
I’m not dunking on anyone. We have all written code like this. In our darkest moments, we all have to admit that we’ve actually written worse code than this.
In fact, tech debt is a good sign: your team built a thing that customers use and pay for, but now we have to think about scale rather than panic code just to make ends meet. The way I’ve started to think about tech debt is that the problem isn’t necessarily the debt itself, all codebases are bad, and getting used to that fact is the difference between being a junior and senior engineer in my opinion. The real problem is the conversation, or the lack thereof about that tech debt, and making a viable plan for the future.
All these variable names and confusing color schemes had become a running gag at the company. We all dunked on them because we knew they’re not part of an organized system and we all knew it had to be fixed. Some day at least. Well, the time had come. I had finally had enough and was going to fix this dang thing. Thankfully an audit had already been made of our colors—matching our completely bonkers older variables with a new color palette made in a Figma doc.
So I did what I do with all refactor projects now: I made a new a spreadsheet and started documenting things. I made a list of every existing color variable in the app today and paired that with the colors in our new palette from Figma:
The columns on the left signify the two codebases that we have and if an instance of a variable had been removed (Done) or if that variable had been removed entirely (Removed). It’s a pretty nasty spreadsheet, please do not @ me. The important thing about this is that I could understand the system and how much work was left to be done.
Next up, I added all our new variables into our
theme.tsx file. We use emotion at Sentry and our theme file is where all our common variables live. Then I started removing the instances from both codebases and then removing the variable itself, updating the spreadsheet as I went. This stuff is long and tedious work but thankfully we had Percy setup so that with each commit I could see the impact that the color swaps had on our components.
Now, after a week or so of work, we finally have a brief list of variables to use everywhere and we can see them in the codebase, in Figma, and also in Slack. But to make a rather long story short, I think the moral of this story is that all design systems projects should begin and end with a spreadsheet. Boy, I love spreadsheets.
What is Developer Experience?
I love this post by Chris about what the term Developer Experience means and its role in the industry today:
The difference between a poor developer environment (no IDE help, slow saves, manual refreshes, slow pipelines) and a great developer environment (fancy editor assistance, hot reloading, fast everything) is startling. A good developer environment, good DX, makes you a better and more productive programmer.
I’d argue that DX is all about keeping developers focused. If they have to wait for long build times, or wait for CSS to compile, or they’re thinking about anything besides solving the problem then that’s a warning signal. And I’d say design systems fit neatly into this bucket too.
A tool for making pattern background images
Patternico does just that: you can throw an icon onto the canvas, pick a background color, and see how it’ll look when it’s tiled across the whole background:
Last year we listed a ton of resources to help make interesting backgrounds that can spice up your design a bit. One tool that I hadn’t seen from this list was SVG Backgrounds which is super impressive. It gives you a ton of options, from subtle backgrounds to keep you focused on the task at hand or completely bonkers neon hexagons that are fun as heck:
Also it’s very much worth checking out Hero Patterns, too.
Advice for Complex CSS Illustrations
Jhey Tompkins takes a look at how to make those rather complex and beautiful CSS illustrations you might’ve seen floating about lately. Diana Smith’s work is an obvious starting point because her work is simply lovely and whenever I look at her work my eye starts to twitch as I try to figure out the sheer amount of time each one took:
Jhey writes about what it takes to make something like this:
CSS illustration takes lots of time and practice. The more accurate you want to be and the more complicated the illustration, the longer it’s going to take. The time-consuming part isn’t usually deciding on which properties to use and how, but the tinkering of getting things to look right. Be prepared to get very familiar with the styles inspector in your browser dev tools! I also recommend trying out VisBug if you haven’t.
I particularly like that Jhey recommends to get around the difficulty of starting it’s totally okay to trace an image, too. You can throw an image onto the page and change the opacity to make it much easier to create each section, just as Jhey mentioned:
Where do you learn HTML & CSS in 2020?
Chris made some notes about how to do just that, listing a ton of great resources in the process, and then has this bit of advice for everyone who’s just getting started:
People learn anything — music and web development included — inside a hurricane of influences. Let’s stick with music for a second. Learning to play comes in many forms. You learn by listening to music an awful lot. You can do fundamental practice, like finger exercises and going up and down scales. You can learn to transpose chords on a chalkboard. You can watch YouTube all day and night. You can sign up for online courses. You can go to local jams to watch and play along. You can join a band. You can take lessons from someone advertising on Craigslist. You can go to a local music school. You can read books about music.
You get the idea.
You can and will do all of that. With learning web design and development, getting anywhere will involve all sorts of ways. There’s no silver bullet. It takes bashing on it lots of different ways. There’s no requirement to sprinkle money on it, but you do need multiple angles, time, and motivation.
Outside of the great list of resources that Chris recommends in this post, I would highly recommend just straight up copying things. Do you like the old Gameboy boot up animation? That could be a little project! Or perhaps you like the UI in a videogame or Mondrian paintings or something. Those things can be projects, too!
The reason I recommend copying things you like is that I’ve always found having a project in mind is always more helpful than trying to learn about technology X, Y, or Z.
Easing Animations in Canvas
Darshan Somashekar made a Solitaire game in canvas and in this post walks us through the ease-in and ease-out animations that were required to get things feeling just right. Darshan then shows how complex animations are a whole bunch easier with Greensock.
This reminds me that earlier this year Sarah wrote about how to animate on the web with Greensock, too. She made a ton of great examples like this one:
Jetpack Site Scan
Jetpack Scan uses automated scanning and one-click fixes to keep your site ahead of security threats.
This is how I look at it: Automattic has a very strong vested interest in keeping WordPress sites secure. WordPress is a juicy target for spammers and malicious internet jerks because of how widely it is used, and Automattic doesn’t need WordPress being thought of as an insecure platform. So here’s the answer. Automattic themselves will watch your site for security issues and help you fix them.
I haven’t had a WordPress site hacked in something like a decade, and before that when I have, it was always some vulnerability that I caused myself. Jetpack Scan saves you from yourself.
[Chris]: We often think of the HTML and CSS support in HTML emails to be this other world of terribleness. We rarely go there, leaving that work to specialists and email builder products.
In some ways, it is true. We don’t have evergreen Chromium in email clients. Email clients don’t make what seems like it would be a strong move to pick up Gecko as the rendering engine. I have no idea why. I imagine there are serious technical challenges and perhaps some issues with the email client market not being rewarding enough.
In other ways, we don’t need to feel helpless in HTML email land. One way to think of that environment is the ultimately test of our progressive enhancement abilities. That is, code in such a way that will work no matter what, and if certain capabilities are present, they are used.
An example? Three years ago Kevin Mandeville was sending production client-facing emails with CSS grid. Why not? Some email clients support it, and the ones that don’t get a column of boxes which is what most emails are anyway.
That’s a grid-powered email that looks like that in Apple Mail 10.3+, Outlook 2016 for Mac, AOL Mail in Chrome or Firefox, and Freenet.de in Chrome or Firefox. Cool.