[Design] Scoping out sharing-related 0.7 projects
mimi at osafoundation.org
Tue Feb 7 13:23:50 PST 2006
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 can either go with User A's changes or override them with
+ User A and all other sharees would never has to know there was a
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
> 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.
> 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
>>> + 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
>>> 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
>> 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
>>>> 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
>>>> 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
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>> Open Source Applications Foundation "Design" mailing list
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "Design" mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Design