Link tags: stem

181

sparkline

The Design System Priority of Constituencies - Cloud Four

Jason applies my favourite design principle to design systems.

User needs come before the needs of component consumers, which come before the needs of component developers, which come before the needs of the design system team, which come before theoretical purity.

Also: how frickin’ cool is it that the Cloud Four office has the priority of constituencies emblazoned on the wall!

A History of Design Systems on the Web - The History of the Web

It’s great to see former Clearlefties like Nat, Paul and Anna rightly getting namechecked in this history of designing for the web in a systemic way. It’s a tradition that continues to this day with projects like Utopia.

The word for web is forest | New_ Public Magazine

The wood wide web has been a powerhouse metaphor for popularizing the mutualistic relationships of healthy forests. But like a struggling forest, the web is no longer healthy. It has been wounded and depleted in the pursuit of profit. Going online today is not an invigorating walk through a green woodland—it’s rush-hour traffic alongside a freeway median of diseased trees, littered with the detritus of late capitalism. If we want to repair this damage, we must look to the wisdom of the forest and listen to ecologists like Simard when they tell us just how sustainable, interdependent, life-giving systems work.

A beautiful piece by the brilliant Claire L. Evans.

The project of decentralizing the web is vast, and only just beginning. It means finding a way to uproot our expression and communication from the walled gardens of tech platforms, and finding novel ways to distribute the responsibilities of infrastructure across a collective network. But we needn’t start from nothing.

Dancing With Systems - The Donella Meadows Project

We can’t control systems or figure them out. But we can dance with them!

  1. Get the beat.
  2. Listen to the wisdom of the system.
  3. Expose your mental models to the open air.
  4. Stay humble. Stay a learner.
  5. Honor and protect information.
  6. Locate responsibility in the system.
  7. Make feedback policies for feedback systems.
  8. Pay attention to what is important, not just what is quantifiable.
  9. Go for the good of the whole.
  10. Expand time horizons.
  11. Expand thought horizons.
  12. Expand the boundary of caring.
  13. Celebrate complexity.
  14. Hold fast to the goal of goodness.

A Lifetime of Systems Thinking - The Systems Thinker

I don’t agree with all of the mythbusting in this litany of life lessons, but this one is spot on:

The best thing that can be done to a problem is to solve it. False. The best thing that can be done to a problem is to dissolve it, to redesign the entity that has it or its environment so as to eliminate the problem.

Remember that next time you’re tempted to solve a problem by throwing more code at it.

Design System Day, Thursday 22 July 2021

This looks interesting: a free one-day Barcamp-like event online all about design systems for the public sector, organised by the Gov.uk design system team:

If you work on public sector services and work with design systems, you’re welcome to attend. We even have some tickets for people who do not work in the public sector. If you love design systems, we’re happy to have you!

My 3 Greatest Revelations - Issue 102: Hidden Truths - Nautilus

Caleb Scharf:

Wait a minute. There is no real difference between the dataome—our externalized world of books and computers and machines and robots and cloud servers—and us. That means the dataome is a genuine alternative living system here on the planet. It’s dependent on us, but we’re dependent on it too. And for me that was nerve-wracking. You get to the point of looking at it and going, Wow, the alien world is here, and it’s right under our nose, and we’re interacting with it constantly.

I like this Long Now view of our dataome:

We are constantly exchanging information that enables us to build a library for survival on this planet. It’s proven an incredibly successful approach to survival. If I can remember what happened 1,000 years ago, that may inform me for success today.

GrilloPress - Don’t let your design system seem complete

The level of authority and professionalism in a design system helps sell it so teams use it. But increases the perception things are fixed. Done. And not open to change.

Meet Utopia: Designing And Building With Fluid Type And Space Scales — Smashing Magazine

An excellent explainer from Trys and James of their supersmart Utopia approach:

Utopia encourages the curation of a system small enough to be held in short-term memory, rather than one so sprawling it must be constantly referred to.

Fluid Space Calculator | Utopia

Type and space are linked, so if you’re going to have a fluid type calculator, it makes sense to have a fluid space calculator too. More great work from Trys and James!

