Journal tags: libraries

21

sparkline

Suspicion

I’ve already had some thoughtful responses to yesterday’s post about trust. I wrapped up my thoughts with a request:

I would love it if someone could explain why they avoid native browser features but use third-party code.

Chris obliged:

I can’t speak for the industry, but I have a guess. Third-party code (like the referenced Bootstrap and React) have a history of smoothing over significant cross-browser issues and providing better-than-browser ergonomic APIs. jQuery was created to smooth over cross-browser JavaScript problems. That’s trust.

Very true! jQuery is the canonical example of a library smoothing over the bumpy landscape of browser compatibilities. But jQuery is also the canonical example of a library we no longer need because the browsers have caught up …and those browsers support standards directly influenced by jQuery. That’s a library success story!

Charles Harries takes on my question in his post Libraries over browser features:

I think this perspective of trust has been hammered into developers over the past maybe like 5 years of JavaScript development based almost exclusively on inequality of browser feature support. Things are looking good in 2022; but as recently as 2019, 4 of the 5 top web developer needs had to do with browser compatibility.

Browser compatibility is one of the underlying promises that libraries—especially the big ones that Jeremy references, like React and Bootstrap—make to developers.

So again, it’s browser incompatibilities that made libraries attractive.

Jim Nielsen responds with the same message in his post Trusting Browsers:

We distrust the browser because we’ve been trained to. Years of fighting browser deficiencies where libraries filled the gaps. Browser enemy; library friend.

For example: jQuery did wonders to normalize working across browsers. Write code once, run it in any browser — confidently.

Three for three. My question has been answered: people gravitated towards libraries because browsers had inconsistent implementations.

I’m deliberately using the past tense there. I think Jim is onto something when he says that we’ve been trained not to trust browsers to have parity when it comes to supporting standards. But that has changed.

Charles again:

This approach isn’t a sustainable practice, and I’m trying to do as little of it as I can. Jeremy is right to be suspicious of third-party code. Cross-browser compatibility has gotten a lot better, and campaigns like Interop 2022 are doing a lot to reduce the burden. It’s getting better, but the exasperated I-just-want-it-to-work mindset is tough to uninstall.

I agree. Inertia is a powerful force. No matter how good cross-browser compatibility gets, it’s going to take a long time for developers to shed their suspicion.

Jim is glass-half-full kind of guy:

I’m optimistic that trust in browser-native features and APIs is being restored.

He also points to a very sensible mindset when it comes to third-party libraries and frameworks:

In this sense, third-party code and abstractions can be wonderful polyfills for the web platform. The idea being that the default posture should be: leverage as much of the web platform as possible, then where there are gaps to creating great user experiences, fill them in with exploratory library or framework features (features which, conceivably, could one day become native in browsers).

Yes! A kind of progressive enhancement approach to using third-party code makes a lot of sense. I’ve always maintained that you should treat libraries and frameworks like cattle, not pets. Don’t get too attached. If the library is solving a genuine need, it will be replaced by stable web standards in browsers (again, see jQuery).

I think that third-party libraries and frameworks work best as polyfills. But the whole point of polyfills is that you only use them when the browsers don’t supply features natively (and you also go back and remove the polyfill later when browsers do support the feature). But that’s not how people are using libraries and frameworks today. Developers are reaching for them by default instead of treating them as a last resort.

I like Jim’s proposed design princple:

Where available, default to browser-native features over third party code, abstractions, or idioms.

(P.S. It’s kind of lovely to see this kind of thoughtful blog-to-blog conversation happening. Right at a time when Twitter is about to go down the tubes, this is a demonstration of an actual public square with more nuanced discussion. Make your own website and join the conversation!)

Trust

I’ve noticed a strange mindset amongst front-end/full-stack developers. At least it seems strange to me. But maybe I’m the one with the strange mindset and everyone else knows something I don’t.

It’s to do with trust and suspicion.

I’ve made no secret of the fact that I’m suspicious of third-party code and dependencies in general. Every dependency you add to a project is one more potential single point of failure. You have to trust that the strangers who wrote that code knew what they were doing. I’m still somewhat flabbergasted that developers regularly add dependencies—via npm or yarn or whatever—that then pull in even more dependencies, all while assuming good faith and competence on the part of every person involved.

It’s a touching expression of faith in your fellow humans, but I’m not keen on the idea of faith-based development.

I’m much more trusting of native browser features—HTML elements, CSS features, and JavaScript APIs. They’re not always perfect, but a lot of thought goes into their development. By the time they land in browsers, a whole lot of smart people have kicked the tyres and considered many different angles. As a bonus, I don’t need to install them. Even better, end users don’t need to install them.

And yet, the mindset I’ve noticed is that many developers are suspicious of browser features but trusting of third-party libraries.

When I write and talk about using service workers, I often come across scepticism from developers about writing the service worker code. “Is there a library I can use?” they ask. “Well, yes” I reply, “but then you’ve got to understand the library, and the time it takes you to do that could be spent understanding the native code.” So even though a library might not offer any new functionality—just a different idion—many developers are more likely to trust the third-party library than they are to trust the underlying code that the third-party library is abstracting!

Developers are more likely to trust, say, Bootstrap than they are to trust CSS grid or custom properties. Developers are more likely to trust React than they are to trust web components.

On the one hand, I get it. Bootstrap and React are very popular. That popularity speaks volumes. If lots of people use a technology, it must be a safe bet, right?

But if we’re talking about popularity, every single browser today ships with support for features like grid, custom properties, service workers and web components. No third-party framework can even come close to that install base.

And the fact that these technologies have shipped in stable browsers means they’re vetted. They’ve been through a rigourous testing phase. They’ve effectively got a seal of approval from each individual browser maker. To me, that seems like a much bigger signal of trustworthiness than the popularity of a third-party library or framework.

So I’m kind of confused by this prevalent mindset of trusting third-party code more than built-in browser features.

Is it because of the job market? When recruiters are looking for developers, their laundry list is usually third-party technologies: React, Vue, Bootstrap, etc. It’s rare to find a job ad that lists native browser technologies: flexbox, grid, service workers, web components.

I would love it if someone could explain why they avoid native browser features but use third-party code.

Until then, I shall remain perplexed.

Inertia

When I’ve spoken in the past about evaluating technology, I’ve mentioned two categories of tools for web development. I still don’t know quite what to call these categories. Internal and external? Developer-facing and user-facing?

The first category covers things like build tools, version control, transpilers, pre-processers, and linters. These are tools that live on your machine—or on the server—taking what you’ve written and transforming it into the raw materials of the web: HTML, CSS, and JavaScript.

The second category of tools are those that are made of the raw materials of the web: CSS frameworks and JavaScript libraries.

I think the criteria for evaluating these different kinds of tools should be very different.

For the first category, developer-facing tools, use whatever you want. Use whatever makes sense to you and your team. Use whatever’s effective for you.

But for the second category, user-facing tools, that attitude is harmful. If you make users download a CSS or JavaScript framework in order to benefit your workflow, then you’re making users pay a tax for your developer convenience. Instead, I firmly believe that user-facing tools should provide some direct benefit to end users.

When I’ve asked developers in the past why they’ve chosen to use a particular JavaScript framework, they’ve been able to give me plenty of good answers. But all of those answers involved the benefit to their developer workflow—efficiency, consistency, and so on. That would be absolutely fine if we were talking about the first category of tools, developer-facing tools. But those answers don’t hold up for the second category of tools, user-facing tools.

If a user-facing tool is only providing a developer benefit, is there any way to turn it into a developer-facing tool?

That’s very much the philosophy of Svelte. You can compare Svelte to other JavaScript frameworks like React and Vue but you’d be missing the most important aspect of Svelte: it is, by design, in that first category of tools—developer-facing tools:

Svelte takes a different approach from other frontend frameworks by doing as much as it can at the build step—when the code is initially compiled—rather than running client-side. In fact, if you want to get technical, Svelte isn’t really a JavaScript framework at all, as much as it is a compiler.

