The Undo UI Pattern – even in Clarify using ClearBasic
A common UI pattern you see today is the Undo pattern.
The Undo pattern, as described by Patternry:
People tend to make mistakes when interacting with applications. Making one mistake can throw away hours of work.
Therefore users should be have an option to easily undo their actions and get their work back.
What problem does the pattern solve?
- Whenever there is an opportunity to lose work, the program should allow undo actions.
- The more costly it is to lose data, the more important it is to provide undo.
- Never use a warning when you mean undo.
This pattern is inspired by Aza Raskin’s article “Never Use a Warning When you Mean Undo”.
Undo in Clarify
We see this pattern a lot in contemporary applications, but there’s no reason you can’t also implement this pattern in legacy applications – such as the Clarify Client.
Typically in Clarify, you’ll see a “Are you sure you want to delete?” message box used as a confirmation when you try to delete something. Most of the time, you do want to delete, so this message box slows you down most of the time.
Instead, we’ll let the delete action occur without requiring the user to acknowledge a message box. And we’ll allow for an Undo option.
I recently did some Clarify Classic Client customizations where I used this pattern. Lets have a look.
Time Logs form
I have a Time Logs form for creating/deleting time log entries.
As I mentioned, it’s common to use a confirmation dialog when the user clicks the Delete button, like so:
Instead, lets skip the conformation dialog, and just the let the delete happen without confirmation.
Like so: (you’ll just have to trust me here that there’s no confirmation dialog posted)
Notice that I’m also using the Improved Clarify Messaging (the yellow message bar at the top of the form) that I discussed in a previous post to inform the user what happened.
Also notice that the Undo Delete button is now enabled.
Clicking that button will Undo the Delete action.
Here’s what it looks like after clicking the Undo Delete button.
Pretty sweet. We’ve just un-done the delete.
How to
The way I accomplish this is pretty simple.
When the Delete button is clicked, I simply save a copy of the record that I’m deleting in a form (module) level variable.
When the Undo Delete button is clicked, I simply insert the record that was previously saved in the Delete click.
That’s basically it.
Activity Logs
If you’re creating activity logs for these actions, it does get a little trickier.
In this particular scenario, when I delete a time log, I also add an activity entry for the delete action.
So, when I Undo the delete, I also:
- Delete the previous Delete Time Log activity entry
- Relate the new time log back to the act_entry from the original Create Time Log activity
To make this easier, when I do the delete action, I also save a copy of the Create Time Log act_entry record in a form (module) level variable, so I can use it in the Undo action.
Like I said, a little tricky to wrap your head around, but pretty easy to code once you understand it.
Summary
Just because you may be working with a legacy language or legacy application doesn’t mean that you can’t use good code and UI patterns.
Your users will thank you.
Rock on.
