Eons ago, some time after I joined a division consisting of about 300 computer programmers, I became aware of the polarization between those programmers who used the native text editor (on Dec Vax or Apollo computers) or emacs or vi. Later, in the laboratory where I worked for 23 years, the vi people had by far the upper hand, and I was the sole emacs outlier. There was no hope of ever convincing these people that vi was the very epitome of a counterintuitive program, also one somewhat limited compared with Gnu Emacs anyway.
The intuitive view of a text editor is something like this:
1. Type lots of text
2. Save to file and close
So, when you open the text editor, you expect to just start typing.
But no, not with vi anyway. When you start the text editor you are in "command mode." To actually start typing, you need to type "A" or "I" to enter append or insert modes. Then, when you later exit from insert or append modes with Escape, the cursor moves back one, so if you intend to continue typing to the same stream you must remember to use the A option.
With emacs, more intuitively, you type right away, but causing special functions whenever needed with Command and Meta keys, or named operations. Exit and save? Control-X Control-C, then you have an option to save. That's all you need to know to use the program most basically. With other programs, you have to warp your mind with many new concepts just to do anything.
I could never understand why anyone would think vi to be superior. I long felt it was a sort of political thing. I think sort of that is why vi was even developed, by the BSD team, so they had an editor free of the Gnu copyleft, so they could use the more corporate friendly BSD license.
But I think really it's what people were raised with. If you happened to have been raised on vi, you would take it as your life's personal mission to raise your colleagues and successors with vi to be similarly hobbled.
I am thinking there are similar anti-intuitivities in Gimp, the now nearly standard image processing program (because it's free, of course). Last night I struggled to create a page with text located in the right place. If I didn't get it in the right place to begin with (which of course I never do) I could absolutely not move it. I could try to "select" the text all over again, but then instead of moving the text the mouse moved the entire page underneath, a function whose value I still haven't figured out. Sometimes when I tried to save the image with text in it, I got a box around the text which I had not been intended (I never stroked any such box, I've been finding that function impossible to use also).
Now I discover that part of the magic (but rarely mentioned until after you listen to an hour of complicated re-setup designs on tutorials) is that you must de-select everything after creation, to "release" it down upon the current layer. Only then does the select box go away. In every other program I've encountered, de-selection is axiomatic upon clicking anywhere else or doing anything else. But not in Gimp. There's a control character for de-select, or you can choose de-select from the Selection menu.
So I've finally worked out that problem after hours of frustration. How much longer to the creation of a simple page with text blocks and colored circles?
I had these dreams I would use the bucket to fill the entire background with some non-white color. First of all (using the 2016 version) I couldn't figure out how to select any color at all, I had to bring up another page with a picture and use the color chooser on that. So finally I've picked up the color I want as the "foreground" color, and I try to paint the background with it.
Nope, without any explanation the bucket refuses to dump any paint color into a background region. You can tell it's not going to because it has a NO sign on the mouse "pointer" (which is a combination of nearly impossible to interpret symbols regarding which it's not obvious which is the actual "point" that's being pointed to). But why, and how are you supposed to color the background?
Well now it appears in the complicated dialog in which you create a new image there's also a box for the background color. So you really need to do that, I guess (or maybe in the above case it was simply a de-selection problem).
This gets to one of my pet peeves in interface designs. There is one and only one correct way of doing things, and if you try to do things any other way you will be slapped. Such it was with the Lincoln I rented for a trip in Oregon in 2000 (which was mostly a pretty nice car btw). But if you tried to lock it with the dongle after already having locked it, for shame for shame, it would beep at you to let you know you should see your doctor about Alzheimer's. I'd re-lock doors all the time with my Toyotas when I can't remember whether I'd locked them or not, and it would just lock itself as it always did without protest.
So in my view, the User should be considered the final authority. Do what the user wants. If it requires changing some damned mode, change the damned mode, don't just beep or show the "naughty" sign. At worst there should be a helpful dialog respecting what you seem to be trying to do and advising of the correct way to do that, if it's even possible.
But the Make-The-User-Learn-His-Lesson approach is nearly everywhere, now that I think about it. In many cases it's make-the-user-learn-to-never-make-mistakes, even though that will never happen. For example, my (otherwise truly wonderful in every way, and so far long lasting at 14 years old) Whirlpool washer will refuse to change ANYTHING after a cycle is started. Even, say, the Rinse setting which won't start for many minutes. You can't just pause, you have to stop the washer completely for that. Then, even if it hasn't filled the basket with water yet, it will pointlessly need to drain all the water (including an impossible to estimate quantity of detergent) before you can change those settings.
Where to learn all these mind warping concepts about Gimp? It's not clear. Nobody ever starts with the basic concepts, like a Day -1 lecture in which you learn about things like object-oriented image programs and their selection-concepts. People start with all the bullshit you already had to solve (such as downloading and installing the program) even before you became aware you going to need a crash seminar just to do the most basic things.
Back in the olden days, there would be an O'Reilly textbook on whatever counter-intuitive but powerful Unix command you needed to know about (such as Awk for example) and it would be Pretty Good at introducing the basic ideas in the first section or so. Nowadays it's unclear where to go, there seem to be hundreds of books about Gimp and tens of thousands of tutorials, a veritable industry.
Gimp itself changed in many at least superficial ways back in 2018, and many of the books were written with the older version in mind. (Things have been far far worse with Sox, the sound processing program, in which the entire command structure seems to have changed about a dozen times, so if you web search for any answer you are almost certain to get something not relevant for your version.)
Actually, way back around 1995 I bought my first copy of Photoshop, and I struggled through the first chapter or so in the tutorial book, I could sort of use it. I can't remember if I ever used it, because by the time I really needed to use it, I was not longer using the computer that I had installed Adobe Photoshop on.
That's the way it has seemed for many commercial programs. By the time I learn how to use them, they are gone forever, replaced by something new and completely different that I have to learn, if not pay for, all over again.
I remember the giddy days when the Mac was introduced. Everything was going to be intuitive, simple, and you'd never have to learn anything else. That feeling lasted about a month maybe, at least for anyone else who hadn't become an instant devoted fan.
By then it had become clear to me (and seemingly nobody else) that the new Graphical Interfaces were ways of hiding, not exposing, the actual functionality. I got into arguments with the Manager of the User Interface Group of the company I worked for in 1985. He insisted that Graphical Interfaces with Dialogs were the only truly unlimited form of interfaces. They could do everything, whereas nothing else could.
Well that might be fine, but with the actual interfaces here on earth that we used, the options were ridiculously simple and non-useful compared with old Unix ways of doing things. And then when things like Adobe Photoshop appeared, the ridiculously simple became ridiculously complicated. Sure you could search for help...if you even knew what to start looking for.
Nowadays it's well understood that GUI's don't necessarily mean intuitive or easy to use. They are just considered necessary for the things non-technical people need to use. Only programmers and similarly technical people are expected and sometimes required to use command line interfaces.
I spent much of my career developing and enhancing such interfaces. It really seems to do anything serious technically you have to get into text in some way, though in theory you could do all your programming in some all-encompassing graphical development environment. But often it seems that real GUI systems leave out a few things that you can only control with text commands in one form or another (such as in configuration files). It sometimes seems they might do this deliberately to keep most people away from the inner workings, except for those who have to work on such things.
I think the basic problem is that graphical systems are simply too complex to do everything. But for the Users we take the trouble to wrap things up nicely in graphical metaphors. For the people down in the computer room, we more often use text interfaces, which we generally prefer anyway, and they are far and away by orders of magnitude easier to program too.
This article is not intended to be a full on critique of GUI and defense of CLI simply because I don't have time for that today. CLI's have many advantages including transparency (you can most often look at a succinct "history" of every previous command, and repeat and/or modify any of them) and power. I would put it like this: GUI is fine when you are not going to be getting fairly deep into things or doing things that are fundamentally graphic in the first place. In every other case, you are going to need some commands somewhere, such as for repeating common operations. It has been my feeling for some time that OSX has a pretty nice combination of BSD unix derived shell and tools and underlying system with snazzy GUI. But a good Unix/X combination would be fairly good too, if they could make a fairly nice one without a steep learning curve.
It was to my horror that in the glamorous roll out of Windows 95 that Microsoft marketeers were promoting the idea "and you'll never have to use this again" while dismissing the (relatively brain dead) MSDOS CLI. Now even Microsoft has upgraded shells (and you can run many of the others on Windows too).
But the fundamental problems in intuitive interface design I have always felt to be somewhat independent of whether the interface is GUI or CLI. It has more to do with intuitive underlying object models and how they are expressed.
