4 ms·

A lot of modern day UX designers would be aghast at the sheer quantity of data and speed at which a user can handle it IFF the UI is adequately designed. PoS s

A lot of modern day UX designers would be aghast at the sheer quantity of data and speed at which a user can handle it IFF the UI is adequately designed. PoS software really plateaued in the 90s. The most common flows were so simple an average user can hold a mental map of the program and always know exactly how to get where they need to be. Pros can fly through ten levels of menus in literally half a second to access some obscure report. In modern UI we've totally given up and just give the user a search box on every screen. Instead of a clean indexed list of menu items you can hit a key to access, we have to fumble around with tooltips.

jerf 2y ago
I don't have the time for it, but if I were going to make a new web front-end framework, it would be focused on this sort of expert-level interface. The key thing would be some sort of input-buffering system, where you can have lots of things bound to keys, and the framework will actually buffer things. Generally web browsers and modern UIs in general throw away input on reloads and such, on the generally-correct but very novice-biased theory that you didn't mean to be inputting into a screen you can't see yet. If you undo that and allow buffering keystrokes across loading actions you could start recovering some of that expert-level speed, where you can be using screens that aren't even loaded yet. "Expert-focused" UIs don't have to be bound to the terminal. That was all an accidental thing. Expert-focused UIs are nearly dead because all our UI frameworks actively block them. That is also not a fundamental fact of computing and can be undone.
- wild_egg 2y ago
  Thanks for this. I've a passing interest in those older expert-level interfaces and input buffering wasn't on my radar but is completely vital. I remember relying heavily on that functionality back in the day and yet it's non-existent in most modern interfaces.
- BalinKing 2y ago
  For me, the most obvious example of input-buffering in modern tools is in the terminal, where I'll often type in subsequent command(s) while the first is still executing. Sure, it's possible to make a mistake and have to Ctrl+C the current process to stop the botched command from executing—but for "safe" commands like `cd`, it's a super convenient feature. (The other tool that comes to mind is Emacs, but that's appreciably less mainstream than the command line in general.)
- MrLeap 2y ago
  I propose not stopping at input-buffering. Keep going, how fast could we get the REPL times if that were the KPI? I doubt we'd be doing full page redraws and slinging json of all things. I think what you'd end up with is something that looked a little more like a game engine than react. That would be a fun project to work on.
  - jerf 2y ago
    A REPL might be an option, you do have Javascript sitting right there, but is not generally the sort of "expert" I'm thinking of. I certainly wouldn't stop at input buffering. Another I'd want is some sort of systematic keypress discoverability. You still probably want a conventional GUI at least mostly available but using the GUI ought to be constantly teaching the user how to do whatever it is they just did with the keyboard instead. This might as well get wrapped into the framework, to standardize it and to make it easy to use.
    - mike_hearn 2y ago
      It's worth recalling that in the early days, GUIs always had underlined letters showing what the keyboard shortcuts are. That's been lost now, I suppose because it looked messy or confused people or something. Some tools show you the underlines only once you push the modifier key that can activate them. Unfortunately, one of the many shortcomings of the web as an application and GUI platform is (a) no menu bars, (b) no context menus, (c) no accelerator key framework, (d) keyboard focus is often nowhere in particular or somewhere stupid that will do something bad if you touch the keys.
tjpnz 2y ago
>A lot of modern day UX designers would be aghast at the sheer quantity of data and speed at which a user can handle it IFF the UI is adequately designed. Would they even know? There was a time when there was such a thing as domain expertise and when usability studies were an integral facet of many SDLC. Those days seem long gone now. The industry seems far more content to haphazardly adapt OTS solutions or create something that's "pretty" or "modern" at the expense of being functional.
- chrisjj 2y ago
  > Would they even know? Key point. We are now in a UI idiocracy.
ajackfox 2y ago
This is bang on. I am shocked by how poor UX really is these days in most modern applications. I worked at an old grocery store running the front office as a teenager through college maaaany years ago, and everything was a keyboard shortcut, non-touchscreen driven interface from probably the early 90’s. It took some time to get used to and train others on, but I could fly through those interfaces in a way a modern UX simply does not allow by focusing on the lowest common denominator for usability instead of any attempt to cater to ‘experts’: aka the people who have to use those interfaces day in and day out. Sure, the modern interfaces look great (usually) and in the ideal state anyone can pick it up and use it without much instruction. But there’s no attempt to focus on the poor soul who has to use it in their day to day and just wants to get it done as quickly as possible.
- deleted 2y ago
  [deleted]
