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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
|