You install it on your machine, you write your code in Svelte, but what it spits out at the other end is HTML, CSS, and JavaScript. Unlike Vue or React, you don’t ship the library to end users.

In my opinion, this is an excellent design decision.

I know there are ways of getting React to behave more like a category one tool, but it is most definitely not the default behaviour. And default behaviour really, really matters. For React, the default behaviour is to assume all the code you write—and the tool you use to write it—will be sent over the wire to end users. For Svelte, the default behaviour is the exact opposite.

I’m sure you can find a way to get Svelte to send too much JavaScript to end users, but you’d be fighting against the grain of the tool. With React, you have to fight against the grain of the tool in order to not send too much JavaScript to end users.

But much as I love Svelte’s approach, I think it’s got its work cut out for it. It faces a formidable foe: inertia.

If you’re starting a greenfield project and you’re choosing a JavaScript framework, then Svelte is very appealing indeed. But how often do you get to start a greenfield project?

React has become so ubiquitous in the front-end development community that it’s often an unquestioned default choice for every project. It feels like enterprise software at this point. No one ever got fired for choosing React. Whether it’s appropriate or not becomes almost irrelevant. In much the same way that everyone is on Facebook because everyone is on Facebook, everyone uses React because everyone uses React.

That’s one of its biggest selling points to managers. If you’ve settled on React as your framework of choice, then hiring gets a lot easier: “If you want to work here, you need to know React.”

The same logic applies from the other side. If you’re starting out in web development, and you see that so many companies have settled on using React as their framework of choice, then it’s an absolute no-brainer: “if I want to work anywhere, I need to know React.”

This then creates a positive feedback loop. Everyone knows React because everyone is hiring React developers because everyone knows React because everyone is hiring React developers because…

At no point is there time to stop and consider if there’s a tool—like Svelte, for example—that would be less harmful for end users.

This is where I think Astro might have the edge over Svelte.

Astro has the same philosophy as Svelte. It’s a developer-facing tool by default. Have a listen to Drew’s interview with Matthew Phillips:

Astro does not add any JavaScript by default. You can add your own script tags obviously and you can do anything you can do in HTML, but by default, unlike a lot of the other component-based frameworks, we don’t actually add any JavaScript for you unless you specifically tell us to. And I think that’s one thing that we really got right early.

But crucially, unlike Svelte, Astro allows you to use the same syntax as the incumbent, React. So if you’ve learned React—because that’s what you needed to learn to get a job—you don’t have to learn a new syntax in order to use Astro.

I know you probably can’t take an existing React site and convert it to Astro with the flip of a switch, but at least there’s a clear upgrade path.

Astro reminds me of Sass. Specifically, it reminds me of the .scss syntax. You could take any CSS file, rename its file extension from .css to .scss and it was automatically a valid Sass file. You could start using Sass features incrementally. You didn’t have to rewrite all your style sheets.

Sass also has a .sass syntax. If you take a CSS file and rename it with a .sass file extension, it is not going to work. You need to rewrite all your CSS to use the .sass syntax. Some people used the .sass syntax but the overwhelming majority of people used .scss

I remember talking with Hampton about this and he confirmed the proportions. It was also the reason why one of his creations, Sass, was so popular, but another of his creations, Haml, was not, comparitively speaking—Sass is a superset of CSS but Haml is not a superset of HTML; it’s a completely different syntax.

I’m not saying that Svelte is like Haml and Astro is like Sass. But I do think that Astro has inertia on its side.

Mind the gap

In May 2012, Brian LeRoux, the creator of PhoneGap, wrote a post setting out the beliefs, goals and philosophy of the project.

The beliefs are the assumptions that inform everything else. Brian stated two core tenets:

  1. The web solved cross platform.
  2. All technology deprecates with time.

That second belief then informed one of the goals of the PhoneGap project:

The ultimate purpose of PhoneGap is to cease to exist.

Last week, PhoneGap succeeded in its goal:

Since the project’s beginning in 2008, the market has evolved and Progressive Web Apps (PWAs) now bring the power of native apps to web applications.

Today, we are announcing the end of development for PhoneGap.

I think Brian was spot-on with his belief that all technology deprecates with time. I also think it was very astute of him to tie the goals of PhoneGap to that belief. Heck, it’s even in the project name: PhoneGap!

I recently wrote this about Sass and clamp:

I’ve said it before and I’ll say it again, the goal of any good library should be to get so successful as to make itself redundant. That is, the ideas and functionality provided by the tool are so useful and widely adopted that the native technologies—HTML, CSS, and JavaScript—take their cue from those tools.

jQuery is the perfect example of this. jQuery is no longer needed because cross-browser DOM Scripting is now much easier …thanks to jQuery.

Successful libraries and frameworks point the way. They show what developers are yearning for, and that’s where web standards efforts can then focus. When a library or framework is no longer needed, that’s not something to mourn; it’s something to celebrate.

That’s particularly true if the library of code needs to be run by a web browser. The user pays a tax with that extra download so that the developer gets the benefit of the library. When web browsers no longer need the library in order to provide the same functionality, it’s a win for users.

In fact, if you’re providing a front-end library or framework, I believe you should be actively working towards making it obselete. Think of your project as a polyfill. If it’s solving a genuine need, then you should be looking forward to the day when your code is made redundant by web browsers.

One more thing…

I think it was great that Brian documented PhoneGap’s beliefs, goals and philosophy. This is exactly why design principles can be so useful—to clearly set out the priorities of a project, so that there’s no misunderstanding or mixed signals.

If you’re working on a project, take the time to ask yourself what assumptions and beliefs are underpinning the work. Then figure out how those beliefs influence what you prioritise.

Ultimately, the code you produce is the output generated by your priorities. And your priorities are driven by your purpose.

You can make those priorities tangible in the form of design principles.

You can make those design principles visible by publishing them.

The Technical Side of Design Systems by Brad Frost

Day two of An Event Apart San Francisco is finishing with a talk from Brad on design systems (so hot right now!):

You can have a killer style guide website, a great-looking Sketch library, and robust documentation, but if your design system isn’t actually powering real software products, all that effort is for naught. At the heart of a successful design system is a collection of sturdy, robust front-end components that powers other applications’ user interfaces. In this talk, Brad will cover all that’s involved in establishing a technical architecture for your design system. He’ll discuss front-end workshop environments, CSS architecture, implementing design tokens, popular libraries like React and Vue.js, deploying design systems, managing updates, and more. You’ll come away knowing how to establish a rock-solid technical foundation for your design system.

I will attempt to liveblog the Frostmeister…

“Design system” is an unfortunate name …like “athlete’s foot.” You say it to someone and they think they know what you mean, but nothing could be further from the truth.

As Mina said:

A design system is a set of rules enforced by culture, process and tooling that govern how your organization creates products.

A design system the story of how an organisation gets things done.

When Brad talks to companies, he asks “Have you got a design system?” They invariably say they do …and then point to a Sketch library. When the focus goes on the design side of the process, the production side can suffer. There’s a gap between the comp and the live site. The heart and soul of a design system is a code library of reusable UI components.

Brad’s going to talk through the life cycle of a project.

Sell

He begins with selling in a design system. That can start with an interface inventory. This surfaces visual differences. But even if you have, say, buttons that look the same, the underlying code might not be consistent. Each one of those buttons represents time and effort. A design system gives you a number of technical benefits:

  • Reduce technical debt—less frontend spaghetti code.
  • Faster production—less time coding common UI components and more time building real features.
  • Higher-quality production—bake in and enforce best practices.
  • Reduce QA efforts—centralise some QA tasks.
  • Potentially adopt new technologies faster—a design system can help make additional frameworks more managable.
  • Useful reference—an essential resource hub for development best practices.
  • Future-friendly foundation—modify, extend, and improve over time.

Once you’ve explained the benefits, it’s time to kick off.

Kick off

Brad asks “What’s yer tech stack?” There are often a lot of tech stacks. And you know what? Users don’t care. What they see is one brand. That’s the promise of a design system: a unified interface.

