Okay, I have finally gotten around to writing up an end-user /
scenario-based description of how conflicts should be resolved in the
edit/update workflows. These notes came about after several meetings
with bkirsch, philippe, bryan, grant, jeffrey, katie, sheila, priss,
morgen and a partridge in a pear tree.
I've tried to sum up the main points at the top and leave the nitty-
gritty details to the scenario walk-throughs at the bottom.
Please review and reply with comments and questions. I'm hoping this
isn't going to be far off what's been discussed on the dev list:
http://lists.osafoundation.org/pipermail/chandler-dev/2006-December/
007394.html
Approach
1. In the Preview timeframe, it is inevitable that conflicts will
happen and data will be lost. The best we can do is give users fair
warning. We hope to learn from dogfood feedback, where to best focus
our energies in the bottomless pit of conflict resolution UI issues.
2. Whenever possible, we should minimize changes to the sharing code.
3. We should make conflict resolution wrt email work in the same way
as conflict resolution in sharing, both for conceptual consistency
for the end-user and ease of implementation for Chandler developers.
Assumptions (re attribute-level conflict resolution)
+ If Updates always win over Edits, then it's more likely that we
will successfully keep everyone (Sharees and Non-Sharees) in sync.
Sharer/Sharees/and Non-sharing email people.
+ However, Updates are stored in email and edits aren't, so
overwriting edits with updates seem poor.
+ Emailed updates should be merged with local edits and/or edits
received via sharing. This will result in situations where non-
sharees will get out of sync with sharees because non-sharees will
not receive
- Conflicts and merges should resolve consistently for all edit/
update and sharing participants. That will minimize the likelihood of
the same 2 versions of an item getting merged/conflict-resolved in
different ways by different users, thereby creating more conflicts.
Proposal
+ We merge edits and email updates whenever we can
+ Edits always win over Updates
+ We provide error messages whenever there is a conflict:
- Sharing conflict. First person to sync wins.*
- Sharing edit v. Update conflict. Sharing Edit wins.
- Local Edit v. Update conflict. Local Edit wins.
- Update v. Update conflict. First Update wins.**
- All of these different kinds of conflicts could happen concomitantly.
* Based on timestamp of when the user synced.
** Based on the timestamp of when the user sent the update.
Error messages
+ Question: Can we display more than 1 conflict message at a time if
multiple conflicts occurred?
+ Sharing conflictt: xxx overwrote your edits.
+ Any conflicts having to do with Updates: Due to a conflict, updates
from xxx and xxx were rejected. Check your email to retrieve lost
changes. (How do we make this clear so people don't just check their
Chandler email?)
+ When we think users may be out of sync: You may need to resend this
item to ensure that everyone has the same version. (This would only
show up for 1 of the users, whichever one is easiest to identify:
Original creator of the item? Original sender of the item? Last
sender of the item?)
What to display in the byline
+ Updated by xxx on xxx is shared
+ Ideally, bylines are customized to whatever makes sense for each
user. If 2 users A and b edit and/or update an item at the same time.
Each user should see the other user (A sees B, B sees A) as the last
person to edit or update that time. This is true for both sharing and
edit/update via email scenarios. However, it is unlikely we will have
this for Preview. For Preview, we will simply have the first user to
sync wins.
===
Here are some scenarios to twist your brain and illustrate the above
in action: (It may be best to go over these scenarios in a meeting
with a white board, so we can diagram the relationships.)
Users: S1, S2 and NS1
S = Sharing
NS = Not sharing
ABCDE = Versions of the same item being passed around via Sharing and
Edit/Update via Email. The alphabet is linear, but there versions
aren't linearly ordered, they branch, so it is safer to just think of
them as having reference relationships. e.g. User1 edits C to create
D. User 2 edits C to create E. D refers to C and E refers to C. E
doesn't come after D and for all we know, E was generated prior to D.
...Where an update and edit are successfully merged
+ S1 creates and sends out A
+ S1 updates A to create B
+ NS1 updates B to create C and sends out C as an update
+ S2 updates B to create D
+ S2 receives NS1's C update and merges C and D to get E <Conflicting
updates and edits merge whenever possible>
+ S2 syncs E
+ S1 syncs and gets E; and then
+ S1 receives NS1's C update via email
+ E references C and D, so S1 ignores C
+ E pops to the top of the Dashboard and the byline on the item
displays: Edited by S2 at xxxx
+ S1 and S2 both have E
+ NS1 still only has C
=====
...Where an update and edit conflict and the edit wins
+ S1 creates and sends out A
+ S1 updates A to create B
+ NS1 updates B to create C and sends out C as an update
+ S2 updates B to create D
+ S2 receives NS1's C update and there is an attribute-level
conflict. S2's D wins over NS1's C update to create E. S2 is warned
that an update has been overwritten and told to check their email to
see the rejected update.
+ S2 syncs E
+ S1 syncs and gets E; and then
+ S1 receives NS1's C update via email
+ E references C and D, so S1 ignores C
+ E pops to the top of the Dashboard and the byline on the item
displays: Edited by S2 at xxxx
+ S1 and S2 both have E
+ NS1 still only has C
=====
...Where competing updates are resolved because one was an update of
the other
+ S1 creates and sends out A
+ NS1 updates A to create B and sends out B as an update
+ S2 sees NS1's B update, edits B and sends out C as an update
+ S1 pulls downs C from server; and then
+ S1 receives NS1's B update via email; and then
+ S1 receives S2's C update via email
+ S1 discards B because C refers to B
+ S1 figures out that S2's C update is the same as the C from the server
===
...Where conflicting updates clash, one is rejected because it was
sent after the other, and the user is notified of the conflict.
+ S1 creates and sends out A
+ NS1 updates A to create B and sends out B as an update
+ S2 updates A to create C and sends out C as an update
+ S1 pulls downs C from server; and then
+ S1 receives NS1's B update via email; and then
+ S1 receives S2's C update via email
+ S1 discards C in favor of B, because happened first
+ S1 is warned that there was a conflict, that S2's update was
overwritten by NS1's update, and told to go check their email to see
the rejected update.
+ Question: S1 syncs B??? Or should this be D???
+ S2 pulls the B/D??? update from the server; and/or
+ S2 receives NS1's B update via email
+ S2 overwrites their own update with NS1's B update
ned first
+ S2 is warned that there was a conflict, that their update was
overwritten by NS1's update, and told to check their email to see the
rejected update.
+ NS1 receives S2's update
+ S2's update is discarded because it was sent after NS1's
+ NS1 is warned that there was a conflict, that they overwrote S2's
update, and told to check their email to see the rejected update.
===
...A use case that justifies the need to maintain an items entire
reference history in order to successfully resolve conflicts
+ S1 creates and sends out A
+ S1 edits A to make B and sends out B
+ NS1 receives S1's A and B via email
+ NS1 updates B to create C and sends out C as an update
+ S2 receives S1's A and B via sharing and email
+ S2 edits B to make D, S2 receives C and successfully merges it with
D to make E and sends out E as an update
+ S2 syncs E
+ S1 receives E via sharing and email, E refers to C and D
+ The last version S1 has is B
+ Unless version E's reference history stretches back further than C
and D to B, S1's Chandler has no way to decide whether to treat
differences between E and B as conflicts are as subsequent versions.
===
...Where independent, successful merges constitute a conflict
+ S1 creates and sends out A
+ NS1 updates A to create B and sends out B as an update
+ S2 also updates A to make C and sends out C as an update
+ NS1 receives S2's C update and merges B and C to make D
+ S2 merges B and C to make E
Question for Grant/Jeffrey: I remember discussing this use case as an
example of how the same 2 versions of an item could get merged in
different ways, but I'm not sure I remember why again. It seems like
in this scenario, the merges should happen the same way for both NS1
and S2, making NS1's D indentical to S2's E.
===
What other important scenarios are missing?
Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
