[Design] Scoping out sharing-related 0.7 projects

[Lisa Dusseault]

One possible difference to the user, between what Morgen described  
and what Mitch described (assuming of course I've interpreted  
correctly), is whether "third party" users see that there's a conflict.

E.g. when A and B make conflicting changes to a resource, as I  
understand in Morgen's proposal for 0.7, only the user whose synch  
happened last would see that there was a conflict and have an option  
to resolve it.

    Whereas, in Mitch's proposal for the long term, not only A and B  
but also C and D would be able to see that conflicting changes had  
been made to a resource, that hadn't been resolved yet.   They can  
all know there's some confusion e.g. about what room to meet in, and  
anybody has a chance to resolve the confusion.

Obviously since these are short term vs. long term proposals there's  
no immediate problem but I thought it interesting to highlight an  
essential difference.

Lisa

On Feb 7, 2006, at 8:43 AM, Mitchell Kapor wrote:

> My post, to which Morgen replies, was actually in response to  
> Mimi's proposal, not the current implementation or Morgen's plan.   
> But since I omitted including mimi's original, I inadvertently  
> created confusion.  Sorry.  For completeness, here is what Mimi  
> wrote.  I'm not going to respond point by point to Morgen;  I think  
> it would only confuse things further.
>
> - I have no problem with implementing in stages.
>
> - While the repository needs to have just one "official" winner in  
> case of a conflict in the current domain model, we could of course  
> adapt the domain model to add something which would allow multiple  
> values for attributes in conflict or a sidecar attribute and then  
> have a UI which utilized whatever we did.  I think though we need  
> to decide on what the correct behavior is for the user and then see  
> how to model it in the repository.
>
>
>> On Feb 6, 2006, at 2:48 PM, Mimi Yin wrote:
>> Here are some proposals for lightweight conflict management in 0.7
>>
>> Providing users with visual feedback
>> + "Flag" on items that have been newly added to a share/ edit or  
>> changed / have conflict(s)
>> + "Flag" is displayed in the mark-up bar of changed / conflicted  
>> items
>> + User can click on "Flag" to view edit/conflict details in the  
>> Activity Log
>> + In the Activity Log, user can click on "something" to take them  
>> back to the original item detail view
>>
>> If flags are going to be employed, it's important they be visible  
>> in the summary view, not just the detail view, if they're going to  
>> be noticed.
>>
>> If you're editing a field that has been changed by the server
>> + Phase 1: Chandler over-writes the user's edits with the server's  
>> changes
>> + Phase 2: Can we intercept item change notifications coming from  
>> the server before they get displayed in the detail view? The  
>> user's edits win and a "conflict" Flag is raised on the item in  
>> the mark-up bar. Users can click on the Flag to see what got  
>> sucked down from the server.
>> + Phase 3: Display a modal dialog: The "notes" have been edited  
>> since you last synced. (Here are the edits). Do you still want to  
>> proceed with your edits? Okay Cancel. (Not sure if this is  
>> necessary.)
>>
>> Server-side conflicts
>> + Last version to get synced wins
>> + Conflicting versions are both pulled down and "stored" in the  
>> Notifications/Activity log as Activity notifications.
>> + User pulling down conflicts can examine the log to see what  
>> happened, but there doesn't need to be a "compare versions" UI in 0.7
>>
>> Mimi
>
> On Feb 6, 2006, at 10:43 PM, Morgen Sagen wrote:
>
>>
>> On Feb 6, 2006, at 4:50 PM, Mitchell Kapor wrote:
>>
>>> I want to offer a different perspective on handling conflicts.   
>>> For the sake of simplicity, let's assume there are two users, A  
>>> and B, each synching once an hour hour.  (I don't think we are  
>>> going to support more frequent synching due to issues with  
>>> managing server load.)  When synching is done with this  
>>> frequency, if two people change the same item and attribute such  
>>> as to create a conflict, there is no reason to prefer one to the  
>>> other, even though, by definition, one change is going to hit the  
>>> server first.  We have to stop thinking that one change precedes  
>>> the other.  From a God's-eye view it's true,  but from the user's  
>>> perspective, changes occurring in the same synching period happen  
>>> essentially simultaneously.  Here's a worked out example.
>>>
>>> Let's assume A is scheduled to sync at 15 minutes past the hour  
>>> and B at 30 minutes past the hour.  (To balance server load, time  
>>> time of synching should be chosen somewhat randomly).  Now A  
>>> makes a change at 12:00.  At 12:15 A's change hits the server.   
>>> Now let's say B changes the same item at 12:20.  B won't see A's  
>>> change since the last time B synched was 11:30.  As far as B is  
>>> concerned, B is editing an unconflicted calendar.  When B syncs  
>>> at 12:30, a conflict is detected.  What should happen?
>>
>> At 12:30, B would automatically download A's 12:00 change, A's  
>> change would "win", and B's local 12:20 change would be stored in  
>> a Conflict Notification to be resolved at B's leisure.
>>
>>> Let's also assume, not unrealistically, that B isn't at the  
>>> computer at 12:30 to notice the change.  If "last sync wins" then  
>>> when A comes back to the computer at 1:20, A's change has been  
>>> blown away.  A says to self: WTF?
>>
>> As implemented today, the last sync doesn't win.  It's the first  
>> sync that wins.  A's 12:00 change wouldn't be blown away in this  
>> case -- A's change remains both on the server and in A's  
>> repository.  However, say B gets back to his desk at 1:00 and  
>> notices the Conflict Notification in the sharing log.  If B feels  
>> that A's change is okay, he does nothing; otherwise if B wants his  
>> 12:20 change instead of A's 12:00 change, he clicks an "I want my  
>> change to win" button or something.  At 1:30, B's change would go  
>> to the server and at 2:15, A's client would sync, B's change would  
>> appear in A's repository,  and A would get a Change Notification  
>> in his log.
>>
>>> (It could even be argued that A is being punished for being  
>>> prompt in the case both A & B noticed a problem with same event  
>>> but chose different ways to fix it.)
>>
>> Actually, it's the early bird that wins in the current  
>> implementation.
>>
>>> Also, whether a change is over-written or not will be a random  
>>> function of when the user's computer is set to sync vis a vis  
>>> someone else's computer.  I think this will make people crazy.   
>>> If A made a change at 12:00 and B a change at 12:20, but it  
>>> happened that A was synching at 25 past and B at 22 past the  
>>> hour, then A's change would win.  In this case A would get what  
>>> was expected, but B would be going WTF.  It's the opposite  
>>> outcome as before even though A's and B's behaviors were identical.
>>
>> In this case, B's 12:00 change would go the server at 12:22, A  
>> would download it at 12:25, B's change would "win", A's local  
>> change would be logged in A's repository as a Conflict Notification.
>>
>>>   It would be very disconcerting to have who wins and who loses  
>>> essentially be random.  I think users will find it plain  
>>> unacceptable.  It will create enormous support headaches trying  
>>> to explain it.
>>>
>>> A change made later on the clock but between two sync periods  
>>> don't really happen "later" from the user's point of view.  The  
>>> changes happen "simultaneously".  Maybe a better way to put it is  
>>> that any two changes being made within an hour of each other  
>>> happen more or less simultaneously as far as the user is  
>>> concerned (when synching is only done once an hour, which is the  
>>> driving assumption.  If synching were instantaneous, these issues  
>>> would not arise.
>>
>> It's always going to be the case that one user's changes make it  
>> to the server before the other user.  The second client to sync is  
>> always going to have to be the one to perform conflict resolution,  
>> unless we change our model of how the server stores items.  It's  
>> all about how we present the info to the user...
>>
>>> The only right thing to do is to carry both version and let the  
>>> user decide.
>>
>> Right, and this is the biggest question -- how we support  
>> presenting two versions of an item to the user (both from the UI  
>> design and engineering points of view).  You want the application  
>> to have both versions of the item co-existing in the repository as  
>> equals it seems, not a winning change and a losing change.
>>
>>> If, as a matter of simplifying the UI, one version was made  
>>> "authentic" but flagged and the other was carried along in some  
>>> sort of sidecar with the item (not in some separate log) and the  
>>> two were easily switchable, it would be ok with me but only on  
>>> the grounds of expedience.
>>
>> As far as I know, when there is a sharing conflict, under the hood  
>> one version indeed needs to be the "winner" at the repository  
>> level -- i.e., those winning changes are applied to the item --  
>> and we can store the losing changes somewhere for later access.   
>> We can design the domain model to provide the UI with as much help  
>> as we can; for instance, having bi-directional references between  
>> Conflict Notification and the Item that had the conflict -- that  
>> way whatever UI is displaying an item has easy access to  
>> unresolved conflicts.
>>
>> Anyway, I was just setting out to do an extremely simple UI for  
>> 0.7, since most of the work is going to be under the hood to allow  
>> for background synchronization.  I am fine with punting a fancy  
>> conflict resolution UI to a later release, but we should at least  
>> have Notifications of conflicts available to the user (which I  
>> proposed doing for 0.7 as a list of items in the summary table).   
>> My simple 0.7 conflict resolution UI was going to be a detail view  
>> that contained:  item name, attribute name, winning (remote)  
>> value, losing (local) value, and a button labeled with the  
>> equivalent of "apply my change instead"; just something to let us  
>> work out the kinks of dealing with conflicts at the framework level.
>>
>>
>>>> On Feb 6, 2006, at 2:18 PM, Sheila Mooney wrote:
>>>>
>>>>> I just wanted to point out that any kind of sophisticated  
>>>>> conflict resolution or versioning handling UI is out of scope  
>>>>> for 0.7. We will likely implement things in stages but the  
>>>>> first step for all of this will be to record the conflicts and  
>>>>> log them in a way a user can view them and manually make  
>>>>> updates if they choose to. Once we get that working (just to  
>>>>> understand more about when conflicts are happening), we can  
>>>>> figure out what enhanced UI would be the next logical step.  
>>>>> Perhaps some of this will be done during 0.7 but I think it's  
>>>>> important to get something primitive up and running first.
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Design" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/design
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060207/434e55ec/attachment.html