How do you make a design system deal with all the different tech stacks? You don’t (at least, not yet). Start with a high priority project. Use that as a pilot project for the design system. Dan talks about these projects as being like television pilots that could blossom into a full season.

Plan

Where to build the design system? The tech stack under the surface is often an order of magnitude greater than the UI code—think of node modules, for example. That’s why Brad advocates locking off that area and focusing on what he calls a frontend workshop environment. Think of the components as interactive comps. There are many tools for this frontend workshop environment: Pattern Lab, Storybook, Fractal, Basalt.

How are you going to code this? Brad gets frontend teams in a room together and they fight. Have you noticed that developers have opinions about things? Brad asks questions. What are your design principles? Do you use a CSS methodology? What tools do you use? Spaces or tabs? Then Brad gets them to create one component using the answers to those questions.

Guidelines are great but you need to enforce them. There are lots of tools to automate coding style.

Then there’s CSS architecture. Apparently we write our styles in React now. Do you really want to tie your CSS to one environment like that?

You know what’s really nice? A good ol’ sturdy cacheable CSS file. It can come in like a fairy applying all the right styles regardless of tech stack.

Design and build

Brad likes to break things down using his atomic design vocabulary. He echoes what Mina said earlier:

Embrace the snowflakes.

The idea of a design system is not to build 100% of your UI entirely from components in the code library. The majority, sure. But it’s unrealistic to expect everything to come from the design system.

When Brad puts pages together, he pulls in components from the code library but he also pulls in one-off snowflake components where needed.

The design system informs our product design. Our product design informs the design system.

—Jina

Brad has seen graveyards of design systems. But if you make a virtuous circle between the live code and the design system, the design system has a much better chance of not just surviving, but thriving.

So you go through those pilot projects, each one feeding more and more into the design system. Lather, rinse, repeat. The first one will be time consuming, but each subsequent project gets quicker and quicker as you start to get the return on investment. Velocity increases over time.

It’s like tools for a home improvement project. The first thing you do is look at your current toolkit. If you don’t have the tool you need, you invest in buying that new tool. Now that tool is part of your toolkit. Next time you need that tool, you don’t have to go out and buy one. Your toolkit grows over time.

The design system code must be intuitive for developers using it. This gets into the whole world of API design. It’s really important to get this right—naming things consistently and having predictable behaviour.

Mina talked about loose vs. strict design systems. Open vs. locked down. Make your components composable so they can adapt to future requirements.

You can bake best practices into your design system. You can make accessibility a requirement in the code.

Launch

What does it mean to “launch” a design system?

A design system isn’t a project with an end, it’s the origin story of a living and evolving product that’ll serve other products.

—Nathan Curtis

There’s a spectrum of integration—how integrated the design system is with the final output. The levels go from:

  1. Least integrated: static.
  2. Front-end reference code.
  3. Most integrated: consumable compents.

Chris Coyier in The Great Divide talked about how wide the spectrum of front-end development is. Brad, for example, is very much at the front of the front end. Consumable UI components can create a bridge between the back of the front end and the front of the front end.

Consumable UI components need to be bundled, packaged, and published.

Maintain

Now we’ve entered a new mental space. We’ve gone from “Let’s build a website” to “Let’s maintain a product which other products use as a dependency.” You need to start thinking about things like semantic versioning. A version number is a promise.

A 1.0.0 designation comes with commitment. Freewheeling days of unstable early foundations are behind you.

—Nathan Curtis

What do you do when a new tech stack comes along? How does your design system serve the new hotness. It gets worse: you get products that aren’t even web based—iOS, Android, etc.

That’s where design tokens come in. You can define your design language in a platform-agnostic way.

Summary

This is hard.

  • Your design system must live in the technologies your products use.
  • Look at your product roadmaps for design system pilot project opportunities.
  • Establish code conventions and use tooling and process to enforce them.
  • Build your design system and pilot project UI screens in a frontend workshop environment.
  • Bake best practices into reusable components & make them as rigid or flexible as you need them to be.
  • Use semantic versioning to manage ongoing design system product work.
  • Use design tokens to feed common design properties into different platforms.

You won’t do it all at once. That’s okay. Baby steps.

The Mythology of Design Systems by Mina Markham

It’s day two of An Event Apart San Francisco. The brilliant Mina Markham is here to talk to us about design systems (so hot right now!). I’m going to attempt to liveblog it:

Design systems have dominated web design conversations for a few years. Just as there’s no one way to make a website, there is no one way to make a design system. Unfortunately this has led to a lot of misconceptions around the creation and impact of this increasingly important tool.

Drawing on her experiences building design systems at two highly visible and vastly different organizations, Mina will debunk some common myths surrounding design systems.

Mina is a designer who codes. Or an engineer who designs. She makes websites. She works at Slack, but she doesn’t work on the product; she works on slack.com and the Slack blog. Mina also makes design systems. She loves design systems!

There are some myths she’s heard about design systems that she wants to dispel. She will introduce us to some mythological creatures along the way.

Myth 1: Designers “own” the design system

Mina was once talking to a product designer about design systems and was getting excited. The product designer said, nonplussed, “Aren’t you an engineer? Why do you care?” Mina explained that she loved design systems. The product designer said “Y’know, design systems should really be run by designers” and walked away.

Mina wondered if she had caused offense. Was she stepping on someone’s toes? The encounter left her feeling sad.

Thinking about it later, she realised that the conversation about design systems is dominated by product designers. There was a recent Twitter thread where some engineers were talking about this: they felt sidelined.

The reality is that design systems should be multi-disciplinary. That means engineers but it also means other kinds of designers other than product designers too: brand designers, content designers, and so on.

What you need is a hybrid, or unicorn: someone with complimentary skills. As Jina has said, design systems themselves are hybrids. Design systems give hybrids (people) a home. Hybrids help bring unity to an organization.

Myth 2: design systems kill creativity

Mina hears this one a lot. It’s intertwined with some other myths: that design systems don’t work for editorial content, and that design systems are just a collection of components.

Components are like mermaids. Everyone knows what one is supposed to look like, and they can take many shapes.

But if you focus purely on components, then yes, you’re going to get frustrated by a feeling of lacking creativity. Mina quotes @brijanp saying “Great job scrapbookers”.

Design systems encompass more than components:

  • High level principles.
  • Brand guidelines.
  • Coding standards.
  • Accessibility compliance.
  • Governance.

A design system is a set of rules enforced by culture, process and tooling that govern how your organization creates products.

—Mina

Rules and creativity are not mutually exclusive. Rules can be broken.

For a long time, Mina battled against one-off components. But then she realised that if they kept coming up, there must be a reason for them. There is a time and place for diverging from the system.

It’s like Alice Lee says about illustrations at Slack:

There’s a time and place for both—illustrations as stock components, and illustrations as intentional complex extensions of your specific brand.

Yesenia says:

Your design system is your pantry, not your cookbook.

If you keep combining your ingredients in the same way, then yes, you’ll keep getting the same cake. But if you combine them in different ways, there’s a lot of room for creativity. Find the key moments of brand expression.

There are strict and loose systems.

Strict design systems are what we usually think of. AirBnB’s design system is a good example. It’s detailed and tightly controlled.

A loose design system will leave more space for experimentation. TED’s design system consists of brand colours and wireframes. Everything else is left to you:

Consistency is good only insofar as it doesn’t prevent you from trying new things or breaking out of your box when the context justifies it.

Yesenia again:

A good design sytem helps you improvise.

Thinking about strict vs. loose reminds Mina of product vs. marketing. A design system for a product might need to be pixel perfect, whereas editorial design might need more breathing room.

Mina has learned to stop fighting the one-off snowflake components in a system. You want to enable the snowflakes without abandoning the system entirely.

A loose system is key for maintaining consistency while allowing for exploration and creativity.

Myth 3: a design system is a side project

Brad guffaws at this one.

Okay, maybe no one has said this out loud, but you definitely see a company’s priorities focused on customer-facing features. A design system is seen as something for internal use only. “We’ll get to this later” is a common refrain.

