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.

We are developing a simple web based single-page CRM-like app. I was thinking about what happens when two operators are both editing the details of a customer "John Doe". On the server side we use a optimistic updating, i.e. the ajax update payload includes revision-number which must match whats in the database, however on the front-end I was wondering how we should handle this?

I thought about a modal popup along the lines of: "Sorry AgentB has already updated the record and your working copy might not be up-to-date? Would you like to:" (a) Update anyway (b) Reload (c) Some form of merge

However I can imagine the users being confused by this. Then I start thinking this scenario must have been covered a million times already. Are there any guidelines and fantastic reference apps to demonstrate the best way to handle such common concerns in a web based multi-user line of business applications?

We are open to use any necessary cool-aid to achieve the best solution (websockets, ui frameworks etc...).

share|improve this question
add comment

3 Answers 3

You are trying to deal with concurrent editing, and unfortunately there isn't any easy solution for this. The common ways of dealing with it are:

  1. Lock the record when someone starts editing it. This will prevent a second user from editing a record that is being edited and should inform them that someone else (possibly a name) is editing that record. This is generally the safest, but sometimes you have issues where something goes wrong while a record is locked, and then nobody can access it. As @Marjan mentioned, it's also a headache when nothing goes wrong but someone starts editing and then runs out for lunch. If you use this method, you should use 'optimistic locking' or 'optimistic concurrency control' where you check for recent record changes. I won't go into how to deal with that as it is a StackOverflow question.

  2. Allow multiple people to edit a record at the same time, and simply update the record when each user saves their edits. This is the easiest to implement, but can have some very frustrating consequences where data that was entered is missing even though someone is sure they entered it. I would advise against this method.

  3. Allow real time updates to the content so that each editor can see the changes happening in real time. This is the most preferable from a user's perspective, but the most technically challenging to implement. If you can I would recommend this method. As a slight modification of this method, you can have a sort of mini-lock where each field is locked while a user edits it, but not the entire record. This is the way that HotGloo for example deals with concurrent users and it works well.

Summary: If you don't have much time and resources, use option 1. If resources and time aren't a problem, go for option 3. Avoid option 2 unless you are sure there will not be multiple users editing a record at the same time.

share|improve this answer
4  
Number one is also a headache when nothing goes wrong but someone starts editing and then runs out for lunch. Especially when database locks are at the table page instead of the record level. It basically presents the worst UX experience and is a continual headache for application support. Use optimistic locking. It is number two with a "has someone updated this record just before me" check. –  Marjan Venema Apr 22 '13 at 6:55
    
@MarjanVenema I'm going to steal that situation and add it to my answer :) Thanks! –  JohnGB Apr 22 '13 at 6:56
    
No worries. Added a bit to the comment in the meantime. Optimistic locking is the way most apps are setup that do not go all the way of number three. –  Marjan Venema Apr 22 '13 at 6:57
    
Summary should be: go with optimistic locking unless you can go all the way with live updates. –  Marjan Venema Apr 22 '13 at 6:59
add comment

Versioning systems are fun.

While versioning systems and models do exist, the issues with editing the same file as someone else usually come back to management (either physical management or personnel management). When two people have the same file open at the same time, unless there is a need, chances are they are making decisions for themselves.

That being said there are instances where two people may want to make the same revision. My wife and I were talking about online bill pay in our bank. With the system they have in place it is entirely possible for me to setup an automatic bill payment and for her to setup one under her login. While we use the same account there would be no way to tell the same payment was made twice off of the same bank account because of the way the bank treats user privacy. This is a huge issue for us because we can't delegate bill paying to one or the other, or we have to compromise the security of our accounts by sharing the same login in more than one location (added risk).

There are several options available from a programming point of view

You might want to look into something like etherpad to get an idea for how it works. Google incorporated the app into Google Wave. Basically it's realtime collaborative meaning you can see other people typing and you can see who it is that's typing and their edits. Here is a post on lifehacker featuring the top 10 web collaboration tools.

Software development teams use applications like CVS (Concurrent Versioning System) to "check out" files to edit, then if someone else goes to connect to the file they do not have the option. Smashing Magazine has an article showing 7 CVS-style versioning systems.

Versioning even exists for copywriters

Applications like Microsoft Word, Adobe Indesign, and Adobe InCopy use versioning and will create a locked version of a file and allow other users to see it in read-only mode. Word can also track changes in a file and then allow different people to authorize or commit the changes. InCopy and Indesign allow two people to work on the same file, the second user imports the edited content into their document.

When I'm doing web design I use Adobe Dreamweaver. While it integrates with CVS (if you've configured your server for it) they also allow you to specify an application for recognizing file differences and tracking changes. In that case I use WinMerge which shows me line by line which lines have changed and both versions of the document are editable. It's great for showing a line by line comparison of files.

One of the other versioning systems that I've become familiar with over the past couple of months is in use here on Stack Exchange. I examine everything from a user experience standpoint and apply my findings to projects. Basically when an edit is made in the system a javascript listener notices the change and updates the user interface letting you know a new answer has been posted, or an edit to content has been made. Then it prompts you to update the content. This is one of the better methods I've seen for notifying people in terms of changes. While the execution of alterations in code or copy aren't always the best you could show someone a preview of the changes in a little window prior to them loading it.

When I'm using MySQL Workbench (a database connector GUI) to work directly on databases I've noticed that they are very smart about performing their database update queries. In my experience most web developers will replace an entire record set whether changes were made or not (because it's easier). In Workbench they've taken their time and only replace the record that has changed. So if I update a phone number on one row and a title on another row, my database SQL updates only show the phone number for the first ID and the title for the second ID. This can definitely cut down on the amount of overwritten copy since most information is stored in a database.

It's a little more work, but if you have the time, making a system that merges a lot of these functions would provide the best user experience and save the most time (and money due to double work and overwritten records) in the long run.

share|improve this answer
add comment

The best way is to actually avoid this conflict by updating the status of a customer in real-time, so that as soon as one user starts updating then other users are locked out (or provide a read-only view). However, if you require that both users can access and update the same records, then you need to be able to create duplicate instances that require a merge to be done either automatically or manually (recommended). From a usability perspective, it is better that a user knows the state of something rather than make changes and see something that is different to what their previous action would indicate. However, it would depend on how the users want to use the system, and what the specific business requirements are in terms of customer information. Perhaps just making some fields editable (e.g. a text only notes section) and others read-only would work.

share|improve this answer
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.