- ilamont 2y ago
  Hardware, too. I worked in broadcast television in the 1990s and we used these very large Sony three-quarter inch videotape decks for editing. Two of them paired together and a monitor. Once I learned how to edit using the buttons and the scroll wheels, I could fly through putting together a news segment with all kinds of cuts, fades and overdubs. I remember thinking, I couldn’t believe how fast my fingers were flying. The closest thing I can compare it to is learning how to play a guitar; after a certain point muscle memory takes over.
Tarq0n 2y ago
The professional cashier mostly disappeared as a career though. There's no point in optimizing for expert use when your users are temporary labor.
- CyberDildonics 2y ago
  Who said anything about "professional cashiers" or "temporary jobs"? Did you mean to reply somewhere else?
  - accrual 2y ago
    I think it's because GP mentioned "PoS software" which is often used by cashiers, but is not limited to cashiers. Anywhere a user might swipe or tap their credit card could be considered a PoS. As a related aside, I recently visited Microcenter where they run their own PCI-compliant PoS system that's all text based. The staff all knew how to zip through various text menus to apply discounts, warranties, etc.
- wil421 2y ago
  BS, in the food service industry quickness is better for prompt service. When I waited tables I could click ahead of the UI to get what I needed and the POS would catch up. It needs to be easy and quick. Doesn’t matter if they are pros or people doing college jobs.
  - mike_hearn 2y ago
    What he means is that GUIs won over TUIs because they're intuitive and learnable. They might be slower to use (mostly; I'm faster in IntelliJ than vim) but that is counterbalanced by the lower training costs. In industries with high staff turnover, it's probably better to have slower workers but with much lower training costs.
    - layer8 2y ago
      There is no inherent conflict between GUIs and TUI-like speed. It’s the web tech stack and cloud-based apps, and piles upon piles of leaky abstractions in other environments, who have made things slow. Open Microsoft Word or Excel from 25 years ago, and it will be incredibly fast to operate.
jazzyjackson 2y ago
Every time I need to copy paste an email address from someone’s name in outlook and I have to wait a whole second for an on-hover tooltip to appear with the address and the “copy to clipboard” button I want to die. I would use the desktop client but it doesn’t have an interface to hyperlink to files in sharepoint.
layer8 2y ago
> we have to fumble around with tooltips. You’re lucky to get any tooltips nowadays.

jerf 2y ago

I don't have the time for it, but if I were going to make a new web front-end framework, it would be focused on this sort of expert-level interface. The key thing would be some sort of input-buffering system, where you can have lots of things bound to keys, and the framework will actually buffer things. Generally web browsers and modern UIs in general throw away input on reloads and such, on the generally-correct but very novice-biased theory that you didn't mean to be inputting into a screen you can't see yet. If you undo that and allow buffering keystrokes across loading actions you could start recovering some of that expert-level speed, where you can be using screens that aren't even loaded yet. "Expert-focused" UIs don't have to be bound to the terminal. That was all an accidental thing. Expert-focused UIs are nearly dead because all our UI frameworks actively block them. That is also not a fundamental fact of computing and can be undone.

wild_egg 2y ago
Thanks for this. I've a passing interest in those older expert-level interfaces and input buffering wasn't on my radar but is completely vital. I remember relying heavily on that functionality back in the day and yet it's non-existent in most modern interfaces.
BalinKing 2y ago
For me, the most obvious example of input-buffering in modern tools is in the terminal, where I'll often type in subsequent command(s) while the first is still executing. Sure, it's possible to make a mistake and have to Ctrl+C the current process to stop the botched command from executing—but for "safe" commands like `cd`, it's a super convenient feature. (The other tool that comes to mind is Emacs, but that's appreciably less mainstream than the command line in general.)
MrLeap 2y ago
I propose not stopping at input-buffering. Keep going, how fast could we get the REPL times if that were the KPI? I doubt we'd be doing full page redraws and slinging json of all things. I think what you'd end up with is something that looked a little more like a game engine than react. That would be a fun project to work on.
- jerf 2y ago
  A REPL might be an option, you do have Javascript sitting right there, but is not generally the sort of "expert" I'm thinking of. I certainly wouldn't stop at input buffering. Another I'd want is some sort of systematic keypress discoverability. You still probably want a conventional GUI at least mostly available but using the GUI ought to be constantly teaching the user how to do whatever it is they just did with the keyboard instead. This might as well get wrapped into the framework, to standardize it and to make it easy to use.
  - mike_hearn 2y ago
    It's worth recalling that in the early days, GUIs always had underlined letters showing what the keyboard shortcuts are. That's been lost now, I suppose because it looked messy or confused people or something. Some tools show you the underlines only once you push the modifier key that can activate them. Unfortunately, one of the many shortcomings of the web as an application and GUI platform is (a) no menu bars, (b) no context menus, (c) no accelerator key framework, (d) keyboard focus is often nowhere in particular or somewhere stupid that will do something bad if you touch the keys.

