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. (?)
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. (?)
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.
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.
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.