0

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.

2
  • "After double checking, my changes are wrong and I would like to revert to what is stored on the database" – This is a little confusing, if the database still holds old values where were your changes saved? Are you storing multiple instances so that these can be reverted back? If yes, then 'Revert' is another possible button to consider.
    – Ren
    Jun 27, 2019 at 10:04
  • Who are your target users? Are they technologically-proficient enough to understand that there may be newer versions of the data in the database than what they are currently working with? Jun 27, 2019 at 14:09

2 Answers 2

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.

0

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).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.