Being easy to use and easy to learn are not necessarily the same thing. GUI's are generally easier to learn, but not necessarily the most productive once a typical user reaches the plateau of the learning curve. A UI designed to minimize hand and eye movements may have a longer learning curve than a GUI. The ideal solution may thus depend on staff turnover rate.

I think you'd be surprised how quickly people can pick up on an interface that is as simple as the kinds of TUIs we're talking about. These kinds of things were very common for all sorts of tasks throughout the late 80s and early 90s and I don't think I've ever heard of the learning curve being a problem.

Shift+F5 F10 F10 code Return.

How to look up unsold inventory on the system at the first job I worked in 1999.

There people there who could navigate 5 screens without looking until the system returned the result they wanted.

People are smarter than many give them credit, the computing revolution in business really started taking off in an era when computers booted to something like.

    C:\>

I’m not suggesting we throw out guis but we could do much better in some areas.

Those old green screen apps (CICs etc) supported enormous key stroke rates all right, with nary a mouse in sight.

But productivity was not as high as a rosy colored view of the past might suggest.

Operators had to be highly skilled. Entering a record for the East coast sales team would require remembering the code ESALES03. There were no helpful UI affordances of the modern age, e.g. fuzzy or free form searching.

So combine the two, there isn’t intrinsically a reason you couldn’t do either with a TUI.

I work on enterprise systems and try hard to keep things consistent, it’s amazing how much enterprise web stuff I’ve run into that doesn’t even handle tab order correctly on a form that is pure data entry.

It’s hard to go all in on keyboard because browsers are somewhat inconsistent on which key combos do what though.

Not sure the lesson here in going back to CLI. What designers need to do is to conduct research - interviews, observational studies, etc - to understand how and why people use their software and then create design alternatives.

Ignoring a learning curve for the sake of argument, the most effective UI's tend to be command-oriented. If you memorize the abbreviated commands, you don't have to traverse menu trees. Command-line interfaces can still have menus for newbies.

For example, pressing Enter or giving the command "m" or the fuller "menu" at the command prompt may give a menu similar to:

   1 - Search for employees (SE)
   2 - New hire (NH)
   3 - Department transfer (DT)
   4 - Etc.
   0 - Back to prior menu [app-wide convention]
   Command: __

Here newbies just enter menu numbers; but next to each menu is a shortcut command, such as "DT". After they get experienced, they start using the shortcut commands to jump across the menu tree as needed, they are usually global. It's like a Go-to (gasp!). The prior stuff is still on the screen for reference because they wouldn't get a menu when using the shortcut commands; it only shows up if you ask for one.

And the shortcuts may take optional parameters, such as "SE gar" to search for all employees with a last name starting with "Gar". (Without the parameter, they get a typical search form.)

Before GUI's, I worked with users directly to gradually fine-tune such gizmos, and after a while their productivity screamed. They loved me and even forgave my lack-luster people skills.

Many emacs modes use something akin to this (see magit as a stellar example). This makes learning it relatively easy (it's discoverable), but becoming a power user is still possible.

Yup. Magit is a stellar example of UI that's both discoverable and ergonomic. It shows you a popup with a list of options available to you at a given stage, with plainly visible keyboard shortcut. But it doesn't block or slow you down with this.

Say you're trying to show git log. The first time around, you'll press "?" to show the top-level popup, notice "l" is for logging, press "l", see the popup for logging commands, notice you need to press "l" again, press it. The next time around, you'll just press "l l" without thinking, and Magit will react as fast as you can type.

There are custom keyboards, they're just hard to find. The Devlin KMX-144 or the Logic Controls LK1800 come to mind. I'm sure there are others. You can use (n?)curses to make a terminal user interface.

I still prefer the web - just with the keyboard as a first class citizen.

I don’t think webapps can ever make the keyboard a first class citizen. The browser already has a bunch of keybindings.

Personally, I’ve never used a web app that I actually liked or trusted. Maybe it’s just me, but I’m always worried the page will time out or refresh or something.

Like imagine emacs or vim in a browser window, it would be horrible!

I wasn't going to mention qutebrowser[0] since I didn't think it was relevant, but it works well. Most of the keys in the browser can actually be rebound. With keyboards like I mentioned, the additional keys can be mapped to special key combos like `Alt+Shift+D` to avoid collisions.

It's also possible to map most or all of Chrome's (not sure about other browsers - but we're talking within the enterprise) keys can be rebound. Check out keycode.info - every key even ones like `Alt+D` and F1 and even `Ctrl+R` can be rebound and prevented from doing their normal function in place of something else!

[0]:https://www.qutebrowser.org/

Try vimium, I've been using it for years - as long as the HTML is semantically correct a surprisingly amount of the web is navigable.

No. Just mimic the speed, information density, and task-centricity.

Even a web app could do that in a pretty straightforward way with proper handling of keyboard events and tab order and a compact layout. "Press 1/2/3/4 to select a tab" is entirely doable in a web view.