5 ms·

When I was writing software for medical devices in the '90s, we had a very clear policies for dealing with cognitive drift that included performance ceilings, t

When I was writing software for medical devices in the '90s, we had a very clear policies for dealing with cognitive drift that included performance ceilings, testing for drift in beta testing, etc. In our testing, 10 seconds was the absolute maximum time that a surgeon could "idle" and stay on task in surgery. In addition, we found that including spinners, progress bars, etc. would not necessarily reduce the cognitive drift but would reduce emotional frustration. The worst thing for frustration was UI elements being slow; buttons that responded slowly, scrolls that lag, pull-downs that didn't pull down. Exactly as this author notes. There was very little tolerance for those kinds of delays. I presume that, like website response rate tolerance thresholds that have dropped from 5 seconds to less than 2 seconds now, the medical industry is probably using much lower times now.

phkahler 7y ago
>> The worst thing for frustration was UI elements being slow; buttons that responded slowly, scrolls that lag, pull-downs that didn't pull down. Exactly as this author notes. There was very little tolerance for those kinds of delays. IMHO there is NO excuse for those kinds of delays. None. If you have those issues you're doing something terribly wrong.
- penagwin 7y ago
  I don't know the details, but many embedded interfaces/controllers don't have very fast processors/microcontrollers and UI is really expensive compared to everything else it has to do (take some inputs, and submit some data). Think about how laggy the raspberry pi 2 or even 3 in the desktop interface. Sure they can be optimized etc, but now imagine what they wouldn've used 10+ years ago and how slow it would be. EDIT: I have to agree with you guys, even given the tech they had they should've put a higher priority on responsiveness. I don't know what the status is today, but I know even the 2015 Prius's touch screen feels too unresponsive to my liking.
  - jblow 7y ago
    The Amiga 500 was pretty responsive, and its CPU power was epsilon compared to a Raspberry Pi or any modern embedded system. It's just that modern software is garbage. That's all.
    - arendtio 7y ago
      I agree. A few years ago, I powered up some old 166 MHz Windows 95 PC and was surprised how fast it was (certainly not on all tasks, but in general).
    - renox 7y ago
      And Amiga had no memory protection which means that it would be very unsafe to use Internet with it. That said BeOS was quite responsive and had memory protection, but still inadequate security for modern security attacks.
      - bmurphy1976 7y ago
        The memory protection doesn't account for the performance hit. It's all the layers of shitty software and garbage devices on top.
        renox 7y ago
        Memory protection only adds a small performance hit that's true but it also requires a totally different way of working. I don't know much about Amiga but I remember that when reading about Synthesis (a very fast & low latency kernel https://en.wikipedia.org/wiki/Self-modifying_code#Synthesis https://en.wikipedia.org/wiki/Self-modifying_code#Synthesis ) thinking that it was only possible without memory protection..
  - ambicapter 7y ago
    Don't think it really matters, if your device can display a dropdown, then it can display an empty dropdown and load entries within a couple seconds.
- Ensorceled 7y ago
  Well, we used to have to write our own UI elements and swap them into the top 8 bits of the framebuffer reserved for the overlay.
mcntall 7y ago
This is one of the reasons why you will often see software installation look linear [10min until it is finalized, 8min until is finalized...] even though on a micro-scale, the process may be oscillating a lot more.
- penagwin 7y ago
  I highly doubt most programs know when they'll finish, usually there's multiple stages of say installation, copying files, editing the registry, generating some other files, downloading updates, etc. Some of those stages take milliseconds, others can take minutes or longer. Maybe some take seconds on an NVME SSD but takes 4 minutes on an HDD (verifying files commonly has this behaviour), etc. If the progress bar doesn't differentiate which stage it's in then it's purpose is mostly just to let the user know it's doing something.
- mark-r 7y ago
  I had an Epson scanner that had a progress bar while scanning. You could HEAR the scanner progress, and it wasn't close to even - sometimes it would stop for a while, or even back up. It didn't matter though, the progress bar kept an even pace and always finished at the exact instant the scan was done. That has always stood out as one of the more impressive engineering feats I've seen.
wpietri 7y ago
I don't know how optimistic I'd be about the whole industry. I'd suspect medical devices are way more disciplined than EHR apps. A friend's sister is a doctor. We happened to be visiting her hospital the week they were rolling out a new system. If if I recall rightly, her hospital was part of a multi-hospital company, and they were developing it in house. The developers were in some location distant to the hospital, and my doctor pal had never met anybody who worked on it. From my perspective, the thing was a disaster. Not only was it laggy as hell, but the interface was dumbfoundingly bad. For a doctor to prescribe something for a patient, the would have to pick the medication name from an absurdly long drop-down. Then they could type in a quantity and pick a unit from a pulldown that had mcg, mg, g, and kg choices. Once that was entered, it would show up on the reports nurses would use to give medication. However, they didn't have the field sizing right on the reports, so 100 mg would turn into 10 mg. It was only nurse experience that kept people from getting dangerously wrong doses of their medication. The whole thing was hot garbage of exactly the sort made in a big waterfall process by developers who never met the users and never saw them in action. I'm sure every bit of it was technically to spec, but I'd be amazed if nobody died from it.
- Ensorceled 7y ago
  It's the procurment process and the lack of skilled management. With the Ontario eHealth debacle[1], the people in charge were hospital administrators with no software project experience. They were taken advantage of by the contractors, their employees and, to be fair, their own greed. These kinds of large projects really need to spend the money on a real CTO and/or CPO. [1] https://en.wikipedia.org/wiki/EHealth_Ontario#Consulting_and_contracting_controversies https://en.wikipedia.org/wiki/EHealth_Ontario#Consulting_and...

phkahler 7y ago

>> The worst thing for frustration was UI elements being slow; buttons that responded slowly, scrolls that lag, pull-downs that didn't pull down. Exactly as this author notes. There was very little tolerance for those kinds of delays. IMHO there is NO excuse for those kinds of delays. None. If you have those issues you're doing something terribly wrong.

penagwin 7y ago
I don't know the details, but many embedded interfaces/controllers don't have very fast processors/microcontrollers and UI is really expensive compared to everything else it has to do (take some inputs, and submit some data). Think about how laggy the raspberry pi 2 or even 3 in the desktop interface. Sure they can be optimized etc, but now imagine what they wouldn've used 10+ years ago and how slow it would be. EDIT: I have to agree with you guys, even given the tech they had they should've put a higher priority on responsiveness. I don't know what the status is today, but I know even the 2015 Prius's touch screen feels too unresponsive to my liking.
- jblow 7y ago
  The Amiga 500 was pretty responsive, and its CPU power was epsilon compared to a Raspberry Pi or any modern embedded system. It's just that modern software is garbage. That's all.
  - arendtio 7y ago
    I agree. A few years ago, I powered up some old 166 MHz Windows 95 PC and was surprised how fast it was (certainly not on all tasks, but in general).
  - renox 7y ago
    And Amiga had no memory protection which means that it would be very unsafe to use Internet with it. That said BeOS was quite responsive and had memory protection, but still inadequate security for modern security attacks.
    - bmurphy1976 7y ago
      The memory protection doesn't account for the performance hit. It's all the layers of shitty software and garbage devices on top.
      - renox 7y ago
        Memory protection only adds a small performance hit that's true but it also requires a totally different way of working. I don't know much about Amiga but I remember that when reading about Synthesis (a very fast & low latency kernel https://en.wikipedia.org/wiki/Self-modifying_code#Synthesis https://en.wikipedia.org/wiki/Self-modifying_code#Synthesis ) thinking that it was only possible without memory protection..
- ambicapter 7y ago
  Don't think it really matters, if your device can display a dropdown, then it can display an empty dropdown and load entries within a couple seconds.
Ensorceled 7y ago
Well, we used to have to write our own UI elements and swap them into the top 8 bits of the framebuffer reserved for the overlay.

mcntall 7y ago

This is one of the reasons why you will often see software installation look linear [10min until it is finalized, 8min until is finalized...] even though on a micro-scale, the process may be oscillating a lot more.

penagwin 7y ago
I highly doubt most programs know when they'll finish, usually there's multiple stages of say installation, copying files, editing the registry, generating some other files, downloading updates, etc. Some of those stages take milliseconds, others can take minutes or longer. Maybe some take seconds on an NVME SSD but takes 4 minutes on an HDD (verifying files commonly has this behaviour), etc. If the progress bar doesn't differentiate which stage it's in then it's purpose is mostly just to let the user know it's doing something.
mark-r 7y ago
I had an Epson scanner that had a progress bar while scanning. You could HEAR the scanner progress, and it wasn't close to even - sometimes it would stop for a while, or even back up. It didn't matter though, the progress bar kept an even pace and always finished at the exact instant the scan was done. That has always stood out as one of the more impressive engineering feats I've seen.

wpietri 7y ago

I don't know how optimistic I'd be about the whole industry. I'd suspect medical devices are way more disciplined than EHR apps. A friend's sister is a doctor. We happened to be visiting her hospital the week they were rolling out a new system. If if I recall rightly, her hospital was part of a multi-hospital company, and they were developing it in house. The developers were in some location distant to the hospital, and my doctor pal had never met anybody who worked on it. From my perspective, the thing was a disaster. Not only was it laggy as hell, but the interface was dumbfoundingly bad. For a doctor to prescribe something for a patient, the would have to pick the medication name from an absurdly long drop-down. Then they could type in a quantity and pick a unit from a pulldown that had mcg, mg, g, and kg choices. Once that was entered, it would show up on the reports nurses would use to give medication. However, they didn't have the field sizing right on the reports, so 100 mg would turn into 10 mg. It was only nurse experience that kept people from getting dangerously wrong doses of their medication. The whole thing was hot garbage of exactly the sort made in a big waterfall process by developers who never met the users and never saw them in action. I'm sure every bit of it was technically to spec, but I'd be amazed if nobody died from it.

Ensorceled 7y ago
It's the procurment process and the lack of skilled management. With the Ontario eHealth debacle[1], the people in charge were hospital administrators with no software project experience. They were taken advantage of by the contractors, their employees and, to be fair, their own greed. These kinds of large projects really need to spend the money on a real CTO and/or CPO. [1] https://en.wikipedia.org/wiki/EHealth_Ontario#Consulting_and_contracting_controversies https://en.wikipedia.org/wiki/EHealth_Ontario#Consulting_and...