[ethbr0]

The problem is modern attempts to birfurcate UX into silos of efficiency-agnostic design art + implementation-only engineering.

If you call designers artists, remove objective KPIs, and give them free reign, you get one-button mice. Similarly, if you let engineers build something, you end up with git's cli.

In contrast, design and use been studied as a unified discipline since the early 1900s: https://en.m.wikipedia.org/wiki/Time_and_motion_study

Taking decades to reinvent a preexisting organizational wheel is why "Humble" should be a corporate value in every company: learn from the past.

I drive a 2015 Hyundai Genesis. Why? Because I test drove recent Infinities and Mercedes (and I can't stand Lexus' grill). Knobs with tactile bumps work.

> Social network VK offered music playing, but over the last 5-6 years the number of taps it takes to start playing grew from 3 to 6 or 8 if you need a particular playlist

(Cue MySpace laughing in the corner, smugly rocking zero-touch autoplay since the early-00s)

[tomrod]

> If you call designers artists, remove objective KPIs, and give them free reign, you get one-button mice. Similarly, if you let engineers build something, you end up with git's cli.

Am I in the wrong to think both of these are plenty functional to the point I like them?

A one button mouse functions a lot like a touchbad when you factor in meta keys (at least to my memory -- I've only ever used one in conjunction with schooling years due to low-Apple footprint). And having learned git cli recently, it seems to make sense to me.

But I agree generally -- silo boundaries can lead to poor results due to ignoring second order effects and holistic user experience (your users aren't siloed).

[ethbr0]

Regarding the optimal number of buttons on mice, I'd respectfully observe that the average number of human fingers on a hand is 5.

And as for git cli, I have no problem with it (conceptually or practically), but I also accept that most people aren't us.

It's moderately difficult to build something that's perfect for yourself: it's much harder to build something that's optimal for everyone not-you.

[culebron21]

I used Mercurial CLI in 2010-2016, before finally having to completely switch to git. I almost never had to memorize or look hg commands up. In Git, I routinely need to google that same answer on SO for flags. I do understand that it's the real inner machinery, and back in 2009 I did read how git works, but still cli is hard to remember.

[twic]

In some ways, the Git CLI is easier: whatever you're trying to do, the command you need is always "checkout".