It's not you. Bad doors are everywhere.

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]

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]

You take position of authority, criticize, but you are not educating. > The fields of art and aesthetics have a long, complex history and have been studied and written upon by thousands of intelligent scholars, designers, artists, philosophers, and religious figures. So, let me ask you, why should I care? I care about design e.g. "The Design of Everyday Things": [VIDEO] But what is it about aesthetics that is not subjective?

I often use doors as the introduction to understand affordances. It's crazy that we've had doors for 5000 years and we still make them hard to open. See "Norman Doors": [VIDEO] The Design of Everyday Things: [LINK]

Sometimes feature requests are actually bugs and can be illustrative of one not properly understanding design. But I think it is important how user feature requests are interpreted. They have a frustration that you might not be aware of but they aren't aware of all the code and constraints. It can even be in design, which is still important. Very often there is a way to resolve a feature request that is not what the user explicitly asks for. But to do that you have to read between the lines, and carefully. Of course, some people go completely the wrong way with this and cough Apple cough decide that they know what is best for the user. It's totally a hard balance to strike, but I think it is very common for it to be framed much simpler. There's the joke that the user is dumb, and maybe they are, but that doesn't mean the issue they face is. It's not always dumb when a person pulls on a door that says push, because it may actually be that the sign and design are saying different things[0]. And personally, I like when users suggest methods of resolving the problem. I might throw that in the garbage, but it can often give me better context clues as to what they're trying to ask for and really does tell me if they're thinking hard about the problem that they care about the product. They just don't have the same vantage point that I do, and that's okay. [0] [VIDEO]

> 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