Hi Philippe, see in-line...
On Jan 3, 2007, at 10:44 PM, Philippe Bossut wrote:
Hi,
I read the proposal several times and I'm unconvinced: it seems
complex even in the simplest case, UI heavy and leaves lots of
questions unanswered: what happens if the user has no time to
resolve the conflicts right now?
You click ignore.
what if other edits coming from other users pile up while trying to
resolve the previous conflicts?
Is this likely with a small group?
will the conflict UI be active as long as the user(s) does not
resolve them one way or another (ignore/resolve)? if a conflict is
ignored, will a future update reactivate the same conflicts again?
Yes, the update will just be added to the list of conflicts.
(looks like it will). Will a future update eventually wipe out the
ignored conflicts? (actually we have this problem for any edit that
is not sent out with an Update under the server wins policy)
It seems to me that the proposal would work in a simple 2 users
situations but in the asynchronous world of Chandler/Cosmo where a
bunch of users are sending updates all the time, I don't see this
workable at all. It's like trying to svn edit a heavily edited
file, you get the conflict dialog every time you try to commit.
Devs tend to live with this (code has a sort of sacred aura to it
and getting it right is important) but users of a calendar are
unlikely to be as patient.
I'm not sure we need to solve for all cases. In the Preview
timeframe, I think 5-10 users all sending updates to the same version
of an item is unlikely?
The more I look at the problem and the more I think we can't avoid
a real versioning of the entire item so to avoid data loss and
allow users to manually "merge" (i.e. choose) between conflicting
versions of something without too much hand holding by the system
through a complex UI (the per attribute conflict resolution seems
to me really UI heavy since changes throughout a bunch of
attributes do usually have some consistency so you will likely end
up choosing one version against another as a whole, not on a per
attribute basis).
Yes I agree, this is the ideal, robust solution, but I wonder if it's
necessary to address the immediate problem of conflicts between 2-3
users.
I know that historization/versioning (think of it as the list of
edits at the bottom of a Wiki page from a UI standpoint) has been
punted long time ago but it seems to be less complex than the
current proposal from a user/UI standpoint though, from a data/
model standpoint, it's likely to be more complex.
I'm not sure about that. As far as UI components go, this requires a
pop-up, not unlike the Log dialog we have today. If we want to go the
extra mile, we can add in the radio buttons to allow users to
automatically resolve conflicts with a few clicks of the mouse.
However, in the short-term, we can simply provide them with the data,
so that information isn't just overwritten and lost.
Is there UI you're thinking of that I'm missing? (I guess there is
also the conflict message in the detail view, but I think we would
need that, even if we did version.)
Mimi
Thoughts?
- Philippe
Mimi Yin wrote:
As promised, here is a quick mock-up of the conflict resolution UI
in the Notes field: http://wiki.osafoundation.org/bin/view/Journal/
ConflictResolution#NotesField
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
