It's not you. Bad doors are everywhere.

What people said

crote · 2025-02 · Recommendation

Yeah, but it's not supposed to. With good design it is immediately obvious whether the door is push or pull - even when the frame doesn't have any clear indications. For example, the door in [0] (apologies for the YT short) has no immediately clear hints if you look at the frame or handle. Both sides look exactly the same, so how are you supposed to know? Add a "push/pull" sticker you'll miss 90% of the time? The Vox vodcast(?) in [1] goes a lot further into the problem, starting from a very similar door. The solution is pretty simple, in hindsight: if they designed the door properly, you won't even be able to pull on a push door. Have a pull handle on the pull side, and a push plate on the push side. [0]: [LINK] [1]: [VIDEO]

Read the original HN comment ↗

WhitneyLand · 2021-10 · Recommendation

You probably don’t feel like you’re fighting your front door when you walk out of your house or apartment also right? All that means is that git tools, and your front door, work well once you have mastered them. The ease of use and discoverability of tools over the life of their learning curve is what determines if they are a Norman door. For lots of people, using a Unix command line or Git for the first time feels like a Norman door. This is why other interfaces exist (like guis) for the same tools. What is a Normal door - 5 min Vox short [VIDEO]

Read the original HN comment ↗

godelski · 2024-09 · Reference

> If there were some kind of usage study or telemetry This still wouldn't convince me because it's not what my argument is about. (Fwiw, I think one of the reasons BS is upset is how frequent the issue is brought up. You can see his frustration in the GitHub issues too. And how he points to it being at the top of the readme and it still doesn't get through to people. Just like a sign on a door saying pull. There's a reason that doesn't work. Why literate people keep failing. Ask why and how it can be prevented.) I know I'm miscommunicating but I'm really not sure how. Because it isn't about what most people do. It isn't about what most people what. I know this sounds odd, and maybe that's what's getting in the way. Maybe I shouldn't say error because you're thinking the tool has errored? How about user mistake? When user uses the tool wrong? When something unexpected happens? Any of these will substitute. It's all about when I user does something and it's not what they think they're doing. Similarly I understand how it appears I'm arguing for verbose by default, and in a way I am (I'm not blind to this lol), but I'm also not really. But when talking about verbosity in terms of programs I think we'd need to distinguish number of words from what kind of words. Though I think it's not uncommon for debug or warnings to be misclassified as info haha. Design is about communication. Any command you enter gives you feedback. Returning nothing or returning too much are feedback, the t

Read the original HN comment ↗