Here’s the website for Alla’s forthcoming book. You can sign up to a low-volume mailing list to get notified of updates.
Alla’s book is going to be a must-have (I know because I’ve been reviewing it as she’s been writing it). Pre-order it now. It’s out in September.
Dave muses on the challenges of maintaining a pattern library:
- Rolling out a Pattern Library is infinitely harder than building one.
- If you don’t have pages, it’s doesn’t solve the problem.
- Vertical spacing will make or break you.
- The Pattern Library is dead if it’s not prioritized.
This is a really intriguing book that combines design theory and programming—learn about contrast, colour, and shapes, with each lesson supported by code examples.
It’s still a work in progress but the whole thing is online for free. Yay for web books!
Another instance of Fractal in the wild, this time for the Federalist design system.
- It’s open source.
- It’s easy to use.
- It generates standalone HTML previews of each component.
- It uses or supports many of the technologies we use already.
- Fractal offers a customizable theme engine.
I’m not sure the particular use-case outlined here is going to apply much outside of AirBnB (just because the direction of code-to-Sketch feels inverted from most processes) but the underlying idea of treating visual design assets and code as two manifestations of the same process …that’s very powerful.
A look at the history of design systems and how they differ from pattern libraries. Or, to put it another way, a pattern library is one part of a design system.
Design-system builders should resist the lure of the new. Don’t confuse design-system work with a rebrand or a tech-stack overhaul. The system’s design patterns should be familiar, even boring.
The job is not to invent, but to curate.
Interesting thoughts from Josh on large-scale design systems and how they should prioritise the mundane but oft-used patterns.
When the design system is boring, it frees designers and developers to do the new stuff, to solve new problems. The design system carries the burden of the boring, so that designers and developers don’t have to.
Paul finishes up his excellent three part series by getting down to the brass tacks of designing and building components on the web …and in cities. His closing provocation has echoes of Heydon’s rallying cry.
If you missed the other parts of this series, they are:
Dan describes his approach to maintainable CSS. It’s a nice balance between semantic naming and reusable styles.
Warning: the analogies used here might make you very, very hungry.
Philip Ball certainly has a way with words.
Paul is turning his excellent talk on design systems into a three part series. Here’s part one, looking at urban planning from Brasília to London.
Ethan has been thinking smarty-thinky thoughts about patterns and pattern libraries.
Gall’s Fundamental Theorem of Systems is that new systems mean new problems. I think the same can safely be said of code—more code, more problems. Do it without a new system if you can
A cautionary tale of the risks involved with embracing new frameworks.
But when you introduce a new system, you introduce new variables, new failure points, and new problems.
…almost anything is easier to get into than out of.
A ten-year old paper that looks at the history of the ARAPNET and internet to see how they dealt with necessary changes.
Changing a large network is very difficult. It is much easier to deploy a novel new protocol that fills a void than it is to replace an existing protocol that more or less works.
Here’s an epic brain dump by Vitaly on the challenges of putting together a pattern library and then maintaining it.
Sacrificing consistency for usability is fine. A slightly open-ended, inconsistent but heavily used pattern library is better than a perfectly consistent pattern library that is never used.
Dan has been researching the history of design systems, annotating as he goes.
A newsletter dedicated to all things related to design systems, style guides, and pattern libraries.