[Design] [Proposal] Conflict Resolution UI

[Philippe Bossut]

Hi,

I read the proposal several times and I'm unconvinced: it seems complex 
even in the simplest case, UI heavy and leaves lots of questions 
unanswered: what happens if the user has no time to resolve the 
conflicts right now? what if other edits coming from other users pile up 
while trying to resolve the previous conflicts? will the conflict UI be 
active as long as the user(s) does not resolve them one way or another 
(ignore/resolve)? if a conflict is ignored, will a future update 
reactivate the same conflicts again? (looks like it will). Will a future 
update eventually wipe out the ignored conflicts? (actually we have this 
problem for any edit that is not sent out with an Update under the 
server wins policy)

It seems to me that the proposal would work in a simple 2 users 
situations but in the asynchronous world of Chandler/Cosmo where a bunch 
of users are sending updates all the time, I don't see this workable at 
all. It's like trying to svn edit a heavily edited file, you get the 
conflict dialog every time you try to commit. Devs tend to live with 
this (code has a sort of sacred aura to it and getting it right is 
important) but users of a calendar are unlikely to be as patient.

The more I look at the problem and the more I think we can't avoid a 
real versioning of the entire item so to avoid data loss and allow users 
to manually "merge" (i.e. choose) between conflicting versions of 
something without too much hand holding by the system through a complex 
UI (the per attribute conflict resolution seems to me really UI heavy 
since changes throughout a bunch of attributes do usually have some 
consistency so you will likely end up choosing one version against 
another as a whole, not on a per attribute basis).

I know that historization/versioning (think of it as the list of edits 
at the bottom of a Wiki page from a UI standpoint) has been punted long 
time ago but it seems to be less complex than the current proposal from 
a user/UI standpoint though, from a data/model standpoint, it's likely 
to be more complex.

Thoughts?

- Philippe


Mimi Yin wrote:
> As promised, here is a quick mock-up of the conflict resolution UI in 
> the Notes field: 
> http://wiki.osafoundation.org/bin/view/Journal/ConflictResolution#NotesField 
>