5 ms·

Another reason is because the simple text-based interfaces and terminals are also much more responsive. Some people prefer a snappy response over constantly mov

Another reason is because the simple text-based interfaces and terminals are also much more responsive. Some people prefer a snappy response over constantly moving their hand between the keyboard and mouse.

toast0 3y ago
Typically, the TUIs are also really good at consistently handling input, so even when they do get behind in processing the input, you can keep typing, and it will buffer inputs and catch up. There's often an attention key which is not buffered, and will dump the input buffer and stop any operations in progress, in case something is stuck. Even if a GUI does buffer input, it's unusual for users to be comfortable clicking where the buttons will show up, before they do. More frequently, click processing is separate from whatever else, and early clicks (or taps) are ignored or directed elsewhere.
- bombcar 3y ago
  I remember watching clerks at Fry's Electronics I think it was - they had PCs with windows on them, but all they ran was some sort of terminal emulator to access the system mainframe or whatever. You could ask them for a pick slip for whatever, they'd turn around, ask your name, type everything in in seconds, and then turn to the next customer; the computer would slowly plug along through all the screens and then print out the slip. They knew all the commands that far ahead.
  - toast0 3y ago
    Yeah --- Fry's used to be all real terminals, but I guess they ran out of equipment, so they ran a terminal emulator in Windows instead (almost always full screen, but modal popups from the printer? would break it out so you could see it was Windows). And the sales and returns terminals were usually setup so you could see them work. Cash registers were under the same system, but you usually couldn't see those. Word on the street was one of the Fry brothers had written that system, I think the server was a PC in the store somewhere (they did have some ability to check other store inventory, but I don't know how realtime that was) Airline service desks and vehicle/driver licensing are also popular places to have a well developed TUI along with experienced operators that will queue up a large buffer of inputs.
    - bombcar 3y ago
      At a company years ago we had a GUI that worked "well enough" but the dirty secret was it just sent keystrokes to an older TUI program that the C-level had decided was "too old looking and slow". A TUI isn't that far from an actual API, after all.
    - xp84 3y ago
      It always warms my heart to see these classic TUIs on a screen at a place like an airline service desk or a store. (Same as the non-IP Nortel Norstar phone systems that are 25 years old but still work that are in most supermarkets and department stores)
- masfuerte 3y ago
  GUIs used to handle keyboard input consistently so you could type ahead, even into future dialog boxes, if you weren't using the mouse. Unfortunately, this tends to be broken for modern GUIs using async frameworks.
  - wolpoli 3y ago
    This is a nice side-effect of running processing code on the GUI thread. I guess we can't do that anymore now we are dealing with network latency all the time.
kjellsbells 3y ago
This is massively important, especially for line of business apps or tools that the user touches hundreds pf times a day. GUIs are great when there are multiple, equally likely paths that the user could take. But LOB apps tend not to be like that: there is a mainline path (or very small number of paths) that dominates all others, and apps that let the user keystroke/tab/enter their way through these hot paths are waaaay fast. For US people, look at how fast the employee in your local Costco can look you up on their ancient-looking text app. You can do this in a GUI, or at least, you could in native apps, to some extent, with a series of tab presses to traverse the interface, and in the peak VB5 era this wast kinda ok, but not great, and webapps are a hot mess for this use case. If I'm shopping for flights, a gui webapp is great: lots of paths are valid, and i can poke around. If I'm a gate agent looking for the last seat on the plane out of O'Hare, I want speed.

toast0 3y ago

Typically, the TUIs are also really good at consistently handling input, so even when they do get behind in processing the input, you can keep typing, and it will buffer inputs and catch up. There's often an attention key which is not buffered, and will dump the input buffer and stop any operations in progress, in case something is stuck. Even if a GUI does buffer input, it's unusual for users to be comfortable clicking where the buttons will show up, before they do. More frequently, click processing is separate from whatever else, and early clicks (or taps) are ignored or directed elsewhere.

bombcar 3y ago
I remember watching clerks at Fry's Electronics I think it was - they had PCs with windows on them, but all they ran was some sort of terminal emulator to access the system mainframe or whatever. You could ask them for a pick slip for whatever, they'd turn around, ask your name, type everything in in seconds, and then turn to the next customer; the computer would slowly plug along through all the screens and then print out the slip. They knew all the commands that far ahead.
- toast0 3y ago
  Yeah --- Fry's used to be all real terminals, but I guess they ran out of equipment, so they ran a terminal emulator in Windows instead (almost always full screen, but modal popups from the printer? would break it out so you could see it was Windows). And the sales and returns terminals were usually setup so you could see them work. Cash registers were under the same system, but you usually couldn't see those. Word on the street was one of the Fry brothers had written that system, I think the server was a PC in the store somewhere (they did have some ability to check other store inventory, but I don't know how realtime that was) Airline service desks and vehicle/driver licensing are also popular places to have a well developed TUI along with experienced operators that will queue up a large buffer of inputs.
  - bombcar 3y ago
    At a company years ago we had a GUI that worked "well enough" but the dirty secret was it just sent keystrokes to an older TUI program that the C-level had decided was "too old looking and slow". A TUI isn't that far from an actual API, after all.
  - xp84 3y ago
    It always warms my heart to see these classic TUIs on a screen at a place like an airline service desk or a store. (Same as the non-IP Nortel Norstar phone systems that are 25 years old but still work that are in most supermarkets and department stores)
masfuerte 3y ago
GUIs used to handle keyboard input consistently so you could type ahead, even into future dialog boxes, if you weren't using the mouse. Unfortunately, this tends to be broken for modern GUIs using async frameworks.
- wolpoli 3y ago
  This is a nice side-effect of running processing code on the GUI thread. I guess we can't do that anymore now we are dealing with network latency all the time.

kjellsbells 3y ago

This is massively important, especially for line of business apps or tools that the user touches hundreds pf times a day. GUIs are great when there are multiple, equally likely paths that the user could take. But LOB apps tend not to be like that: there is a mainline path (or very small number of paths) that dominates all others, and apps that let the user keystroke/tab/enter their way through these hot paths are waaaay fast. For US people, look at how fast the employee in your local Costco can look you up on their ancient-looking text app. You can do this in a GUI, or at least, you could in native apps, to some extent, with a series of tab presses to traverse the interface, and in the peak VB5 era this wast kinda ok, but not great, and webapps are a hot mess for this use case. If I'm shopping for flights, a gui webapp is great: lots of paths are valid, and i can poke around. If I'm a gate agent looking for the last seat on the plane out of O'Hare, I want speed.