This is related to something I have often wondered about modern user interface that try so hard to simplify things for the end user.
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.
This is something I always keep harping on about: Simplicity and the ability of something to explain itself (=be intuitive) is a positive quality in many domains. But since the iPhone got popular people try to use that UI paradigm everywhere, regardless of the downsides.
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.
Just my two cents for two trends I recognize: First, the ongoing unification of mobile and desktop UI, where the mobile users win features but the desktop users loose functionality. Large buttons or hamburgers instead of classical menu bars are outcomes of this trend.
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).
Keyboard focused paradigms like single key shortcuts (or key sequences) are super powerful in CAD. There are only so many ways how you could say your CAD tool to <rotate> the selected things around the <median> of the <X-axis> while <snapping> to the <increment>.
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 if it takes a hundred hours to become comfortable with an IDE, a DAW or a CAD tool, over the time a professional will spend using the tool in total that's usually a relatively small investment. Flattening the learning curve in such cases should never happen at the expense of "power use".
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.
I think because software UIs have essentially binary actions. You either click, or you don't. You are hovering or not. You save, or you don't.
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.
A nuance to this is musical instruments are designed to not change. That's a blessing in most aspects, but wouldn't fit with most of our work.
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.
> A nuance to this is musical instruments are designed to not change. That's a blessing in most aspects, but wouldn't fit with most of our work.
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.
> Our tools could be designed not to change too if there were some convention they abide.
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.
I'm not diagreein with you, but one should bear in mind that a piano essentially contains 88 copies of the same mechanism (with some exceptions). That brings you from 12,000 parts to 136 parts, which is much simpler to grasp. Of course, having 88 copies creates its own challenges.
Maybe this is not a pamphlet against superficial simplicity so much so that it is a criticism of implicit knowledge being used to declutter interfaces.
You know what I'm against? This modern trend of newsletters. This is what _I_ would call Superficial and Simple(-Minded). These legions of me-too wannabes trying to get you to Subscribe to theirs so you can receive their "3 pithy one-liners that I graciously grace you with every day" in your inbox.
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.
I respect this comment for being very aggressive while still, AFAICT, being within the HN rules lol. I also came to the comments with a “wait, does this make any sense…?” attitude.
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.
The paradox of KISS is that it makes things simpler... for the designers. Because they don't have to think about the cognitive psychology aspects of their work.
Superficial simplicity here could be thought of as worse outcomes with fewer abstractions. Succeeding at fewer does not guarantee better outcomes.
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.
