Against Superficial Simplicity (2022)
jarango.com
jarango.com
Contrast that to musical instruments where the "user interfaces" can be complicated, requiring years to master but they allow huge variations in how the music can be played in some cases.
There must be something in the middle. (?)
Second, there is a re-terminalization in developer land. Microsofts product line, from PowerShell via Term and MS Visual Studio Code is a good demonstrator. They tend to be controlled only by keyboard commands ("one big search bar") which can be super fast for power users but is also typically not very accessible. Interestingly, strong keyboard focussed interfaces never left in professional tools such as CAD (or think of Blender).
Other software has to smooth out the initial learning curve more aggressively. Yet other software doesn't or shouldn't, but unfortunately attempts to do so anyway.
Sure you can put UI toggles for each of those, but in any 3D application worth its salt those are going to be many toggles. And using the keyboard will always be faster, especially if you have to switch between different settings a lot (and you typically need to).
Even a trumpet with only three keys, has all sorts of shades of gray depending on far you press they key down, and your air pressure, how still you hold the instrument, etc.
I can imagine an UI that uses proximity to guide you with UI hints, but it wouldn't change the binary nature of the action being taken.
Some of this info is considered in analytics, like rage clicks, mad mouse movements, etc, but that doesn't change the result of the software.
I assumed for a while that our job, being to basically type in documents, would see very little interface change. And in practice some people are still rocking their fullscreen Vim/emacs setup. But most of us use a ton more tools, have yhem integrated into our workflows and our coding interface looks more often than not like a plane cockpit than a piano keyboard.
Same for drawing, it feels like it could be done with a pencil and a blank canvas, but looking at pros it's a flurry of input devices/buttons, dials, with tons of UI to assist them.
Our tools could be designed not to change too if there were some convention they abide. Things like project configuration, linting, debugging, formatting, code analysis and navigation. IDEs are great because of this, but they only support a handful of project types and languages.
I'm with you on the possibility, with the underlying assumption that we won't make any significant changes to our tools down the line.
On the piano example, electronic keyboards for instance look nothing like grand pianos, they come with external input, have a flurry of options and their whole interface is cryptic without the specific manual for the keyboard in front of you. There's the anecdote of the guy feeding Roland manuals to a LLM to then query for specific configuration options.
I think at some point there will be programmers on the side of "we have a fixed configuration that doesn't need to evolve anymore" grand piano style (I guess the people working on COBOL could be already there ?), and the rest of us more on the electronic piano side, embracing the chaos to get a more cutting edge technology.
A cash register software needs to be fast to learn AND fast to use. But the latter is more important than the former. Some phone app that is used once a week by your grandpa needs to be easy to use first of all. The software used by a flight traffic controller needs avoid mistakes first, be fast to use second and easy to learn last.
So it is important to figure out who is going to use your software and what their priorities are (or should be).
Very important note: Like there are solutions that are powerful and intuitive to learn, there are also solutions that are neither. You don't always have to trade one for the other. E.g. a text editor like vim totally traded the ease of getting into it for the power after. If someone were to make a similar editor today they could however easily create an editor that is intuitive to use by the beginner and allows similar powerful editing for the poweruser at the same time.
Software that is intuitive first usually has no depth. There is no additional, more powerful layer you can discover. And often this is an active decision. Often it is also a bad decision.
Violins have a few strings that you interface with a bow.
A piano is basically a slider split into finger sized segments.
Violins are quite simple though, also drums, brass.
Going by your logic brass instruments are insanely complicated. You have to invent metallurgy.
The problem being then discoverability.
This "article" is under 500 words, and says nothing that hasn't been said a million times before. It's just a dude _not_ moving the conversation forward at all. "Hurr durr, low information density bad" is trite. I've known that for 20 years now. It's boring. It's short because the author has to write one of these every fortnight. No one has that many new ideas and things worth inflicting upon the world. The lad's a consultant, so this newsletter is just another self-aggrandizing tool te can boast about when he is charging speaking fees at sub-standard conferences of other such self-aggrandizers.
Seth Godin is the original perpetrator of this bullshit genre, and I wish that all of such one-bite quick-snack articles would burn to the ground. I seek something more intellectually rigorous.
That said, I disagree with your decision to see this line of work as dishonest, despite the higher tempo meaning they’re a bit more rote. They’re popular because they’re easy to digest, and i think that’s an important role!
Consider what this article is: they’re just trying to critique a particular design and explain the principles behind it. Not everyone already knows every design principle.
…IMO
This would be a much more credible pitch for his consultancy with an "Oh that's clever" answer to the problem.
1. go way way deeper into why this is good case to make
2. try to present at least an attempt to a causal hypothesis so people can be inspired to think in remedies and continue the discussion about these
Which brings us to the main source of disagreement. Define worse.
A confident developer or designer will often sell or even prove their simpler design is better. That's their job. But to be sold or convinced isn't the experience. Using the thing is.
It is the only way to close the loop. You need empirical approach somewhere as users come with a big bag of biases from other UIs.