Showing posts with label user interface. Show all posts
Showing posts with label user interface. Show all posts

Prostate Cancer Diary: Day 115 — Therac 25 and a thankfully minor glitch in my radiotherapy

  July 24, 2026    

[Note to readers: I am not posting prostate cancer (PCa) diary entries every day. To be honest, I can't keep up. The hormone therapy (ADT) that I started three and a half months ago has slowed me down, as has the radiotherapy (RT) which I started on the first of July. I've been warned that the effects of RT build toward the end of the sessions and even beyond, before tapering off. Thankfully my last session is July 28. Hoping to pick up the pace mid-August. In the meantime, I will post what I can, when I can.]

July 24. 2026

This morning, I was off to a flying start at the Arden Cancer Centre. Arrived early for my 9:15 appointment thanks to light traffic. Was called in at 9:13. Bladder scan was positive and I was ushered into theatre right away. The team was in good mood, joking with M, one of the TRs I haven't met before. Apparently, she had "saved the day" the day before when a late start due to routine system checks backed up appointments pretty badly. (News that made me even more grateful that they had squeezed me in early yesterday.)

I hopped up on the scanning table, pulled my pants down, and they quickly placed the modesty wrapper in place. Then it was just a few minutes before the targeting scan was happening. Whir, whir, as the massive VersaHD head unit rotated, imaging my innards in great detail, then:

Click! The machine froze and started going beep, beep, beep...

Naturally, my first thought was: Therac-25! Quickly followed by: "Don't worry, the photon beam is not on, there's no radiation happening, this is just the targeting run." Also: "Surely they can hear this beeping."

Turns out, they could hear the beeping, and they spent several minutes trying various measures to clear the error that was causing it before coming into the room. They assured me it was nothing to worry and an engineer was on his way. They also started checking the equipment to find a way to silence the beeps. Eventually, the beeps stopped and the engineer arrived. 

The decision was made to proceed with my session on a different, identical VersaHD machine, and the bed was lowered. I pulled up my pants and was helped down. As I was putting on my shoes to walk to the other machine, I said something like:

1980s radiotherapy machine, the Therac-25
(Original source: untraceable)

"At least it's not a Therac-25." 

To which several of the team responded, "What's that?"

But to my delight, the engineer launched into a very good summary of the Therac-25 incident.

This was a series of six massive radiation overexposure accidents involving a computer-controlled radiation therapy machine called the Therac-25, between 1985 and 1987, driven by race conditions, poor software design, and removed hardware safety interlocks. These software faults caused patients to receive up to 250 times the intended radiation dose, resulting in severe burns and multiple deaths. (Wikipedia).

Fortunately, when the details of these horrific incidents came to light, the entire medical technology world took notice, and the Therac-25 was subjected to intense scrutiny. A range of problems was identified:

  • a race condition in the software that allowed the high-power beam to fire without the beam-spreader plate in place, 
  • an overconfidence in software safety that led engineers to remove hardware interlocks present in earlier models, 
  • poor error reporting that displayed cryptic codes like "Malfunction 54" instead of clear warnings, 
  • and a culture at the manufacturer, AECL, that was slow to investigate and acknowledge the reports of injury.

The fallout reshaped how the industry thinks about safety-critical software. Nancy Leveson and Clarence Turner's 1993 investigation became a foundational case study, still taught in software engineering and systems safety courses today. It clarified the dangers of relying too heavily on software alone to enforce safety without independent hardware checks.

More concretely, the incidents contributed to tighter US FDA oversight of software in medical devices, spurring the development of formal standards such as IEC 62304 for medical device software lifecycle processes and IEC 60601 for electrical safety. 

The Therac-25 failures also pushed the field toward practices like formal hazard analysis, independent redundant safety mechanisms, and rigorous change-control procedures for software updates, recognizing that a single software fix, applied without full re-verification, can introduce new failure modes just as dangerous as the ones it was meant to fix.

And that is why I was not too alarmed by today's glitch in the VersaHD that has been photon-beaming me. Although the hardware and software employed in prostate cancer radiotherapy today are orders of magnitude more complex than those of 40 years ago, I am confident they are far safer as well.

   / / / / / / / / /

  No Comments

Color Blind Web Sites: And other design decisions

  March 19, 2008    

