It's not you. Bad doors are everywhere.

> 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 tool communicating to you. That's why this is less about majority of the time and user preference. Most of the time I want to filter dotfiles. But I don't always and that still won't convince me because it's orthogonal to my argument. I think if you can see why you might understand my argument a bit more. Because you still seem to be focusing on it being about preferences when it's not. It's about the information users get back when they enter commands and what that means and tells the user. I know this sounds like preference, but it isn't. This is why I brought up Norman Doors before. I wouldn't fault someone for thinking a vertical bar on a door that you push is just preference because we don't talk about these types of language and just expect people to get it. But it isn't preference, it is bad design. I think if you watch this you'll understand my argument much better (it's 5 minutes haha). Because I think you'll understand why one could say that they way these doors are made are objectively bad but it looks like it's all about aesthetics ▶ this video So design isn't just about aesthetics, it is about language. Albeit an unspoken and unwritten one. > Maybe your issue with these tools is that the names of them shadow their coreutils counterparts, Please see my initial post. I think we've been talking so much that things got lost. > I'm not fucking around I will destroy everything We shouldn't get rid of sudo. But yes, requiring an explicit action to enter this mode is the design principle I'm discussing. > Hillel Wayne had a great post about it I didn't like the post tbh. His issue is better solved by writing a better comment. The comment is terrible and doesn't communicate what it needs to. But most people think they're far better at writing and communicating than they actually are. If I'm doubt, let my own comments serve as examples lol. It also has poor assumptions. Ones that work for him if he is the only one using the code but I think it's absurd to think a lack of comment will be reliably interpreted as intentional and holding meaning that the function is inefficient. It only works if comments are highly prolific. And a new person coming in will assume that it's just because of how common this is and it's a more likely explanation. But he's right about not using self documenting code in that cumbersome way. That is, as you say, too much. I do apologize. This conversation has been exhausting for me. Not reall

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]: ▶ this video

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] ▶ this video

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 ▶ this 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": ▶ this video But what is it about aesthetics that is not subjective?