“Later” is a mythical creature—a phoenix that will supposedly rise from the ashes of completed projects. Mina has never seen a phoenix. You never see “later” on a roadmap.

Don’t treat your design system as a second-class system. If you do, it will not mature. It won’t get enough time and resources. Design systems require real investment.

Mina has heard from people trying to start design systems getting the advice, “Just do it!” It seems like good advice, but it could be dangerous. It sets you up for failure (and burnout). “Just doing it” without support is setting people up for a bad experience.

The alternative is to put it on the roadmap. But…

Myth 4: a design system should be on the product roadmap

At a previous company, Mina once put a design system on the product roadmap because she saw it wasn’t getting the attention it needed. The answer came back: nah. Mina was annoyed. She had tried to “just do it” and now when she tried to do it through the right channels, she’s told she can’t.

But Mina realised that it’s not that simple. There are important metrics she might not have been aware of.

A roadmap is multi-faceted thing, like Cerebus, the three-headed dog of the underworld.

Okay, so you can’t put the design sytem on the roadmap, but you can tie it to something with a high priority. You could refactor your way to a design system. Or you could allocate room in your timeline to slip in design systems work (pad your estimates a little). This is like a compromise between “Just do it!” and “Put it on the roadmap.”

A system’s value is realized when products ship features that use a system’s parts.

—Nathan Curtis

The other problem with putting a design system on the roadmap is that it implies there’s an end date. But a design system is never finished (unless you abandon it).

Myth 5: our system should do what XYZ’s system did

It’s great that there are so many public design systems out there to look to and get inspired by. We can learn from them. “Let’s do that!”

But those inspiring public systems can be like a succubus. They’re powerful and seductive and might seem fun at first but ultimately leave you feeling intimidated and exhausted.

Your design system should be build for your company’s specific needs, not Google’s or Github’s or anyone’s.

Slack has multiple systems. There’s one for the product called Slack Kit. It’s got great documentation. But if you go on Slack’s marketing website, it doesn’t look like the product. It doesn’t use the same typography or even colour scheme. So it can’t use the existing the design system. Mina created the Spacesuit design system specifically for the marketing site. The two systems are quite different but they have some common goals:

  • Establish common language.
  • Reduce technical debt.
  • Allow for modularity.

But there are many different needs between the Slack client and the marketing site. Also the marketing site doesn’t have the same resources as the Slack client.

Be inspired by other design systems, but don’t expect the same resutls.

Myth 6: everything is awesome!

When you think about design systems, everything is nice and neat and orderly. So you make one. Then you look at someone else’s design system. Your expectations don’t match the reality. Looking at these fully-fledged design systems is like comparing Instagram to real life.

The perfect design system is an angel. It’s a benevolent creature acting as an intermediary between worlds. Perhaps you think you’ve seen one once, but you can’t be sure.

The truth is that design system work is like laying down the railway tracks while the train is moving.

For a developer, it is a rare gift to be able to implement a project with a clean slate and no obligations to refactor an existing codebase.

Mina got to do a complete redesign in 2017, accompanied by a design system. The design system would power the redesign. Everything was looking good. Then slowly as the rest of the team started building more components for the website, unconnected things seemed to be breaking. This is what design systems are supposed to solve. But people were creating multiple components that did the same thing. Work was happening on a deadline.

Even on the Hillary For America design system (Pantsuit), which seemed lovely and awesome on the outside, there were multiple components that did the same thing. The CSS got out of hand with some very convoluted selectors trying to make things flexible.

Mina wants to share those stories because it sometimes seems that we only share the success stories.

Share work in progress. Learn out in the open. Be more vulnerable, authentic, and real.

Patterns Day video and audio

If you missed out on Patterns Day this year, you can still get a pale imitation of the experience of being there by watching videos of the talks.

Here are the videos, and if you’re not that into visuals, here’s a podcast of the talks (you can subscribe to this RSS feed in your podcasting app of choice).

On Twitter, Chris mentioned that “It would be nice if the talks had their topic listed,” which is a fair point. So here goes:

It’s fascinating to see emergent themes (other than, y’know, the obvious theme of design systems) in different talks. In comparison to the first Patterns Day, it felt like there was a healthy degree of questioning and scepticism—there were plenty of reminders that design systems aren’t a silver bullet. And I very much appreciated Yaili’s point that when you see beautifully polished design systems that have been made public, it’s like seeing the edited Instagram version of someone’s life. That reminded me of Responsive Day Out when Sarah Parmenter, the first speaker at the very first event, opened everything by saying “most of us are winging it.”

I can see the value in coming to a conference to hear stories from people who solved hard problems, but I think there’s equal value in coming to a conference to hear stories from people who are still grappling with hard problems. It’s reassuring. I definitely got the vibe from people at Patterns Day that it was a real relief to hear that nobody’s got this figured out.

There was also a great appreciation for the “big picture” perspective on offer at Patterns Day. For myself, I know that I’ll be cogitating upon Danielle’s talk and Emil’s talk for some time to come—both are packed full of ineresting ideas.

Good thing we’ve got the videos and the podcast to revisit whenever we want.

And if you’re itching for another event dedicated to design systems, I highly recommend snagging a ticket for the Clarity conference in San Francisco next month.

Patterns Day Two

Who says the sequels can’t be even better than the original? The second Patterns Day was The Empire Strikes Back, The Godfather Part II, and The Wrath of Khan all rolled into one …but, y’know, with design systems.

If you were there, then you know how good it was. If you weren’t, sorry. Audio of the talks should be available soon though, with video following on.

The talks were superb! I know I’m biased becuase I put the line-up together, but even so, I was blown away by the quality of the talks. There were some big-picture questioning talks, a sequence of nitty-gritty code talks in the middle, and galaxy-brain philosophical thoughts at the end. A perfect mix, in my opinion.

Words cannot express how grateful I am to Alla, Yaili, Amy, Danielle, Heydon, Varya, Una, and Emil. They really gave it their all! Some of them are seasoned speakers, and some of them are new to speaking on stage, but all of them delivered the goods above and beyond what I expected.

Big thanks to my Clearleft compadres for making everything run smoothly: Jason, Amy, Cassie, Chris, Trys, Hana, and especially Sophia for doing all the hard work behind the scenes. Trys took some remarkable photos too. He posted some on Twitter, and some on his site, but there are more to come.

Me on stage. Inside the Duke of York's for Patterns Day 2

And if you came to Patterns Day 2, thank you very, very much. I really appreciate you being there. I hope you enjoyed it even half as much as I did, because I had a ball!

Once again, thanks to buildit @ wipro digital for sponsoring the pastries and coffee, as well as running a fun giveaway on the day. Many thank to Bulb for sponsoring the forthcoming videos. Thanks again to Drew for recording the audio. And big thanks to Brighton’s own Holler Brewery for very kindly offering every attendee a free drink—the weather (and the beer) was perfect for post-conference discussion!

It was incredibly heartwarming to hear how much people enjoyed the event. I was especially pleased that people were enjoying one another’s company as much as the conference itself. I knew that quite a few people were coming in groups from work, while other people were coming by themselves. I hoped there’d be lots of interaction between attendees, and I’m so, so glad there was!

You’ve all made me very happy.

The schedule for Patterns Day

Patterns Day is less than three weeks away—exciting!

We’re going to start the day at a nice civilised time. Registration is from 9am. There will be tea, coffee, and pastries, so get there in plenty of time to register and have a nice chat with your fellow attendees. There’ll be breaks throughout the day too.

Those yummy pastries and hot drinks are supplied courtesy of our sponsors Buildit @ Wipro Digital—many thanks to them!

Each talk will be 30 minutes long. There’ll be two talks back-to-back and then a break. That gives you plenty of breathing space to absorb all those knowledge bombs that the speakers will be dropping.

Lunch will be a good hour and a half. Lunch isn’t provided so you can explore the neighbourhood where there are plenty of treats on offer. And your Patterns Day badge will even get you some discounts…

