> Because software should “know” that we form habits.
This is my problem with SaaS as an end-user.
Imagine one day you leave home to drive to work. You have a coffee in one hand and a briefcase in the other. You have done this a million times before, getting from the front door to your driver's seat, and you can do it blindfolded. So you grab your brief case with your coffee hand and watch so you don't drop either. You extend your hand to open your car door and ...
OUCH!
You stubbed your fingers.
Surprised, you look down and to your horror you see that your car door handle isn't there. You look around and notice that 6 inches away is something that kind of sort of looks like something resembling a car door handle, but it's different and wasn't there before. You try it, and to your relief it opens the door.
You take a seat, turn on the ignition and suddenly your am/fm radio turns on and a strange voice shouts "Welcome to Your Car Version 2.0! Try Our All New Shifter Feature!"
And that's when you look down and realize ... your damned shifter has moved to.
You never asked for this, you are now late for work and are going to take shit from your boss, your life is objectively worse off for the change and you can't, for the life of you, see how any of this is "better."
But that describes pretty much all software in current year.
Yes - that's my problem - an interface should be stable. Disable selections, fine. Remove them, no. Reorder them, absolutely not.
The changing layout of buttons in Office - yuck - I just want to do it, I don't want to think about where it is.
Fixefox seems to randomly change whether it expands bookmark menus to left or right - yuck - if it's the same bookmark/selection as a moment ago, I expect it to be in the same place!
You still need a solution for non-destructive actions. To once again use Gmail as an example, there is a setting that allows you to "undo" sending an email. However, obviously, once sent and received it cannot be undone, and on the other hand the software can't just leave it in an undoable state forever or it will never get sent at all. So you have to establish a time period during which undoing is possible. Make that time period too long, and people get annoyed that their mails are unnecessarily delayed. Make it too short, and people will fall over themselves trying to click undo before the timer runs out and might miss their window anyway.
And while email isn't too bad about this, since it's expected to be asynchronous, there are other contexts where we expect things to be immediate and not suffer an undo-delay. Here's one: broadcasting your webcam or sharing your screen on a video call. In these cases, I am happy that the software warns me ahead of time that my camera is about to be shared, rather than either 1) sharing immediately with an option to undo (oops, now all my co-workers realize that I'm butt-ass naked), or 2) sharing immediately but delaying the feed by 30 seconds to give me time to undo. It's clear in this case that an up-front warning is preferable.
I built an interface to manage an audio router. A single misplaced click could take an entire radio or television station offline, an error that occured one to many times.
So.. what I went with is a simple "hold-to-activate" button. If you clicked it without activation a few times, a little box would pop up and tell you what to do. Once you held the button down, it would display a counter, and once it reached zero, then it would take the action. We added a short cut where if you held control and alt it would bypass the counter entirely.
At the same time it would add the previous system state to an undo list where you could revert that or any number of previous actions to return to a prior state.
Once we implemented this errors fell off considerably, and errors impacting broadcast almost entirely disappeared and most of our users were very happy with the way it operated.
Unfortunately, developers who don't understand why click-and-hold was implemented then implement it in their own game for no reason. Valid reasons to implement click-and-hold include destructive actions or a lack of available buttons, but I've seen developers use it for non-destructive actions while the simple press is unoccupied.
The "pop up while I was typing and it hit a button when I hit a space" situation is especially painful. I use a custom keyboard layout with lots of layers so it's doubly frustrating for me. I just see a UI flash and I'm like "wtf did I just do?"
Any salient state change of important data ought to be reversible in the short term. I'm especially fond of Gmail's Undo Send feature (I think it's a Labs plugin, it's not default iirc). For whatever reason, the brain often finds things it forgot when you actually execute the action.
Related, being able to trace what actions were taken is also super valuable. Often this is baked in to the UI (e.g. outbox/sent items, undo menu).
Inevitably, this results in a lot of state accumulation, thus disk usage, but this can be handled by manual garbage collection (which is the 2nd step in data destruction, so this can't be undone, so use a warning here) or tunable cache/LRU settings.
GitHub is notorious for this. If you happen to accidentally press "e" while viewing a file, it will not only drop you into a clunky web editor, but it will also fork the project to your account in the background!
Just half an hour ago I accidentially wired to much money while paying an invoice. I made the transfer on desktop in my browser and had to confirm with a phone app that showed recipient and amount - i just tapped "ok". A split second later I realized my mistake. There even is a cancel transaction function in the user interface but it just told me it's too late because the transaction is already processed...
Delaying transactions for about 1 minute with a cancel option would be a possible solution.
(in this case I mailed the recipient and hope they are honest)
The problem is there are a number of scans revolving around returning accidental extra money. IE someone sends you $500 too much, they ask for it back. You send it back and then they somehow reverse the original transaction, etc.
More commonly, the original transaction looked legit, but turns out after a few days not to be. A common medium is a cashier's check; they seem more "real" than checks, but they aren't really, and it can be a week or longer before you find out one is bogus.
I don't know about just a delay. A short summary, a delay and cancel button combined with Wise's transfer money animation that gave you time to act would be a nice UX in my mind.
They should adopt the 30 second Gmail/Fastmail undo. It's saved me a few times. People don't like to proofread until after they commit.
Call up your bank and ask how to get the suggestion to the right people. I made a suggestion to my bank, and they implemented it in their app, so you never know.
Fast forward to 2022. I feel the problem has been inverted. It is no longer about losing information by lack of or ignoring a warning, today it is about creating information where none should be created.
Example 1: In better times, dialogs would store the information on ok and discard any changes on cancel. Modern implementations store on change (especially modern web guis). People close dialog windows through the window close button, with no distinction whether this is ok or cancel.
Example 2: Auto-save. Some office document opens in the browser. One wrong swipe with the pointing device, swoosh, change created and logged in the eternal history. No warning "do you want to modify this document?", and no way to turn back.
Bring back an environment where it is possible to lose something, which means one where it is possible to not modify something unintentionally.
If a user has the habit of frequently quitting the program with unsaved changes, with their brain clicking through the "discard changes?" dialog in auto-pilot mode, it is next to impossible to distinguish that case from a situation in which it was done without intent, causing unwanted loss of data.
I suspect that a simple UI modification which could reduce occurrences of the situation, without being too obtrustive would be to make it a checkbox:
[ ] I agree with unsaved data being discarded [ OK ]
The OK button is ignored unless the box is checked. This is exactly like a Terms-of-Service agreement workflow.
Another idea would be to make the UI sensitive to the amount of unsaved content. The software should have an idea of whether the unsaved content represents 57 edit operations, or just two. Or maybe in terms of number of objects or bytes involved or some other specific measure.
If the amount of unsaved material seems significant, then have the checkbox workflow. Otherwise just the [OK] without the checkbox.
If a user has the habit of frequently quitting the program with unsaved changes, with their brain clicking through the "discard changes?" dialog in auto-pilot mode, it is next to impossible to distinguish that case from a situation in which it was done without intent, causing unwanted loss of data.
This problem was solved in MacOS X Lion 11 years ago. The solution is to get rid of this dialog entirely and to simply auto-save documents by default when quitting and to re-open all documents when the application is started again (persistent state). This feature applies even to new documents which have never been explicitly saved by the user nor even given a name. Only when you attempt to close (or explicitly save) an unnamed document does it ask you to choose a name or delete the document (with an explicit delete button marked in red text).
This also has the added benefit that when you use the save command (command-s) you're actually saving a snapshot of your document which you can recover later with a time-machine like history viewer interface. Otherwise, all other changes to your document since the last snapshot are auto-saved.
A further option is to do what Notepad++ does: save current state even through closing and reopening the application until the user closes the file. When you restart the app files that were never saved and never close are as they were, modified files too. The possible issues with modified files is that if you think you've saved and don't get prompted then run some other tool that relies on the new information it won't be there (as the saved state is elsewhere, not the main file).
Keep the “do you want to save first?” prompts for when closing the file.
Of course for some file types this could use a lot of storage, so it won't be as applicable everywhere.
or you can do what libreoffice does and display an obnoxious dialog when the program starts, demanding to know what to do with the documents you were messing with last time
To really rub it in in proper libreoffice fashion it also needs to pop up an opaque warning message telling you that the restore failed and this is your only chance to try to restore the restore of the restore.
Nothing about what's being discussed has been presented as an absolute. So in situations like that, just give a warning, if anything, since saving might be counter to the intent of the mode. In other words, exercise good judgment based on the circumstances.
>> So in situations like that, just give a warning, if anything [quoting myself, adding emphasis]
Again, it's about judgement for the circumstances. We're in agreement here, but your original comment read as if you were taking the discussion here as being about absolutes.
Correct. Nothing like this should be enabled in a private mode, and no user should expect it to be¹ enabled in a private mode. Losing unsaved data is a logical consequence of being in a private mode, it is up to the user to be careful here.
This won't harm unsuspecting users if you need to explicitly request privacy, by for instance opening an incognito window, if you request privacy it is valid to assume you know the potential consequences.
----
[1] Though you shouldn't rely on it not being, never assume there are no idiots around not thinking straight when implementing private functions and things that might interact with them! Trust but verify. Or just verify.
TFA sort of addresses this and while it's better, it's still "warn-think", it's just a more glorified and tedious habit, depending on what happens when OK is clicked without the discard box checked.
I presume the default action stashes the data somewhere, in which case it's basically the trash bin pattern or tempfile pattern (stored durably, not /tmp), and we can safely go back to a plain dialog like:
You have unsaved changes.
Do you wish to save as a new file,
or discard?
(Unsaved changes can be recovered
for 1 month before permanent deletion)
I wonder if we need a new UX pattern where every single destructive action is delayed by ~30s such that there is ample time to press “cmd+z” or a toast undo button.
It’s not very difficult to implement the client side code for this, and I think users would appreciate it.
However delaying a “delete” would cause some complications with the local data, where you might want to optimistically render the UI such that the delete went through. That shouldn’t be difficult in any modern state management library though.
with as much time, effort, use, and praise that these get, I would expect every state change / collection to have a corresponding input and action buffer, effectively making all user actions CTRL+Z-able.
The latest version of the MacOS (Ventura) has a delay in sending mail. I haven't timed it, but it seems like about 20 seconds. During that time, there's an "Undo Send" in the bottom of the nav pane.
We might be better off if conventions in email programs changed so that the "Send" was not the default but rather something like "Schedule this to be sent at the next top of the hour". We wouldn't have to resort to any UI fakery, and there might be interesting societal effects if widespread enough. (Most mail delivery doesn't need to be immediate, but pretty much no one tunes their setup to minimize interruptions.)
It obviously won't work very well if it's entirely handled by the client, since your battery might die, you might go out of range, etc.
The even worse version of this is dialogue windows suddenly popping into focus. You're writing an email and suddenly your whitespace ends up "yes"ing a file overwrite. Windows is rather bad at these; browsers seem to be better by keeping these dialogues local to the tabs at least.
Firefox has added a small delay to prevent this exploit.
Chrome has responded that it has yet to have been detected and weaponized yet.
Imagine a small game where you must press the [Enter] key rapidly.
Would you, with a few similar boxes in game to detract, notice the Open_Folder_DialogBox for a few frames? Probably not in time to not hit the [Enter] key, giving the webpage's javascript full permissions to everything in the default, selected Folder...which is the C: drive.
> Firefox has added a small delay to prevent this exploit.
This can be a mild irritation in FF. In other contexts it could be very irritating. The problem with blocking user action for the user's safety is that most users don't appreciate it until they do something wrong (by which point I've found the option to turn the protection off!)
A trivial band-aid, such as only delaying the input if the user has repeatedly pressed the [Enter] button in the last 3 seconds, could thwart naive attempts.
A clever bypass would be to have the [Enter] button be pressed when reacting to something on screen, such as an incoming guitar strum or a dinosaur hopping over a cactus, then throw the OpenFileDialog before the goal/expected [Enter] keypress.
Actually there were scam games like that back in the era of Symbian Java Apps. You click-click-click and then a window asking you to send an expensive sms pops up.
Which is exactly why various window managers on linux have "focus stealing prevention" settings. E.g. in compiz you can tell it how hard to prevent focus stealing. On the strictest setting applications simply cannot steal focus. On lower settings it will prevent focus changing for a few seconds after typing or clicking.
The window manager I use doesn't even have the concept of applications taking focus. When they try the window border simply turns red instead. It's great. Now if only they'd have some way to make newly opened windows not entirely clobber your window layout it'd be perfect.
Ideally, when calling OpenFileDialog or equivalent user prompts, one should opt for using verbose action labels, instead of the often ambiguous defaults (Okay/Cancel, Yes/No, worst yet: Yes/No/Cancel):
Are you sure you want to delete this draft? [(Yes) Delete Draft] [Cancel (Deletion)]
Are you sure you would like to Exit? [(Yes) Exit ($appname)] [No, Continue]
()*optional extra specificity for clarity
With more sensitive commands with possibly dubious parameters, prompting the user to re-enter the dubious argument can help default mindless clicks or the occasional brain fog or mistype; even translates well onto command line:
>>Are you sure you want to delete 12 folders, totalling 23,401 files? Please confirm the number of files to proceed:
>>23401
One horrible example was back in the MS-DOS days. FORMAT wanted you to tell it when you had inserted the floppy. So it said "Hit any key to continue". And it really meant "hit any key". Control-C? Continue. Escape? Continue. Cntrl-alt-delete? Continue. There literally was no way out except to power off the machine. (Well, if it was a floppy, you could remove the floppy.)
Not accepting the normal ways of stopping execution, when it's a destructive operation, and not explicitly warning the user that you're going to proceed even on the normal "stop" keystrokes... that's a really bad combination.
It's hard to construct such phrases to be disambiguous.
"Continue" as an answer to "Would you like to exit?" can be interpreted as continuing with the exit or with using the software. And there are plenty of similar examples.
My problem with lots of these experiences is that they're still boilerplate (whether verbose or not) and require me to apply a conditional that the computer should tell me about.
For example, quitting a game: "Are you sure (Y/N)? (Unsaved progress may be lost)"
Don't tell me that. Tell me whether unsaved progress will be lost and what it consists of.
Likewise, when I'm typing a description in JIRA and want to follow a link "Are you sure you want to navigate away (Y/N)? (Unsaved changes may be lost)"
Wait--do I have unsaved changes? If so, what are they? That's what I should be basing my decision on--what specifically will happen if I click Yea or Nay? Not a general exhortation to be careful because waves hands something bad might happen: YOU get to figure out if it will or not!
Windows Notepad has gotten that right since inception, but a more detailed report of the magnitude of action/changes/loss would definitely be a trivial and welcome feature.
I think the overall idea is that smaller dialog in prompt boxes are somehow better to avoid "warning/agree fatigue" but ultimately it worsens the overall clarity of the function and purpose.
Sure, it would have to be thoughtful, careful, context-dependent and possibly optional (e.g. a "Details" toggle or something).
But it would still be so much more useful to see "Do you want to navigate away? (580 characters of Description and two other fields will be lost)". Or "Do you want to quit? (0:28 mins of play will be lost)" versus just quitting when nothing will be lost because the auto-save is up to date.
Just warning that something may or may not be destructive and leaving it up to me to guess how things work feels lazy to me, as a user. As a developer, I understand it entirely!
And it would help avoid warning fatigue because the warning only appears when something actually is going to be lost--and then you can decide whether to keep it or not.
> But it would still be so much more useful to see "Do you want to navigate away? (580 characters of Description and two other fields will be lost)". Or "Do you want to quit? (0:28 mins of play will be lost)" versus just quitting when nothing will be lost because the auto-save is up to date.
For games, you could perhaps even omit the warning entirely if you just saved manually.
Right--that's the heart of what I'm thinking. If there really isn't unsaved work or unsaved progress or whatever... don't warn me at all. That will also solve the habituation problem of always dismissing warnings--because when a warning appears, I'll know it's substantive.
> Are you sure you want to delete this draft? [(Yes) Delete Draft] [Cancel (Deletion)]
> Are you sure you would like to Exit? [(Yes) Exit ($appname)] [No, Continue]
I see you are starting to discover the GNOME Human Interface Guidelines. Yes/No and OK/Cancel are discouraged, opting for meaningful button names instead.
Especially in a mobile interface. The user is physically touching "I'm done for now"; it's a visceral interface; real hard to mess up unless some motility accident happens (like the phone slips)
I disagree that it's visceral on mobile. First, close your eyes then toss your phone up in the air with a spin, catch it and try and then try and click on 'I'm done for now'. Feels exactly the same as "I'm still working!". "Visceral" should be reserved for things with physical buttons that make a satisfying ca-chunk and you're sure, blindfolded, that you didn't press the wrong one. Not slippery glass bricks.
I used to think you could just use a warning that forces the user to follow specific instructions. But the author says this "impossible to ignore" warnings:
> It causes us to concentrate on the unhabitual-task at hand and not on whether we want to be throwing away our work
And in fact, I learned this the hard way. One time, while in a rush to meet up with some friends, I tried to sign out of a mobile app. I went to settings and scanned for the logout button, saw some red text, and clicked it. There was a warning, which I quickly clicked through. Then there was a dialog asking me to enter my password to confirm. I thought that was strange, but just then I got a notification that my friends were outside, and I quickly tapped the input box, auto-filled from my password manager, and headed out the door. Later on, I learned that I deleted my account.
I was very lucky that this happened to be an account for a service that I self host and backup regularly. I restored from backup and got my account back. But I shudder to think what would happen if it were my Google or iCloud account.
Honestly I don't know what the app developers could have done differently here. Maybe not put the sign out button next to the delete account button. But it goes to show that impossible-to-ignore warnings are totally possible to ignore
I don't know how it works. The pull down is small and vanishes after some seconds. And then? I am still to late and feel even more sorry for myself (double fail)
On my systems I have undo of the file system under control. snapshots. I'm using it since years. Saved me twice! I recommend this all the time ... (I know it's not for everybody)
I still wish I could convince gmail to send emails immediately though. Used to be that they showed up within a second or two, but now you need to wait half a minute or longer before it shows up in someone else's inbox.
Setting the timeout lower doesn't seem to help much.
We have some custom tools at my office that don't provide warnings or undo. It would be nice if they at least provided a warning when you hit delete with multiple items selected. When I asked the senior dev on the system about it he said, "Undo? Why would we have that?" (or words to that effect) "Just save more often and when you delete something you didn't mean to, close it and reopen it" (that part is near verbatim).
Undo systems can be annoying to create after the fact, but if you use a variation on the command pattern you can often get them "for free" (along with a lot of other useful capabilities). I wish that were more common.
"Okay, provide rotating backups, at least!" I would have said.
Saving is also a destructive operation that can lose data, which brings us back to undo. If you open a document, make an unwanted edit and save, and you have no undo, you can only recover the prior state from the editor backup.
Without automated multiple backups, the user would have to do "save as" regularly, choosing different filenames, rather than just "save".
I have a couple startups and this desperation framework does not resonate with me. I do startups because I enjoy creating software/processes/opportunities that others benefit from and not having my financial outcomes bound directly to time. I don't feel desperation at all.
Inverse problem: I accidentally hit the "cancel ride" button when I was in a lyft ride. It opened up a dialog to confirm where I hit "cancel" to cancel the operation of cancelling and of course it cancelled the ride. That was embarrassing.
A List Apart always brings the memories. But I never realized that Aza Raskin posted there even I've read somethig like this from him elsewhere. Was big fan of Enso.
And while you're at it, never disable a menu item or widget without providing feedback (like a tooltip) about WHY it's disabled and what to do to enable it!
[2007] but also timeless advice, at least while our UIs still follow the same general paradigms.
It's important to note that Aza Raskin is the son of Jef Raskin, who wrote a lot about interfaces (including a book called The Humane Interface), and worked on the original Macintosh at Apple, on the interface.
https://xkcd.com/1425/ but replace "whether they're in a national park" with "show a warning" and "whether the photo is of a bird" with "have a undo button".
“When you delete an e-mail, it immediately gives you an option to undo that action. How humane! ” - except that option disappears after a while, so if I hit delete, switch windows and then think “oh shit I need that email back” then the undo option is gone and I’m screwed anyway.
I’m also unsure about an article that claims “to one of the most basic and important mantras of interface design: Never use a warning when you mean undo.” When in the first examples it ignores one of the most basic and important mantras of interface design: use full sentences in your action buttons, not just “Okay”.
It's not a nightmare unless you try to tack it on after the fact. Start (or earlier in the process incorporate) some variation of command pattern into the system and it's not too bad. Some actions will remain irreversible, but those are ones that would be irreversible regardless of whether you have an undo-facility or not.
Right, something like a transaction log is extremely useful in many circumstances, it's just a smart way to build stuff. It can give you better data integrity, sane parallel processing, etc.
This is my problem with SaaS as an end-user.
Imagine one day you leave home to drive to work. You have a coffee in one hand and a briefcase in the other. You have done this a million times before, getting from the front door to your driver's seat, and you can do it blindfolded. So you grab your brief case with your coffee hand and watch so you don't drop either. You extend your hand to open your car door and ...
OUCH!
You stubbed your fingers.
Surprised, you look down and to your horror you see that your car door handle isn't there. You look around and notice that 6 inches away is something that kind of sort of looks like something resembling a car door handle, but it's different and wasn't there before. You try it, and to your relief it opens the door.
You take a seat, turn on the ignition and suddenly your am/fm radio turns on and a strange voice shouts "Welcome to Your Car Version 2.0! Try Our All New Shifter Feature!"
And that's when you look down and realize ... your damned shifter has moved to.
You never asked for this, you are now late for work and are going to take shit from your boss, your life is objectively worse off for the change and you can't, for the life of you, see how any of this is "better."
But that describes pretty much all software in current year.