[Design] Scoping out sharing-related 0.7 projects

[Mitchell Kapor]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060207/44a132c5/attachment.htm