I have worked with AS400, and its concept of an input queue is great. Basically, none of your inputs are ignored if the system is busy, they are cached by the terminal and sent one by one when the system responds.

To give you an example, imagine hitting Ctrl-Alt-Del, entering your login and password, hitting Enter, entering FFOX to run Firefox, hitting Enter, hitting F3 to open a tab, entering news.ycombinator.com, hitting Enter, hitting F3 for another tab, entering another URL, hitting Enter and it just works. Your machine can be waiting to show you the login screen, or applying some global policies, or launching Firefox, but it will never lose your input.

I do enjoy this aspect about terminals - how you can type a few lines with enters while a long running process is executing.

However, I wish there was a way to ignore (or cache?) this buffered input if the process exits with an error or something else of the sort. Does this exist?

It can quickly get dangerous otherwise!

I worked on an AS/400 system 4 years ago during an high school internship in Italy. It's still used in a medium-size company. It was painful at first but since my first language was Pascal the difference was bearable. Sure it helped me with my formation as a young developer. Anyway, it was fast and sure AS/400 still can be competitive but in a business pov it is a mess: there are almost no developers with an adequate formation and the old developers are close to retirement. My main accomplishment was to run battleship and some other games, I'll find the link with the library to install if I have time.

I developed for AS400s back in the day and IMHO only the iPad comes close to the consistent UI that data entry workers need and expect. I remember my employer introducing a Windows GUI front end and being told by major customers that they needed to offer green screen entry again or they would buy my employer and make them do it.

A relative of mine works at a not-so-small place (some 100s of terminals) that used to run AS400s. Years have passed, but It's still green screens galore. He explained me that most of the personnel have memorized the menu so well that they can do their job without hardly ever looking at the screens. Changing that would spell catastrophe in terms of re-training and lost productivity alone.

My father worked on AS/400 applications as a project manager. When they moved to Windows he changed job, but still in the same field. Among his former users, the preferred replacement was Visual FoxPro applications that looked pretty much exactly like the old AS/400 programs---not any newfangled client/server or browser-based thing, even though there were already some available.

> She hated the move to Windows. All the sudden, everything was slow, error prone, fiddly. Keyboard navigation was mostly gone and although employees could start working with less training, she knew the move was generally a big step backwards.

She was right.

Autohotkey can solve a lot of these problems.

Though it can require some politics playing to accept it as a legitimate tool.

Autohotkey is wonderful (and I can relate to the issue of getting it accepted as a legitimate tool). I also think that the beauty of the AS/400 UX is beyond just keyboard shortcuts. It probably has more to do with consistency, context awareness and that the most important functions are reliably available everywhere. But I never worked with it myself, I only have looked over the shoulders of some green screen users, so maybe there is more to it.

Another thing is that the WIMP (Windows, Icons, Menus, Pointer) paradigm was, at least in part, born because of the insight that the block oriented approach of the green screen terminals wouldn't scale beyond a certain point. I'm more interested in the ideas that made IBM 5250 like UX successful than in a modern interpretation of it. Using keyboard shortcuts is certainly one of these ideas and so is tiling windows instead of stacking them.

> I'm a UX designer/developer. There is something to be said for these old terminal systems, when it comes to repetitive daily tasks.

Out of curiosity, are you then employing the experiences of your mother when designing user interfaces?

I'm a programmer, and I rarely design anything more complex than a static website or a CLI. I have no illusions about UI design being easy. However, I am disappointed that it seems most UI designers, whom I do assume to be competent, are working on UIs that are optimised for ease-of-use by the novice, rather than the expert.

I use and enjoy several programs that have "expert-optimised" UIs. Emacs is one, and the Unix shell is another. However, these are grown in an ad-hoc way, usually by people who did not think too hard about UI. I wonder what an optimised expert-oriented UI would look like, if it were developed by true UI experts.

Terminal-style input queueing is made impossible by the OS most of the time. You can't queue input commands for a window that hasn't appeared yet, because they get sent to some other window that currently does have the focus. Per example upthread:

> imagine hitting Ctrl-Alt-Del, entering your login and password, hitting Enter, entering FFOX to run Firefox, hitting Enter, hitting F3 to open a tab, entering news.ycombinator.com, hitting Enter, hitting F3 for another tab, entering another URL, hitting Enter and it just works. Your machine can be waiting to show you the login screen, or applying some global policies, or launching Firefox, but it will never lose your input.

You'd have to wait after starting firefox for it to appear to get your input queued correctly.

Within a browser you can mostly hit Ctrl-T and start typing, although I've seen this break down. Edge for some reason was bad at this.

Within websites there is often anti-user javascript which causes problems: the absolute worst offender is Facebook, after you've put focus in a text box you need to wait for it to settle or your text will come out in the wrong order.

Well, Windows (and all window-based, graphical UI) encourages you to use the _mouse pointer_ with it's clumsy properties like navigating a visual field and upon locating an interactive element, using at most 5 different action buttons (clicks and scrolls).

Compared to that, these old systems were modal (edit, browse, etc modes) and keyboard-based with it's ~100 action buttons, where pixel-by-pixel navigating was not needed.

From an efficiency standpoint, petting a computer with mouse-based navigation is ridiculous. It might help a newbie until they explore a software's features but later on it's a waste of time. And your mother knew this very well.

Those old modal interfaces were dead ends that ultimately didn't scale. Try using a CAD program sometime, or for that matter even a spreadsheet, without a mouse.

You missed the "pixel by pixel navigation" part.

There are obviously a plethora of use cases (mostly graphic design software, games, etc) where a pointing device would benefit far much better.

OTOH I would love to see a vim-like excel/spreadsheet software.

My first job required the use of an AS/400 for data entry. Hated it at first, but really grew to appreciate it for what it did. That single machine ran an entire manufacturing site. When we were forced to use a Windows front-end to enter data, it was an order of magnitude slower, it was that cumbersome and inefficient. Other front-ends, doing real-time visualisation of the plant operations were actually useful. But the AS/400 fills an important niche, and it's one which I don't think modern systems do a good job at replacing.

My father's employer moved from an AS/400 to some poorly implemented Oracle system about a decade ago.

Hates it every day and still gives me examples of how the old system was superior and faster.

Fastest UI for expert users (fastest to slowest):

Keyboard > Mouse > Touch > Voice