Building Dark Mode | Product Blog • Sentry

Robin makes a good point here about using dark mode thinking as a way to uncover any assumptions you might have unwittingly baked into your design:

Given its recent popularity, you might believe dark mode is a fad. But from a design perspective, dark mode is exceptionally useful. That’s because a big part of design is about building relationships between colors. And so implementing dark mode essentially forced everyone on the team to think long, hard, and consistently about our front-end design components. In short, dark mode helped our design system not only look good, but make sense.

So even if you don’t actually implement dark mode, acting as though it’s there will give you a solid base to build in.

I did something similar with the back end of Huffduffer and The Session—from day one, I built them as though the interface would be available in multiple languages. I never implemented multi-language support, but just the awareness of it saved me from baking in any shortcuts or assumptions, and enforced a good model/view/controller separation.

For most front-end codebases, the design of your color system shows you where your radioactive styles are. It shows you how things are tied together, and what depends on what.

System fonts don’t have to be ugly /// Iain Bean

You don’t have to use web fonts—there are some pretty nice options if you stick to system fonts (like Georgia, Charter, and Palatino).

Interplanetary Lobbing

League tables for the game of probe-throwing currently underway in our solar system.

The league covers expensive hardware lob matches held between planets in the Solar System. Two dwarf planets have recently been admitted to the league and lost their first matches against league champions Team Earth.

Eleanor Lutz - An Orbit Map of the Solar System

A lovely visualisation of asteroids in our solar system.

People Problems | CSS-Tricks

I’d maybe simplify this people problem a bit: the codebase is easy to change, but the incentives within a company are not. And yet it’s the incentives that drive what kind of code gets written — what is acceptable, what needs to get fixed, how people work together. In short, we cannot be expected to fix the code without fixing the organization, too.

The 2020 Design Systems Survey by Sparkbox

These survey results show that creating and maintaining an impactful design system comes with challenges such as planning a clear strategy, managing changes to the system, and fostering design system adoption across the organization. Yet the long-lasting value of a mature design system—like collaboration and better communication—awaits after the hard work of overcoming these challenges is done.

SydCSS 7th Birthday with Ethan Marcotte - YouTube

A great talk by Ethan called The Design Systems Between Us.

SydCSS 7th Birthday with Ethan Marcotte

Built to Last

Don’t blame it on the COBOL:

It’s a common fiction that computing technologies tend to become obsolete in a matter of years or even months, because this sells more units of consumer electronics. But this has never been true when it comes to large-scale computing infrastructure. This misapprehension, and the language’s history of being disdained by an increasingly toxic programming culture, made COBOL an easy scapegoat. But the narrative that COBOL was to blame for recent failures undoes itself: scapegoating COBOL can’t get far when the code is in fact meant to be easy to read and maintain.

It strikes me that the resilience of programmes written in COBOL is like the opposite of today’s modern web stack, where the tangled weeds of nested dependencies ensures that projects get harder and harder to maintain over time.

In a field that has elevated boy geniuses and rockstar coders, obscure hacks and complex black-boxed algorithms, it’s perhaps no wonder that a committee-designed language meant to be easier to learn and use—and which was created by a team that included multiple women in positions of authority—would be held in low esteem. But modern computing has started to become undone, and to undo other parts of our societies, through the field’s high opinion of itself, and through the way that it concentrates power into the hands of programmers who mistake social, political, and economic problems for technical ones, often with disastrous results.

A walkthrough of our design system and how we got here | Kyan

It all started at Patterns Day…

(Note: you’ll probably need to use Reader mode to avoid taxing your eyes reading this—the colour contrast …doesn’t.)

The design systems between us. — Ethan Marcotte

Smart thoughts from Ethan on how design systems can cement your existing ways of working, but can’t magically change how collaboration works at your organisation.

Modern digital teams rarely discuss decisions in terms of the collaborative costs they incur. It’s tempting—and natural!—to see design- or engineering-related decisions in isolation: that selecting Vue as a front-end framework only impacts the engineering team, or that migrating to Figma only impacts designers. But each of these changes the way that team works, which impacts how other teams will work and collaborate with them.