“Record in Use By Other User” Guidance: Try Again Later? Or Other Solution?

Question

Considered we have a use case where the product technology doesn't allow edits of the same record at the same time (for example different users might be want to editing different parts of a customer record - credit rating, address, email, whatever).

Who should that be conveyed to editors of the records? The row could be locked in the database, but what should the user see and be told?

I was considering a red error icon on the table row in the UI with a tip or legend saying record in use. I would say prevention of the editing action is the safest way to go here, but what should the user be told about when the record is updated and enabled for editing again? "Record is being edited by another user. Try again later"?

But in how long...?..:) Maybe a contextual action on the record being edited, showing who has it in use and a dialog box option with instant message, email or click to dial to ask?

Another option might be to enable the attempting editing user to save a draft of their edits and then merge them back to the record when the row is unlocked for editing. Again a message that changes are saved, and changes can be reviewed before merging (and which changes) would be needed I guess.

Anyone got best practices, or examples they can share? Trying to eliminate any dirty data or duplicate record cleanup later.

Answer 1

Try going out of your way to make things easier for your users. Have you considered having a "resolution screen" from which a user can manually merge two records? For example...

1. User A opens the record and starts editing things.
2. User B opens the record and starts editing things.
3. User A saves his modifications. As a result, a timestamp field is updated in the record.
4. User B attempts to save his modifications. Your application notices the timestamp field has changed since User B opened the record.
5. User B is presented with a side-by-side view of the two versions of the record - his on the left, and the database's on the right.
6. User B can then choose specific fields of his to merge right into the database version.
7. User B can then save his changes to disk (assuming the timestamp field hasn't changed again).

This sort of approach may not work if your records are exceedingly complex. However, it does save users from needing to re-input their data if there is contention over the record.

Things like revision summaries and highlighting diffs would help as well.

Answer 2

To suggest another approach from the ones already submitted above: you could also take a hint from Google's collaborative editing. Instead of having to resolve conflicts, you make sure that opened copies of the same data always stay in sync in real time. So, both users A and B have the same record open, and user A starts editing fields, these fields are immediately updated for user B as well. Because the information between the instances stays in sync, there is no need for merging versions of the data later on.

This solution is technically very challenging, of course. But I think in terms of user experience, it is hard to beat. A demo of collaboratively editing a Google Docs document can be seen on youtube, though I'm sure there are plenty of other similar demos to be found. I remember the video from the unveiling of Google Wave that introduced this, and that was quite impressive.

Answer 3

In general, merging of two edits of the same record requires very complex logic of resolving conflicts. Thus it's not good idea.

If a user who locked the record doesn't critically affects another user's activitity, i.e., another user can do something else while waiting for unlocking the record - usual indication is enough. Like you described in your question - color or icon identification with some generic message.

But if such locking is critical you need to make appropriate changes not only to interface but to functionality as well. Maybe in such general scenario:

1. User A edits the record. User B wants to edit the record too and is asked a question: 'Ask another user to unlock the record?' User B answers Yes.
2. User A receives notification at his edit form that somebody also needs to edit this record. User B makes his best to finish editing ASAP.
3. If User A is absent, software activates inactivity timer and after timeout expires it automaticaly closes editing form as if Cancel button pressed.