4 ms·

Lots of such "dated" software can be used much more productively than modern GUI or web based software. Most oldschool DOS-y business software is very keyboard

Lots of such "dated" software can be used much more productively than modern GUI or web based software. Most oldschool DOS-y business software is very keyboard driven, so the learning curve is much steeper than that of your average web app. But once you're there, and really it's just a few hours of learning to hit the right keys while your experienced colleague is training you up, then it's super fast. There's no web page loading times. Click ... Wait .... Click ... Etc ... Inputs are properly tab indexed, because that's the only way to navigate between them. Every keyboard hit has instant feedback No time wasted mousing around. Look, mouse/touch driven UIs are great for discoverability, and web based UIs are great for deliverability, but neither of those are super important when all users of the software are expected to use it a lot, and use it from a known amount of places (eg branches of a retail chain). Of course there's nothing preventing web based UIs from supporting the same speed and productivity, but I know of few examples that actually do this. I love web based software and I make it for a living, but I wish UX designers for line of business applications would take a few more hints from the nineties. If you can assume that a new user gets a few hours of on-the-job training from a colleague, then that wildly changes the assumptions underlying your UX design.

johannes1234321 7y ago
Not only is the response fast, but also don't you have to look at the keys or for some entries even the screen. https://youtu.be/oOjnpOyUzS0 https://youtu.be/oOjnpOyUzS0 For a while I always said, that I preferred a counter for getting tickets (train or something) as the trained clerk is faster on the keyboard than me on the touchscreen of a ticket machine. Nowadays however clerks on counters have to push the mouse more and more and seemingly have less training.
holri 7y ago
> Of course there's nothing preventing web based UIs from supporting the same speed and productivity, but I know of few examples that actually do this. Can you give a few of those examples? What must be done to accomplish this?
- darkwater 7y ago
  No the GP but I'd say that they should: * be 100% keyboard driven (so, indexed inputs for easy TAB navigation) * really quick and responsive (probably with all the needed code locally available, storing data locally and then sync when no action is going on). It's probably one of the best example where a SPA would be really useful * be really lightweight so it can run on older hardware (like 10+ years old) But doing those points "right" with nowadays frontend-mindset I'd say that's pretty difficult.
  - holri 7y ago
    isn't SPA and lightweight a contradiction? My ten year old N900 can not run a modern SPA frontend but is pretty "snappy" with plain old small HTML sites.
    - darkwater 7y ago
      But that probably lies more in the framework used rather then in the "SPA concept". Disclaimer: I'm not a front-end developer so I may be totally wrong.
      - goldenkey 7y ago
        The only things needed to make SPA possible are same page requests and DOM updates. We have pretty much always had iframes and form posts that can be targeted to submit to hidden iframes that JS can read, so XMLHttpRequest is easy to polyfill. We used to use jQuery and globals or straight DOM manipulation. Or Backbone.js or just straight classes. It has always been possible to make a SPA. And if you actually are able to download and cache most of the app upfront, it should be pretty quick. The question is, I suppose, how big is the SPA codebase and do newer browsers know how to cache identical codebases into their "entry points"? The real draw of React and Vue, and more recently, Lit-Element (Google), is that they update the DOM in a smart efficient way, doing updates much more efficiently than you might could do without an intermediate layer.
  - skrebbel 7y ago
ecthiender 7y ago
This comment has some good insights. Actually a lot of "business" software were like that in the 90s and early 00s. They were optimized for productivity of the user and not necessarily aesthetics of appearance or ease of use (well, trade-off). Even old version of excel etc. were designed like that. Unfortunately modern web software has such high importance on making it eye-candy.
jacquesm 7y ago
I knew someone working on a system like that who could 'type ahead' a couple of screens worth because the layout had not changed in a decade, it 'just worked' and the system had trouble keeping up with the user because of that. Very impressive.
- Angostura 7y ago
  I used to be like that string commands together in Wordstar
- icebraining 7y ago
  Buffering input is something we are still missing on the web. Concurrency is indispensable, but if the program is modal (and almost all are, to certain extent), processing an input command should wait for the previous one to be processed.
- nikau 7y ago
  Was that user on a therac-25?

johannes1234321 7y ago

Not only is the response fast, but also don't you have to look at the keys or for some entries even the screen. https://youtu.be/oOjnpOyUzS0 https://youtu.be/oOjnpOyUzS0 For a while I always said, that I preferred a counter for getting tickets (train or something) as the trained clerk is faster on the keyboard than me on the touchscreen of a ticket machine. Nowadays however clerks on counters have to push the mouse more and more and seemingly have less training.

holri 7y ago

> Of course there's nothing preventing web based UIs from supporting the same speed and productivity, but I know of few examples that actually do this. Can you give a few of those examples? What must be done to accomplish this?

darkwater 7y ago
No the GP but I'd say that they should: * be 100% keyboard driven (so, indexed inputs for easy TAB navigation) * really quick and responsive (probably with all the needed code locally available, storing data locally and then sync when no action is going on). It's probably one of the best example where a SPA would be really useful * be really lightweight so it can run on older hardware (like 10+ years old) But doing those points "right" with nowadays frontend-mindset I'd say that's pretty difficult.
- holri 7y ago
  isn't SPA and lightweight a contradiction? My ten year old N900 can not run a modern SPA frontend but is pretty "snappy" with plain old small HTML sites.
  - darkwater 7y ago
    But that probably lies more in the framework used rather then in the "SPA concept". Disclaimer: I'm not a front-end developer so I may be totally wrong.
    - goldenkey 7y ago
      The only things needed to make SPA possible are same page requests and DOM updates. We have pretty much always had iframes and form posts that can be targeted to submit to hidden iframes that JS can read, so XMLHttpRequest is easy to polyfill. We used to use jQuery and globals or straight DOM manipulation. Or Backbone.js or just straight classes. It has always been possible to make a SPA. And if you actually are able to download and cache most of the app upfront, it should be pretty quick. The question is, I suppose, how big is the SPA codebase and do newer browsers know how to cache identical codebases into their "entry points"? The real draw of React and Vue, and more recently, Lit-Element (Google), is that they update the DOM in a smart efficient way, doing updates much more efficiently than you might could do without an intermediate layer.
- skrebbel 7y ago

ecthiender 7y ago

This comment has some good insights. Actually a lot of "business" software were like that in the 90s and early 00s. They were optimized for productivity of the user and not necessarily aesthetics of appearance or ease of use (well, trade-off). Even old version of excel etc. were designed like that. Unfortunately modern web software has such high importance on making it eye-candy.

jacquesm 7y ago

I knew someone working on a system like that who could 'type ahead' a couple of screens worth because the layout had not changed in a decade, it 'just worked' and the system had trouble keeping up with the user because of that. Very impressive.

Angostura 7y ago
I used to be like that string commands together in Wordstar
icebraining 7y ago
Buffering input is something we are still missing on the web. Concurrency is indispensable, but if the program is modal (and almost all are, to certain extent), processing an input command should wait for the previous one to be processed.
nikau 7y ago
Was that user on a therac-25?