Adam Silver has an article titled “Do you trust design advice from ChatGPT?” wherein he prompted the LLM: How do you add hint text to radio buttons? It gave various suggestions, each of which Adam breaks down. Here’s an an example response from ChatGPT: If you want the hint to appear when the user hovers on the radio button, use a tooltip for a cleaner design Adam’s response: ‘If you want’ Design is not about what you want. It’s about what users need. ‘use a tooltip’ If a hint is useful, why hide it behind a difficult-to-use and inaccessible interaction? ‘for a cleaner design’ Design is about clarity, not cleanliness. Adam’s point-by-point breakdowns are excellent. The entire article is a great example of how plausible-sounding ideas can quickly fall apart under scrutiny from an expert who reframes the issue. It’s funny how prevalent this feels in our age of fast-paced information overload. You read an argument and it seems rational — that is, if you don’t think about it too long, which who has the time? But an expert with deep experience can quickly refute these mediocre rationales and offer a more informed perspective that leaves you wondering how you ever nodded along to the original argument in the first place. Humorously, it reminds me of the culture of conspiracy theories where the burden of proof is on you to disprove the bare assertions being made (a time-consuming job). Hence the value of experience (and what’s experience but an investment of time?) to pierce through these kinds of middle-of-the-road rationales. Experience helps clarify and articulate what lesser experience cannot see, let alone articulate. That all leads me back to Adam: ChatGPT pulls unreliable, uninformed and untrustworthy design advice from the internet and delivers it with confidence. I mean you can certainly listen to its advice. But I think it’s better to develop the instinct to ask the right questions and be able to recognise bad advice when you see it. There’s no shortcut to gaining experience. You can’t consume enough content to get it. You have to do. Email · Mastodon · Bluesky

I recently finished Carlo Rovelli’s book “The Order of Time” and, of course, had a few web-adjacent thoughts come to mind. Who says lessons from physics can’t be applied to making software? (I know, nobody is actually dying on that hill.) A Weakness of Being Data-Driven Being data-driven is the most scientific way of building products? Hold that thought: The ability to understand something before it’s observed is at the heart of scientific thinking. If you can only imagine that which you can observe, understand, and measure, you’re limiting yourself. If you can only believe that which you can observe, then you’ll only ever understand that which you can see. Abstract thought can anticipate by centuries hypotheses that find use — or confirmation — in scientific inquiry. Beware the Prejudice of the Self-Evident The things that seemed self-evident to us were really no more than prejudices. The earth is flat. The sun revolves around the earth. These were mistakes determined by our perspective. There are undoubtedly more things that seem self-evident now, but as we progress in experience and knowledge we will realize that what seems self-evident is merely a prejudice of our perspective given our time and place in the world. There’s always room to be wrong. Children grow up and discover that the world is not as it seemed from within the four walls of their homes. Humankind as a whole does the same thing. Asking the Wrong Questions When we cannot formulate a problem with precision, it is often not because the problem is profound; it’s because the problem is false. Incredibly relevant to building software. If you can’t explain a problem (and your intended solution), it’s probably not a problem. Objectivity Is Overrated When we do science, we want to describe the world in the most objective way possible. We try to eliminate distortions and optical illusions deriving from our point of view. Science aspires to objectivity, to a shared point of view about which it is possible to be in agreement. This is admirable, but we need to be wary about what we lose by ignoring the point of view from which we do the observing. In its anxious pursuit of objectivity, science must not forget that our experience of the world comes from within. Every glance that we cast toward the world is made from a particular perspective. I love this idea. Constantly striving for complete and total objectivity is like trying to erase yourself from existence. As Einstein showed, point of view is everything in a measurement. Your frame of reference is important because it’s yours, however subjective, and you cannot escape it. What we call “objectivity” may merely be the interplay between different subjective perspectives. As Matisse said, “I don’t paint things. I paint the relationship between things.” Email · Mastodon · Bluesky

Web developers have been waiting years for traction in styling HTML form controls. Is it possible the day has come? Here’s Jen Simmons on Mastodon: My team is working on a solution — you’ll apply appearance: base and switch to a new interoperable, consistent controls with easy to override default CSS. They inherit much more of what you already have going on. And then you can override (even more of) those styles using new pseudo-elements. If you want the details, check out the working draft. It’s pretty cool what they’ve come up with, especially in the face of what is undoubtedly a Herculean task to balance developer desire against user preference while preserving accessibility standards. I applaud all involved 👏 That said, I have thoughts. Not new ones. I’ve voiced them before. And I’ll do it again. As developers, we’ve long been clamoring for this functionality: “We want to override defaults, give us more control!” But I wish there was equal voice for: “We want better defaults, not more control!” More control means you have to do more work. I don’t want to do more work, especially for basic computing controls. There are too many edge cases to think about across the plethora of devices, etc. that exist in the world wide web — it’s overwhelming if you stop to think about them all, let alone write them down. I want to respect user choice (which includes respecting what hardware and OS they’ve chosen to use) and build web user interfaces on top of stable OS primitives. Give me better APIs for leveraging OS primitives rather than APIs to opt out of them completely. That’s me, the developer talking. But there’s a user-centric point to be made here too: when you re-invent the look, appearance, and functionality of basic form inputs for every website you’re in charge of, that means every user is forced to encounter inconsistent form controls across the plethora of websites they visit. I’m not saying don’t do this. The web is a big place. There’s undoubtedly a need for it. But not all websites need it, and I’m afraid it’ll be the default posture for handling form controls. I don’t need different radio controls for every healthcare form, shopping cart, and bank account website I use. As a user, I’d prefer a familiar, consistent experience based on the technology choices (hardware, OS, etc.) I’ve made. As a developer, I don’t want to consistently “re-invent the wheel” of basic form controls. Sure, sometimes I may need the ability to opt-out of browser defaults. But increasingly I instead want to opt-in to better browser (and OS) defaults. Less UI primitive resets and more UI primitive customizations. I want to build on top of stable UI pace layers. Email · Mastodon · Bluesky

Here’s Gordon Brander in an article titled “Don't fork the ecosystem”: Most of our software has been shaped by chance decisions made in haste by people who could not have predicted how the system would end up being used today. And if we could rebuild those systems today, knowing what we know now, we’d invent a whole new class of problems for ourselves twenty years from now. Software can be rebuilt, because software is a machine. But a software ecosystem is not a machine. It is a living system. When we attempt to rebuild the ecosystem, we’re making a category error. We confuse the software for the ecological process unfolding around it. Seems akin to hiring and firing. People are not cogs in a machine. Team dynamics are disrupted when people leave, as an ecosystem is being tampered with. When I was a kid, I did not understand why we couldn’t “just” go back to the moon. We’d already done it once before. So if we’d done it before, can’t we just do it again? I thought of it like riding a bicycle: once you know how to do it, can’t you just do it again whenever you want? Only as I grew older did I come to understand that an entire ecosystem of people, processes, tools, organizations, experience, storehouses of knowledge, and more made it possible to go to the moon. And you can’t just turn that back on with the flip of a switch. I was confusing the artifact (a human being on the moon) for the ecosystem that made it possible (NASA, contractors, government officials, technology, etc.) Carrying forward old baggage offends our sense of aesthetics, but hey, that’s how evolved systems work. Chickens still carry around the gene for dinosaur teeth. This is because a living system must be viable at every evolutionary stage. It can never pause, reset, or make a breaking change. The path of evolution is always through the adjacent possible. Lesson: the web isn’t an artifact. It’s an ecosystem. Don’t break the web. Email · Mastodon · Bluesky