Hi Mitch,
Thx for putting all this down on paper, I know you've been thinking
about this issue for a long time now. I agree this is an important
issue to address in the Preview timeframe. I also agree that we
should focus our energies on making our solution comprehensible, if
not comprehensive.
We can accomplish this by making sure we give users the information
they need to redress conflicts, if not the elegant UI affordances for
resolving them quickly and seamlessly.
It seems to me that the major pieces of information users require are:
1. Time of last sync
2. Who made edits
3. Which attribute was edited
4. What was the edit
5. When was the edit made
We can make the user experience better or worse when it comes to
actually resolving the conflict, what's important for Preview is that
the 5 pieces of information mentioned above are available to users.
See more in-line.
On Dec 21, 2006, at 11:52 AM, Mitch Kapor wrote:
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.
Yes the notes field is the most problematic because it is free-form
and people put so many different things in there. It really functions
as the poor-man's user-definable attributes affordance. May I ask
what kinds of information you and Esther typically enter into the
notes field of your events? Directions, agendas, itinerary details, etc?
Where does this information typically come from? e.g. email, phone
calls, hallway conversations? your head? Esther's head?
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.
What is our current sync interval? I'm wondering how much of this we
can address by tightening up the frequency of sync.
Could you elaborate on your simulation? More specifically, what were
the circumstances that led you and "Esther" to both edit the same
event in such close temporal proximity.
(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.)
Yes, given the limitations of where we can put the last sync info,
it's questionable whether most users will even notice it when we do
add it.
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.
That's interesting. I hadn't thought of errors in that way. I was
thinking of error in terms of mail server errors and connectivity
errors. We should explore alternatives to error, but I am concerned
about introducing more icons to communicate different sub-types of
errors: user errors v. conflicts v. server errors v. offline, etc.
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.
Yes, that is detailed on the wiki page proposal.
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.
That's interesting. I will try mocking something up to that effect.
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.
Absolutely!
Thanks for your input Mitch. :o)
Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
