Why doesn’t the arch villain just kill Bond when he has the chance? Why does he have to describe his evil plans and what has OneDrive conflict management got to do with all this?
“Ah. Mr Bond. I and my evil colleague No 2, have been working on our plans for World Domination through management of the outcomes of World Conflicts. In spite of appointing Kevin McCloud from Grand Designs to project manage the construction of my evil lair, I realised we had less time than we thought. I therefore appointed No 2 in Geneva to also work on these plans. There are four components to conflict management Mr Bond. Listen very carefully.
Both I and No 2 have made changes to the plan for World Domination. We both independently hit ‘save’. The developers employed in Microsoft, the previous organisation devoted to World Domination, have written software to detect conflicts and alert me. I click that I have seen the conflict giving me four options.
- My plans are better than No 2’s plans and I upload mine and overrule his plan.
- No 2 has had some good ideas and I download his excellent plans. (No 2 well knows the price of failure)
- No 2 has some good ideas but so have I. I incorporate some of his ideas but upload my document, overruling his previous plan and making mine the Master Plan.
- At the same time as I was changing No 2’s plans to provide for my white cat, No 2 was making even further changes to his previous changes. When I save the plans for my white cat, more conflicts appear and I have to stop thinking about World Domination. I need to run ‘track changes’ in Word to see if I can fathom out what changes he has made to my changes or whether I have to change the changes I made to the earlier changes.
Well Mr Bond. What do you think of my evil plan for managing World Conflicts?”
“Dr Evil, you are forgetting one thing. You and your conflicted thinking are doomed to fail. You have have taken my gun but I am an expert in unarmed conflict.”
Bond kills Dr Evil with a single blow, moves to Dr Evil’s computer and foils his global plans by setting the evil plan’s status to ‘Checked Out’.
Well I am sure my analogy has cleared that all up for you.
But behind this jokey overview of the problem lies a real issue. Let’s say 4 users decide they will each work on 25% of a big document so that it can be created quickly or perhaps they each have different areas of expertise. So what happens? This is from the Microsoft Help manual.
“To edit the document at the same time, each author opens the same file from a common location on a server. With the document open on your computer, you can see who else is editing the document, who is editing a specific paragraph, and when updates from other authors are available on the server.
…..When you save your changes to the server, any updates from other authors are automatically refreshed in the document. Updates from other authors are refreshed automatically only if they don’t conflict with changes that you made. If you and another author both change the same item, then a conflict may occur. If a conflict occurs when you save the document, you are prompted to review the conflict and accept or reject the change.”
So far so good. However, in reality it doesn’t matter if our four authors are going to stick to their respective sections. The problem is that the whole exercise as managed above falls apart as soon as any of the editors in my example decide to synchronise the whole document with their own offline client. At that point ANY change in the document becomes a defacto conflict and the subsequent review of the conflict becomes mandatory.
The solution to our eyes lies in making the technology work for the end user in preserving clarity. Capturing that there has been a conflict remains important but expecting a busy end-user to work out where those changes are, on the fly, is usually impossible. That’s the key point at which data typically gets lost or compromised.
The end user needs to make an informed or considered decision as to which changes should prevail. For that to happen we need to preserve the changes in each document until the end user decides what they want to have happen. Indeed, it may not even be their decision with perhaps even the CEO making a contribution to the document. The CEO might not warmly appreciate if their changes were discarded in a cavalier manner.
For that reason, conflict management needs to be a) clear and b) persist until dismissed. Digilink’s latest software will include local versioning of all document overwrites. We obviously recommend the user switches on Microsoft’s own versioning too. For Microsoft Word documents, a good option is to merge the two documents with track changes preserved. That puts the documents into the same state as described in Microsoft’s own simultaneous document editing approach. That approach is not always 100% available depending on the versions of Word being used. What does work however is for the software Conflict Manager to capture the conflict and to record which two files are in conflict.
Our standard settings are that if conficting changes happen out there in the cloud, we’ll sync them down, preserve all the changes the local user made and hold the location details of both these files until the end user decides exactly what they want to do.
- Review and either accept or reject those changes.
- Don’t bother to review but just accept or reject those changes.
End users can still discard changes if they choose, but by using a synchronisation utility to manage the process it will not be by mistake. Indeed, the software will continue to preserve the version history so that any such decision can be unwound and re-visited.
Dr. Evil’s plans are thwarted yet again.