[Design] Scoping out sharing-related 0.7 projects
mimi at osafoundation.org
Tue Jan 31 09:35:00 PST 2006
It seems like there are an increasing number of "experimental UI"
items we might have for 0.7...
+ Activity log
+ Sharing log
+ Free-busy views
Perhaps we should consider a "Sandbox" area in a separate pane in the
sidebar (ie. toggling with the mini-calendar) that could be invoked
from a menu item.
Could the sharing log be merged with a general activity log?
Some more questions in-line:
On Jan 30, 2006, at 9:14 PM, Morgen Sagen wrote:
> I'm currently scoping out the following projects for 0.7:
> A) Background synchronization (let the user continue to use
> Chandler while syncing)
> B) User Notification framework (provide the user some way to see
> that shared items have been changed)
> C) Conflict resolution (let the user manually reconcile
> conflicting changes that have been synced)
> Below is a brief description of each, including areas in which I
> would need help from other groups (Andi with some repository work,
> and the Apps team for some CPIA work). Comments are welcome.
> (A) Background (or "asynchronous") syncing involves moving the
> current sharing operations into their own thread rather than
> blocking the main UI thread as they do today. The difficulty here
> will mostly be in the repository view merging code, since using a
> different thread requires using a different repository view. I
> expect I will need some amount of Andi's time to work through view
> merging issues, and we'll need some way in CPIA to indicate
> (probably via some animated icon) that a collection is currently
> being synced. Grant has already done an experiment with moving
> sharing to its own thread, and I will incorporate that work soon.
> Some details to be worked out here include what happens if the user
> is in the middle of editing an item that is modified by a
> background sync.
> (B) User Notifications: I'm not sure if I'm talking about what has
> been referred to as "big-N Notifications", but clearly what is
> needed for sharing is some way for the user to see a log of changes
> that happened as a result of syncing. Currently you can see such
> changes flash by quickly in the Sync dialog, but Mitch proposed the
> idea of having a sidebar collection which acts much like an RSS
> feed of changes. We could add a new Kind to the domain model named
> "UserNotification" (or some name to distinguish it from any
> internal notifications). Changes made in the background during
> syncing would get a corresponding UserNotification item added to
> the Changes collection. The user could then, at their leisure,
> scan through the changes via the list view of that Changes
> collection, and either mark each UserNotification as "read" or else
> delete the UserNotification item. This same mechanism could be
> used not just for sharing-related changes, but for any kind of
> thing that needs to be brought to the user's attention in a non-
> immediate manner. These UserNotifications could be fed into a
> single collection, or multiple collections, depending on
> preference. This requires from CPIA: (1) a way to sort the list
> view, and (2) some sort of 'mark as read' facility.
> (C) Conflict Resolution: In 0.6, when two people change the same
> attribute on the same shared item and synchronize, the first one to
> sync wins. The second user gets a notification of the conflict in
> the Sync dialog, but their local change is lost, overwritten by
> what the first user assigned. There are a few approaches we could
> take to provide better conflict resolution: (1) Quarantine all
> background sharing changes until the user is at a point where they
> are ready to incorporate all of those changes. The user is then
> presented with each conflict (either one-by-one or altogether) and
> they choose from either the local change or the remote change. All
> conflicts would have to be resolved at this point, otherwise the
> repository could not continue with the repository view "refresh".
> (2) Pick an automatic conflict resolution policy ('local changes
> win' versus 'remote changes win') and when a conflict happens
> follow that policy, but in addition add a special kind of
> UserNotification ("ConflictNotification"?) item to the Changes/
> Notification log collection, recording in it which Item/attribute
> had the conflict, and what the two attribute values were. I prefer
> (2); this would allow sharing-related changes to appear at any time
> (since from the repository's standpoint, conflicts are resolved
> immediately), and allow the user to review/resolve conflicts at
> their leisure. Ideally reviewing a conflict would mean clicking on
> a ConflictNotification item in the list view and being presented in
> the detail view with a side-by-side comparison of an item -- local
> changes next to remote changes -- and buttons allowing the user to
> pick between the two. This project would require some CPIA work
> for presenting a conflict resolution detail view.
Would you be able to view 2 conflicting versions of the same item as
individual items in the detail view?
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "Design" mailing list
More information about the Design