Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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.

share|improve this question
1  
Have the developers look up optimistic locking versus pessimistic locking and convince them to do away with pessimistic locking. It seems safe but is actually a problem waiting to happen. With optimistic locking you need to take care of an update conflict, but that is much to be desired over a record being locked "forever" because someone went to lunch without pressing update/cancel. –  Marjan Venema Jan 28 '13 at 8:13
    
Thanks. Good example of including dev stakeholders in the wiireframing and playing nice...:) Let me check. –  uobroin Jan 28 '13 at 8:14
add comment

3 Answers

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.
share|improve this answer
    
Nice in principle, but there is already a lot that can go wrong there. For instance with step 3: what happens to any changes that user A has made to the record, but not yet submitted? Are these going to be lost? Data loss seems unacceptable to me... –  André Jan 29 '13 at 8:28
    
@André: There is no problem with dataloss in such case because there is no dataloss at all - data was not saved in the system so it can't be lost. Yes, User B looses his input, but he should save entered data before going for cup of cofee. From the other side, inactivity timer is commonly used feature at websites for autologout for security purpose. –  Serg Jan 29 '13 at 11:55
    
User B loosing his imput is data loss. You have no idea why he might have been side tracked. It might be a cup of coffee, it might also be something legit that required immediate attention. I don't see why it is OK for user B to loose his input. –  André Jan 29 '13 at 15:27
    
@André: Loosing input is not OK to User B, but it's OK to this particular system. Reason - User B didn't satisfy system's requirements on time duration of his inactivity. Of course, if the system has such requirement. In our case - it does. –  Serg Jan 29 '13 at 18:58
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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