Some sensible answers to this question here…
…of which, exactly zero mention end users.
Some sensible answers to this question here…
…of which, exactly zero mention end users.
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.
I know I’m biased because I work with Jerlyn, but I think this in-depth piece by her is really something! She suveys the design system landscape and proposes some lo-fi governance ideas based around good old-fashioned dialogue.
Developing a design system takes collaboration between the makers of the design systems and the different users of the system. It’s a continual process that doesn’t have to require a huge investment in new departments or massive restructuring.
It can start small.
Fuck yeah, libraries!
Even more radically, your time at the library comes with absolutely no expectation that you buy anything. Or even that you transact at all. And there’s certainly no implication that your data or your rights are being surrendered in return for the services you partake in.
This rare openness and neutrality imbues libraries with a distinct sense of community, of us, of everyone having come together to fund and build and participate in this collective sharing of knowledge and space. All of that seems exceedingly rare in this increasingly commercial, exposed world of ours. In a way it’s quite amazing that the concept continues to persist at all.
And when we look at it this way, as a startlingly, almost defiantly civilized institution, it seems even more urgent that we make sure it not only continues to survive, but that it should also thrive, too.
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.
Just last week I came across an example of what Ethan describes here: accessibility (in a pattern library) left to automatic checks rather than human experience.
Scores of people who just want to deliver their content and have it look vaguely nice are convinced you need every web technology under the sun to deliver text.
This is very lawnoffgetting but I can relate.
I made my first website about 20 years ago and it delivered as much content as most websites today. It was more accessible, ran faster and easier to develop then 90% of the stuff you’ll read on here.
20 years later I browse the Internet with a few tabs open and I have somehow downloaded many megabytes of data, my laptop is on fire and yet in terms of actual content delivery nothing has really changed.
The beauty of this approach is that the site doesn’t ever appear broken and the user won’t even be aware that they are getting the ‘default’ experience. With progressive enhancement, every user has their own experience of the site, rather than an experience that the designers and developers demand of them.
A case study in applying progressive enhancement to all aspects of a site.
I think we often focus on designing or building an element, without researching the other elements it should connect to—without understanding the system it lives in.
We decided to ask the Fractal community for help, and the response has been overwhelming. We’ve received so many offers of support in all forms that we can safely say that development will be starting up again shortly.
Although Fractal itself is barely two years old, it’s part of a much longer legacy at Clearleft…
It all started with Natalie. She gave a presentation back in 2009 called Practical Maintainable CSS . She talks about something called a pattern porfolio—a deliverable that expresses every component and documents how the markup and CSS should be used.
When Anna was interning at Clearleft, she was paired up with Natalie so she was being exposed to these ideas. She then expanded on them, talking about Front-end Style Guides. She literally wrote the book on the topic, and starting curating the fantastic collection of examples at styleguides.io.
At Clearleft, rather than deliver an inflexible set of static pages, we present our code as a series of modular components (a ‘pattern portfolio’) that can be assembled into different configurations and page layouts as required.
Such systematic thinking was instigated by Natalie, yet this is something we continually iterate upon.
To see the evolution of Paul’s thinking, you can read his three part series from last year on designing systems:
Later, Charlotte joined Clearleft as a junior developer, and up until that point, hadn’t been exposed to the idea of pattern libraries or design systems. But it soon became clear that she had found her calling. She wrote a brilliant article for A List Apart called From Pages to Patterns: An Exercise for Everyone and she started speaking about design systems at conferences like Beyond Tellerrand. Here, she acknowledges the changing terminology over the years:
Pattern portfolio is a term used by Natalie Downe when she started using the technique at Clearleft back in 2009.
Front-end style guides is another term I’ve heard a lot.
Personally, I don’t think it matters what you call your system as long as it’s appropriate to the project and everyone uses it. Today I’m going to use the term “pattern library”.
(Mark was always a fan of the term “component library”.)
Now Charlotte is a product manager at Ansarada in Sydney and the product she manages is …the design system!
Thinking back to my work on starting design systems, I didn’t realise straight away that I was working on a product. Yet, the questions we ask are similar to those we ask of any product when we start out. We make decisions on things like: design, architecture, tooling, user experience, code, releases, consumption, communication, and more.
It’s been fascinating to watch the evolution of design systems at Clearleft, accompanied by an evolution in language: pattern portfolios; front-end style guides; pattern libraries; design systems.
There’s been a corresponding evolution in prioritisation. Where Natalie was using pattern portfolios as a deliverable for handover, Danielle is now involved in the integration of design systems within a client’s team. The focus on efficiency and consistency that Natalie began is now expressed in terms of design ops—creating living systems that everyone is involved in.
When I step back and look at the history of design systems on the web, there are some obvious names that have really driven their evolution and adoption, like Jina Anne, Brad Frost, and Alla Kholmatova. But I’m amazed at the amount of people who have been through Clearleft’s doors that have contributed so, so much to this field:
It’s possible to create components in a vacuum, but ultimately you have no idea whether or not those components can successfully address your user and business needs. I’ve witnessed firsthand several design system initiatives crash and burn due to components created in isolation.
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.
I’ve come to believe that the goal of any good framework should be to make itself unnecessary.
The ultimate purpose of PhoneGap is to cease to exist.
That makes total sense, especially if your code is a polyfill—those solutions are temporary by design. Autoprefixer is another good example of a piece of code that becomes less and less necessary over time.
But I think it’s equally true of any successful framework or library. If the framework becomes popular enough, it will inevitably end up influencing the standards process, thereby becoming dispensible.
querySelector without jQuery. The library proved the need for the feature. The same is true for a whole load of DOM scripting features.
The same process is almost certain to occur with React—it’s a good bet there will be a standardised equivalent to the virtual DOM at some point.
When Google first unveiled AMP, its intentions weren’t clear to me. I hoped that it existed purely to make itself redundant:
As well as publishers creating AMP versions of their pages in order to appease Google, perhaps they will start to ask “Why can’t our regular pages be this fast?” By showing that there is life beyond big bloated invasive web pages, perhaps the AMP project will work as a demo of what the whole web could be.
Alas, as time has passed, that hope shows no signs of being fulfilled. If anything, I’ve noticed publishers using the existence of their AMP pages as a justification for just letting their “regular” pages put on weight.
Worse yet, the messaging from Google around AMP has shifted. Instead of pitching it as a format for creating parallel versions of your web pages, they’re now also extolling the virtues of having your AMP pages be the only version you publish:
In fact, AMP’s evolution has made it a viable solution to build entire websites.
On an episode of the Dev Mode podcast a while back, AMP was a hotly-debated topic. But even those defending AMP were doing so on the understanding that it was more a proof-of-concept than a long-term solution (and also that AMP is just for news stories—something else that Google are keen to change).
But now it’s clear that the Google AMP Project is being marketed more like a framework for the future: a collection of web components that prioritise performance …which is kind of odd, because that’s also what Google’s Polymer project is. The difference being that pages made with Polymer don’t get preferential treatment in Google’s search results. I can’t help but wonder how the Polymer team feels about AMP’s gradual pivot onto their territory.
If the AMP project existed in order to create a web where AMP was no longer needed, I think I could get behind it. But the more it’s positioned as the only viable solution to solving performance, the more uncomfortable I am with it.
Which, by the way, brings me to one of the most pernicious ideas around Google AMP—positioning anyone opposed to it as not caring about web performance. Nothing could be further from the truth. It’s precisely because performance on the web is so important that it deserves a long-term solution, co-created by all of us: not some commandents delivered to us from on-high by one organisation, enforced by preferential treatment by that organisation’s monopoly in search.
It’s the classic logical fallacy:
By marketing itself as the only viable solution to the web performance problem, I think the AMP project is doing itself a great disservice. If it positioned itself as an example to be emulated, I would welcome it.
I wish that AMP were being marketed more like a temporary polyfill. And as with any polyfill, I look forward to the day when AMP is no longer necesssary.
I want AMP to become extinct. I genuinely think that the Google AMP team should share that wish.
In my experience, there’s no casual mode within React. You need to be all-in, keeping up with the ecosystem, or else your knowledge evaporates.
I think Dave is right. At this point, it’s possible to be a React developer exclusively.
React is an ecosystem. I feel like it’s a disservice to anyone trying to learn to diminish all that React entails. React shows up on the scene with Babel, Webpack, and JSX (which each have their own learning curve) then quickly branches out into technologies like Redux, React-Router, Immutable.js, Axios, Jest, Next.js, Create-React-App, GraphQL, and whatever weird plugin you need for your app.
And, as Jake points out, you either need to go all in or not at all—you can’t really incrementally add Reactness to an existing project.
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.)
A terrific talk by Adrian Holovaty. I really hope front-end developers talk its message to heart.
The canonical example in just about every pattern library is documenting button variations. Here, Tyler shows how even this seemingly simple pattern takes a lot of thought.
Wise words from Ethan on how to react when people create bespoke patterns instead of using something in an existing pattern library.
It’s easy for an organization to look at that one-off pattern as a problem of compliance, of not following the established rules. And in many cases, that might be true! But it’s also worth recognizing when a variation’s teaching you a lesson: namely, that your design system isn’t meeting the needs of the people who’re using it.
Another brilliant talk from Frank, this time on the (im)balance between the commercial and the cultural web.
Remember: the web is a marketplace and a commonwealth, so we have both commerce and culture; it’s just that the non-commercial bits of the web get more difficult to see in comparison to the outsized presence of the commercial web and all that caters to it.
This really resonates with me:
If commercial networks on the web measure success by reach and profit, cultural endeavors need to see their successes in terms of resonance and significance.
Harsh (but fair) assessment of the performance costs of doing everything on the client side.