I've seen it many times, particularly in finance which still has plenty of VT100 applications.
The reason is that once you know the codes, you can navigate and enter data at a genuinely incredible rate. If you've ever watched an experienced operator on one of these applications you'd be amazed. For one loan processing application, the terminal was an order of magnitude faster than the Web-based interface that was being deployed.
The key here though, is "experienced". This is someone who has developed the knowledge and muscle-memory to operate at that speed. This also makes the system more brittle (and often harder to change). Critically, it also means it takes a lot of training and time for people to be productive.
The reason many big organizations dropped the terminals - they wanted to be able to train people quicker, not because it was more productive.
The example I put in there was loan applications, which are quite complex. Loan origination (especially Business Loans) is perhaps the most complex business process I've ever encountered.
Text terminal can provide superior user interface. They can be faster and very logical. When you use them several hours per day and master the system they surpass most modern UI's. Minimal distraction, fast access and less errors.
Good modern UI design uses common metaphors that make it easier to learn new systems that are used with mouse if you are familiar with metaphors. They are designed for the beginner. There is nothing that prevents modern UI designer from learning the lessons from old terminals and carefully crafting the application so that experienced users can use different screen layout with fast keyboard navigation. It's just very rare.
The worst thing about our modern GUIs, IMO, is that they've basically brought UI evolution to a screeching halt.
I don't think we've even begun to develop optimal user interfaces, and we won't as long as the "common metaphor" idea holds sway.
Think what it would be like if we applied that idea to the real world, so (e.g.) hammers, can openers, toilets, and bulldozers all had to operate using a common set of widgets. It's hard to envision, but I would bet a very large sum of money that the result wouldn't be optimal for any of those jobs.
That's what we've done with computer UIs.
Unfortunately, I don't see any real way out of the trap.
>Think what it would be like if we applied that idea to the real world, so (e.g.) hammers, can openers, toilets, and bulldozers all had to operate using a common set of widgets.
Only apps don't do that. Paint apps use brushes and canvases, spreadsheet apps use cell grids, music apps use notation views and piano rolls, writing apps use document screens, games use whatever invented controls and worlds, etc.
What is common is that a lot of stuff we do involves mere text and symbol manipulation (buying tickets, reading news, checking sports scores, entering customer data, etc). For those we use the same widgets, yes.
But in the real world we do build all kinds of stuff, from cars to boats, and from skyscrapers to bulldozers, to pinballs with nuts, bolts, screws, wires, glass panels, etc., too. A hammer is as useful for hanging a frame as it is for building a house.
No, they use skeuomorphic simulations of those things.
(edit, to expand a bit)
We have the capability to put anything on the screen that we can imagine, but we're not doing that. We're limiting ourselves to bad simulations of real-world tools. The "brushes" are just more of the same thinking that gave us "desktops", "file folders" and "trash cans". As others have noted, those things do make it easier for newbies to learn the system, and yeah, that's a point in its favor. It's just disappointing to me that we haven't come further than we have with respect to truly innovative interfaces.
You even see it in VR! You get the same menus, buttons, and whatnot, but, hey, now the components are rendered as high-resolution stereo images. Yay! I guess?
>No, they use skeuomorphic simulations of those things.
No, they don't. You don't paint moving some virtual drawn brush gizmo, taking to some "virtual water box" to wash it out, etc.
You paint moving a cursor (whether it has a brush icon is irrelevant and not skeuomorphic in the UI sense), and you control properties of the underlying line (color, spread, width etc) with some of them going far beyond what a real world brush can do.
>We have the capability to put anything on the screen that we can imagine, but we're not doing that.
That's because it's not convenient. Except if you have some cool new idea we haven't tried.
Unfortunately, I don't see any real way out of the trap.
Some new device or application will introduce a new metaphor or technology that eventually trickles into existing software. Unfortunately, last time this happened that new tech was touchscreens, and I fear voice is next. These are both regressions in efficiency for lots of tasks.
Nah. Green screens were great. Stuff today is crap.
How does a user interface? For a web site, primarily with a mouse. So, single touch input. For green screen they have an array of dedicated individual simultaneous input devices (known as "keys"). In addition, green screen often provides near-immediate response, whereas touchscreens can suffer from lag either in the physical interface or the unfortunate multiprocess operating system. Finally, green screen was designed to step quickly through the interface, where web requires lots of hunting around for what you want to do.
You simply can't interface better with an application than a single process dedicated application using fixed multiple inputs with immediate response. It's like web pages are a cart and horse and green screen is a race car.
The first job I took right out of college (I was kinda out of money and needed a job immediately) was at a polling company. You know, the obnoxious kids who call and say, "If an election were held tomorrow..."
Anyway, the place still used green screen terminals in 2006 (Mmm, with mechanical keyboards attached). In most cases, the only input required was a single number for each response, so once I'd memorized a script and the responses, I could get through a survey without looking at either the screen or the terminal.
Eventually the company shut down, and needing another job right away, I went to another polling company, who used a web interface for some reason. So there I had to use a vintage mouse (...which obviously did not bring the same joy as a vintage keyboard) to click radio buttons and check boxes and was, frankly, just a painful experience all around.
So, yeah, I agree, there are a surprising number of instances where an old terminal UI is significantly better.
From talking to the sales & service agents at ${COMPANY} after prototyping some 'New Generation' systems we determined that Web-based UIs had two advantages:
1. Multi-column layout with independent updates. Useful for presenting prompts and help information beside the main transaction window.
2. AJAX-style dynamic updates on data-selection.
Other than that there were few advantages to Web UI. In fact we had to spend some time developing Javascript functionality such as tab-order and F-key capture that are elementary, 'free' features with green-screen and which greatly improve transaction speed.
Any 5250 terminal emulator from the 1990s onwards offered copy-and-paste and multi-session capabilities so a Web UI didn't offer advantage there.
On what TUI systems is a multi-column layout not possible? On what TUI systems are dynamic updates not possible? In my experience, teletype or ssh is much better in this regard, as the systems use socket connections which support push, which allows updates to propogate faster and more efficiently than using http (I know, http2 improves this system, as well as websockets, but those are recent arivals and only serve to play catch-up).
I think that depends on what you mean by "good". Being able to complete transactions without taking your fingers off the keyboard is almost always faster.
So, if it's an application where the end user spends a lot of time, a green screen can be more efficient. Things like a call center, or the check-in counter at an airport, etc.
It does depend on a good text and boxes ui though. Green screens had things like pulldowns, copy/paste, etc.
And even if it weren't faster, it's more comfortable. As someone who spends the vast majority of his waking hours behind a screen, I can tell the difference between two days that involved a lot of mousing around and two days typing (I usually get to type most, but there are projects where I can't). I can only imagine what it must feel like if you have to use a web interface to move between pages all the time.
Me and three upvotes in however many minutes. Plus all the old ladies at the supermarket who can enter a product code into the terminal without even looking at the screen, because the rules for what element is focused are so simple.
I agree that terminals are more "productive". One of the reasons that the mouse based interfaces gained such traction is that the sales people pitched it as "you can teach someone to use this interface in X amount of time" where X is orders of magnitude less than using a terminal interface. Like saying that Nodepad is quicker to learn than Emacs or Vim. This is true at face value, the trade off is that you pay for it later on as people become productive with it. Alas, cutting down "training time" and the costs involved with this for new employees is something bean counters can measure.
As "more recent technologies", probably not. (At least as good) as the non-native, slowly-responding, glitchy web UIs that are so hip lately, most likely yes, especially when it comes to tasks like data entry and the like.
