How I think about handling conflicts which arise in Chandler:
A type of occurrence which I think will arise relatively frequently
is one in which two people (Apex and Assistant, for instance) are
sharing a calendar. Apex and Assistant both change, say, the notes
field of an event, without being aware the of the other's change.
I was simulating this myself, playing the role of two users, before
trying it out with Esther, when I ran into exactly this problem
within 15 minutes.
(The situation is exacerbated by not being able to tell the time of
the last sync. I understand this feature will be added. Even so,
users shouldn't be asked to have to be conscious all the time of when
a sync has happened. It undercuts the notion of automatic sync.)
Today Chandler's behavior results in data loss for whoever syncs
second under the "server wins" policy. Data loss is completely
unacceptable.
My first principle: No data loss.
A conflict is not an error. Using the iconography of errors, as
suggested is the strawperson, implicitly criticizes a user for
something over which she has no control. Because there is a lag
after a change is made and before it is synchronized with the server,
conflicts will arise through the innocent behavior of users. We
don't want to think of this as an error, and we certainly don't want
users to think of it as an error when there's nothing they can do to
prevent it.
Second Principle: A conflict is a conflict, not an error.
In an ideal world, the user would be presented with a conflict
resolution dialog which she would work through. Foxmarks
successfully employs a series of these as does .mac, albeit they are
less well done. If schedule doesn't permit this level of work, I'd
be satisfied with sending a notification of some kind (to the status
bar?) and perhaps modifying the Notes field of the event in some
fashion to show the conflicting information. This could be done by
appending a section to the Notes field with details of the conflict.
The user could then manually fix up the item as needed.
This is merely meant to be suggestive. The key idea is the user
know there is a conflict and give her the information needed to make
a decision about what to do about it.
Third principle: Notify the user, and give her a chance to fix the
problem.
On Dec 20, 2006, at 1:55 PM, Mimi Yin wrote:
http://wiki.osafoundation.org/bin/view/Journal/ConflictResolution
Katie asked me to think more about some simple solutions to improve
the user experience for:
1. Finding out about sharing and edit/update conflicts
2. Resolving sharing and edit/update conflicts, ideally without
data loss
In the past we've talked about clusters (http://
wiki.osafoundation.org/bin/view/Journal/OneDotZeroClustersProposal)
as an ideal solution for conflict resolution. According to the
proposal, each item would maintain an item history of all version
of that item (conflicting and non-conflicting) and clusters would
provide the UI affordance for displaying an item's history.
But Clusters is more than just conflict resolution UI. Clusters are
designed to support ad-hoc, lightweight organization by combining
email threads and task dependencies with in-line item creation when
taking notes in an item's notes field. Furthermore, clusters are
entirely user-configurable. Users can add, remove and re-order
items in clusters. In other words, an item's item history would
display in the context of the item's 'full, extended history', in
the context of replies, forwards, task dependencies and any other
related items the user decided to associate with that item.
Sadly, we deferred Clusters until after Preview. But perhaps we
shouldn't defer conflict resolution along with it.
So, is there room in the schedule for a simple, pared down design
to smooth the edges when it comes to dealing with conflicts?
Strawperson Proposal:
1. Error icon in the communication status column in the Dashboard
2. Error message at the top of the detail view
3. Pop-up to to view and resolve details of the conflict
There is a lot of room for different approaches within the loose
framework of this proposal. We can make it more or less ideal
depending on user needs and development resources. I'm simply
throwing this out to provide something concrete to discuss.
Most importantly, for dogfooders who have experienced conflicts, it
would be enormously helpful if you could recount your experiences
and inform the design with what information you think you need in
order to effectively resolve conflicts.
1. Were they conflicts with yourself? or with others?
2. How many people were involved in the conflict?
3. Which attributes were in conflict?
4. How much time elapsed before you discovered the conflict?
5. Were you able to figure out what had happened?
6. Were any of the sharees in question offline for a long period of
time?
Thx,
Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