The lovely Café Rust is offering these deals to attendees:

  • Cake and coffee for £5
  • Cake and cup of tea for £4
  • Sandwich and a drink for £7

The Joker (right across the street from the conference venue) is offering a 10% discount of food and drinks (but not cocktails) to Patterns Day attendees. I highly recommend their hot wings. Try the Rufio sauce—it’s awesome! Do not try the Shadow—it will kill you.

Here’s how the day is looking:

Registration
Opening remarks
Alla
Yaili
Break
Amy
Danielle
Lunch
Heydon
Varya
Break
Una
Emil
Closing remarks

We should be out of the Duke of York’s by 4:45pm after a fantastic day of talks. At that point, we can head around the corner (literally) to Holler Brewery. They are very kindly offering each attendee a free drink! Over to them:

Holler is a community based brewery, always at the centre of the local community. Here to make great beer, but also to help support community run pubs, carnival societies, mental health charities, children’s amateur dramatic groups, local arts groups and loads more, because these are what keep our communities healthy and together… the people in them!

Holler loves great beer and its way of bringing people together. They are excited to be welcoming the Patterns Day attendees and the design community to the taproom.

Terms and conditions:

  • One token entitles to you one Holler beer or one soft drink
  • Redeemable only on Friday 28th June 2019 between 4:45 and 20:00
  • You must hand your token over to the bar team

You’ll get your token when you register in the morning, along with your sticker. That’s right; sticker. Every expense has been spared so you won’t even have a name badge on a lanyard, just a nice discrete but recognisable sticker for the event.

I am so, so excited for Patterns Day! See you at the Duke of York’s on June 28th!

Sponsor Patterns Day

Patterns Day 2 is sold out! Yay!

I didn’t even get the chance to announce the full line-up before all the tickets were sold. That was meant to my marketing strategy, see? I’d announce some more speakers every few weeks, and that would encourage more people to buy tickets. Turns out that I didn’t need to do that.

But I’m still going to announce the final two speakers here becuase I’m so excited about them—Danielle Huntrods and Varya Stepanova!

Danielle is absolutely brilliant. I know this from personal experience because I worked alongside her at Clearleft for three years. Now she’s at Bulb and I can’t wait for everyone at Patterns Day to hear her galaxy brain thoughts on design systems.

And how could I not have Varya at Patterns Day? She lives and breathes design systems. Whether it’s coding, writing, speaking, or training, she’s got years of experience to share. Ever used BEM? Yeah, that was Varya.

Anyway, if you’ve got your ticket for Patterns Day, you’re in for a treat.

If you didn’t manage to get a ticket for Patterns Day …sorry.

But do not despair. There is still one possible way of securing an elusive Patterns Day ticket: get your company to sponsor the event.

We’ve already got one sponsor—buildit @ wipro digital—who are kindly covering the costs for teas, coffees, and pastries. Now I’m looking for another sponsor to cover the costs of making video recordings of the talks.

The cost of sponsorship is £2000. In exchange, I can’t offer you a sponsor stand or anything like that—there’s just no room at the venue. But you will earn my undying thanks, and you’ll get your logo on the website and on the screen in between talks on the day (and on the final videos).

I can also give you four tickets to Patterns Day.

This is a sponsorship strategy that I like to call “blackmail.”

If you were really hoping to bring your team to Patterns Day, but you left it too late to get your tickets, now’s your chance. Convince your company to sponsor the event (and let’s face it, £2000 is a rounding error on some company’s books). Then you and your colleagues need not live with eternal regret and FOMO.

Drop me a line. Let’s talk.

Frameworking

There are many reasons to use a JavaScript framework like Vue, Angular, or React. Last year, Nicole asked for some of those reasons. Her question received many, many answers from people pointing out the benefits of using a framework. Interesingly, though, not a single one of those benefits was for end users.

(Mind you, if the framework is being used on the server to pre-render pages, then it’s a moot point—in that situation, it makes no difference to the end user whether you use a framework or not.)

Hidde recently tried using a client-side JavaScript framework for the first time and documented the process:

In the last few months I built my very first framework-based front-end, in Vue.js. I complemented it with a router, a store and a GraphQL library, in order to have, respectively, multiple (virtual) pages, globally shared data and a smart way to load new data in my templates.

It’s a very even-handed write-up. I highly recommend reading it. He describes the pros and cons of using a framework and using vanilla JavaScript:

I am glad I tried a framework and found its features were extremely helpful in creating a consistent interface for my users. My hope is though, that I won’t forget about vanilla. It’s perfectly valid to build a website with no or few dependencies.

Speaking of vanilla JavaScript… the blogging machine that is Chris Ferdinandi also wrote a comparison post recently, asking Why do people choose frameworks over vanilla JS? Again, it’s very even-handed and well worth a read. He readily concedes that if you’re working at scale, a framework is almost certainly a good idea:

If you’re building a large scale application (literally Facebook, Twitter, QuickBooks scale), the performance wins of a framework make the overhead worth it.

Alas, I’ve seen many, many framework-driven sites that are most definitely not that operating at that scale. Trys speaks the honest truth here:

We kid ourselves into thinking we’re building groundbreakingly complex systems that require bleeding-edge tools, but in reality, much of what we build is a way to render two things: a list, and a single item. Here are some users, here is a user. Here are your contacts, here are your messages with that contact. There ain’t much more to it than that.

Just the other day, I saw a new site launch that was mostly a marketing site—the home page weighed over five megabytes, two megabytes of which were taken up with JavaScript, and the whole thing required JavaScript to render text to the screen (I’m not going to link to it because I don’t want to engage in any kind of public shaming and finger-wagging).

I worry that all the perfectly valid (developer experience) reasons for using a framwork are outweighing the more important (user experience) reasons for avoiding shipping your dependencies to end users. Like Alex says:

If your conception of “DX” doesn’t include it, or isn’t subservient to the user experience, rethink.

And yes, I am going to take this opportunity to link once again to Alex’s article The “Developer Experience” Bait-and-Switch. Please read it if you haven’t already. Please re-read it if you have.

Anyway, my main reason for writing this is to point you to thoughtful posts like Hidde’s and Chris’s. I think it’s great to see people thoughtfully weighing up the pros and cons of choosing any particular technology—I’m a bit obsessed with the topic of evaluating technology.

If you’re weighing up the pros and cons of using, say, a particular JavaScript library or framework, that’s wonderful. My worry is that there are people working in front-end development who aren’t putting that level of thought into their technology choices, but are instead using a particular framework because it’s what they’re used to.

To quote Grace Hopper:

The most dangerous phrase in the language is, ‘We’ve always done it this way.’

Three more Patterns Day speakers

There are 73 days to go until Patterns Day. Do you have your ticket yet?

Perhaps you’ve been holding out for some more information on the line-up. Well, I’m more than happy to share the latest news with you—today there are three new speakers on the bill…

Emil Björklund, the technical director at the Malmö outpost of Swedish agency inUse, is a super-smart person I’ve known for many years. Last year, I saw him on stage in his home town at the Confront conference sharing some of his ideas on design systems. He blew my mind! I told him there and then that he had to come to Brighton and expand on those thoughts some more. This is going to be an unmissable big-picture talk in the style of Paul’s superb talk last year.

Speaking of superb talks from last year, Alla Kholmatova is back! Her closing talk from the first Patterns Day was so fantastic that it I just had to have her come back. Oh, and since then, her brilliant book on Design Systems came out. She’s going to have a lot to share!

The one thing that I felt was missing from the first Patterns Day was a focus on inclusive design. I’m remedying that this time. Heydon Pickering, creator of the Inclusive Components website—and the accompanying book—is speaking at Patterns Day. I’m very excited about this. Given that Heydon has a habit of casually dropping knowledge bombs like the lobotomised owl selector and the flexbox holy albatross, I can’t wait to see what he unleashes on stage in Brighton on June 28th.

Emil Björklund Alla Kholmatova Heydon Pickering
Emil, Alla, and Heydon

Be there or be square.

Tickets for Patterns Day are still available, but you probably don’t want to leave it ‘till the last minute to get yours. Just sayin’.

