When I started my first job in 1995, the old hands were still using DEC ALL-IN-1 [0] from terminals on their desks but it was in the process of being phased out (for Microsoft Mail or something on Windows for Workgroups), so I never got to use it myself.
Ask HN: Interesting TUIs (text user interfaces), maybe forgotten ones?
241–250 of 299 posts
Re: Ask HN: Interesting TUIs (text user interfaces), maybe forgotten ones?
#242If you are in the US, pick a slow day and chat to the customer service people at Lowes or Costco. Both stores use TUI interfaces for their instore service apps, and boy are they fast with them. They reserve GUI things for the self service point of sale systems and keep the TUI for cases where speed matters. I suspect that these apps might once have been mainframe hosted (in other words, screen-oriented, with the PC t…
> Both stores use TUI interfaces for their instore service apps, and boy are they fast with them. They reserve GUI things for the self service point of sale systems and keep the TUI for cases where speed matters.
What magic makes TUI faster than GUI?
TUI just use glyphs to render the interface. AFAIK that's not faster that a proper graphics engine.
Keyboard shortcuts are not exclusive to TUI.
Maybe if we would stop hyping UI gimmicks and put more focus on fundamentals, there wouldn't be so many bad GUI apps.
Re: Ask HN: Interesting TUIs (text user interfaces), maybe forgotten ones?
#243If you are in the US, pick a slow day and chat to the customer service people at Lowes or Costco. Both stores use TUI interfaces for their instore service apps, and boy are they fast with them. They reserve GUI things for the self service point of sale systems and keep the TUI for cases where speed matters. I suspect that these apps might once have been mainframe hosted (in other words, screen-oriented, with the PC t…
If one were to start a project from scratch today, with the goal of having such a hyper-efficient TUI, similar to the Lowes/Costco ones, to be accessible via SSH/Telnet/locally... are there frameworks out there to use? Would my best bet still be ncurses? Are there simpler alternatives?
I’ve thought about this a lot. I’d use the default system GUI but build in an optional command line.
Re: Ask HN: Interesting TUIs (text user interfaces), maybe forgotten ones?
#244In stark contrast to most GNU/*nix tools, I really liked MS-DOS's edit.com text editor. Unlike emacs or vim or even nano, it didn't have a bunch of invisible shortcut keys, just a Windows-like drop-down menu system (but rendered in DOS). You could easily browse through the menu hierarchy, but still memorize certain shortcuts that you often use (just like Windows). In later versions you could even use the mouse to sel…
Yeah, the Unix tools' unfriendliness comes from their history of being developed for a literal teletype, i.e. the computer's output would come out on a roll of paper, not a screen. In that environment you want to be very conservative with your output and can't really show a help screen. At least Vim tells you a couple of basic commands to get started with on its splash screen - ":q" to exit, ":help" for help. It still suffers from really poor discoverability and the fact that if you don't get you have to type a colon first, but interpret it as part of the help phrase and just press "q" on its own, you enter macro recording mode. Or bring up the history with "q:". Thinking about it, it should be pretty easy to add a menu bar showing the GUI entries, but experienced users obviously have zero incentive to do that.
Re: Ask HN: Interesting TUIs (text user interfaces), maybe forgotten ones?
#245If you are in the US, pick a slow day and chat to the customer service people at Lowes or Costco. Both stores use TUI interfaces for their instore service apps, and boy are they fast with them. They reserve GUI things for the self service point of sale systems and keep the TUI for cases where speed matters. I suspect that these apps might once have been mainframe hosted (in other words, screen-oriented, with the PC t…
> Both stores use TUI interfaces for their instore service apps, and boy are they fast with them. They reserve GUI things for the self service point of sale systems and keep the TUI for cases where speed matters. What magic makes TUI faster than GUI? TUI just use glyphs to render the interface. AFAIK that's not faster that a proper graphics engine. Keyboard shortcuts are not exclusive to TUI. Maybe if we would stop h…
It's not keyboard shortcuts, it's pure keyboard input; an important distinction to make, as with modern GUI interfaces, keyboard input is often an afterthought.
Re: Ask HN: Interesting TUIs (text user interfaces), maybe forgotten ones?
#246From the pre-GUI era, one favorite would be Ken Thompson's text editor "ed". It's built with a print output in mind and it doesn't show you the text itself by default. You'd have to target a line range and specify an action such as replacement or even to print it out to screen or paper; using the now famous g/re/p pattern. The minimalism is really cool. ed is still around as a vital part of the vim text editor to thi…
That's not what is commonly meant by "TUI". But as you mentioned, these old UNIX tools were really meant to be used with output printed to paper, which formed part of their "user interface": With CRT terminals, they actually become less usable, since anything that scrolls off the screen gets lost (even today in a terminal window, there is usually a limit to how far you can scroll back).
And I feel like all those UNIX lovers going on and on about how efficient command line tools are don't get this at all. For a command like "replace 'foo' with 'bar' in lines 1237-1451" to make sense, you either need superhuman memory, or a printout nearby. And if you don't use it every day, you'll also need to look up the exact syntax for that command.
PCs running MS-DOS might have been less powerful than UNIX machines, but they got really good, discoverable text user interfaces that took advantage of the hardware available, and could access that hardware in the most direct way. The best that is available now on Linux are really just pale imitations, and have to go through layers of terminal libraries and ugly hacks, like connecting to the X server in order to get the state of modifier keys that the terminal doesn't send.
Re: Ask HN: Interesting TUIs (text user interfaces), maybe forgotten ones?
#247Earlier quoted context omitted.
> Both stores use TUI interfaces for their instore service apps, and boy are they fast with them. They reserve GUI things for the self service point of sale systems and keep the TUI for cases where speed matters. What magic makes TUI faster than GUI? TUI just use glyphs to render the interface. AFAIK that's not faster that a proper graphics engine. Keyboard shortcuts are not exclusive to TUI. Maybe if we would stop h…
It's not keyboard shortcuts, it's pure keyboard input; an important distinction to make, as with modern GUI interfaces, keyboard input is often an afterthought.
I agree. I wish there was a common way to toggle keyboard navigation hints in GUIs. Like F1 is often help, F2 rename etc.
Re: Ask HN: Interesting TUIs (text user interfaces), maybe forgotten ones?
#248Euporie is the most complex TUI application I have built:
https://github.com/joouha/euporie
It consists of a TUI editor (and interactive REPL) for Jupyter notebooks, and supports displaying rich output in the terminal (images, LaTeX, HTML, interactive widgets, etc.).
Re: Ask HN: Interesting TUIs (text user interfaces), maybe forgotten ones?
#249Earlier quoted context omitted.
Back in the old days, the primary users of many mainframe UIs were the data entry team (almost universally female). Sitting in large offices with rows of desks and a huge clock on the front wall, they weren't interacting with customers, they were transcribing from sales sheets, order forms, application forms, etc. prepared by someone else. There was no great need for user friendliness, because the only users were in…
Mice are the problem, not the rest of the GUI. Keyboards are just faster once you learn them.
While I prefer to use a keyboard, it is not true that keyboard are universally faster. Even text navigation can be significantly faster with a mouse if done right, especially if you start to go into button chords.
What works best is heavily task dependent, and also needs to account for cognitive load and training requirements. Stations with few primary tasks taking limited input (e.g., product lookup forms and customer purchase forms) lend themselves heavily to a keyboard driven UI, but many others either do not. In that area, it ends up just being a strong personal preference guiding what seems best.
Re: Ask HN: Interesting TUIs (text user interfaces), maybe forgotten ones?
#250Earlier quoted context omitted.
> Both stores use TUI interfaces for their instore service apps, and boy are they fast with them. They reserve GUI things for the self service point of sale systems and keep the TUI for cases where speed matters. What magic makes TUI faster than GUI? TUI just use glyphs to render the interface. AFAIK that's not faster that a proper graphics engine. Keyboard shortcuts are not exclusive to TUI. Maybe if we would stop h…
It's not keyboard shortcuts, it's pure keyboard input; an important distinction to make, as with modern GUI interfaces, keyboard input is often an afterthought.
I fully agree. I made a TUI client/server framework loosely modeled around the concepts of CSS/HTML. One of my core design decisions was keyboard only input.