[Design] [Proposal] Conflict Resolution UI

[Mimi Yin]

Hi Philippe, see in-line...

On Jan 3, 2007, at 10:44 PM, Philippe Bossut wrote:

> 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?

You click ignore.

> what if other edits coming from other users pile up while trying to  
> resolve the previous conflicts?

Is this likely with a small group?

> 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?

Yes, the update will just be added to the list of conflicts.

> (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.

I'm not sure we need to solve for all cases. In the Preview  
timeframe, I think 5-10 users all sending updates to the same version  
of an item is unlikely?

>
> 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).

Yes I agree, this is the ideal, robust solution, but I wonder if it's  
necessary to address the immediate problem of conflicts between 2-3  
users.

>
> 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.

I'm not sure about that. As far as UI components go, this requires a  
pop-up, not unlike the Log dialog we have today. If we want to go the  
extra mile, we can add in the radio buttons to allow users to  
automatically resolve conflicts with a few clicks of the mouse.  
However, in the short-term, we can simply provide them with the data,  
so that information isn't just overwritten and lost.

Is there UI you're thinking of that I'm missing? (I guess there is  
also the conflict message in the detail view, but I think we would  
need that, even if we did version.)

Mimi

>
> 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