The current—still incomplete—line-up comprises:

That isn’t even the full roster of speakers, and it’s already an unmissable event!

I very much hope you’ll join me in the beautiful Duke of York’s cinema on June 28th for a great day of design system nerdery.

Split

When I talk about evaluating technology for front-end development, I like to draw a distinction between two categories of technology.

On the one hand, you’ve got the raw materials of the web: HTML, CSS, and JavaScript. This is what users will ultimately interact with.

On the other hand, you’ve got all the tools and technologies that help you produce the HTML, CSS, and JavaScript: pre-processors, post-processors, transpilers, bundlers, and other build tools.

Personally, I’m much more interested and excited by the materials than I am by the tools. But I think it’s right and proper that other developers are excited by the tools. A good balance of both is probably the healthiest mix.

I’m never sure what to call these two categories. Maybe the materials are the “external” technologies, because they’re what users will interact with. Whereas all the other technologies—that mosty live on a developer’s machine—are the “internal” technologies.

Another nice phrase is something I heard during Chris’s talk at An Event Apart in Seattle, when he quoted Brad, who talked about the front of the front end and the back of the front end.

I’m definitely more of a front-of-the-front-end kind of developer. I have opinions on the quality of the materials that get served up to users; the output should be accessible and performant. But I don’t particularly care about the tools that produced those materials on the back of the front end. Use whatever works for you (or whatever works for your team).

As a user-centred developer, my priority is doing what’s best for end users. That’s not to say I don’t value developer convenience. I do. But I prioritise user needs over developer needs. And in any case, those two needs don’t even come into conflict most of the time. Like I said, from a user’s point of view, it’s irrelevant what text editor or version control system you use.

Now, you could make the argument that anything that is good for developer convenience is automatically good for user experience because faster, more efficient development should result in better output. While that’s true in theory, I highly recommend Alex’s post, The “Developer Experience” Bait-and-Switch.

Where it gets interesting is when a technology that’s designed for developer convenience is made out of the very materials being delivered to users. For example, a CSS framework like Bootstrap is made of CSS. That’s different to a tool like Sass which outputs CSS. Whether or not a developer chooses to use Sass is irrelevant to the user—the final output will be CSS either way. But if a developer chooses to use a CSS framework, that decision has a direct impact on the user experience. The user must download the framework in order for the developer to get the benefit.

So whereas Sass sits at the back of the front end—where I don’t care what you use—Bootstrap sits at the front of the front end. For tools like that, I don’t think saying “use whatever works for you” is good enough. It’s got to be weighed against the cost to the user.

Historically, it’s been a similar story with JavaScript libraries. They’re written in JavaScript, and so they’re going to be executed in the browser. If a developer wanted to use jQuery to make their life easier, the user paid the price in downloading the jQuery library.

But I’ve noticed a welcome change with some of the bigger JavaScript frameworks. Whereas the initial messaging around frameworks like React touted the benefits of state management and the virtual DOM, I feel like that’s not as prevalent now. You’re much more likely to hear people—quite rightly—talk about the benefits of modularity and componentisation. If you combine that with the rise of Node—which means that JavaScript is no longer confined to the browser—then these frameworks can move from the front of the front end to the back of the front end.

We’ve certainly seen that at Clearleft. We’ve worked on multiple React projects, but in every case, the output was server-rendered. Developers get the benefit of working with a tool that helps them. Users don’t pay the price.

For me, this question of whether a framework will be used on the client side or the server side is crucial.

Let me tell you about a Clearleft project that sticks in my mind. We were working with a big international client on a product that was going to be rolled out to students and teachers in developing countries. This was right up my alley! We did plenty of research into network conditions and typical device usage. That then informed a tight performance budget. Every design decision—from web fonts to images—was informed by that performance budget. We were producing lean, mean markup, CSS, and JavaScript. But we weren’t the ones implementing the final site. That was being done by the client’s offshore software team, and they insisted on using React. “That’s okay”, I thought. “React can be used server-side so we can still output just what’s needed, right?” Alas, no. These developers did everything client side. When the final site launched, the log-in screen alone required megabytes of JavaScript just to render a form. It was, in my opinion, entirely unfit for purpose. It still pains me when I think about it.

That was a few years ago. I think that these days it has become a lot easier to make the decision to use a framework on the back of the front end. Like I said, that’s certainly been the case on recent Clearleft projects that involved React or Vue.

It surprises me, then, when I see the question of server rendering or client rendering treated almost like an implementation detail. It might be an implementation detail from a developer’s perspective, but it’s a key decision for the user experience. The performance cost of putting your entire tech stack into the browser can be enormous.

Alex Sanders from the development team at The Guardian published a post recently called Revisiting the rendering tier . In it, he describes how they’re moving to React. Now, if this were a move to client-rendered React, that would make a big impact on the user experience. The thing is, I couldn’t tell from the article whether React was going to be used in the browser or on the server. The article talks about “rendering”—which is something that browsers do—and “the DOM”—which is something that only exists in browsers.

So I asked. It turns out that this plan is very much about generating HTML and CSS on the server before sending it to the browser. Excellent!

With that question answered, I’m cool with whatever they choose to use. In this case, they’re choosing to use CSS-in-JS (although, to be pedantic, there’s no C anymore so technically it’s SS-in-JS). As long as the “JS” part is JavaScript on a server, then it makes no difference to the end user, and therefore no difference to me. Not my circus, not my monkeys. For users, the end result is the same whether styling is applied via a selector in an external stylesheet or, for example, via an inline style declaration (and in some situations, a server-rendered CSS-in-JS solution might be better for performance). And so, as a user-centred developer, this is something that I don’t need to care about.

Except…

I have misgivings. But just to be clear, these misgivings have nothing to do with users. My misgivings are entirely to do with another group of people: the people who make websites.

There’s a second-order effect. By making React—or even JavaScript in general—a requirement for styling something on a web page, the barrier to entry is raised.

At least, I think that the barrier to entry is raised. I completely acknowledge that this is a subjective judgement. In fact, the reason why a team might decide to make JavaScript a requirement for participation might well be because they believe it makes it easier for people to participate. Let me explain…

It wasn’t that long ago that devs coming from a Computer Science background were deriding CSS for its simplicity, complaining that “it’s broken” and turning their noses up at it. That rhetoric, thankfully, is waning. Nowadays they’re far more likely to acknowledge that CSS might be simple, but it isn’t easy. Concepts like the cascade and specificity are real head-scratchers, and any prior knowledge from imperative programming languages won’t help you in this declarative world—all your hard-won experience and know-how isn’t fungible. Instead, it seems as though all this cascading and specificity is butchering the modularity of your nicely isolated components.

It’s no surprise that programmers with this kind of background would treat CSS as damage and find ways to route around it. The many flavours of CSS-in-JS are testament to this. From a programmer’s point of view, this solution has made things easier. Best of all, as long as it’s being done on the server, there’s no penalty for end users. But now the price is paid in the diversity of your team. In order to participate, a Computer Science programming mindset is now pretty much a requirement. For someone coming from a more declarative background—with really good HTML and CSS skills—everything suddenly seems needlessly complex. And as Tantek observed:

Complexity reinforces privilege.

The result is a form of gatekeeping. I don’t think it’s intentional. I don’t think it’s malicious. It’s being done with the best of intentions, in pursuit of efficiency and productivity. But these code decisions are reflected in hiring practices that exclude people with different but equally valuable skills and perspectives.

Rachel describes HTML, CSS and our vanishing industry entry points:

If we make it so that you have to understand programming to even start, then we take something open and enabling, and place it back in the hands of those who are already privileged.

I think there’s a comparison here with toxic masculinity. Toxic masculinity is obviously terrible for women, but it’s also really shitty for men in the way it stigmatises any male behaviour that doesn’t fit its worldview. Likewise, if the only people your team is interested in hiring are traditional programmers, then those programmers are going to resent having to spend their time dealing with semantic markup, accessibility, styling, and other disciplines that they never trained in. Heydon correctly identifies this as reluctant gatekeeping:

