[Design] [Proposal] Conflict Resolution UI
mitch at kapor.com
Thu Dec 21 11:52:29 PST 2006
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
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
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
On Dec 20, 2006, at 1:55 PM, Mimi Yin wrote:
> 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://
> 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
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "Design" mailing list
More information about the Design