"Undo Changes" & "Refresh"

Question

In a desktop application, where users are pulling and sometimes updating values on a "datagridview" (DGV) that is data-bound to a database, how should a designer distinguish between "undo changes" and "refresh page"?

We currently use both and they have very similar behavior - erase any values in the DGV and re-pull from the database to display what is stored.

The original idea was to handle two different situations:

1. "UNDO": I made some changes. After double checking, my changes are wrong and I would like to revert to what is stored on the database. This button prompts the user if they are sure they want to undo their changes.
2. "REFRESH:" Something was updated on the server that was not pushed/updated from my view, and I would like to pull the most current information. This button does not prompt the user if they are sure of their action.

Essentially, our "refresh" button is just an "undo" button, but without the confirmation prompt.

Some of our users are relatively tech-challenged, or speak English as a second language. Our current impression is that removing one of the buttons, or combining their text into an "UNDO/REFRESH" button, might cause some confusion.

Answer 1

"UNDO": I made some changes. After double checking, my changes are wrong and I would like to revert to what is stored on the database. This button prompts the user if they are sure they want to undo their changes.

The usual meaning of undo is to revert the most recent change that was made, not to restore the last saved version. Undo is usually performed locally within working memory.

Suppose a user makes several pages of changes to a word processing document. Then the user makes a typo. Undo should revert the most recently typed sequence, namely the typo, not restore the document from the hard drive, causing multiple pages of work to be lost. Similarly for database work that has not yet been committed. Undo should revert the last change the user made from a locally stored sequence of user actions, not destroy all work the user might have done by reloading everything from the database.

Your departure from the usual meaning of undo by overloading the term in the phrase "undo [all] changes" can lead to user confusion and lost work. The button is also redundant when "refresh" is available. Consider dropping this extra "undo" button. Also, refreshes should be undoable, so work can be restored after accidental refreshes.

Answer 2

I think the way you describe your functionality may be giving you the issue here.

I would expect a refresh button to bring back the latest data from the server, but also respect changes I had made on the client. I wouldn't expect to lose my changes. I'd expect refresh to be asyncronous and not reload the page. I might expect my changes to be held in client side state and re-applied / some form of conflict resolution encountered if I were editing something which changed on the server (concurrency issue).

Undo, I would expect my changes on the client to be reverted, but I wouldn't expect the latest data from the server. I might even expect undo to revert changes one by one.

It seems like you may be trying to combine two distinct functions into one operation. If that's acceptable to your user, then removing one option and changing the naming to something that describes what their expectation of the function seems sensible.

If your refresh will also lose your changes, that seems like a problem, but not the worst I've ever seen. However in your question your rationale for using refresh is that a user would somehow know that changes have happened and want to update, how would they know?

If your undo also gets the latest data from the database that seems a little dishonest as to it's true function.

From how you've described it I think it sounds like you could do away with refresh and just use "Undo" or "Revert" (pick a term which resonates with your users). I'd probably not bother trying to reload from the DB on and undo action, I'd revert to what the client loaded when the page was accessed. Then handle concurrency issues as a separate thing (if last in wins isn't sufficient).