By assuming the role of the Full Stack Developer (which is, in practice, a computer scientist who also writes HTML and CSS), one takes responsibility for all the code, in spite of its radical variance in syntax and purpose, and becomes the gatekeeper of at least some kinds of code one simply doesn’t care about writing well.

This hurts everyone. It’s bad for your team. It’s even worse for the wider development community.

Last year, I was asked “Is there a fear or professional challenge that keeps you up at night?” I responded:

My greatest fear for the web is that it becomes the domain of an elite priesthood of developers. I firmly believe that, as Tim Berners-Lee put it, “this is for everyone.” And I don’t just mean it’s for everyone to use—I believe it’s for everyone to make as well. That’s why I get very worried by anything that raises the barrier to entry to web design and web development.

I’ve described a number of dichotomies here:

  • Materials vs. tools,
  • Front of the front end vs. back of the front end,
  • User experience vs. developer experience,
  • Client-side rendering vs. server-side rendering,
  • Declarative languages vs. imperative languages.

But the split that worries the most is this:

  • The people who make the web vs. the people who are excluded from making the web.

Dev perception

Chris put together a terrific round-up of posts recently called Simple & Boring. It links off to a number of great articles on the topic of complexity (and simplicity) in web development.

I had linked to quite a few of the articles myself already, but one I hadn’t seen was from David DeSandro who wrote New tech gets chatter:

You don’t hear about TextMate because TextMate is old. What would I tweet? Still using TextMate. Still good.

I think that’s a very good point.

It’s relatively easy to write and speak about new technologies. You’re excited about them, and there’s probably an eager audience who can learn from what you have to say.

It’s trickier to write something insightful about a tried and trusted (perhaps even boring) technology that’s been around for a while. You could maybe write little tips and tricks, but I bet your inner critic would tell you that nobody’s interested in hearing about that old tech. It’s boring.

The result is that what’s being written about is not a reflection of what’s being widely used. And that’s okay …as long as you know that’s the case. But I worry that theres’s a perception problem. Because of the outsize weighting of new and exciting technologies, a typical developer could feel that their skills are out of date and the technologies they’re using are passé …even if those technologies are actually in wide use.

I don’t know about you, but I constantly feel like I’m behind the curve because I’m not currently using TypeScript or GraphQL or React. Those are all interesting technologies, to be sure, but the time to pick any of them up is when they solve a specific problem I’m having. Learning a new technology just to mitigate a fear of missing out isn’t a scalable strategy. It’s reasonable to investigate a technology because you genuinely think it’s exciting; it’s quite another matter to feel like you must investigate a technology in order to survive. That way lies burn-out.

I find it very grounding to talk to Drew and Rachel about the people using their Perch CMS product. These are working developers, but they are far removed from the world of tools and frameworks forged in the startup world.

In a recent (excellent) article comparing the performance of Formula One websites, Jake made this observation at the end:

However, none of the teams used any of the big modern frameworks. They’re mostly Wordpress & Drupal, with a lot of jQuery. It makes me feel like I’ve been in a bubble in terms of the technologies that make up the bulk of the web.

I think this is very astute. I also think it’s completely understandable to form ideas about what matters to developers by looking at what’s being discussed on Twitter, what’s being starred on Github, what’s being spoken about at conferences, and what’s being written about on Ev’s blog. But it worries me when I see browser devrel teams focusing their efforts on what appears to be the needs of typical developers based on the amount of ink spilled and breath expelled.

I have a suspicion that there’s a silent majority of developers who are working with “boring” technologies on “boring” products in “boring” industries …you know, healthcare, government, education, and other facets of everyday life that any other industry would value more highly than Uber for dogs.

Trys wrote a great blog post called City life, where he compares his experience of doing CMS-driven agency work with his experience working at a startup in Shoreditch:

I was chatting to one of the team about my previous role. “I built two websites a month in WordPress”.

They laughed… “WordPress! Who uses that anymore?!”

Nearly a third of the web as it turns out - but maybe not on the Silicon Roundabout.

I’m not necessarily suggesting that there should be more articles and talks about older, more established technologies. Conferences in particular are supposed to give audiences a taste of what’s coming—they can be a great way of quickly finding out what’s exciting in the world of development. But we shouldn’t feel bad if those topics don’t match our day-to-day reality.

Ultimately what matters is building something—a website, a web app, whatever—that best serves end users. If that requires a new and exciting technology, that’s great. But if it requires an old and boring technology, that’s also great. What matters here is appropriateness.

When we’re evaluating technologies for appropriateness, I hope that we will do so through the lens of what’s best for users, not what we feel compelled to use based on a gnawing sense of irrelevancy driven by the perceived popularity of newer technologies.

Patterns Day 2: June 28th, 2019

Surprise! Patterns Day is back!

The first Patterns Day was in the Summer of 2017, and it was a glorious—a single day devoted to all things design system-y: pattern libraries, style guides, maintainability, reusability. It was a lot of fun, so let’s do it again!

Patterns Day 2 will take place on Friday, June 28th, in the beautiful Duke of York’s cinema in Brighton. If you went to the first Patterns Day, then you’ll know how luxuriously comfy it is in there.

Tickets are £175+VAT. The format will likely be the same as before: an action-packed day of eight talks, each 30 minutes long.

I’ve got an amazing line-up of speakers, but instead of telling you the whole line-up straightaway, I’m going to tease a little bit, and announce more speakers over the next few weeks and months. For now, here are the first three speakers, to give you an idea of the quality you can expect:

  • All the way from the US of A, it’s Una Kravets, who needs no introduction.
  • From the Government Digital Service, we’ve got Amy Hupe—she’ll have plenty to share about the GOV.UK design system.
  • And we’ve got Yaili, now a senior designer at Microsoft, where she works on the Azure DevOps design system.

Patterns Day will have something for everyone. We’ll be covering design, development, content strategy, product management, and accessibility. So you might want to make this a one-day outing for your whole team.

If you want to get a feel for what the day will be like, you can watch the videos of last year’s talks

Tickets for last year’s Patterns Day went fairly fast—the Duke of York’s doesn’t have a huge capacity—so don’t dilly-dally too long before grabbing your ticket!

The history of design systems at Clearleft

Danielle has posted a brief update on Fractal:

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.

It’s so gratifying to see that other people are finding Fractal to be as useful to them as it is to us. We very much appreciate all their support!

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.

When Paul joined Clearleft, it was a perfect fit. He was already obsessed with style guides (like the BBC’s Global Experience Language) and started writing and talking about styleguides for the web:

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:

  1. Theory, Practice, and the Unfortunate In-between,
  2. Layers of Longevity, and
  3. Components and Composition

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:

Natalie Downe, Anna Debenham, Paul Lloyd, Mark Perkins, Charlotte Jackson, and Danielle Huntrods …thank you all!

AMPstinction

I’ve come to believe that the goal of any good framework should be to make itself unnecessary.

Brian said it explicitly of his PhoneGap project:

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.

jQuery is the classic example of this. There’s very little reason to use jQuery these days because you can accomplish so much with browser-native JavaScript. But the reason why you can accomplish so much without jQuery is because of jQuery. I don’t think we would have 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:

  1. Performance! Something must be done!
  2. AMP is something.
  3. Now something has been done.

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.

Design ops for design systems

Leading Design was one of the best events I attended last year. To be honest, that surprised me—I wasn’t sure how relevant it would be to me, but it turned out to be the most on-the-nose conference I could’ve wished for.

Seeing as the event was all about design leadership, there was inevitably some talk of design ops. But I noticed that the term was being used in two different ways.

Sometimes a speaker would talk about design ops and mean “operations, specifically for designers.” That means all the usual office practicalities—equipment, furniture, software—that designers might need to do their jobs. For example, one of the speakers recommended having a dedicated design ops person rather than trying to juggle that yourself. That’s good advice, as long as you understand what’s meant by design ops in that context.

There’s another context of use for the phrase “design ops”, and it’s one that we use far more often at Clearleft. It’s related to design systems.

