Monday, June 17th, 2019
This really is a most excellent introduction to React. Complete with cheat sheet!
Tuesday, June 11th, 2019
A very thoughtful post by Hidde that draws a useful distinction between the “internals” of a component (the inner workings of a React component, Vue component, or web component) and the code that wires those components together (the business logic):
I really like working on the detailed stuff that affects users: useful keyboard navigation, sensible focus management, good semantics. But I appreciate not every developer does. I have started to think this may be a helpful separation: some people work on good internals and user experience, others on code that just uses those components and deals with data and caching and solid architecture. Both are valid things, both need love. Maybe we can use the divide for good?
Thursday, May 2nd, 2019
The bait’n’switch is laid bare. First, AMP is positioned as a separate format. Then, only AMP pages are allowed ranking in the top stories carousel. Now, let’s pretend none of that ever happened and act as though AMP is just another framework. Oh, and those separate AMP pages that you made? Turns out that was all just “transitional” and you’re supposed to make your entire site in AMP now.
I would genuinely love to know how the Polymer team at Google feel about this pivot. Everything claimed in this blog post about AMP is actually true of Polymer (and other libraries of web components that don’t have the luxury of bribing developers with SEO ranking).
Some alternative facts from the introduction:
AMP isn’t another “channel” or “format” that’s somehow not the web.
Weird …because that’s exactly how it was sold to us (as a direct competitor to similar offerings from Apple and Facebook).
It’s not an SEO thing.
That it outright false. Ask any company actually using AMP why they use it.
It’s not a replacement for HTML.
And yet, the article goes on to try convince you to replace HTML with AMP.
Friday, April 26th, 2019
I think the situation that Remy outlines here is quite common (in client-rehydrated server-rendered pages), but what’s less common is Remy’s questioning and iteration.
So I now have a simple rule of thumb: if there’s an onClick, there’s got to be an anchor around the component.
Wednesday, April 24th, 2019
Chris ponders the motivations behind companies sharing their design systems publicly. Personally, I’ve always seen it as a nice way of sharing work and saying “here’s what worked for us” without necessarily saying that anyone else should use the same system.
That said, I think Chris makes a good poin here:
My parting advice is actually to the makers of public design systems: clearly identify who this design system is for and what they are able to do with it.
Tuesday, April 16th, 2019
Wednesday, April 10th, 2019
Wouldn’t it be great if every component in your design system had accessibility acceptance criteria? Paul has some good advice for putting those together:
- Start with accessibility needs
- Don’t be too generic
- Don’t define the solution
- Iterate criteria
document.querySelectorfirst got wide browser support and started to end jQuery’s ubiquity? It finally gave us a way to do natively what jQuery had been providing for years: easy selection of DOM elements. I believe the same is about to happen to frontend frameworks like Angular and React.
The article goes on to give a good technical overview of custom elements, templates, and the Shadow DOM, but I was surprised to see it making reference to the
is syntax for extending existing HTML elements—I’m pretty sure that that is, sadly, dead in the water.
Thursday, April 4th, 2019
This is a really nice write-up of creating an accessible progressive disclosure widget (a show/hide toggle).
Where it gets really interesting is when Andy shows how it could all be encapsulated into a web component with a progressive enhancement mindset
Friday, March 15th, 2019
A few common gotchas when using BEM, and how to deal with them.
Saturday, February 23rd, 2019
Monday, January 14th, 2019
Jonathan shares his notes on that great flexbox container queries article from Heydon that I linked to.
Sunday, January 13th, 2019
Er …I think Heydon might’ve cracked it. And by “it”, I mean container queries.
This is some seriously clever thinking involving CSS custom properties,
calc, and flexbox. The end result is a component that can respond to its container …and nary a media query in sight!
Wednesday, January 9th, 2019
Saturday, December 29th, 2018
Friday, December 14th, 2018
A starter list of Fractal examples and links. You can expand it.
Saturday, November 10th, 2018
A great selection of links about design systems, collected and categorised.
Sunday, November 4th, 2018
You could create components that strike the perfect balance between reuse and context sensitivity. But defining the components of your design system is just the first step. It has to make its way into the product. If it doesn’t, a design system is like a language with no extant literature or seminal texts.
Marissa Christy outlines the reasons why your design system might struggle:
- The redesign isn’t prioritized
- The tech stack is changing
- Maintenance takes discipline
But she also offers advice for counteracting these forces:
- Get buy-in from the whole team
- Prioritize a lightweight re-skin on older parts of the product
- Treat a design system like any other product project: start small
- Don’t wait for others. Lead by example.
- Finally, don’t compare yourself to others on the internet
Monday, October 8th, 2018
The hits keep on comin’ from Clearleft. This time, it’s Danielle with an absolutely brilliant and thoughtful piece on the perils of gaps and overlaps in pattern libraries, design systems and organisations.
This is such a revealing lens to view these things through! Once you’re introduced to it, it’s hard to “un-see” problems in terms of gaps and overlaps in categorisation. And even once the problems are visible, you still need to solve them in the right way:
Recognising the gaps and overlaps is only half the battle. If we apply tools to a people problem, we will only end up moving the problem somewhere else.
Some issues can be solved with better tools or better processes. In most of our workplaces, we tend to reach for tools and processes by default, because they feel easier to implement. But as often as not, it’s not a technology problem. It’s a people problem. And the solution actually involves communication skills, or effective dialogue.
That last part dovetails nicely with Jerlyn’s equally great piece.