Some babies have to be taught to nurse...

I'm pretty sure that won't stand in the way of somebody inventing a square bottle nipple and blaming the users for not using it properly.

And that's precisely why QA still exists and why it shouldn't be the devs. And yet, you'll still wind up with weird situations, despite your best efforts!

And some of that is because some users have been trained on some other bad UX.

and this is an incredibly valuable reason to have a technically simple UI, because it fundamentally limits the amount of stupid shit people can do, without it being the fault of the designer.

This is very perfectionist. Let me install my doors the way it's comfortable or pleasing. Where I see a knob I'll reach. And where I see a "pull" sign I pull, or get contex clues.

There is research for everything, let's say it's more comfortable to push and the knob is on the right side for me. I could spend way more time and effort than thia desrves to apeal to that study, "I have great UX", I'd tell myself. But then I'd show this product on some eastern market where they read in "reverse" and it'll not be comfortable nor "100% natural" for them. Meaning, I'd fail, my UX'd be horrible for half the planet.

This might be worth for universal things, that are already researched and you don't need to spend years and a kidney to figure out. Like maybe how are "next", "cancel" and "back" buttons are next to each other. But I mean.. just copy the most recent you used.

there's a difference between trying to open a door from the hinged side, vs designing a door that has 14 different deadbolts, and three latches on it.

One of those is user error, the other is designed complexity generally being a hindrance to the user.

"Wrong way" for whom?

In Software Development it ultimatelly boils down to "are making software for the end users or are you making it for yourself?"

Because in your example, that's what ultimatelly defines whose "wrong" the developer is supposed to guide him/herself by.

(So yeah, making software for fun or you own personal use is going to follow quite different requirement criteria than making software for use by other people).

"Ugh, it works, but it was overly complicated to get what I needed."

Yes you should. I think most comments here are about products that have millions of users where it's actually worthwhile spending all that extra time and money to perfect things.

For most development, it isn't worthwhile and the best approach is to wing it, then return later to iterate, if need be.

The same goes for most craftsmanship, carpentry in particular. A great carpenter knows that no-one will see the details inside the walls or what's up on the attic. Only spend the extra time where it actually matters.

It triggers me immensely when people say "I could have made a better job than that" about construction work. Sure maybe with twice the budget and thrice the time.

floating WMs are intuitive, but the problem is that they're an incredibly mediocre solution, and the way that problems are often solved around one, is just entirely asinine. Let's build ten different ways to do the same thing, now we have 10x the code to build and maintain, and it's 10x more confusing to the end user who probably won't know about half of them, because 90% of our documentation is redundant!

Tiling WMs have significantly less issues with this, because they often have a very strict set of management rules, and only those. Nothing more.

i'm not sure that's a CLI problem, sounds more like an application problem from what i'm hearing.

Thanks a lot!