[Design] Scoping out sharing-related 0.7 projects

[Mimi Yin]

As Mitch pointed out, it probably doesn't make a difference from the  
user's point of view where the early bird wins or the last synced  
version wins. It seems like we all agree that"

+ users should get notification of conflicts
+ users should be able to see if there was a conflict when they view  
the details of an item
+ user data should never be blown away and that
+ users should have a way to "restore" their changes.

Whether we do that in some kind of specialized UI or just an item in  
an Activity Log is a matter of staging?

To answer Lisa's question, I think all sharees should see conflicts.

===

One way to minimize conflicts (that we've discussed in the past): We  
could also make it so that users always suck down changes from the  
server before uploading their own changes...
+ User A syncs changes to Item Foo
+ User B downloads user A's edits to Item Foo
+ User B's Chandler detects a conflict and shows User A's changes to  
User B
+ User B can either go with User A's changes or override them with  
his own
+ User A and all other sharees would never has to know there was a  
conflict

Mimi


On Feb 7, 2006, at 10:17 AM, Lisa Dusseault wrote:

> 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
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> 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/17617980/attachment.htm