From: blockedofcourse@foo.invalid   
      
   On 12/10/2025 6:51 AM, Martin Brown wrote:   
   >> For something as ubiquitous and ESSENTIAL, there doesn't seem to be   
   >> much GOOD thought going into their design!   
   >   
   > They are cheap and cheerful consumer products (even the expensive ones).   
      
   But, that doesn't mean they can't be THOUGHTFULLY designed!   
   We're long past the "blinking 12:00 on VCRs" era.  They include   
   "10 year power sources" to address the fact that battery replacement   
   is an issue discouraging their use.  Why not put some thought into   
   how they ALARM and how the user interacts with them?  (Or, make   
   false alarms IMPOSSIBLE!)   
      
   >> There's a way to "silence" our alarm -- but, ask me if I remember how...   
   >> Damn thing can talk so why can't it TELL me how to silence itself when   
   >> it starts screaming?   
   >   
   > ISTR that in the Three Mile Island disaster they spent the first fifteen   
   > minutes of the emergency trying to silence all the different damn alarms that   
   > made it impossible to think in the control room. Only once they had the noise   
   > under control could they communicate with each other across the room. It was   
   > part of a human factors course on best practice interface design with good   
   and   
   > bad examples.   
      
   Yes.  An alarm should be something done FOR the user not something done TO him.   
      
   > Aircraft have got much more sensible warning and alert systems making the   
   > simplifying assumption that the pilots don't want to die.   
      
   I designed a LORAN-C -based autopilot for boats in ~1980; type in lat-lon and   
   I'll get you there, compensating for ocean currents, drift, etc.   
      
   But, no tie-in to the RADAR and no optical sensing -- so I can't tell if   
   I'm going to drive OVER some other craft on the way!   
      
   However, I could tell you when we have arrived at the destination -- but,   
   can't cut the throttle (so, I'm essentially going to make a 180 once I get   
   past the destination and head *back* to it, as soon as I sense I've passed   
   it.  Repeating this behavior until the tanks run dry!   
      
   I advocated to put an alarm on it so the skipper would know that we were   
   approaching that point (imagine him being below deck or aft setting   
   up lobster pots and not "seeing" where the craft was).  Boss told me:   
   "The first time that alarm sounds, the skipper is going to cut the wires   
   to it!"   
      
   That was a turning point in how I handled "notifications"; they are   
   INTERRUPTIONS, don't force them on the user.   
      
   Like early Windows print drivers that would put up a modal dialog   
   indicating "out of paper' -- effectively locking up the machine   
   just because there was no paper in the printer, NOW (um, what's   
   the purpose of multitasking if you can't alert to some condition   
   WHILE also doing other things???)   
      
   >> Attempting to remove power requires you to remove the unit from its   
   >> mount (which tends to be over the heads of many folks); hold the unit   
   >> in one hand (constrained by the length of the pigtails that connect   
   >> it to the household wiring) and release the mechanical "catch" that   
   >> secures the mains connection to the device; remove that connection;   
   >> open the battery compartment (which is not mechanically possible while   
   >> the mains connection is in place) and remove the batteries.   
   >>   
   >> And, HOPE that the unit you've dissected is the one responsible for   
   >> initiating the alarm!   
   >   
   > One in our village hall went rogue last week. I needed my apple picking tool   
   to   
   > remove it from the ceiling. It was so loud that I didn't want to get any   
   nearer   
   > to it! It had a sounder disable switch on the back.   
      
   Ours has a single button:  press to test.  Likely ALSO the "press to silence"   
   button -- but, do I have to find the unit that is reporting the alarm to   
   silence it?  What if I push "silence" on one of the "cheerleader" units?   
   Will it, instead, invoke the test function?  If I silence the offender,   
   will that also silence his peers?  Do I have to do this on every unit?   
   ("Would someone please kill that blasted noise so I can THINK about this?")   
      
   There's a description of how to interpret the tri-color LED printed on it...   
   in GREY letters on a white background.  (wouldn't want it to be TOO noticeable   
   as then the detector itself might stand out instead of blending into the   
   wallpaper!)   
      
   IN A 3 POINT TYPEFACE!  (yeah, I'm going to be able to read that up   
   above my head)   
      
   Oh, and "TEST WEEKLY".   
      
   On the BACk are the instructions describing how each alert is signaled   
   (CO vs smoke vs low battery vs end-of-life vs fault vs on-battery vs all ok!)   
      
   Yet, nothing about how the secondary units behave...   
      
   C'mon, you're making BILLIONS of these things!  You can't spend a few more   
   design minutes thinking about how to improve their utility???   
      
   > Again battery fail in the cold weather but instead of an annoying bleep it   
   went   
   > off as if there was a fire. Luckily the neighbour is deaf!   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)