>"Think of how often you Undo every day. Undo makes lots of apps safe for exploration and regular use."
In 2015, when I see and use software that doesn't subtly prompt the user to undo actions for a short period of time after an interaction I just shake my head.
It's such an easy way to reduce customer service complaints it's ridiculous. Empirically, with the companies I have consulted, 'ridiculous' often means 20-40% instant reduction of complaints.
> In 2015, when I see and use software that doesn't subtly prompt the user to undo actions for a short period of time after an interaction I just shake my head.
Subtly prompting is not enough, keeping a recycle bin or undo-stack is much preferable. The android photo app is a great example of this. By sliding right or left you move to the next/previous photo. By sliding the photo up you delete it and then move to the next photo! The only notification of this is a subtle prompt at the bottom of the screen: "Photo deleted - Undo?"
I gave my tablet to my mom to browse through photos, guess what she did to browse to the next photo: swipe up. She didn't notice the subtle prompt at the bottom of the screen and ended up deleting half of my photos before she noticed it, by then it was too late as the undo only worked one step back. Luckily i had the photos stored elsewhere also.
This has to be the worst UI decision I've seen in any app ever.
Especially as when you're lying down the phone can switch between landscape and portrait seemingly randomly, and suddenly the exact same action for scrolling becomes delete
The Unix shell, one of the most successful user interfaces ever developed, doesn't support undo nor does it need to. It's successful because it doesn't presume to know better than the user.
Oh but i would like it so much if it did. There would be no need for --dry-run options on commands, and it would be much easier to test command-line software and do exploratory learning.
I think it would be a great usability improvement. Even if it were "only" on a file-system change level. And even if weren't always enabled, like, maybe make it so you have to first "begin" a file-system transaction to be able to roll it back if you don't like the changes you did. Imagine something like:
$ begin-tx
tx$ ./some-script-i-am-not-sure-works-properly
tx$ # Check if everything looks good.
tx$ # In case everything went good:
tx$ Ctrl+D # ...or "commit" to end the transaction.
tx$ # Or, in case i see something went wrong:
tx$ Ctrl+X # ...or "abort" to roll back the changes.
$
(Disclaimer: maybe something like this already exists, is widely supported, and i've just been doing it wrong the whole time.)
Strangely, the only command-line software where i feel i can do exploratory learning, instead of always having to resort to the man pages, is git. With git, even if i'm making the most destructive history rewriting with `git filter-branch`, i know that if i screw up i can always run `git reflog` and checkout some ref that i know was OK.
You would need to implement this at the file-system level. You should be able to do this easily with any file-system that supports snapshotting, such as btrfs.
I don't think it's that easy and I do think the parent has a point. I mean, while you're busy writing a perl one-liner to munge on your file, ten daemons are writing to their log files, all on the same file system. You want to roll back the effects of your script doing an accidental rm ~/*, but not what's in the logs. Probably a better idea is to strace the shell's children and record changes, then apply or forget them.
In 2015, when I see and use software that doesn't subtly prompt the user to undo actions for a short period of time after an interaction I just shake my head.
It's such an easy way to reduce customer service complaints it's ridiculous. Empirically, with the companies I have consulted, 'ridiculous' often means 20-40% instant reduction of complaints.