Cassie’s redesign is gorgeous—so much attention to detail! (And performant too)
Thursday, June 25th, 2020
Friday, June 19th, 2020
What I love about the web is that it’s a hypertext. (Though in recent years it has mostly been used as a janky app delivery platform.)
I am very much enjoying Matt’s thoughts on linking, quoting, transclusion, and associative trails.
My blog is my laboratory workbench where I go through the ideas and paragraphs I’ve picked up along my way, and I twist them and turn them and I see if they fit together. I do that by narrating my way between them. And if they do fit, I try to add another piece, and then another. Writing a post is a process of experimental construction.
And then I follow the trail, and see where it takes me.
Saturday, June 13th, 2020
This looks like a nifty tool for blogs:
Quotebacks is a tool that makes it easy to grab snippets of text from around the web and convert them into embeddable blockquote web components.
Friday, June 12th, 2020
Congratulations and kudos to Phil for twenty years of blogging!
Here he describes what it was like online in the year 2000. Yes, it was very different to today, but…
Anyone who thinks blogging died at some point in the past twenty years presumably just lost interest themselves, because there have always been plenty of blogs to read. Some slow down, some die, new ones appear. It’s as easy as it’s ever been to write and read blogs.
Though Phil does note:
Some of the posts I read were very personal in a way that’s less common now, in general. … Even “personal” websites (like mine) often have an awareness about them, about what’s being shared, the impression it gives to strangers, presenting a public face, maybe a feeling of, “I’m just writing personal nonsense but, why, yes, I am available for hire”.
Maybe that’s why I’m enjoying Robin’s writing so much.
Wednesday, June 3rd, 2020
Personal website owners – what do you think about collecting all of the feeds you are producing in one way or the other on a
Sounds like a good idea! I’ll get on that.
Tuesday, May 26th, 2020
You see, diversity of rendering engines isn’t actually in itself the point. What’s really important is diversity of influence: who has the ability to make decisions which shape the web in particular ways, and do they make those decisions for good reasons or not so good?
Wednesday, April 1st, 2020
A group blog by a whole bunch of people who are staying at home.
It’s hard to believe, but there was a time where the internet was just full of casual websites posting random stuff. And you’d go to them maybe even multiple times a day to see if they had posted any new stories. It was something we all did when we were bored at our desks, at our jobs. Now there are no more desks. But there are still blogs.
Friday, March 27th, 2020
I find myself thinking about writing more than usual at the moment. This is partially because I am inspired by more people sharing their own thoughts and stories, but also because I want to record how I’m feeling, and what’s happening on a day-to-day basis.
Thursday, March 26th, 2020
This is my favourite website now.
Tuesday, March 24th, 2020
RSS: now more than ever!
You get to choose what you subscribe to in your feed reader, and the order in which the posts show up. You might prefer to read the oldest posts first, or the newest. You might group your feeds by topic or another priority. You are not subjected to the “algorithmic feed” of Facebook, Twitter, Instagram, YouTube, where they choose the order for you.
Monday, March 23rd, 2020
We’re all hunkering down in our homes. That seems to be true of our online homes too.
People are sharing their day-to-day realities on their websites and I’m here for it. Like, I’m literally here for it. I can’t go anywhere.
On an episode of the Design Observer podcast, Jessica Helfand puts this into context:
During times of crisis, people want to make things. There’s a surge in the keeping of journals when there’s a war… it’s a response to the feeling of vulnerability, like corporeal vulnerability. My life is under attack. I am imprisoned in my house. I have to make something to say I was here, to say I mattered, to say this day happened… It’s like visual graphic reassurance.
It’s not just about crisis though. Scott Kelly talks about the value of keeping a journal during prolonged periods of repitition. And he should know—he spent a year in space:
NASA has been studying the effects of isolation on humans for decades, and one surprising finding they have made is the value of keeping a journal. Throughout my yearlong mission, I took the time to write about my experiences almost every day. If you find yourself just chronicling the days’ events (which, under the circumstances, might get repetitive) instead try describing what you are experiencing through your five senses or write about memories. Even if you don’t wind up writing a book based on your journal like I did, writing about your days will help put your experiences in perspective and let you look back later on what this unique time in history has meant.
That said, just stringing a coherent sentence together can seem like too much during The Situation. That’s okay. Your online home can also provide relief and distraction through tidying up. As Ethan puts it:
let a website be a worry stone
It can be comforting to get into the zone doing housekeeping on your website. How about a bit of a performance audit? Or maybe look into more fluid typography? Or perhaps now is the time to tinker about with that dark mode you’ve been planning?
Whatever you end up doing, my point is that your website is quite literally an outlet. While you’re stuck inside, your website is not just a place you can go to, it’s a place you can control, a place you can maintain, a place you can tidy up, a place you can expand. Most of all, it’s a place you can lose yourself in, even if it’s just for a little while.
Wednesday, March 18th, 2020
Cameron’s blog is back, and very nicely redesigned/aligned it is too!
Wednesday, February 5th, 2020
Design systems roundup
When I started writing a post about architects, gardeners, and design systems, it was going to be a quick follow-up to my post about web standards, dictionaries, and design systems. I had spotted an interesting metaphor in one of Frank’s posts, and I thought it was worth jotting it down.
But after making that connection, I kept writing. I wanted to point out the fetishism we have for creation over curation; building over maintenance.
Then the post took a bit of a dark turn. I wrote about how the most commonly cited reasons for creating a design system—efficiency and consistency—are the same processes that have led to automation and dehumanisation in the past.
That’s where I left things. Others have picked up the baton.
Dave wrote a post called The Web is Industrialized and I helped industrialize it. What I said resonated with him:
This kills me, but it’s true. We’ve industrialized design and are relegated to squeezing efficiencies out of it through our design systems. All CSS changes must now have a business value and user story ticket attached to it. We operate more like Taylor and his stopwatch and Gantt and his charts, maximizing effort and impact rather than focusing on the human aspects of product development.
But he also points out the many benefits of systemetising:
At the same time, I have seen first hand how design systems can yield improvements in accessibility, performance, and shared knowledge across a willing team. I’ve seen them illuminate problems in design and code. I’ve seen them speed up design and development allowing teams to build, share, and validate prototypes or A/B tests before undergoing costly guesswork in production. There’s value in these tools, these processes.
Emphasis mine. I think that’s a key phrase: “a willing team.”
A design system that optimizes for consistency relies on compliance: specifically, the people using the system have to comply with the system’s rules, in order to deliver on that promised consistency. And this is why that, as a way of doing something, a design system can be pretty dehumanizing.
But a design system need not be a constraining straitjacket—a means of enforcing consistency by keeping creators from colouring outside the lines. Used well, a design system can be a tool to give creators more freedom:
Does the system you work with allow you to control the process of your work, to make situational decisions? Or is it simply a set of rules you have to follow?
I definitely share Jeremy’s concern, but also think it’s important to stress that this isn’t an intrinsic issue with design systems, but rather the organizational culture that exists or gets built up around the design system. There’s a big difference between having smart, reusable patterns at your disposal and creating a dictatorial culture designed to enforce conformity and swat down anyone coloring outside the lines.
Brad makes a very apt comparison with Agile:
Not Agile the idea, but the actual Agile reality so many have to suffer through.
Agile can be a liberating empowering process, when done well. But all too often it’s a quagmire of requirements, burn rates, and story points. We need to make sure that design systems don’t suffer the same fate.
Jeremy’s thoughts on industrialization definitely struck a nerve. Sure, design systems have the ability to dehumanize and that’s something to actively watch out for. But I’d also say to pay close attention to the processes and organizational culture we take part in and contribute to.
Matthew Ström weighed in with a beautifully-written piece called Breaking looms. He provides historical context to the question of automation by relaying the story of the Luddite uprising. Automation may indeed be inevitable, according to his post, but he also provides advice on how to approach design systems today:
We can create ethical systems based in detailed user research. We can insist on environmental impact statements, diversity and inclusion initiatives, and human rights reports. We can write design principles, document dark patterns, and educate our colleagues about accessibility.
Care applies to the built environment, and especially to digital technology, as social media becomes the weather and the tools we create determine the expectations of work to be done and the economic value of the people who use those tools. A well-made design system created for the right reasons is reparative. One created for the wrong reasons becomes a weapon for displacement. Tools are always beholden to values. This is well-trodden territory.
Well-trodden territory indeed. Back in 2015, Travis Gertz wrote about Design Machines:
Designing better systems and treating our content with respect are two wonderful ideals to strive for, but they can’t happen without institutional change. If we want to design with more expression and variation, we need to change how we work together, build design teams, and forge our tools.
Design systems are certainly a new way of thinking about product development, and introduce a different set of tools to the design process, but design systems are not going to lessen the need for designers. They will instead increase the number of products that can be created, and hence increase the demand for designers.
And in 2019, Kaelig wrote:
In order to be fulfilled at work, Marx wrote that workers need “to see themselves in the objects they have created”.
When “improving productivity”, design systems tooling must be mindful of not turning their users’ craft into commodities, alienating them, like cogs in a machine.
All of this is reminding me of Kranzberg’s first law:
Technology is neither good nor bad; nor is it neutral.
I worry that sometimes the messaging around design systems paints them as an inherently positive thing. But design systems won’t fix your problems:
Just stay away from folks who try to convince you that having a design system alone will solve something.
It’s just the beginning.
At the same time, a design system need not be the gateway drug to some kind of post-singularity future where our jobs have been automated away.
As always, it depends.
Remember what Frank said:
A well-made design system created for the right reasons is reparative. One created for the wrong reasons becomes a weapon for displacement.
The reasons for creating a design system matter. Those reasons will probably reflect the values of the company creating the system. At the level of reasons and values, we’ve gone beyond the bounds of the hyperobject of design systems. We’re dealing in the area of design ops—the whys of systemising design.
This is why I’m so wary of selling the benefits of design systems in terms of consistency and efficiency. Those are obviously tempting money-saving benefits, but followed to their conclusion, they lead down the dark path of enforced compliance and eventually, automation.
But if the reason you create a design system is to empower people to be more creative, then say that loud and proud! I know that creativity, autonomy and empowerment is a tougher package to sell than consistency and efficiency, but I think it’s a battle worth fighting.
Design systems are neither good nor bad (nor are they neutral).
Addendum: I’d just like to say how invigorating it’s been to read the responses from Dave, Ethan, Brad, Matthew, and Frank …all of them writing on their own websites. Rumours of the demise of blogging may have been greatly exaggerated.
Sunday, January 19th, 2020
A Cataloged Archive of Information Relating to the Now Closed Mystery Flesh Pit National Park
Tuesday, December 31st, 2019
2019 in numbers
I posted to adactio.com 1,600 times in 2019:
In amongst those notes were:
If you like, you can watch all that activity plotted on a map.
Away from this website in 2019:
Monday, December 30th, 2019
Words I wrote in 2019
Here are eight posts from during the year that I think are a good representative sample. I like how these turned out.
- Timelines of the web. The World Wide Web is a mashup.
- Dev perception. The perceived state of front-end development tools and technologies might be quite different from the reality.
- Split. Materials and tools; client and server; declarative and imperative; inclusion and privilege.
- A song of AIs and fire. Game of Thrones spoilers ahoy.
- Trad time. From the west coast of Clare to the World Wide Web.
- Passenger’s log, Queen Mary 2, August 2019. The inaugural Dance The Atlantic crossing from Southampton to New York.
- Mental models. Back-end development isn’t the same as front-end development.
- Rams. A most unusual encounter in Frankfurt.
I hope that I’ll write as many blog posts in 2020.
I’m pretty sure that I will also continue to refer to them as blog posts, not blogs. I may be the last holdout of this nomenclature in 2020. I never planned to die on this hill, but here we are.
Actually, seeing as this is technically my journal rather than my blog, I’ll just call them journal entries.
Here’s to another year of journal entries.
Monday, December 16th, 2019
Liveblogging An Event Apart 2019
I managed to do a bit of liveblogging during the event. Combined with the liveblogging I did during the other two Events Apart that I attended this year—Seattle and Chicago—that makes a grand total of seventeen liveblogged presentations!
- Slow Design for an Anxious World by Jeffrey Zeldman
- Designing for Trust in an Uncertain World by Margot Bloomstein
- Designing for Personalities by Sarah Parmenter
- Generation Style by Eric Meyer
- Making Things Better: Redefining the Technical Possibilities of CSS by Rachel Andrew
- Designing Intrinsic Layouts by Jen Simmons
- How to Think Like a Front-End Developer by Chris Coyier
- From Ideation to Iteration: Design Thinking for Work and for Life by Una Kravets
- Move Fast and Don’t Break Things by Scott Jehl
- Mobile Planet by Luke Wroblewski
- Unsolved Problems by Beth Dean
- Making Research Count by Cyd Harrell
- Voice User Interface Design by Cheryl Platz
- Web Forms: Now You See Them, Now You Don’t! by Jason Grigsby
- The Weight of the WWWorld is Up to Us by Patty Toland
- The Mythology of Design Systems by Mina Markham
- The Technical Side of Design Systems by Brad Frost
For my part, I gave my talk on Going Offline. Time to retire that talk now.
Here’s what I wrote when I first gave the talk back in March at An Event Apart Seattle:
I was quite nervous about this talk. It’s very different from my usual fare. Usually I have some big sweeping arc of history, and lots of pretentious ideas joined together into some kind of narrative arc. But this talk needed to be more straightforward and practical. I wasn’t sure how well I would manage that brief.
The dates for next year’s Events Apart have been announced, and I’ll be speaking at three of them:
The question is, do I attempt to deliver another practical code-based talk or do I go back to giving a high-level talk about ideas and principles? Or, if I really want to challenge myself, can I combine the two into one talk without making a Frankenstein’s monster?
Come and see me at An Event Apart in 2020 to find out.
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.