Now, “design system” is itself a term that can be ambiguous. See also “pattern library” and “style guide”. Quite a few people have had a stab at disambiguating those terms, and I think there’s general agreement—a design system is the overall big-picture “thing” that can contain a pattern library, and/or a style guide, and/or much more besides:

None of those great posts attempt to define design ops, and that’s totally fair, because they’re all attempting to define things—style guides, pattern libraries, and design systems—whereas design ops isn’t a thing, it’s a practice. But I do think that design ops follows on nicely from design systems. I think that design ops is the practice of adopting and using a design system.

There are plenty of posts out there about the challenges of getting people to use a design system, and while very few of them use the term design ops, I think that’s what all of them are about:

Clearly design systems and design ops are very closely related: you really can’t have one without the other. What I find interesting is that a lot of the challenges relating to design systems (and pattern libraries, and style guides) might be technical, whereas the challenges of design ops are almost entirely cultural.

I realise that tying design ops directly to design systems is somewhat limiting, and the truth is that design ops can encompass much more. I like Andy’s description:

Design Ops is essentially the practice of reducing operational inefficiencies in the design workflow through process and technological advancements.

Now, in theory, that can encompass any operational stuff—equipment, furniture, software—but in practice, when we’re dealing with design ops, 90% of the time it’s related to a design system. I guess I could use a whole new term (design systems ops?) but I think the term design ops works well …as long as everyone involved is clear on the kind of design ops we’re all talking about.

Pattern Libraries, Performance, and Progressive Web Apps

Ever since its founding in 2005, Clearleft has been laser-focused on user experience design.

But we’ve always maintained a strong front-end development arm. The front-end development work at Clearleft is always in service of design. Over the years we’ve built up a wealth of expertise on using HTML, CSS, and JavaScript to make better user experiences.

Recently we’ve been doing a lot of strategic design work—the really in-depth long-term engagements that begin with research and continue through to design consultancy and collaboration. That means we’ve got availability for front-end development work. Whether it’s consultancy or production work you’re looking for, this could be a good opportunity for us to work together.

There are three particular areas of front-end expertise we’re obsessed with…

Pattern Libraries

We caught the design systems bug years ago, way back when Natalie started pioneering pattern libraries as our primary deliverable (or pattern portfolios, as we called them then). This approach has proven effective time and time again. We’ve spent years now refining our workflow and thinking around modular design. Fractal is the natural expression of this obsession. Danielle and Mark have been working flat-out on version 2. They’re very eager to share everything they’ve learned along the way …and help others put together solid pattern libraries.

Danielle Huntrods Mark Perkins

Performance

Thinking about it, it’s no surprise that we’re crazy about performance at Clearleft. Like I said, our focus on user experience, and when it comes to user experience on the web, nothing but nothing is more important than performance. The good news is that the majority of performance fixes can be done on the front end—images, scripts, fonts …it’s remarkable how much a good front-end overhaul can make to the bottom line. That’s what Graham has been obsessing over.

Graham Smith

Progressive Web Apps

Over the years I’ve found myself getting swept up in exciting new technologies on the web. When Clearleft first formed, my head was deep into DOM Scripting and Ajax. Half a decade later it was HTML5. Now it’s service workers. I honestly think it’s a technology that could be as revolutionary as Ajax or HTML5 (maybe I should write a book to that effect).

I’ve been talking about service workers at conferences this year, and I can’t hide my excitement:

There’s endless possibilities of what you can do with this technology. It’s very powerful.

Combine a service worker with a web app manifest and you’ve got yourself a Progressive Web App. It’s not just a great marketing term—it’s an opportunity for the web to truly excel at delivering the kind of user experiences previously only associated with native apps.

Jeremy Keith

I’m very very keen to work with companies and organisations that want to harness the power of service workers and Progressive Web Apps. If that’s you, get in touch.

Whether it’s pattern libraries, performance, or Progressive Web Apps, we’ve got the skills and expertise to share with you.

Patterns Day

Patterns Day is over. It was all I hoped it would be and more.

I’ve got that weird post-conference feeling now, where that all-consuming thing that was ahead of you is now behind you, and you’re not quite sure what to do. Although, comparatively speaking, Patterns Day came together pretty quickly. I announced it less than three months ago. It sold out just over a month later. Now it’s over and done with, it feels like a whirlwind.

The day itself was also somewhat whirlwind-like. It was simultaneously packed to the brim with great talks, and yet over in the blink of an eye. Everyone who attended seemed to have a good time, which makes me very happy indeed. Although, as I said on the day, while it’s nice that everyone came along, I put the line-up together for purely selfish reasons—it was my dream line-up of people I wanted to see speak.

Boy, oh boy, did they deliver the goods! Every talk was great. And I must admit, I was pleased with how I had structured the event. The day started and finished with high-level, almost philosophical talks; the mid section was packed with hands-on nitty-gritty practical examples.

Thanks to sponsorship from Amazon UK, Craig was videoing all the talks. I’ll get them online as soon as I can. But in the meantime, Drew got hold of the audio and made mp3s of each talk. They are all available in handy podcast form for your listening and huffduffing pleasure:

  1. Laura Elizabeth
  2. Ellen de Vries
  3. Sareh Heidari
  4. Rachel Andrew
  5. Alice Bartlett
  6. Jina Anne
  7. Paul Lloyd
  8. Alla Kholmatova

If you’re feeling adventurous, you can play the Patterns Day drinking game while you listen to the talks:

  • Any time someone says “Lego”, take a drink,
  • Any time someone references Chrisopher Alexander, take a drink,
  • Any time someone says that naming things is hard, take a drink,
  • Any time says “atomic design”, take a drink, and
  • Any time says “Bootstrap”, puke the drink back up.

In between the talks, the music was provided courtesy of some Brighton-based artists

Hidde de Vries has written up an account of the day. Stu Robson has also published his notes from each talk. Sarah Drummond wrote down her thoughts on Ev’s blog.

I began the day by predicting that Patterns Day would leave us with more questions than answers …but that they would be the right questions. I think that’s pretty much what happened. Quite a few people compared it to the first Responsive Day Out in tone. I remember a wave of relief flowing across the audience when Sarah opened the show by saying:

I think if we were all to be a little more honest when we talk to each other than we are at the moment, the phrase “winging it” would be something that would come up a lot more often. If you actually speak to people, not very many people have a process for this at the moment. Most of us are kind of winging it.

  • This is hard.
  • No one knows exactly what they’re doing.
  • Nobody has figured this out yet.

Those sentiments were true of responsive design in 2013, and they’re certainly true of design systems in 2017. That’s why I think it’s so important that we share our experiences—good and bad—as we struggle to come to grips with these challenges. That’s why I put Patterns Day together. That’s also why, at the end of the day, I thanked everyone who has ever written about, spoken about, or otherwise shared their experience with design systems, pattern libraries, style guides, and components. And of course I made sure that everyone gave Anna a great big round of applause for her years of dedicated service—I wish she could’ve been there.

There were a few more “thank you”s at the end of the day, and all of them were heartfelt. Thank you to Felicity and everyone else at the Duke of York’s for the fantastic venue and making sure everything went so smoothly. Thank you to AVT for all the audio/visual wrangling. Thanks to Amazon for sponsoring the video recordings, and thanks to Deliveroo for sponsoring the tea, coffee, pastries, and popcorn (they’re hiring, by the way). Huge thanks to Alison and everyone from Clearleft who helped out on the day—Hana, James, Rowena, Chris, Benjamin, Seb, Jerlyn, and most especially Alis who worked behind the scenes to make everything go so smoothly. Thanks to Kai for providing copies of Offscreen Magazine for the taking. Thanks to Marc and Drew for taking lots of pictures. Thanks to everyone who came to Patterns Day, especially the students and organisers from Codebar Brighton—you are my heroes.

Most of all thank you, thank you, thank you, to the eight fantastic speakers who made Patterns Day so, so great—I love you all.

Laura Ellen Sareh Rachel Alice Jina Paul Alla