How do I politely ask the user to refresh after concurrent editing has occurred?

Question

I know this situation is not ideal but cannot be avoided.

I have a website database system where a user can choose from a list and display information, edit it and then save it. During the time a record is viewed and saved it is possible the information has been updated and an error message will be displayed to the user.

If they refresh the page they can be more inconvenienced as filters used to select the data will be dropped. Instead I want them to select the same item from the list, causing a refresh of the data to the current version.

I am looking for a clear description for the error message. So far I have this, can anyone improve on it as I feel it is not concise, partially because I think refreshing is a common task the users will understand but re-selecting an already selected item wouldn't be a frequent exercise they are familiar with.

"The information for this selection has been modified since it was opened, please select the item again in order to see the most recent changes."

Answer 1

The situation you are working on relates to the more general issue of managing conflicts in a multi-user transactional system.

Before crafting the best and most polite message, you need to make sure you have chosen a crystal clear conflict resolution policy that makes sense in your context and that you and your users are comfortable with.

note 1 : I suspect from your description that having real time refreshed information on your website is not an option. If it were, you could have interesting workflow options and for instance display things like "User X is currently editing this" on User Y's screen (like the "X is typing..." in some web chat services).

note 2 : I also suspect that for the sake of simpicity, implementing a transaction locking system (the first editor locks the item and the following people trying to edit the data are informed that they cannot proceed until the resource has been unlocked) is neither an option.

Let us assume that what the users see is the data as it were when their current page loaded and that their is no locking feature. A (bad) surprise can then come just after a user submits their edit action. It is ok to choose a policy that states : "last editor wins" and you can implement it for example the following way :

• when a user first clicks to edit the data, a reference to the current state of the data is stored in the form (e.g. its id and version number or timestamp)
• the user takes their time to prepare and type their edit
• they submit (the action which is a request for change)
• if the reference to the former state of the data is aligned with the version present in the server, the edit is simply successful
• if not, this means that the data has been edited (generally by another user) in the meantime.

What you want to achieve then is :

1. inform the user
2. allow them to make an informed choice
3. protect them from losing what they've done (hence proving that you value their time and efforts)

A way to achieve the above could be, in the same view and at the same time, to :

• inform them that the data has been edited in the meantime
• show them the edited data
• display their own edit (which has been sent to the server via the form) in a way (e.g. text area for instance) that is still editable
• offer two action buttons : "cancel" (i.e. keep the other user's edit) or "overwrite with my edit"