You can, today, still go back to the can-to-can structure that a personal website, an RSS feed, and a browser provide. It’s not perfect. It leaves an enormous amount of signal unheard. It requires more work to find things, and to be found.
But you can do it. And I hope you do, in some way.
If you look at the available evidence, “craft at scale” is mutually exclusive with the kind of rapid and unending growth that’s the baseline expectation for traditional startups and public tech companies.
We’d say that’s obvious in other industries. Budweiser isn’t craft beer. IKEA isn’t heirloom-quality furniture. But we tend to treat software as immune to the typical relationship between quality and quantity.
Call me Cassandra:
The way that industry incorporates design systems is basically a misappropriation, or abuse at worst. It is not just me who is seeing the problem with ongoing industrialization in design. Even Brad Frost, the inventor of atomic design, is expressing similar concerns. In the words of Jeremy Keith:
[…] Design systems take their place in a long history of dehumanising approaches to manufacturing like Taylorism. The priorities of “scientific management” are the same as those of design systems—increasing efficiency and enforcing consistency.
So no. It is not just you. We all feel it. This quote is from 2020, by the way. What was then a prediction has since become a reality.
This grim assessment is well worth a read. It rings very true.
What could have become Design Systemics, in which we applied systems theory, cybernetics, and constructivism to the process and practice of design, is now instead being reduced to component libraries. As a designer, I find this utter nonsense. Everyone who has even just witnessed a design process in action knows that the deliverable is merely a documenting artifact of the process and does not constitute it at all. But for companies, the “output” is all that matters, because it can be measured; it appeals to the industrialized process because it scales. Once a component is designed, it can be reused, configured, and composed to produce “free” iterations without having to consult a designer. The cost was reduced while the output was maximized. Goal achieved!
James describes his process for designing fluid grid layouts, which very much involves working with the grain of the web but against the grain of our design tools:
In 2022 our design tools are still based around fixed-size artboards, while we’re trying to design products which scale gracefully to suit any screen.
I don’t like making unpaid contributions to a for-profit publisher whose proprietor is an alt-right troll.
Same.
I can see no good arguments for redirecting my voice into anyone else’s for-profit venture-funded algorithm-driven engagement-maximizing wet dream.
Despite growing pains and potential problems, I think this could be one of the most interesting movements on the web in recent years. Let’s see where it goes.
I’m getting the same vibe as Bastian about Mastodon:
Suddenly there was this old Twitter vibe. Real conversations. Real people. Interesting content. A feeling of a warm welcoming group. No algorithm to mess around with our timelines. No troll army to destory every tiny bit of peace. Yes, Mastodon is rough around the edges. Many parts are not intuitive. But this roughness somehow added to the positive experience for me.
This could really work!
The common way to talk about happiness is as a single scale: unhappy at one end, neutral in the middle, happy at the other end.
I think that model is wrong.
Instead, happiness and unhappiness are two separate, independent scales.
This is kind of a Utopia lite: pop in your minimum and maximum font sizes along with a modular scale and it spits out some custom properties for clamp() declarations.
James and Trys have made this terrific explanatory video about Utopia. They pack a lot into less than twenty minutes but it’s all very clearly and methodically explained.
Yes, I’m a sucker for pace layers, but I think Rich is onto something here, mapping a profession onto a pace layer diagram.
A fascinating four-part series by Lisa Charlotte Muth on colour in data visualisations:
I like this mashup of two diagrams: Stewart Brand’s pace layers and Stephanie DiRusso’s typology of design thinking.
An oldie but a goodie. If you think you’re getting statistically significant results from A/B testing, you should probably consider doing some A/A testing.
In an A/A test, you run a test using the exact same options for both “variants” in your test.
I love the idea of cultivating a sixth sense for the location of Sagittarius A.
(I bet Matt would get a kick out of Charlotte’s magnet fingers too.)
Well, this is rather wonderful! It’s like an interactive version of the Eames’s Powers Of Ten.
A handy tool for getting an overview of your site’s CSS:
CSS Stats provides analytics and visualizations for your stylesheets. This information can be used to improve consistency in your design, track performance of your app, and diagnose complex areas before it snowballs out of control.
I do think large tech companies employ JavaScript frameworks because, amongst other things, it saves them money at their scale. And what Big Tech does trickles down in the form of default choices for many others (“they’re doing it and are insanely successful, so mimicking them can’t be a bad idea”). However, the scale at which smaller projects operate doesn’t necessarily translate to the same kind of cost savings.
An ode to the network architecture of the internet:
I believe the DNA of resiliency built into the network manifests itself in the building blocks of what’s transmitted over the network. The next time somebody calls HTML or CSS dumb, think about that line again:
That simplicity, almost an intentional brainlessness…is a key to its adaptability.
It’s not a bug. It’s a feature.
Yes! I wish more web developers would take cues from the very medium they’re building atop of.
I must admit I’ve been wincing a little every time I see a graph with a logarithmic scale in a news article about COVID-19. It takes quite a bit of cognitive work to translate to a linear scale and get the real story.
“Serverless”, is a buzzword. We can’t seem to agree on what it actaully means, so it ends up meaning nothing at all. Much like “cloud” or “dynamic” or “synergy”. You just wait for the right time in a meeting to drop it, walk to the board and draw a Venn Diagram, and then just sit back and wait for your well-deserved promotion.
That’s very true, and I do not like the term “serverless” for the rather obvious reason that it’s all about servers (someone else’s servers, that is). But these three principles are handy for figuring out if you’re building with in a serverlessy kind of way:
- You have no knowledge of the underlying system where your code runs.
- Scaling is an intrinsic attribute of the technology; so much so that it just happens automatically.
- You only pay for what you use.
Abstraction; scale; consumption.