Hacker News Reader

Comment by sgt | Hacker News Reader

Occasionally when you see someone using a point of sale terminal that is terminal based, the operator usually flies through the interface like it's nothing.

So there's something to be said about those types of interfaces - it may look simple and be text based, but it's the most user friendly for the qualified operator to get things done.

View on HN

That has nothing to do with the interface being a terminal, but with the primary input method being a keyboard instead of a pointing device.

You could get the same result with a graphical interface, as long as you provide proper keyboard based navigation. The web browser provide all the capabilities that you need for that.

The nice part of a text based ui is that you have a simpler device to use for rendering, so things like layout is easier, as long as you remain in the domain of what the device allows for.

Agreed that a GUI can be just as keyboard-friendly as a good TUI, but it would seem natural that restricting things to a grid of characters encourages keyboard interaction, whereas allowing arbitrary placement of elements at the pixel level encourages mouse interaction.

Yes, but given the choice, I think most people would opt for the less-efficient mouse navigation on a web page, even if there were no actual upsides to doing it that way.

If a business forced a keyboard-only input method, then that might help to raise the efficiency of everyone more equally.

Another example of this sort of interface is office phones. When someone knows their phone well, they can speed through a hold, page to another desk, then transer to them, without even looking at the keypad.

I have a feeling that sort of "trainable speed" is a feature of interfaces that treat the thing they manage like a physicial "thing" you're rolling thru a process. (instead of a feature of textmode interfaces) Rather than having to get to a menu for outside lines in some abstract window, there's just actual physicial buttons to mash. You get this feeling that you're juggling a call between your fingers because every press you do is doing a "thing", not just opening a menu. There's real physicality to that process that my monkey brain can learn no problem.

I don't have any experience operating a terminal based PoS, but from what I know, they tend to also have the same sort of "juggling" actions, like SALE, DISCOUNT, VOID etc. I have to imagine using them feels like juggling the current item you're looking at thru a few different buttons.

See my sibling comment: https://news.ycombinator.com/item?id=43673486

I've definitely seen this in real life, but recently I've started trying to actually watch when people use these interfaces, and they usually seem very slow - lots of hesitation, lots of mistakes, lots of repetition to do very simple actions. I watched someone use a terminal PoS recently and to clear a text input and insert a new value, she had to navigate to the start of the text box (no home key or anything like that), type new characters over the old ones, and then at the end delete any leftover characters from the previous input that they hadn't typed over. In a modern GUI, I would expect the user to have to (1) tab to the text box or press ctrl-A if they were in that text box, then (2) type the value they were interested in, possibly with typeahead support if it makes sense.

My working theory is that these terminal-based UIs aren't quicker because they're terminal-based, but rather users need to learn the keyboard shortcuts because they're so painful to use any other way. A well-designed GUI equivalent could be significantly quicker, and much easier to learn, but nobody wants to pay for that.

Good GUI apps have shittons of keyboard shortcuts to achieve the same result. The ideal is that the qualified operator keeps their hands on the keyboard for anything that isn't an actual pointing operation. For example, in a video editing app, you can rough-cut with a handful of keys[0] for setting in and out points, jogging through the source material, and inserting into the current active timeline. The keyboard isn't a mere text input device, it's a large-ish macro pad with a huge number of redefineable keys, and it will always be faster to press a button with a known location versus opening a menu and clicking an option by name.

Related: I really liked Blender's text-searchable menus and I wish every GUI app had searchable menus. It's faster than hunting through a static hierarchy. In fact, one of the few criticisms I have of the 4.x era Blender UI is just that it's mildly harder to invoke search.

[0] Which is how linear video edit consoles worked before modern NLEs, mind.

> every GUI app had searchable menus

They do on mac: shift+⌘+? opens a "search menu" menu.

OH MY GOD. I never knew about that.

This doesn’t always show everything. It’s up to developers to make sure some shortcuts can show up in this documentation beyond system ones

Luckily most do, but I’ve encountered situations where they haven’t and it only shows compatible system shortcuts

The amount of alternative navigation and accessibility in macOS is actually astounding.

> I wish every GUI app had searchable menus

On macOS and KDE (Wayland), they do! Agreed it's really handy.

What exactly makes an app a "KDE app"? Obviously a game with a custom UI is not going to have the same searchable menu, right?

I don't think I mentioned "KDE app" or games? KDE's Global Menu works with apps built with other toolkits than QT, and games are typically not considered apps. It would be cool if games did something similar though, I would love to be able to go into a games options and type "subtitles" to quickly find the option.

> KDE's Global Menu works with apps built with other toolkits than QT

Their own wiki page says it does not: https://community.kde.org/Plasma/Wayland_Known_Significant_I...

"Global Menu is not supported for non-Qt apps"

But either way, I still disagree with your comment that "all GUI apps on macOS and KDE (Wayland) have searchable menus", because this requires a menu system that is exported via a specific DBus protocol (https://stackoverflow.com/questions/75215820/how-to-implemen...), meaning it requires support from the application itself (possibly via some toolkit it uses), which IMO is demonstrably not "all apps".

I see the same on any graphical one on the supermarkets and restaurants.

Maybe it is a matter to actually design for the customers use case.

Modern GUI apps tend not to design for the keyboard-wielding power user.

TUIs can have just as many quirks and bugs, but on the whole they tend to be a little simpler, and the author usually is an end-user :-)

Someone is responsible for developing them.

Exactly. POS terminals are optimised for throughput. Otherwise it's literally less sales, your bottom line.

You can build a perfectly snappy, keyboard-driven GUI application; a terminal emulator is (ironically) the perfect example.

Nah i could whip through the GUI POS software at every job that had full keyboard shortcuts for everything on screen. It's the keyboard, not the on screen UI that makes it fast. Replace a keyboard with a touch screen and things will slow down (except maybe jobs where you don't tend to have both hands free--bars and restaurants perhaps)

once those keys become muscle memory no mouse driven interface will ever repair lol. I used to work best buy and they had a bunch of backend inventory/database stuff and I could absolutely fly through those. I used be able to do the same with wordperfect as well. now all those skills and muscle memory..... gone like tears in the rain.

15 years ago the best buy front end pos terminals were also very keyboard navigable. I could fly through that stuff without touching the, uh, "pointing stick" or whatever IBM calls the little nub they put on their laptops and PoS terminals

Airlines (and our corp. interface to it) seem to still rely on those. Kinda weird but fun to see HR/Travel people using those. They definitely have their place still.

Reply on news.ycombinator.com