I've been doing some thinking about color blindness recently (I posted about the perception aspects of this over on my arts blog). As a color blind person I have often thought about this question: Should product designers cater to the color blind?

FYI, the cube on the left shows "normal" vision while the one on the right simulates what the same colors look like to someone with color deficiency.

By some estimates as many as 1 in 12 people have some form of color deficiency (although total color blindness is quite rare). Is that too small a minority to care about? After all, 1 in 12 people are left-handed and very few designers adjust their designs to accommodate lefties. But consider this, if you are designing technology for men, the incidence of color defectiveness is higher in men (as is, coincidentally, left-handedness--I'm not sure of the incidence of left-handed color blind men, but I am one).

What does it mean to design for color deficiency? I recently found an article in Dr. Dobb's that gives some good ideas for web designers looking to adjust designs for color deficiency. I have not yet found anything about "color-adjusting" products like electronics. One design choice that irks me, as a color deficient user of electronics, is the two-color LEDs like the ones that switch from red to green to show different states, for example, to show connected and not connected. Given that the most common form of color deficiency is referred to as "red/green deficiency" this might not be a smart design choice. You run the risk that as many as 1 in 8 of your customers a. won't be able to figure out that LED, and b. will get frustrated and disgruntled. You don't want to be the customer service person who asks "Is the LED red or green?" when the person on the other end says "I have no idea, I'm color blind."

How much more would it cost to have two LEDs? That arrangement gives you location and On/Off states to work with, which color blind people can handle (when the top traffic light is brightest it means stop, when the bottom one is brightest it means go, and so on). Then you can ask "Is the LED on the left on?" and get an accurate answer.

To be honest, and speaking as a businessperson, I don't know if catering to the color blind is a profitable path to take. But product designers might want to try it. You might be surprised how many people appreciate it.

P.S. If you are wondering about your own vision there is a site where you can do some basic tests of your color perceptions.

   /

  No Comments

The Intuitive Interface Myth: The fault of gurus and experts

  May 28, 2007    

Okay, so I am officially fed up with the notion that graphical user interfaces are "intuitive" and "easy to use." There is nothing inherently intuitive or easy in a GUI. It all comes down to the design. Moving a mouse pointer over an icon and clicking it may look cool, may feel cool, but how easy is it for the average person? The answer depends on a variety of factors, like hand eye coordination and icon design. Half the time my screen has a bunch of icons on it the meaning of which is less than obvious. In other words, I have to learn what the icon means, I cannot simply intuit the meaning. Surely a word would be better? Yes, I know that you can turn on words for some icons, but this is inconsistent between applications and operating systems. And when you get to the web all bets are off. Some sites underline links, others don't. Some use rollovers, others don't. The same function is given different names on different sites, and so on and so forth.

How did we arrive at this situation, where computers and software are designed with interfaces that are non-obvious? Obstacles and not enablers? There are several parties to blame. Let's start with the industry giants and the wars between them that did not help (a great case study for MBA students--how the free market influences interface design--does the iPod dominate MP3 players due to interface? Did the windows wars between Apple and Microsoft help or hinder the interface evolution?).

Competition is great for some things, but when companies get fixated with one-upping the competition (in order to sell more product) there is a tendency to force software and hardware developers to add bells and whistles and do things different, even when an unadorned standard config is working fine. There is a whole book in this phenomenon, but consider one example, an interface issue that may well be the single greatest cause of lost productivity in the late nineties and early oughties (or whatever this current decade is called).

I'm talking about the way File Save works. Back in the old days, somewhere between the Pterodactyls and the 386 chip, it was "standard" for the File Save command to require confirmation, much the same way that the File Save As command does today. Suppose you had opened up the spreadsheet of weekly sales figures and updated them. When you selected File Save the spreadsheet application would ask you: Yes or No? The reason for this was obvious: You might want both versions of the spreadsheet, the one that you opened and the edited one . The latter might be very different. For example, the original might be the Megabank proposal which you had edited to become the Ultrabank proposal. You might have deleted a lot of information from the original on the way to the new version.

Obviously the File Save As command is for just such situations, but if there was one instruction that was drummed into the brains of early adopters of PC technology, back in the days when they were prone to disk crashes and brownouts and OS flakiness, it was this: Save now and save often. At that time, saving was not a destructive process. But it became one. And the Apple Mac was where it started. The Mac introduced "File Save with no overwrite confirmation." This meant you could have a problem if you opened a 10 page report, spent an hour re-writing the last 5 pages, hit File Save, then changed your mind about the changes. Even worse, open the document, perform Select All , Cut, File Save, and think about what happens if the machine hiccups before you Paste.

In all these scenarios there were workarounds that prevented them from being problematic, but they required a significant change in work flow. And for what? To make it easier to save work, a goal not necessarily accomplished without some hard lessons and tough data losses in the interim. Arguably things got worse when Microsoft Windows apps aped this style of File Save. (I well recall long distance arguments as a beta-tester with Borland as it struggled to choose the file save style for Quattro Pro--go with the new Excel/Mac "overwrite" style or stick with the traditional "confirm overwrite" style of Lotus 1-2-3.)

Windows aspired to be like Mac only different. That led to several File Save issues. One of the benefits of a graphical OS is the ability to convey more information in the same space. For example, an application could show if File Save was necessary by graying out and disabling the File Save command when the version of the document in memory was the same as that stored on the hard drive. But that feature has never been implemented consistently. That's a pity because it is really handy to know if changes have been made. Consider the task of editing a large image where the File Save command can take a long time to execute; performing unnecessary file saves in this situation is a real waste of time. The Canvas graphics program is one application that conforms to the "gray=saved" convention.

The current "saved" status of a document is particularly important when you are dealing with files that exist in two places, such as a web site you are editing locally before uploading. Fittingly, Dreamweaver MX is another app that uses the "gray=saved" convention.

I like the "gray=saved" convention but like a lot of interface conventions one cannot rely on it being there across apps or platforms. Why is this a problem? Because better and more consistent interfaces improve productivity and safety. We're all familiar with steering wheels. They allow us to jump behind the wheel of any car and navigate through traffic with a high level of expectation of success. They are a convention that car makers mess with at their peril, however much they want to "out-innovate" or "one-up" the competition. And we don't teach our kids to drive cars by telling them clockwise for starboard, anti-clockwise for port, because those are not the conventions used in driving cars. Port and starboard are for boats, where steering is sometimes a matter of push the tiller right to go left and so on. But in the early days of automobiles, some used tillers. Most people agree the wheel thing was a step forward and it has been the automotive interface standard for navigation for nearly a century. Maybe computers could use a similar period of interface standardization and stability.
.

   /

  No Comments

The Intuitive Interface Myth: Why computers aren't any easier to use than they used to be

  April 05, 2007    

Back in the early Post-Columbrian era I taught computer classes, hundreds of them. Four hours each, these classes covered: Computer Basics, Word Processing, Spreadsheets, and Operating System. After taking those classes you would know how to turn on a computer, create/save/print a document or spreadsheet, and make a backup copy of your work on removable media. You would also know the difference between memory and storage, RAM and ROM, and be able to answer qustions like "where does my work go wen the power goes out?"

Just 16 hours or two work days. Done and dusted. Or spend another four hours with me (or one of the dozen or so other trainers at our company) and you could build your own databases.

All of this without any "easy-to-use, intuitive graphical user interface." No hard-to-decipher icons, no tricky point-and-click devices, just simple taps on clearly labeled keys. Now, more than two decades later, a frightening number of office workers and home users have less clue about how to do their work and operate their computers than graduates of those archaic classes.

Why? The answer is going to be in some of my next postings. Meanwhile, consider this test. How easy and intuitive is A versus E? Twenty years ago option E was readily available and clearly labeled on the screen. Todays' screens are bigger, and have a lot more than two colors, but are applications any easier to use? I would argue No. Especially when if you want to talk about web apps, where almost every site has a different user interface (links are underlined, not underlined, underlined only on hover, colored differently, appear only when the arrow is over them, an icon not text, text not an icon, etc, etc).

I would hazard a guess that less than half of all people who use computers in their work today have received anything more than 4 hours of training on how to operate a computer. And that's a hazard, and accident waiting to happen, probably already happening if you dug a little deeper into the constant stream of security breaches being reported.
.

   /

  No Comments

Subscribe to: Posts (Atom)