Growing—that’s a word I want to employ when talking about my personal sites online. Like a garden, I’m constantly puttering around in them. Sometimes I plow and sow a whole new feature for a site. Sometimes I just pick weeds.
Most of my favorite websites out there are grown—homegrown in fact. They are corners of the web where some unique human has been nurturing, curating, and growing stuff for years. Their blog posts, their links, their thoughts, their aesthetic, their markup, their style, everything about their site—and themselves—shows growth and evolution and change through the years. It’s a beautiful thing, a kind of artifact that could never be replicated or manufactured on a deadline.
This part of the web, this organic part, stands in start contrast to the industrial web where websites are made and resources extracted.
Working in a big organization is shocking to newcomers because of this, as suddenly everyone has to be consulted to make the smallest decision. And the more people you have to consult to get something done, the more bureaucracy exists within that company. In short: design systems cannot be effective in bureaucratic organizations. Trust me, I’ve tried.
Who hurt you, Robin?
Writing solidifies, chat dissolves. Substantial decisions start and end with an exchange of complete thoughts, not one-line-at-a-time jousts. If it’s important, critical, or fundamental, write it up, don’t chat it down.
This one feels like it should be Somebody’s Law:
If your words can be perceived in different ways, they’ll be understood in the way which does the most harm.
I’ve signed this letter.
The video of a talk in which Mark discusses pace layers, dogs, and design systems. He concludes:
- Current design systems thinking limits free, playful expression.
- Design systems uncover organisational disfunction.
- Continual design improvement and delivery is a lie.
- 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.
An Interview with Nick Harkaway: Algorithmic Futures, Literary Fractals, and Mimetic Immortality - Los Angeles Review of Books
Nick Harkaway on technology in fiction:
Humans without tools are not magically pure; they’re just unvaccinated, cold, and wet.
SF is how we get to know ourselves, either who we are or who we might be. In terms of what is authentically human, SF has a claim to be vastly more honest and important than a literary fiction that refuses to admit the existence of the modern and goes in search of a kind of essential humanness which exists by itself, rather than in the intersection of people, economics, culture, and science which is where we all inevitably live. It’s like saying you can only really understand a flame if you get rid of the candle. Good luck with that.
And on Borges:
He was a genius, and he left this cryptic, brilliant body of work that’s poetic, incomplete, astonishing. It’s like a tasting menu in a restaurant where they let you smell things that go to other tables and never arrive at yours.
The hits keep on comin’ from Clearleft. This time, it’s Danielle with an absolutely brilliant and thoughtful piece on the perils of gaps and overlaps in pattern libraries, design systems and organisations.
This is such a revealing lens to view these things through! Once you’re introduced to it, it’s hard to “un-see” problems in terms of gaps and overlaps in categorisation. And even once the problems are visible, you still need to solve them in the right way:
Recognising the gaps and overlaps is only half the battle. If we apply tools to a people problem, we will only end up moving the problem somewhere else.
Some issues can be solved with better tools or better processes. In most of our workplaces, we tend to reach for tools and processes by default, because they feel easier to implement. But as often as not, it’s not a technology problem. It’s a people problem. And the solution actually involves communication skills, or effective dialogue.
That last part dovetails nicely with Jerlyn’s equally great piece.
This is great advice from Lindsay Grizzard—getting agreement is so much more important than personal preference when it comes to collaborating on a design system.
When starting a project, get developers onboard with your CSS, JS and even HTML conventions from the start. Meet early and often to discuss every library, framework, mental model, and gem you are interested in using and take feedback seriously. Simply put, if they absolutely hate BEM and refuse to write it, don’t use BEM.
It’s all about the people, people!
I know I should remain calm and sceptical about announcements like this, but …SQUEEEE!
In my experience, “full-stack developers” always translates to “programmers who can do frontend code because they have to and it’s ‘easy’.” It’s never the other way around. The term “full-stack developer” implies that a developer is equally adept at both frontend code and backend code, but I’ve never in my personal experience witnessed anyone who truly fits that description.
An organisation has formed here in the UK as a response to the increasing threats to the web:
We are called to come together in response to growing political and social uncertainty, direct threats to the profession, and a lack of vocal and proactive representation to organise as a representative, independent, and politically responsible industry body.
I like their manifesto; let’s put it to the test-o.
Joschi gives the backstory to last week’s excellent Material conference in Iceland that he and Brian organised. I love that this all started with a conversation at Indie Web Camp Brighton back in 2014.
Neither matters all that much and you can use every method on the same project without the universe imploding.
Some interesting approaches in the comments too.
An unfolding series of vignettes written by Danny Hillis back in 2010. It’s all very Borgesian.
Alla looks at a few different ways of organising the contents of a pattern library, based on her experience with the FutureLearn team.
The video of my talk on hypertext at the HTML Special before CSS Day. I’m pretty pleased with my delivery here. There’s a bit of Q&A afterwards as well.
I can certainly relate to everything Marc describes here. You spend all your time devoted to putting on an event; it’s in the future, coming towards you; you’re excited and nervous …and then the event happens, it’s over before you know it, and the next day there’s nothing—this thing that was dominating your horizon is now behind you. Now what?
I think if you’ve ever put something out there into the world, this is going to resonate with you.