4 ms·

One could say the software looks dated, but you would be surprised how many of such applications are still in use today. I see those a lot at furniture shops an

by cygned 7y ago

One could say the software looks dated, but you would be surprised how many of such applications are still in use today. I see those a lot at furniture shops and large stores. I bought a Mercedes-Benz last week and the dealer’s computer was logged into an IBM mainframe running z/OS and COBOL/JPL. I find it interesting to spot those types of systems in commodity situations.

skrebbel 7y ago
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.
- 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?
stakhanov 7y ago
...actually, I think there may even be a positive effect on the way your customers perceive you if you use a POS that looks like it's from the IBM Mainframe / DOS era. This is because they are seen among businesses which were early adopters of electronic POS systems (usually linked to electronic ERP) which, back in the day, would have been a huge chunk of cash that they would have needed to spend on something that wasn't a core function of their business. And they're still around today. So that has got to be a successful business by somebody's definition of success. So, in a sneaky kind of way, you can pretend to be one of them by setting up a vintage- and corporate-looking system like that, even when you are a brand-new and unproven small business.
- al2o3cr 7y ago
  OTOH, if I go to a store and they're still using that sort of system I also think "here's a place that used to innovate, but gave up about 20 years ago"
  - stakhanov 7y ago
    ...it may be a very sensible business choice to not fix it if it ain't broke. Back in the day, POS/ERP systems were custom-made. So they are likely to be extremely well-tailored to the way a given corporate actually does business. Replicating that in a more modern setting nowadays might either involve buying into SAP's racket and still paying huge sums of money for customization to get what you need, or building a new completely custom-made piece of software. -- There is an attitude in business that I find very lamentable but that is nevertheless a reality in that, nowadays, a business would never in a million years choose the latter course of action (i.e. a non-tech business like a chain of furniture stores would, nowadays, be extremely unlikely to pay for developers' time to build an ERP for furniture retail for their exclusive use). But back then, that was the only thing you could do, and people did do it, because the gains in efficiency that could be reaped were just so big in relative terms (if your old system was pen-and-paper, it's a huge leap forward). Those low-hanging fruit are gone now. The thing is: Those investments that were made back in the late 80s / early 90s continue to pay dividends to this day in the form of money that you don't have to pay to SAP. And this is a considerable amount of money if it means having to go out and hire consultants with staggering hourly rates each time SAP ceases support for the version of their product you're on, with data having to be migrated, customizations having to be re-invented, etc etc (The consultants, BTW, have to turn around and give a good deal of money back to SAP for certifications etc). I think it's exactly what I would do if I was CIO in a corporate like that with a custom-made ERP system from the 80s. My most-preferred option would be to pay for some software developers' time to build a new one. But the likely outcome would be that I couldn't get a mandate to do that. So my second choice would be sticking with the system we have, and try to make it last for as long as it can possibly last. Only when that is no longer an option would I ever consider buying a modern ERP off the rack.
discreditable 7y ago
When I bought a Toyota 4 years ago I was surprised to see the dealer using a separate DOS machine for the contract. I was even more surprised when he printed the contract to a dot matrix printer.
- pete838 7y ago
  I admin a Toyota dealership currently that still uses a very terminal looking ERP with dot matrix OkiData printers. It's amazing how quickly everyone zips around in it without a mouse. I believe it's called Reynolds and Reynolds auto retailing. Does everything a full service dealership needs, from buying used cars to selling parts and body work.
ozzmotik 7y ago
when I worked at the Sears call center, they tracked all orders and service requests through what appeared to be a DOS based service (ironically also named DOS for delivery/order system) and as I recall another one called NPOS that was used to look up items, check availability, etc.

by cygned 7y ago

skrebbel 7y ago

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.
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?

stakhanov 7y ago

...actually, I think there may even be a positive effect on the way your customers perceive you if you use a POS that looks like it's from the IBM Mainframe / DOS era. This is because they are seen among businesses which were early adopters of electronic POS systems (usually linked to electronic ERP) which, back in the day, would have been a huge chunk of cash that they would have needed to spend on something that wasn't a core function of their business. And they're still around today. So that has got to be a successful business by somebody's definition of success. So, in a sneaky kind of way, you can pretend to be one of them by setting up a vintage- and corporate-looking system like that, even when you are a brand-new and unproven small business.

al2o3cr 7y ago
OTOH, if I go to a store and they're still using that sort of system I also think "here's a place that used to innovate, but gave up about 20 years ago"
- stakhanov 7y ago
  ...it may be a very sensible business choice to not fix it if it ain't broke. Back in the day, POS/ERP systems were custom-made. So they are likely to be extremely well-tailored to the way a given corporate actually does business. Replicating that in a more modern setting nowadays might either involve buying into SAP's racket and still paying huge sums of money for customization to get what you need, or building a new completely custom-made piece of software. -- There is an attitude in business that I find very lamentable but that is nevertheless a reality in that, nowadays, a business would never in a million years choose the latter course of action (i.e. a non-tech business like a chain of furniture stores would, nowadays, be extremely unlikely to pay for developers' time to build an ERP for furniture retail for their exclusive use). But back then, that was the only thing you could do, and people did do it, because the gains in efficiency that could be reaped were just so big in relative terms (if your old system was pen-and-paper, it's a huge leap forward). Those low-hanging fruit are gone now. The thing is: Those investments that were made back in the late 80s / early 90s continue to pay dividends to this day in the form of money that you don't have to pay to SAP. And this is a considerable amount of money if it means having to go out and hire consultants with staggering hourly rates each time SAP ceases support for the version of their product you're on, with data having to be migrated, customizations having to be re-invented, etc etc (The consultants, BTW, have to turn around and give a good deal of money back to SAP for certifications etc). I think it's exactly what I would do if I was CIO in a corporate like that with a custom-made ERP system from the 80s. My most-preferred option would be to pay for some software developers' time to build a new one. But the likely outcome would be that I couldn't get a mandate to do that. So my second choice would be sticking with the system we have, and try to make it last for as long as it can possibly last. Only when that is no longer an option would I ever consider buying a modern ERP off the rack.

discreditable 7y ago

When I bought a Toyota 4 years ago I was surprised to see the dealer using a separate DOS machine for the contract. I was even more surprised when he printed the contract to a dot matrix printer.

pete838 7y ago
I admin a Toyota dealership currently that still uses a very terminal looking ERP with dot matrix OkiData printers. It's amazing how quickly everyone zips around in it without a mouse. I believe it's called Reynolds and Reynolds auto retailing. Does everything a full service dealership needs, from buying used cars to selling parts and body work.

ozzmotik 7y ago

when I worked at the Sears call center, they tracked all orders and service requests through what appeared to be a DOS based service (ironically also named DOS for delivery/order system) and as I recall another one called NPOS that was used to look up items, check availability, etc.