Link tags: ems

127

sparkline

Listen To Me And Not Google: HeydonWorks

We have to stop confusing the excesses of capitalism with the hallmarks of quality. Sometimes Google aren’t better, they’re just more pervasive.

cough AMP cough

Systems, Mistakes, and the Sea › Robin Rendle

Robin contemplates design systems as hyperobjects.

He also makes the uncomfortable observation that design systems work is not just hard, it’s inherently demoralising and soul-crushing.

My hunch is this: folks can’t talk about real design systems problems because it will show their company as being dysfunctional and broken in some way. This looks bad for their company and hence looks bad for them. But hiding those mistakes and shortcomings by glossing over everything doesn’t just make it harder for us personally, it hinders progress within the field itself.

Design APIs: The Evolution of Design Systems by Matthew Ström

This is an interesting comparison: design systems as APIs. It makes sense. A design system—like an API—is a contract. Also, an API without documentation is of little use …much like a design system without documentation.

Open UI

An interesting project that will research and document the language used across different design systems to name similar components.

Thinking vs Choosing – The Haystack

There seems to be a tendency to repurpose existing solutions to other people’s problems. I propose that this is the main cause of the design sameness that we encounter on the web (and in apps) today. In our (un)conscious attempts to reduce the effort needed to do our work, we’ve become experts in choosing rather than in thinking.

A very thoughtful piece from Stephen.

When we use existing solutions or patterns, we use a different kind of thinking. Our focus is on finding which pattern will work for us. Too quickly, we turn our attention away from closely examining the problem.

The Ugly Truth about Design Systems

The video of a talk in which Mark discusses pace layers, dogs, and design systems. He concludes:

  1. Current design systems thinking limits free, playful expression.
  2. Design systems uncover organisational disfunction.
  3. Continual design improvement and delivery is a lie.
  4. Component-focussed design is siloed thinking.

It’s true many design systems are the blueprints for manufacturing and large scale application. But in almost every instance I can think of, once you move from design to manufacturing the horse has bolted. It’s very difficult to move back into design because the results of the system are in the wild. The more strict the system, the less able you are to change it. That’s why broad principles, just enough governance, and directional examples are far superior to locked-down cookie cutters.

Intentional and Emergent Design Systems | Jordan Moore

This is a really interesting distinction:

An intentional design system. The flavour and framework may vary, but the approach generally consists of: design system first → design/build solutions.

An emergent design system. This approach is much closer to the user needs end of the scale by beginning with creative solutions before deriving patterns and systems (i.e the system emerges from real, coded scenarios).

It’s certainly true that intentional design systems will invariably bake in a number of (unproven?) assumptions.

The 2019 Design Systems Survey by Sparkbox

The good folks at Sparkbox ran a survey on design systems. Here are the results, presented in a flagrantly anti-Tufte manner.

How using component-based design helps us build faster

A case study from Twitter on the benefits of using a design system:

With component-based design, development becomes an act of composition, rather than constantly reinventing the wheel.

I think that could be boiled down to this:

Component-based design favours composition over invention.

I’m not saying that’s good. I’m not saying that’s bad. I’m also not saying it’s neutral.

Why your design system should include content | Clearleft

Rachel makes the case for integrating content design patterns into component libraries:

Instead of content design systems and visual design systems existing in isolation, the ideal is one design system that accommodates everything, marrying the content and design together in the way it will actually be used and experienced.

The Patterns Day Edition | Amy Hupe, content designer.

Amy’s talk at Patterns Day was absolutely brilliant! Here’s an account of the day from her perspective.

The evident care Jeremy put into assembling the lineup meant an incredible mix of talks, covering the big picture stuff right down to the nitty gritty, and plenty in between.

Her observation about pre-talk nerves is spot-on:

I say all of this because it’s important for me and I think anyone who suffers with anxiety about public speaking, or in general, to recognise that having a sense of impending doom doesn’t mean that doom is actually impending.

Patterns Day

Here’s a nice little round-up of Friday’s Patterns Day.

Weeknotes #16 | Trys Mudford

Just look at these fantastic pictures that Trys took (very unobstrusively) at Patterns Day—so rock’n’roll!

The audience and the stage.

Closing remarks.

The Clearleft crew.

Patterns Day notes

Stuart took copious notes during every single talk at Patterns Day—what a star!

Drop caps & design systems - Vox Product Blog

Sit down and listen to a story from uncle Ethan.

Baking accessibility into components: how frameworks help

A very thoughtful post by Hidde that draws a useful distinction between the “internals” of a component (the inner workings of a React component, Vue component, or web component) and the code that wires those components together (the business logic):

I really like working on the detailed stuff that affects users: useful keyboard navigation, sensible focus management, good semantics. But I appreciate not every developer does. I have started to think this may be a helpful separation: some people work on good internals and user experience, others on code that just uses those components and deals with data and caching and solid architecture. Both are valid things, both need love. Maybe we can use the divide for good?

Complexity Explorables

A cornucopia of interactive visualisations. You control the horizontal. You control the vertical. Networks, flocking, emergence, diffusion …it’s all here.

Norbert Wiener’s Human Use of Human Beings is more relevant than ever.

What would Wiener think of the current human use of human beings? He would be amazed by the power of computers and the internet. He would be happy that the early neural nets in which he played a role have spawned powerful deep-learning systems that exhibit the perceptual ability he demanded of them—although he might not be impressed that one of the most prominent examples of such computerized Gestalt is the ability to recognize photos of kittens on the World Wide Web.

Who Are Design Systems For? | CSS-Tricks

Chris ponders the motivations behind companies sharing their design systems publicly. Personally, I’ve always seen it as a nice way of sharing work and saying “here’s what worked for us” without necessarily saying that anyone else should use the same system.

That said, I think Chris makes a good poin here:

My parting advice is actually to the makers of public design systems: clearly identify who this design system is for and what they are able to do with it.

Improving accessibility with accessibility acceptance criteria — Paul Hayes

Wouldn’t it be great if every component in your design system had accessibility acceptance criteria? Paul has some good advice for putting those together:

  • Start with accessibility needs
  • Don’t be too generic
  • Don’t define the solution
  • Iterate criteria