As with many UI/UX failures, this one has a long pedigree. A Greek interface analyst some years back identified the canonical case: <a href="http://etc.usf.edu/lit2go/35/aesops-fables/375/the-boy-who-cried-wolf/" rel="nofollow">http://etc.usf.edu/lit2go/35/aesops-fables/375/the-boy-who-c...</a><p>I'm a long-time computer professional, I've used systems for decades. I've got a security mindset. Which is to say, I'm the furthest thing from a typical user.<p><i>I consistently dismiss and get rid of security alerts.</i><p>There are a whole host of problems with the general process of <i>conveying information to people in a method likely to result in the desired action</i>. It is a very broad and general problem. It ties into various areas of alerting, alerts overload, cognitive processing, psychological biases (of both users and developers), and more.<p>Among the elements:<p>1. Users are generally trying to do something. Something <i>other</i> than what the developer is trying to alert them of.<p>2. Users are often trying to do <i>several</i> things. The more so with mobile computing. Hopefully they're not operating heavy machinery (lawn mowers, cars, aircraft), <i>but that happens.</i><p>3. The local user environment is often hostile. <i>Never underestimate the hostility of the operating environment.</i> <a href="https://ello.co/dredmorbius/post/ef662JsTwbGM_zH1s8qGZg" rel="nofollow">https://ello.co/dredmorbius/post/ef662JsTwbGM_zH1s8qGZg</a><p>4. The user, not some remote developer or site, is in ultimate control over their system. Perhaps not <i>perfect</i> control, but control.<p>5. <i>Systems are insanely shitty at preserving user state.</i> And pretty much always have been. <i>Especially</i> GUIs. In my physical office, items remain where I leave them. Though the appearance may seem chaotic to others, <i>it has a logic to me</i>, even if that's only happenstance and temporary. <i>Things moved, even only slightly, are maddening.</i><p>Our desktops often have little or no respect for our organisation. They don't have sufficient space, they don't retain order. File managers reorder files, desktops reorder windows and icons. Applications, closed, don't restore to original state.<p>Curiously, it's limited and simple systems which tend to fare far better. Commandline and console tools don't have this state to be interferred with. Directory listings don't re-order themselves spontaneously. Screen, or tmux, or vim, or emacs sessions are surprisingly effective at retaining state. The old PalmOS didn't afford a great many capabilities, <i>but those it did it afforded well</i>. Android, by contrast, fares far worse, and a constant frustration is loss of content-in-process edited in a browser session.<p>The upshot: <i>users hate restarting or updating systems, because everything changes, and systems don't respect user state.</i><p>So even <i>if</i> an update could be run quickly and effectively, it's avoided.<p>6. Systems don't provide an option for rescheduling maintenance work for a truly opportune time. Office cleaners don't work during core business hours. Maintenance work is, where possible, scheduled for off-peak hours or days. Our computers don't generally follow these practices, <i>if only because the maintenance processes themselves aren't self-contained</i>. User prompts or queries (often utterly meaningless) need to be addressed. Updates cannot happen in a single contained session. Multiple reboots and restarts occur.<p>7. Vendors don't limit system security updates to system security changes. In far too many instances, other changes are piggybacked in -- crapware installations, <i>feature removals</i>, and more, which past experience has often shown <i>cannot be effectively rolled back.</i><p>This gets <i>directly</i> to the fable I started this with and its message: trust is a very, very fragile commodity, and abused is lost often forever. <i>Do not fuck with your users' trust, you will die.</i> Maybe not quickly, and often only slowly and painfully.<p>8. Programmers' and users' priorities for alerts differ hugely. A programmer's primary concern is covering their own ass -- not failing to alert for something which might possibly go wrong. A user's concern is <i>getting their job done</i> and <i>being alerted if the building is on fire</i>. For pretty much anything else, <i>they simply do not care, nor should they</i>. Psychological limits on attention, and practical limits on expertise, mean that <i>querying</i> users for actions is almost always wrong. <i>Do the right thing, do it without fucking with what the user's activity, do it without fucking with the user's state.</i><p>I've written previously on alerms and alerting in hospital and Google settings:<p><a href="https://www.reddit.com/r/dredmorbius/comments/1x0p1b/npr_silencing_hospital_alarms_results_in_better/" rel="nofollow">https://www.reddit.com/r/dredmorbius/comments/1x0p1b/npr_sil...</a><p><a href="https://www.reddit.com/r/dredmorbius/comments/2j9xri/alerting_response_google_site_reliability/" rel="nofollow">https://www.reddit.com/r/dredmorbius/comments/2j9xri/alertin...</a><p>Repacking this, what <i>should</i> alerts do?<p>1. If an action is harmful, <i>disable it.</i><p>2. If it's not possible to tell if an action is harmful or not <i>figure out what the underlying threat is and fix the flaw exposing it.</i><p>3. Create stateless systems -- operating systems, applications, etc., should simply <i>revert to previous state when respawned, without user action.</i> (A "wipe slate" feature might also be useful, though think through that.) This calls for a pretty solid re-think of just what applications and environments are.<p>4. <i>Schedule maintenance for times the user isn't actively using the system.</i> The only exception is for maintenance which can occur without violating user space.<p>5. <i>Do not overload security and bugfix updates.</i> The Windows 10 forced migration is a key instance of this. Virtually any carrier- or vendor-based smartphone or tablet update likewise. There are reasons I have bought my last Android device. Samsung and Google have both violated my trust repeatedly.