Friday, September 28th, 2018
Tuesday, September 4th, 2018
I’m going through a pattern library right now, and this rings true:
I’m of the opinion that all cards in a Card UI are destined to become baby webpages. Just like modals. Baby hero units with baby titles and baby body text and baby dropdown menu of actions and baby call to action bars, etc.
In some ways this outcome is the opposite of what you were intending. You wanted a Card UI where everything was simple and uniform, but what you end up with is a CSS gallery website filled with baby websites.
Tuesday, August 21st, 2018
In defence of the cascade (especially now that we’ve got CSS custom properties).
I think embracing CSS’s cascade can be a great way to encourage consistency and simplicity in UIs. Rather than every new component being a free for all, it trains both designers and developers to think in terms of aligning with and re-using what they already have.
Remember, every time you set a property in CSS you are in fact overriding something (even if it’s just the default user agent styles). In other words, CSS code is mostly expressing exceptions to a default design.
Tuesday, July 10th, 2018
A good explanation of web components, complete with some code examples.
Web Components are not a single technology. Instead, they are series of browser standards defined by the W3C allowing developers to build components in a way the browser can natively understand. These standards include:
- HTML Templates and Slots – Reusable HTML markup with entry points for user-specific markup
- Shadow DOM – DOM encapsulation for markup and styles
- Custom Elements – Defining named custom HTML elements with specific behaviour
Rachel goes into detail on how she uses pattern libraries—built with Fractal to build interfaces. I know it sounds like we paid her to say all the nice things about Fractal, but honestly, we didn’t even know she was writing this article!
After discovering Fractal two years ago, we have moved every new project — large and small — into Fractal.
Wednesday, May 23rd, 2018
Monday, May 7th, 2018
Ethan emphasises the importance of making a shared language the heart of any design system. I heartily agree!
This isn’t new thinking, mind: folks like Alla Kholmatova and Charlotte Jackson have been talking about this for ages. (And in doing so, they’ve massively influenced how I think about modular, pattern-driven design.)
Talking about scaling design can get very confusing very quickly. There are a bunch of terms that get thrown around: design systems, pattern libraries, style guides, and components.
The generally-accepted definition of a design system is that it’s the outer circle—it encompasses pattern libraries, style guides, and any other artefacts. But there’s something more. Just because you have a collection of design patterns doesn’t mean you have a design system. A system is a framework. It’s a rulebook. It’s what tells you how those patterns work together.
This is something that Cennydd mentioned recently:
Here’s my thing with the modularisation trend in design: where’s the gestalt?
In my mind, the design system is the gestalt. But Cennydd is absolutely right to express concern—I think a lot of people are collecting patterns and calling the resulting collection a design system. No. That’s a pattern library. You still need to have a framework for how to use those patterns.
I understand the urge to fixate on patterns. They’re small enough to be manageable, and they’re tangible—here’s a carousel; here’s a date-picker. But a design system is big and intangible.
Games are great examples of design systems. They’re frameworks. A game is a collection of rules and constraints. You can document those rules and constraints, but you can’t point to something and say, “That is football” or “That is chess” or “That is poker.”
Even though they consist entirely of rules and constraints, football, chess, and poker still produce an almost infinite possibility space. That’s quite overwhelming. So it’s easier for us to grasp instances of football, chess, and poker. We can point to a particular occurrence and say, “That is a game of football”, or “That is a chess match.”
But if you tried to figure out the rules of football, chess, or poker just from watching one particular instance of the game, you’d have your work cut for you. It’s not impossible, but it is challenging.
Likewise, it’s not very useful to create a library of patterns without providing any framework for using those patterns.
I would go so far as to say that the actual code for the patterns is the least important part of a design system (or, certainly, it’s the part that should be most malleable and open to change). It’s more important that the patterns have been identified, named, described, and crucially, accompanied by some kind of guidance on usage.
I could easily imagine using a tool like Fractal to create a library of text snippets with no actual code. Those pieces of text—which provide information on where and when to use a pattern—could be more valuable than providing a snippet of code without any context.
One of the very first large-scale pattern libraries I can remember seeing on the web was Yahoo’s Design Pattern Library. Each pattern outlined
- the problem being solved;
- when to use this pattern;
- when not to use this pattern.
Only then, almost incidentally, did they link off to the code for that pattern. But it was entirely possible to use the system of patterns without ever using that code. The code was just one instance of the pattern. The important part was the framework that helped you understand when and where it was appropriate to use that pattern.
I think we lose sight of the real value of a design system when we focus too much on the components. The components are the trees. The design system is the forest. As Paul asked:
What methodologies might we uncover if we were to focus more on the relationships between components, rather than the components themselves?
Friday, March 2nd, 2018
- What problems will a component library solve?
- Is everyone on the project behind the component library?
- How will the component library be used?
- What tool(s) will be used to build the component library?
- Where should the component library live?
- How granular should the library be? How should it be organized?
- How will component code be scoped? What about page layout?
- What data will the library use? What else should it have?
Monday, January 22nd, 2018
I’m on Team Dave.
Thursday, June 1st, 2017
Friday, April 28th, 2017
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.
Thursday, March 2nd, 2017
Unsurprisingly, I completely and utterly agree with Ethan’s assessment here:
I’ve written some code that’s saying, “Once the screen is this size and the element appears in a different, smaller container, use a narrower layout on this element.”
But, well, that’s weird. Why can’t we apply styles based on the space available to the module we’re designing, rather than looking at the shape of the viewport?
I also share his frustration with the “math is hard; let’s go shopping” response from browser vendors:
There’s an incredible clamor for container queries, with folks from every corner of the responsive community asking for something that solves this problem. So personally, I’d love to see at least one browser vendor partner with the RICG, and get properly fired up about this.
We had to drag browser makers kicking and screaming to responsive images (to this day, Hixie maintains it’s not a problem that needs solving) and I suspect even more activism is going to be needed to get them to tackle container queries.
Wednesday, March 1st, 2017
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.
Sunday, January 29th, 2017
promises address?” but that is then addressed further down:
Fair enough. In any case, what you’ll find here is mainly good advice for writing modular code.
Monday, October 31st, 2016
Adam Silver has written a free online book all about writing maintainable CSS. It dives straight into naming things and takes it from there.
MaintainableCSS is an approach to writing modular, scalable and of course, maintainable CSS.
Monday, October 10th, 2016
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.
Wednesday, October 5th, 2016
Monday, September 12th, 2016
This slide deck is a whistle-stop tour of all things styleguide and pattern-library related. Nice to see Charlotte’s excellent exercise get a shout-out.
Monday, August 8th, 2016
Dan has been researching the history of design systems, annotating as he goes.