I spent almost 10 years doing IT for a company whose backend was based entirely on as/400. If you've ever used a system like that, I'm sure you know where this is going...
The console's that the front-desk or clerical users used every day had a steep learning curve. It was something that you would definitely not be able to walk up to and just intuit.
However, once you figured it out, there is never going to be a faster UI that you are ever going to experience in your life until we figure out direct BCI stuff.
It was funny watching the new people come on board and insist that we should change the UI to something with a mouse (probably web based). They had no idea that more immediately intuitive was actually a step backwards.
My point is that just because something has a steep learning curve, that doesn't necessarily mean that it's a bad design.
I work for a reservation systems company (a GDS) that is used by thousands of travel agencies. Of course, since the system was created 30 years ago, you were only able to create reservation with a text-based interface at the time, with short commands, inconsistent and complex flows to do some non-trivial things etc. So it's despised by newcomers because learning curve is steep.
However, the company has been building new web-based solutions for a while, but all of them have so called "cryptic mode" where you can still directly input the commands, as it is order of magnitude faster, mandatory feature for experienced old-timer travel agents.
"inconsistent and complex flows to do some non-trivial things"
Note that's a characteristic of bad design, not a characteristic of CLIs, where constraining the UI to GUI, will merely result in a hard to use GUI, instead of a hard to use CLI.
Note that in an email or printed page I can provide any CLI walkthru and anyone can follow with minimal training ("Which key is the any key?"), but some purely graphical GUIs are impossible to discuss verbally, especially if badly designed (see above, and realize the badly designed ones are going to need the most help).
First, click on the icon that looks like a Rhinotia hemistictus nose, except its green. No, not that, thats more of a myrtle color, you want the really bright green one. OK, now if you see a screen that looks like a Type II Seyfert galaxy then you've clicked thru too far and need to click back. Oh no, there's no left arrow icon to go back, we outsourced development to save money and in the programmer's culture a left arrow is an obscene gesture indicating you mate with your sibling, so our discount software uses a thoracic vertebrae, superior side up, for its back icon, isn't that hilarious a "back bone" to go back oh those UX guys crack me up every time. Something thats one line at a shell interface that could have been cut and pasted in, can involve an hour of talking back and forth about a bad GUI.
> "inconsistent and complex flows to do some non-trivial things"
> Note that's a characteristic of bad design, not a characteristic of CLIs
That's a characteristic of hundreds of developers creating features over dozens of years, and those features interacting with each other in subtle ways.
In my experience, even in small projects and codebases things get notoriously inconsistent very fast. It's a hard thing to keep, as it requires conscious effort and most developers don't care that much. And once something goes to production (or far enough in non-regression phase), it's a game over.
On top of that, AFAIU, in legacy systems, storage space was severely limited. Hence PNRs had a rigid structure that was not very extensible. That's another fact due to which implementing new features in a backward-compatible way might have been cumbersome.
You should see how Sabre handles email address with it's bizarre, limited, possibly 7bit character set from 1959.
In Sabre emails can be like 70 characters long. But periods count as two characters, as do underscores, and @ counts as four. I mean given the choice between period and cross of lorraine I know which I am choosing to include.
What character encoding do they use? ASCII is 7-bit, all those characters use 1 byte in ASCII, and of course email addresses were originally (and until recently?) restricted to ASCII.
There's certainly a trade-off between learning curve and long-term productivity. But the problem here is that vi/m gives shitty feedback, that's all. It should say "Press <ESC> and type :quit<Enter> to quit VIM" but it doesn't. Most first-time users lack a mental model of input modes, so they get stuck.
I think your are mixing steep learning curve with having keyboard shortcuts (whether they are commands or combinations of keys). You can have keyboard based shortcuts with any UI. Actually a UI with no shortcut is probably a bad design in the first place. A steep learning curve just means it is hard to learn, i.e. non intuitive, non discoverable. These are not qualities.
I just hate programs that change patterns that are standard everywhere else. E.g. 99% of software uses control+c and control+v to do copy and pasting, so of course software that maps it to something totally different is going to be very frustrating. The same thing with vim using nonstandard way of quitting.
Discoverability is another problem. You can have weird keyboard commands, but make it possible to find them without searching stack overflow. I miss when applications had a big bar at the top of all the commands you could do and their keyboard shortcuts. I'm on chrome right now, and copy and paste is hidden away in a menu. And the keyboard shortcut for it isn't mentioned. How do you think people learned the keyboard shortcut in the first place? Or apple phones have a bunch of gestures that are useful, but no one knows about because you can't discover them.
I'm well aware of that and the historical reasons that it's the case. I'm just using it as an example of breaking well established patterns that screw new users.
Don't worry, in few years new bindings will be familiar to new people straight from their birth date. Then they will complain about changes and you'll tell them that changes were made long before.
Shortly after the introduction of the first generation of brain-computer interfaces: "Why do I have to think of Ctrl-C to copy text in this program? All the other programs have me think of a banana to copy a selection!"
> I'm on chrome right now, and copy and paste is hidden away in a menu. And the keyboard shortcut for it isn't mentioned. How do you think people learned the keyboard shortcut in the first place?
Copy and paste are also in the right-click menu, and the keyboard shortcuts are shown there.
I hate VI not defaulting to wasd for movement like every other single piece of software I used growing up... (e.g. Quake, Marathon...) Ha ha ha. (Or should my games have used hjkl)?
Well it's not quite that simple because it's more complicated than those tools. Once you are in ex mode ':' though it uses the standard exit key.
As for if you stuck in insert mode, this is more akin to when you have text highlighted in a GUI editor, the shortcuts change because you're in a different mode.
Remember all editors have modes, vim is just a bit more in your face with them.
I worked on Z/OS mainframes for a couple of years and the point-and-shoot interface is indeed very efficient, once you've learned to use it.
The only thing I remember being really annoyed with was that there was no way (or no way I managed to find) to select all the text in a line in one go. The same was true for the editor (EZY). I kept pressing Ctrl + V to do a block-select and pasted all sorts of gibberish all over the place. Apparently, there are no line endings in text fields so it's not possible to get something like block-selection working.
But that was about the only thing that sucked from my point of view and I grew up with GUIs and touch-interfaces, like everyone else in my generation.
A bit late to the convo here, but one of the things that really impressed me about the Bloomberg (my employer) Terminal is how they manage this old user vs. new user problem well.
You can still do everything with the same keyboard shortcuts that have worked for 30+ years (pretty much everything with a number in front of it), and the layout of the screens generally don't change. But now everything on the mostly text-based view is clickable as well--everywhere you see a number you can click with a mouse.
Additional shortcuts are hidden behind menus, like "Settings" in the photo. But if you know the shortcut, no need to look at "Settings" first (which itself can be opened by typing 97 or clicking it).
If there is high turn over then the length of the learning curve is more important than the shape of it. Let's say there are two apps each with an employee starting, one requires two full days of training to be 90% proficient, the other allows for an instant start with a more gradual learning curve.
After 30 days of employment the first has spent 28 days at 90% efficiency, the other has had 7 days at 60% efficiency, 7, days at 80% efficiency etc.
A gradual learning curve could be much worse for companies with a high turn over.
The console's that the front-desk or clerical users used every day had a steep learning curve. It was something that you would definitely not be able to walk up to and just intuit.
However, once you figured it out, there is never going to be a faster UI that you are ever going to experience in your life until we figure out direct BCI stuff.
It was funny watching the new people come on board and insist that we should change the UI to something with a mouse (probably web based). They had no idea that more immediately intuitive was actually a step backwards.
My point is that just because something has a steep learning curve, that doesn't necessarily mean that it's a bad design.