Baldur Bjarnason writes an immense treatise on the current sad state of software, grounded in the historical perspective of the past sad state of software.
Businesses focus on efficiencies—doing the things that net them the most money for the least effort. By contrast, taxpayer-funded public programs are designed and expected to cover everyone—including, and especially, the most marginalized. That’s why they’re taxpayer-funded; so they don’t face existential risk be eschewing profit-driven decision-making. Does this work perfectly? No. But I think about it a lot when people shit on the bigness and slowness of government. That bigness & slowness is supposed to create space and resources to account for the communities, that a “lean,” fast approach deliberately ignores.
Some good thought morsels from Robin on product design:
Bad product design is when folks talk more about the UI than what the UI is built on top of.
There’s a lot of talk about how great design is invisible—mostly boring conversations with little substance—but! I think that’s true when it comes to product design.
Bad product design is when your interface looks like your org chart.
How design fiction was co-opted. A piece by Tim Maughan with soundbites from Julian Bleecker, Anab Jain, and Scott Smith.
When your only tool seems like a smartphone, everything looks like an app.
Amber writes on Ev’s blog about products that deliberately choose to be dependent on smartphone connectivity:
We read service outage stories like these seemingly every week, and have become numb to the fundamental reality: The idea of placing the safety of yourself, your child, or another loved one in the hands of an app dependent on a server you cannot touch, control, or know the status of, is utterly unacceptable.
A short, snappy web book on product development from Ryan Singer at Basecamp.
Like Resilient Web Design, the whole thing is online for free (really free, not “give us your email address” free).
We have a tendency in our line of work to assume that what benefits us as developers translates to a benefit for those who use what we make. This is an unsafe assumption.
200 discarded objects from a dump in San Francisco, meticulously catalogued, researched, and documented by Jenny Odell. The result is something more revealing than most pre-planned time capsule projects …although this project may be somewhat short-lived as it’s hosted on Tumblr.
A deep dive into Pixar’s sci-fi masterpiece, featuring entertaining detours to communist propaganda and Disney theme parks.
The newest Gary Hustwit film is a documentary about Dieter Rams, featuring plinkity music by Brian Eno.
Rams is a design documentary, but it’s also a rumination on consumerism, materialism, and sustainability.
A nice walkthrough of a CSS grid in production. I was surprised to see percentages used as units—I wonder if it would feel “cleaner” if they were converted to
I really, really like the way that this straightforward accessibility guide is subdivided by discipline. As Maya wrote in the blog post announcing its launch:
Each person on a team, whether you’re a manager, designer, or developer, has a role to play. Your responsibilities are different depending on your role. So that’s how we structured the guide, with a separate section for each of five roles:
- Product management
- Content design
- UX design
- Visual design
- Front-end development
Prompted by his time at Clearleft’s AI gathering in Juvet, Chris has been delving deep into the stories we tell about artificial intelligence …and what stories are missing.
And here we are at the eponymous answer to the question that I first asked at Juvet around 7 months ago: What stories aren’t we telling ourselves about AI?
The transcript of a talk that is fantastic in every sense.
Fans are organised, motivated, creative, technical, and frankly flat-out awe-inspiring.
An interesting piece by Jessica Kerr that draws lessons from the histories of art and science and applies them to software development.
This was an interesting point about the cognitive load of getting your head around an existing system compared to creating your own:
And just because I’ve spent most of last year thinking about how to effectively communicate—in book form—relatively complex ideas clearly and simply, this part really stood out for me:
When you do have a decent mental model of a system, sharing that with others is hard. You don’t know how much you know.
Advice on building design systems:
- If you can avoid being ambiguous, please do.
- Favor common understanding over dictionary correctness.
- Make great operations a priority.
- Don’t get trapped in defining things instead of explaining things.
Great advice from Jen on writing a book:
- Write emails to Ted. Try to find a little comfort zone inside the larger uncomfortable task.
- Don’t write a Book. Write Chapters. Break a large chore into smaller tasks and focus on one at a time.
- Trap yourself. Set up a workspace that limits distraction and procrastination.
- Don’t despair the zero-word-count days. Give yourself credit for behind-the-scenes work, even self-care.
- Get amnesia. Keep your eye on the prize.