I somewhat disagree with the "Ok and Cancel" metaphor. This was good advice when programs were constrained by memory and CPU power, but the better metaphor when there's abundant resources is Undo/Redo.
If the software is resource constrained and there's no easy going back, it's appropriate to offer a way for the user to back out of committing a change. It lead to the rise of dialogs for very consequential actions, like deleting a file, with "Are you sure?" buttons. They became so common they were routinely ignored, with sometimes catastrophic, or at least angst-inducing, results.
Today, we have the Trash Can metaphor. Deleted that file? Not really, fish it out of the trash. Programs like Photoshop can keep enormous levels of undo stacks, given sufficient memory.
In the author's example, a web page, there's a certain amount of laziness involved. Yes, it's harder to keep undo state, but not that hard.
> the better metaphor when there's abundant resources is Undo/Redo.
I'd be OK with that rather than OK/Cancel (although I'd prefer having both!). But undo/redo is becoming as rare as OK/Cancel.
I think that modern UIs have become degraded in a number of very annoying ways (most of which are covered by TFA), but the removal of undo is one of the worst, particularly when combined with the decreased amount of discovery in modern UIs.
Not having undo means that it's not safe to play with the UI and try things out. Combined with the lack of other forms of discovery, it makes using software into a kind of mystery.
Undo/Redo are fine but they’re not a 1:1 replacement for OK/Cancel.
Ok/Cancel can do clear hulk actions. I open a settings dialog and make a bunch of changes, if I hit Cancel I know none of them applied. However, it I hit undo, I don’t know how many were reversed. I don’t know how many times I need to hit undo to replicate the Cancel behavior, especially if it can go in history beyond the current session, as some word editors such as VIM can for example.
Applications can keep enormous stacks but humans cannot keep the same in their mind. A confirmation dialog for bulk items, or conceptually heavy items, reduces mental taxation.
5 comments
[ 38.5 ms ] story [ 106 ms ] threadIf the software is resource constrained and there's no easy going back, it's appropriate to offer a way for the user to back out of committing a change. It lead to the rise of dialogs for very consequential actions, like deleting a file, with "Are you sure?" buttons. They became so common they were routinely ignored, with sometimes catastrophic, or at least angst-inducing, results.
Today, we have the Trash Can metaphor. Deleted that file? Not really, fish it out of the trash. Programs like Photoshop can keep enormous levels of undo stacks, given sufficient memory.
In the author's example, a web page, there's a certain amount of laziness involved. Yes, it's harder to keep undo state, but not that hard.
I'd be OK with that rather than OK/Cancel (although I'd prefer having both!). But undo/redo is becoming as rare as OK/Cancel.
I think that modern UIs have become degraded in a number of very annoying ways (most of which are covered by TFA), but the removal of undo is one of the worst, particularly when combined with the decreased amount of discovery in modern UIs.
Not having undo means that it's not safe to play with the UI and try things out. Combined with the lack of other forms of discovery, it makes using software into a kind of mystery.
Ok/Cancel can do clear hulk actions. I open a settings dialog and make a bunch of changes, if I hit Cancel I know none of them applied. However, it I hit undo, I don’t know how many were reversed. I don’t know how many times I need to hit undo to replicate the Cancel behavior, especially if it can go in history beyond the current session, as some word editors such as VIM can for example.
Applications can keep enormous stacks but humans cannot keep the same in their mind. A confirmation dialog for bulk items, or conceptually heavy items, reduces mental taxation.