Hi Philip, Thanks for the speedy reply. See comments in-line...
On Jan 23, 2007, at 12:49 PM, Phillip J. Eby wrote:
At 11:49 AM 1/23/2007 -0800, Mimi Yin wrote:
http://wiki.osafoundation.org/Journal/NoDataLossProposal
Note that if we "apply changes", then in the example shown on that
page, the item would be deleted. (i.e., the last change of any
inter-collaborator conflicts would take effect.) One problem with
this is that there is no agreed-on order for the changes; i.e., we
don't know *when* the changes occurred for each collaborator, as
it's dependent on e.g. when the mail arrived and when somebody
chose to send it.
I'm not sure this matters? So long as the changes are indeed applied
in the order listed in the dialog, we haven't misled the user.
This is why I still think we should have individual "apply/discard"
buttons for each pending change, so that you individually apply
changes, causing them to be immediately removed (or greyed, crossed
out, etc.) from the list and updating the detail view, so that you
can interactively apply selected changes.
The changes from the above proposal would be minimal:
1. Each change would include an "apply" button, and a "discard" button
2. When a button is used, both buttons for the item would disappear
or become disabled, and the rendering of the change would be
different (change color, icon, text style, whatever) to indicate
its applied-ness or discarded-ness. If the change were applied,
the summary and detail views would be immediately updated to
reflect the change(s). (If discarded, no such updates would occur.)
3. The dialog would have one button, "Finish later", which would
change to "Done" when all changes have been either applied or
discarded.
Oops, I meant to mock this up. Here's a quick text mockup.
Pending change Apply Discard
1. Notes: xxxxxx [ ] [
]
2. Start time: xxxxx [ ] [ ]
3. Start time: xxxxx [ ] [ ]
[Okay] [Decide later]
It's hard for me to articulate. But my gut feeling is that giving
users more fine grain control over what changes to apply and/or
discard is confusing and perhaps unnecessary. I feel the user
workflows are really more binary than that.
I think the simple cases are:
1. You have a conflict with 1 other person. Their changes look fine.
You just want to accept them and overwrite your own edits; OR
2. The changes are a big jumble and you probably want to 'hand-craft'
what the definitive version of the item really should be, either by
copying and pasting select changes from the pending changes dialog
into the detail view, or discarding the pending changes altogether
and working directly from your own detail view.
3. I suspect that when changes *are* a-jumble, users will seek out
sharees out-of-band to sort out the mess.
If we can't do this (for whatever reason), I think we need to drop
the "Apply Changes" option from the above proposal (or change its
name), since it's not obvious that it *really* means, "go ahead and
maybe lose data". If someone becomes accustomed to using it for 2-
person conflicts, they will likely make the mistake of using it
when a 3-person conflict occurs, thereby losing one person's data
or the other, *without having verified which one they meant*.
I think if there are clearly a confusion of pending changes, users
will consult sharees before doing that and/or work directly off of
their own version of the item.
So, I think it would be better to force explicit acceptance of each
change (or else deny the ability to automatically apply changes at
all!) than to allow the system to do something unexpected and
unexplained as a result of doing what you are already habitually
doing.
Another minor note: items with pending changes *can* be synced with
Cosmo; they just can't be sent in email. The difference is because
when we send out an email, it is the same email to all
collaborators, so we have to resolve inter-collaborator conflicts
in order to send everybody the same thing. But for shares, we have
to sync independently anyway, so we only send out non-conflicting
changes.
This isn't much of a difference, though; it means you can still
sync the collection, but only non-conflicting local changes will be
sent to the server. We could possibly make the operation more
strict, however, and not send *any* changes, even non-conflicting
ones.
Ooh, that's hard to word correctly. Maybe the user doesn't need to be
told that.
Regarding the deletion scenarios, we do not need to sync with the
server or otherwise impede emptying the trash. For server shares,
the conduit will retain the necessary data to know that the item
was removed locally, even after the item no longer exists. So the
trash can be safely emptied at any time. However, upon the next
sync, we would recreate the item if someone changed it. We could
then put it in the trash and make the change pending, as described
in the new proposal.
Okay.
Finally, regarding the last few points under "Workflow", it's not
my understanding that resolving conflicts (regardless of how) is
something that should cause a sync to happen or an update to be
sent. For one thing, if the conflict was resolved by applying the
pending changes and discarding the local ones, then there is
nothing to send; the "other side" is already up-to-date.
That's fine. Although, in the case of multi-way conflicts, isn't the
fact that the conflict has been resolved, something to send?
Also, since there may be other conflicting items for the same
share, it's not clear that we should incur the overhead of an
immediate foreground synchronization for each individual item whose
conflicts are resolved.
Last, but not least, the item may be shared in multiple collections
and with multiple collaborators, so the process of sending off
changes to all these places may be quite expensive.
My assumption, therefore, has been that after conflicts are
resolved, they are transmitted during the next normal sync or
update email, without any special acceleration to the process. If
some sort of acceleration is desired, we probably need to get
clearer about the scope of when and what to accelerate, how.
That's fine, I was more just trying to get across that once the
conflict was resolved, the resolution would get propagated to sharees.
Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
