Josh is great at explaining tricky concepts and here he’s really set himself a challenge: explaining layout modes in CSS.
Monday, April 4th, 2022
Sunday, February 6th, 2022
I remember Lara telling me a great quote from the Clarity conference a few years back: “A design system needs to be correct before it’s complete.” In other words, it’s better to have one realistic component that’s actually in production than to have a pattern library full of beautiful but unimplemented components. I feel like Robin is getting at much the same point here, but he frames it in terms of correctness and usefulness:
If we want to be correct, okay, let’s have components of everything and an enormous Figma library of stuff we need to maintain. But if we want to be useful to designers who want to get an understanding of the system, let’s be brief.
Tuesday, January 18th, 2022
Installing progressive web apps
I don’t know about you, but it seems like everyone I follow on Twitter is playing Wordle. Although I don’t play the game myself, I think it’s pretty great.
Not only does Wordle have a very sweet backstory, but it’s also unashamedly on the web. If you want to play, you go to the URL
powerlanguage.co.uk/wordle. That’s it. No need to download an app.
That hasn’t stopped some nefarious developers trying to trick people into downloading their clones of Wordle from app stores. App stores, which are meant to be curated and safe, are in fact filled with dodgy knock-offs and scams. Contrary to popular belief, the web is quite literally a safer bet.
Wordle has a web app manifest, which means you can add it to your home screen and it will behave just like a native app (although I don’t believe it has offline support). That’s great, but the process of adding a web app to your home screen on iOS is ludicrously long-winded.
Macworld published an article detailing how to get the real Wordle app on your iPhone or iPad. On the one hand it’s great to see this knowledge being spread. On the other hand it’s dispiriting that it’s even necessary to tell people that they can do this, like it’s a hidden nerdy secret just for power users.
At this point I’ve pretty much given up on Apple ever doing anything about this pathetic situation. So what can I do instead?
Well, taking my cue from that Macworld article, the least I can do is inform people how they can add a progressive web app to their home screen.
That’s what I’ve done on thesession.org. I’ve published a page on how to install The Session to your home screen.
On both Android and iPhone the journey to installing a progressive web app begins with incomprehensible iconography. On Android you must first tap on the unlabeled kebab icon—three vertical dots. On iOS you must first tap on the unlabeled share icon—a square with an arrow coming out of it.
When it comes to mobile operating systems, consumer choice means you choose which kind of mystery meat to eat.
I’ve included screenshots to help people identify these mysterious portals. For iOS I’ve also included a video to illustrate the quest to find the secret menu item buried beneath the share icon.
Handy tip: when you’re adding a
start_url value to your web app manifest, it’s common to include a query string like this:
I’m guessing most people to that so they can get analytics on how many people are starting from an icon tap. I don’t do analytics on The Session but I’m still using that query string in my
start_url. On the home page of the site, I check for the existence of the query string. If it exists, I don’t show the link to the installation page. So once someone has installed the site to their home screen, they shouldn’t see that message when they launch The Session.
If you’ve got a progressive web app, it might be worth making a page with installation instructions rather than relying on browsers to proactively inform your site’s visitors. You’d still need to figure out the right time and place to point people to that page, but at least the design challenge would be in your hands.
Should you decide to take a leaf out of the Android and iOS playbooks and use mystery meat navigation to link to such a page, there’s an emoji you could potentially use: 📲
It’s still worse than using actual words, but it might be better than some random combination of dots, squares and arrows.
(I’m not really serious about using that emoji, but if you do, be sure to use a sensible
aria-label value on the enclosing
Monday, November 8th, 2021
Speed for the sake of speed means nothing. If our design systems don’t ultimately lead to better quality experiences, we’re doing it wrong.
When we rush to release one-size-fits-all components, without doing the work to understand different contexts before curating and consolidating solutions, we sacrifice quality at the hands of speed.
The irony? In the long run, this will slow us down. We end up having to undo the work we’ve done to fix the problems we’ve created.
Ultimately, when we prioritise speed over quality, we end up with neither.
Tuesday, September 14th, 2021
I was doing some accessibility work with a client a little while back. It was mostly giving their site the once-over, highlighting any issues that we could then discuss. It was an audit of sorts.
While I was doing this I started to realise that not all accessibility issues are created equal. I don’t just mean in their severity. I mean that some issues can—and should—be caught early on, while other issues can only be found later.
Take colour contrast. This is something that should be checked before a line of code is written. When designs are being sketched out and then refined in a graphical editor like Figma, that’s the time to check the ratio between background and foreground colours to make sure there’s enough contrast between them. You can catch this kind of thing later on, but by then it’s likely to come with a higher cost—you might have to literally go back to the drawing board. It’s better to find the issue when you’re at the drawing board the first time.
Then there’s the HTML. Most accessibility issues here can be caught before the site goes live. Usually they’re issues of ommission: form fields that don’t have an explicitly associated
label element (using the
id attributes); images that don’t have
alt text; pages that don’t have sensible heading levels or landmark regions like
nav. None of these are particularly onerous to fix and they come with the biggest bang for your buck. If you’ve got sensible forms, sensible headings,
alt text on images, and a solid document structure, you’ve already covered the vast majority of accessibility issues with very little overhead. Some of these checks can also be automated:
alt text for images;
labels for inputs.
So if you commission an accessibility audit, you should hope to get feedback that’s mostly in that third category—interactive widgets.
If you get feedback on document structure and other semantic issues with the HTML, you should fix those issues, sure, but you should also see what you can do to stop those issues going live again in the future. Perhaps you can add some steps in the build process. Or maybe it’s more about making sure the devs are aware of these low-hanging fruit. Or perhaps there’s a framework or content management system that’s stopping you from improving your HTML. Then you need to execute a plan for ditching that software.
If you get feedback about colour contrast issues, just fixing the immediate problem isn’t going to address the underlying issue. There’s a process problem, or perhaps a communication issue. In that case, don’t look for a technical solution. A design system, for example, will not magically fix a workflow issue or route around the problem of designers and developers not talking to each other.
When you commission an accessibility audit, you want to make sure you’re getting the most out of it. Don’t squander it on issues that you can catch and fix yourself. Make sure that the bulk of the audit is being spent on the specific issues that are unique to your site.
Tuesday, February 16th, 2021
These definitions work for me:
Tuesday, January 26th, 2021
In the zone
I went to art college in my younger days. It didn’t take. I wasn’t very good and I didn’t work hard. So I dropped out before they could kick me out.
But I remember one instance where I actually ended up putting in more work than my fellow students—an exceptional situation.
In the first year of art college, we did a foundation course. That’s when you try a bit of everything to help you figure out what you want to concentrate on: painting, sculpture, ceramics, printing, photography, and so on. It was a bit of a whirlwind, which was generally a good thing. If you realised you really didn’t like a subject, you didn’t have to stick it out for long.
One of those subjects was animation—a relatively recent addition to the roster. On the first day, the tutor gave everyone a pack of typing paper: 500 sheets of A4. We were told to use them to make a piece of animation. Put something on the first piece of paper. Take a picture. Now put something slightly different on the second piece of paper. Take a picture of that. Repeat another 498 times. At 24 frames a second, the result would be just over 20 seconds of animation. No computers, no mobile phones. Everything by hand. It was so tedious.
And I loved it. I ended up asking for more paper.
(Actually, this was another reason why I ended up dropping out. I really, really enjoyed animation but I wasn’t able to major in it—I could only take it as a minor.)
I remember getting totally absorbed in the production. It was the perfect mix of tedium and creativity. My mind was simultaneously occupied and wandering free.
Recently I’ve been re-experiencing that same feeling. This time, it’s not in the world of visuals, but of audio. I’m working on season two of the Clearleft podcast.
For both seasons and episodes, this is what the process looks like:
- Decide on topics. This will come from a mix of talking to Alex, discussing work with my colleagues, and gut feelings about what might be interesting.
- Gather material. This involves arranging interviews with people; sometimes co-workers, sometimes peers in the wider industry. I also trawl through the archives of talks from Clearleft conferences for relevent presentations.
- Assemble the material. This is where I’m chipping away at the marble of audio interviews to get at the nuggets within. I play around with the flow of themes, trying different juxtapositions and narrative structures.
- Tie everything together. I add my own voice to introduce the topic and segue from point to point.
- Release. I upload the audio, update the RSS feed, and publish the transcript.
Lots of podcasts (that I really enjoy) stop at step two: record a conversation and then release it verbatim. Job done.
Being a glutton for punishment, I wanted to do more of an amalgamation for each episode, weaving multiple conversations together.
Right now I’m in step three. That’s where I’ve found the same sweet spot that I had back in my art college days. It’s somewhat mindless work, snipping audio waveforms and adjusting volume levels. At the same time, there’s the creativity of putting those audio snippets into a logical order. I find myself getting into the zone, losing track of time. It’s the same kind of flow state you get from just the right level of coding or design work. Normally this kind of work lends itself to having some background music, but that’s not an option with podcast editing. I’ve got my headphones on, but my ears are busy.
I imagine that is what life is like for an audio engineer or producer.
When I first started the Clearleft podcast, I thought I would need to use GarageBand for this work, arranging multiple tracks on a timeline. Then I discovered Descript. It’s been an enormous time-saver. It’s like having GarageBand and a text editor merged into one. I can see the narrative flow as a text document, as well as looking at the accompanying waveforms.
Descript isn’t perfect. The transcription accuracy is good enough to allow me to search through my corpus of material, but it’s not accurate enough to publish as is. Still, it gives me some nice shortcuts. I can elimate ums and ahs in one stroke, or shorten any gaps that are too long.
But even with all those conveniences, this is still time-consuming work. If I spend three or four hours with my head down sculpting some audio and I get anything close to five minutes worth of usable content, I consider it time well spent.
Sometimes when I’m knee-deep in a piece of audio, trimming and arranging it just so to make a sentence flow just right, there’s a voice in the back of my head that says, “You know that no one is ever going to notice any of this, don’t you?” I try to ignore that voice. I mean, I know the voice is right, but I still think it’s worth doing all this fine tuning. Even if nobody else knows, I’ll have the satisfaction of transforming the raw audio into something a bit more polished.
Yes, I’m being a little vague on the exact dates. That’s because I’m still in the process of putting the episodes together.
So if you’ll excuse me, I need to put my headphones on and enter the zone.
Wednesday, December 9th, 2020
Chris is gathering end-of-year thoughts from people in response to the question:
What is one thing you learned about building websites this year?
Thursday, October 8th, 2020
A follow-up to full-bleed layout post I linked to recently. Here’s how you can get the same effect with using CSS grid.
I like the use of the principle of least power not just in the choice of languages, but within the application of a language.
Friday, August 28th, 2020
Before the hagiographical praise for working with an iPad Pro, Robin nails the fundamental shape of the design process:
I had forgotten that there are two modes of design, just as there is in writing.
The first mode is understanding the problem, getting a ten-thousand foot view of the land. It’s getting people to acknowledge that this really is the problem we need to agree upon. This work needs to happen in a sketchbook in the form of messy, back-of-the-napkin drawings or in writing. All this helps you to form a proper argument and focus your thoughts.
The second mode of design is taking that ten-thousand foot view and zooming all the way in to the hairs on the back of the rabbit; figuring out the precise UI and components, the copywriting, the animations, the everything else. This should be done in a design tool like Figma or Sketch. And this is when we should be talking about color palettes, icons, design systems, and consistency.
The problem with almost all design work is that first phase never really happens. People don’t take that ten thousand foot view of the problem and are focusing instead on the pixels; they’re trapped by the system they know too well.
Yes, yes, yes! Spot on:
I think people get stuck in that second mode because productivity in design is often tied to “how many pages or frames did I design today?” when productivity should instead be thought of as “how did my understanding of the problem change?
Monday, August 17th, 2020
Netlify redirects and downloads
Making the Clearleft podcast is a lot of fun. Making the website for the Clearleft podcast was also fun.
Design wise, it’s a riff on the main Clearleft site in terms of typography and general layout. On the development side, it was an opportunity to try out an exciting tech stack. The workflow goes something like this:
- Open a text editor and type out HTML and CSS.
Comparing this to other workflows I’ve used in the past, this is definitely the most productive way of working. Some stats:
- Time spent setting up build tools: 00:00
- Time spent wrangling the pipeline to do exactly what you want: 00:00
- Time spent trying to get the damn build tools to work again when you return to the project after leaving it alone for more than a few months: 00:00:00
I have some files. Some images, three font files, a few pages of HTML, one RSS feed, one style sheet, and one minimal service worker script. I don’t need a web server to do anything more than serve up those files. No need for any dynamic server-side processing.
Netlify suits my hosting needs nicely. It also provides the added benefit that, should I need to update my CSS, I don’t need to add a query string or anything to the
link elements in the HTML that point to the style sheet: Netlify does cache invalidation for you!
The mp3 files of the actual podcast episodes are stored on S3. I link to those mp3 files from
enclosure elements in the RSS feed, which is what makes it a podcast. I also point to the mp3 files from
audio elements on the individual episode pages—just above the transcript of each episode. Here’s the page for the most recent episode.
I also want people to be able to download the mp3 file directly if they want (or if they want to huffduff an episode). So I provide a link to the mp3 file with a good ol’-fashioned
a element with an
I throw in one more attribute on that link. The
download attribute tells the browser that the URL in the
href attribute should be downloaded instead of visited. If you give a value for the
download attribute, it will over-ride the file name:
<a href="/files/ugly-file-name.xyz" download="nice-file-name.xyz">download</a>
Or you can use it as a Boolean attribute without any value if you’re happy with the file name:
<a href="/files/nice-file-name.xyz" download>download</a>
There’s one catch though. The
download attribute only works for files on the same origin. That’s an issue for me. My site is
podcast.clearleft.com but my audio files are hosted on
download attribute will be ignored and the mp3 files will play in the browser instead of downloading.
I added a file called
_redirects to the root of my project. It contains one line:
/download/* https://clearleft-audio.s3.amazonaws.com/podcast/:splat 200
That says that any URLs beginning with
/download/ should redirect to
clearleft-audio.s3.amazonaws.com/podcast/. Everything after the closing slash is captured with that wild card asterisk. That’s then passed along to the redirect URL as
:splat. That’s a new one on me. I hadn’t come across that terminology, but as someone who can never remember the syntax of regular expressions, it works for me.
Oh, and the
200at the end is the status code: okay.
Now I can use this
/download/ path in my link:
<a href="/download/season01episode06.mp3" download>Download mp3</a>
Because this URL on the same origin, the
download attribute works just fine.
Tuesday, May 19th, 2020
Five moments in the lifecycle of a design system. They grow up so fast!
- Formation of the Design System Team
- First Page Shipped
- Consumable Outside the Main Product
- First Non-System Team Consumer
- First Breaking Change
Dave makes the observation that design systems are less like open source software and more like enterprise software—software you didn’t choose to use:
Often, in my experience, for an internal Design System to have widespread adoption it requires a literal executive mandate from the top floor of the building.
Also: apparently design systems have achieved personhood now and we’re capitalising them as proper names. First name Design, last name System.
“Please, call me Design. Mr. System was my father.”
Wednesday, December 11th, 2019
The Technical Side of Design Systems by Brad Frost
You can have a killer style guide website, a great-looking Sketch library, and robust documentation, but if your design system isn’t actually powering real software products, all that effort is for naught. At the heart of a successful design system is a collection of sturdy, robust front-end components that powers other applications’ user interfaces. In this talk, Brad will cover all that’s involved in establishing a technical architecture for your design system. He’ll discuss front-end workshop environments, CSS architecture, implementing design tokens, popular libraries like React and Vue.js, deploying design systems, managing updates, and more. You’ll come away knowing how to establish a rock-solid technical foundation for your design system.
I will attempt to liveblog the Frostmeister…
“Design system” is an unfortunate name …like “athlete’s foot.” You say it to someone and they think they know what you mean, but nothing could be further from the truth.
A design system is a set of rules enforced by culture, process and tooling that govern how your organization creates products.
A design system the story of how an organisation gets things done.
When Brad talks to companies, he asks “Have you got a design system?” They invariably say they do …and then point to a Sketch library. When the focus goes on the design side of the process, the production side can suffer. There’s a gap between the comp and the live site. The heart and soul of a design system is a code library of reusable UI components.
Brad’s going to talk through the life cycle of a project.
He begins with selling in a design system. That can start with an interface inventory. This surfaces visual differences. But even if you have, say, buttons that look the same, the underlying code might not be consistent. Each one of those buttons represents time and effort. A design system gives you a number of technical benefits:
- Reduce technical debt—less frontend spaghetti code.
- Faster production—less time coding common UI components and more time building real features.
- Higher-quality production—bake in and enforce best practices.
- Reduce QA efforts—centralise some QA tasks.
- Potentially adopt new technologies faster—a design system can help make additional frameworks more managable.
- Useful reference—an essential resource hub for development best practices.
- Future-friendly foundation—modify, extend, and improve over time.
Once you’ve explained the benefits, it’s time to kick off.
Brad asks “What’s yer tech stack?” There are often a lot of tech stacks. And you know what? Users don’t care. What they see is one brand. That’s the promise of a design system: a unified interface.
How do you make a design system deal with all the different tech stacks? You don’t (at least, not yet). Start with a high priority project. Use that as a pilot project for the design system. Dan talks about these projects as being like television pilots that could blossom into a full season.
Where to build the design system? The tech stack under the surface is often an order of magnitude greater than the UI code—think of node modules, for example. That’s why Brad advocates locking off that area and focusing on what he calls a frontend workshop environment. Think of the components as interactive comps. There are many tools for this frontend workshop environment: Pattern Lab, Storybook, Fractal, Basalt.
How are you going to code this? Brad gets frontend teams in a room together and they fight. Have you noticed that developers have opinions about things? Brad asks questions. What are your design principles? Do you use a CSS methodology? What tools do you use? Spaces or tabs? Then Brad gets them to create one component using the answers to those questions.
Guidelines are great but you need to enforce them. There are lots of tools to automate coding style.
Then there’s CSS architecture. Apparently we write our styles in React now. Do you really want to tie your CSS to one environment like that?
You know what’s really nice? A good ol’ sturdy cacheable CSS file. It can come in like a fairy applying all the right styles regardless of tech stack.
Design and build
Brad likes to break things down using his atomic design vocabulary. He echoes what Mina said earlier:
Embrace the snowflakes.
The idea of a design system is not to build 100% of your UI entirely from components in the code library. The majority, sure. But it’s unrealistic to expect everything to come from the design system.
When Brad puts pages together, he pulls in components from the code library but he also pulls in one-off snowflake components where needed.
The design system informs our product design. Our product design informs the design system.
Brad has seen graveyards of design systems. But if you make a virtuous circle between the live code and the design system, the design system has a much better chance of not just surviving, but thriving.
So you go through those pilot projects, each one feeding more and more into the design system. Lather, rinse, repeat. The first one will be time consuming, but each subsequent project gets quicker and quicker as you start to get the return on investment. Velocity increases over time.
It’s like tools for a home improvement project. The first thing you do is look at your current toolkit. If you don’t have the tool you need, you invest in buying that new tool. Now that tool is part of your toolkit. Next time you need that tool, you don’t have to go out and buy one. Your toolkit grows over time.
The design system code must be intuitive for developers using it. This gets into the whole world of API design. It’s really important to get this right—naming things consistently and having predictable behaviour.
Mina talked about loose vs. strict design systems. Open vs. locked down. Make your components composable so they can adapt to future requirements.
You can bake best practices into your design system. You can make accessibility a requirement in the code.
What does it mean to “launch” a design system?
A design system isn’t a project with an end, it’s the origin story of a living and evolving product that’ll serve other products.
There’s a spectrum of integration—how integrated the design system is with the final output. The levels go from:
- Least integrated: static.
- Front-end reference code.
- Most integrated: consumable compents.
Chris Coyier in The Great Divide talked about how wide the spectrum of front-end development is. Brad, for example, is very much at the front of the front end. Consumable UI components can create a bridge between the back of the front end and the front of the front end.
Consumable UI components need to be bundled, packaged, and published.
Now we’ve entered a new mental space. We’ve gone from “Let’s build a website” to “Let’s maintain a product which other products use as a dependency.” You need to start thinking about things like semantic versioning. A version number is a promise.
A 1.0.0 designation comes with commitment. Freewheeling days of unstable early foundations are behind you.
What do you do when a new tech stack comes along? How does your design system serve the new hotness. It gets worse: you get products that aren’t even web based—iOS, Android, etc.
That’s where design tokens come in. You can define your design language in a platform-agnostic way.
This is hard.
- Your design system must live in the technologies your products use.
- Look at your product roadmaps for design system pilot project opportunities.
- Establish code conventions and use tooling and process to enforce them.
- Build your design system and pilot project UI screens in a frontend workshop environment.
- Bake best practices into reusable components & make them as rigid or flexible as you need them to be.
- Use semantic versioning to manage ongoing design system product work.
- Use design tokens to feed common design properties into different platforms.
You won’t do it all at once. That’s okay. Baby steps.
Monday, December 9th, 2019
Brad gets ranty …with good reason.
Thursday, November 7th, 2019
Tuesday, September 10th, 2019
When you ever had to fix just a few lines of CSS and it took two hours to get an ancient version of Gulp up and running, you know what I’m talking about.
I feel seen.
When everything works, it feels like magic. When something breaks, it’s hell.
I concur with Bastian’s advice:
I have a simple rule of thumb when it comes to programming:
less code === less potential issues
And this observation rings very true:
This dependency hell is also the reason why old projects are almost like sealed capsules. You can hardly let a project lie around for more than a year, because afterwards it’s probably broken.
Saturday, September 7th, 2019
An interesting proposal to allow websites to detect certain SMS messages. The UX implications are fascinating.
Thursday, August 1st, 2019
I love React. I love how server side rendering React apps is trivial because it all compiles down to vanilla HTML rather than web components, effectively turning it into a kickass template engine that can come alive. I love the way you can very effectively still do progressive enhancement by using completely semantic markup and then letting hydration do more to it.
I also hate React. I hate React because these behaviours are not defaults. React is not gonna warn you if you make a form using divs and unlabelled textboxes and send the whole thing to a server. I hate React because CSS-in-JS approaches by default encourage you to write completely self contained one off components rather than trying to build a website UI up as a whole. I hate the way server side rendering and progressive enhancement are not defaults, but rather things you have to go out of your way to do.
And if you want to adjust the front-end code, you’ve got to set up all this tooling just to change a
div to a
button. That’s quite a barrier to entry.
In elevating frontend to the land of Serious Code we have not just made things incredibly over-engineered but we have also set fire to all the ladders that we used to get up here in the first place.
I love React because it lets me do my best work faster and more easily. I hate React because the culture around it more than the library itself actively prevents other people from doing their best work.
Chris broke both his arms just to avoid speaking at the JAMstack conference in London. Seems a bit extreme to me.
Anyway, to make up for not being there, he made a website of his talk. It’s good stuff, tackling the split.
It’s cool to see the tech around our job evolve to the point that we can reach our arms around the whole thing. It’s worthy of some concern when we feel like complication of web technology feels like it’s raising the barrier to entry
Tuesday, July 30th, 2019