What happens when a frequently used option (close widget) is placed next to a Delete function?
There is a guarantee that some percent of the time the user will click on the wrong button. That user, in this case, was me. I deleted everything in a WordPress widget that had 16 individually formatted fields.
Preventing the mistakes of users with good intentions
It’s not that I’m upset that I lost data from the few minutes I spent carefully filling those fields out, it’s the fact that every time I close a widget I have to stop and think, else I may automatically press the Delete button vs. the close button.
Where is the soft delete or modal confirmation?
it’s not a soft delete that happens either – there is no undo, no “are you sure you want to do this?”, no “this widget will be removed — ok/cancel?”. It simply disappears.
Psychological response and conditioning to potential data loss as a result of ill-placed buttons
So either I begin to regard the widget section as a minefield for potential data loss or misfortune and stop editing it unless I’m wide awake and prepared for the potential consequences of an errant click, or something happens where these buttons are placed at least a few target distances apart.
Revisions and soft deletion
If a frequently used option is to be placed next to a delete option, a soft delete or a confirmation dialog for such a drastic action should be employed. Else, the functions should be placed at least one target size away to ensure one is not accidentally clicked in place of the other.
When I posted my initial thoughts about this button placement on Twitter, Devin Price replied, that, “I think the actual flaw is that there isn’t an undo button. Widgets should be saving revisions just like posts do”.
“But just look at how nice, big, blue, beveled and separated “save” is”, Chris Teso responded. In the WordPress widget function, pressing Save doesn’t close the widget box. It would be great if it did. Instead, the user must press Save and then close, going near the dreaded “Delete” option in the process.
This reminded me of a recent discussion Tantek Çelik and I had about forgiving interfaces. One of the best implementations of a forgiving interfaces is Gmail’s undo functionality. Its soft delete allows one to undo every action after it is done. It allows one step backward in time from a potentially damaging action. Users of software such as Photoshop are used to forgiving interfaces, and each new version of the software stores actions and histories in an even more forgiving, and often visual way. This digital paleontology allows one to dig up useful historical states and essentially go back in time.
“Interfaces should always be at least a little forgiving”, writes Çelik, “Allow undo post/edit/delete even if just for 30 seconds”.
“Gmail Labs’ “Undo Send” extension gets this right (without the cognitive load of previous attempts like scheduled sends)”, Çelik, “All forms of send/post/tweet verbs should be as forgiving. If you’re regretting your sending, undo”. He then points to a related article on Undo Send in Google labs.
As for the current moment, I’d like to be able to edit without the physiological drawbacks of constantly worrying whether or not I will lose data simply because I’ve pressed the wrong button.