tjpnz 2y ago

>A lot of modern day UX designers would be aghast at the sheer quantity of data and speed at which a user can handle it IFF the UI is adequately designed. Would they even know? There was a time when there was such a thing as domain expertise and when usability studies were an integral facet of many SDLC. Those days seem long gone now. The industry seems far more content to haphazardly adapt OTS solutions or create something that's "pretty" or "modern" at the expense of being functional.

chrisjj 2y ago
> Would they even know? Key point. We are now in a UI idiocracy.

ajackfox 2y ago

This is bang on. I am shocked by how poor UX really is these days in most modern applications. I worked at an old grocery store running the front office as a teenager through college maaaany years ago, and everything was a keyboard shortcut, non-touchscreen driven interface from probably the early 90’s. It took some time to get used to and train others on, but I could fly through those interfaces in a way a modern UX simply does not allow by focusing on the lowest common denominator for usability instead of any attempt to cater to ‘experts’: aka the people who have to use those interfaces day in and day out. Sure, the modern interfaces look great (usually) and in the ideal state anyone can pick it up and use it without much instruction. But there’s no attempt to focus on the poor soul who has to use it in their day to day and just wants to get it done as quickly as possible.

deleted 2y ago
[deleted]
ilamont 2y ago
Hardware, too. I worked in broadcast television in the 1990s and we used these very large Sony three-quarter inch videotape decks for editing. Two of them paired together and a monitor. Once I learned how to edit using the buttons and the scroll wheels, I could fly through putting together a news segment with all kinds of cuts, fades and overdubs. I remember thinking, I couldn’t believe how fast my fingers were flying. The closest thing I can compare it to is learning how to play a guitar; after a certain point muscle memory takes over.

Tarq0n 2y ago

The professional cashier mostly disappeared as a career though. There's no point in optimizing for expert use when your users are temporary labor.

CyberDildonics 2y ago
Who said anything about "professional cashiers" or "temporary jobs"? Did you mean to reply somewhere else?
- accrual 2y ago
  I think it's because GP mentioned "PoS software" which is often used by cashiers, but is not limited to cashiers. Anywhere a user might swipe or tap their credit card could be considered a PoS. As a related aside, I recently visited Microcenter where they run their own PCI-compliant PoS system that's all text based. The staff all knew how to zip through various text menus to apply discounts, warranties, etc.
wil421 2y ago
BS, in the food service industry quickness is better for prompt service. When I waited tables I could click ahead of the UI to get what I needed and the POS would catch up. It needs to be easy and quick. Doesn’t matter if they are pros or people doing college jobs.
- mike_hearn 2y ago
  What he means is that GUIs won over TUIs because they're intuitive and learnable. They might be slower to use (mostly; I'm faster in IntelliJ than vim) but that is counterbalanced by the lower training costs. In industries with high staff turnover, it's probably better to have slower workers but with much lower training costs.
  - layer8 2y ago
    There is no inherent conflict between GUIs and TUI-like speed. It’s the web tech stack and cloud-based apps, and piles upon piles of leaky abstractions in other environments, who have made things slow. Open Microsoft Word or Excel from 25 years ago, and it will be incredibly fast to operate.

jazzyjackson 2y ago

Every time I need to copy paste an email address from someone’s name in outlook and I have to wait a whole second for an on-hover tooltip to appear with the address and the “copy to clipboard” button I want to die. I would use the desktop client but it doesn’t have an interface to hyperlink to files in sharepoint.

layer8 2y ago

> we have to fumble around with tooltips. You’re lucky to get any tooltips nowadays.