- 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?
Friday, March 2nd, 2018
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.
Monday, August 1st, 2016
Adam and I share the same hopes and frustrations with web components. They can be written in a resilient, layered way that allows for progressive enhancement, but just about every example out there demonstrates a “my way or the highway” approach to using them.
We were chatting about this in the Design Systems slack channel, and it helped clarify some of my thoughts. I’ll try to poop out a blog post about this soon.
Wednesday, July 27th, 2016
I love this back and forth between Brad and Jonathon. I think they’ve both got some good ideas:
- I agree with Brad that you can start marking up these kind of patterns before you’ve got visual designs.
- I agree with Jonathon that it’s often better to have a generic wrapper element to avoid making assumptions about which elements will be used.
Thursday, July 14th, 2016
Thursday, June 23rd, 2016
Striking that balance between the reusability of modular components and maintaining a big-picture vision of the overall design:
We should always strive to use patterns in an application. For example, consistent use of colors and font sizes can quickly indicate to the user elements in the UI that can be interacted with. However, avoid using a pattern just because it has been implemented before; rather, use it because it really solves the problem at hand.
Thursday, May 26th, 2016
Snook has been on a roll lately, sharing lots of great insights into front-end development. This is a particularly astute post about that perennial issue of naming things.
Thursday, March 10th, 2016
Enduring CSS (not int the sense of “put up with” but in the sense of “long-lasting”) is a new book by Ben Frain all about writing and maintaining modular reusable CSS.
You can read the whole thing for free online or buy an eBook.
Monday, February 8th, 2016
We tend to use a variant of BEM in our CSS at Clearleft. Glad to see that when we’ve hit these issues, we’ve taken the same approach.
Wednesday, January 6th, 2016
A really terrific article from Dan on building pattern libraries. In summary:
- Naming things is hard,
- Separation of content and presentation is A Good Thing.
There are some really good insights here into getting just the right level of abstraction for a component—not too tightly tied to a specific visual display, but also not too tightly tied to a specific kind of content type:
When thinking about patterns, content strategists are primarily thinking about Content patterns, designers are primarily thinking about Display patterns, and front-end developers are responsible for bringing the two together.
(And it’s great to see Charlotte’s excellent article get a shout-out in the “Related reading” section at the end,)