[Design] Scoping out sharing-related 0.7 projects

[Mimi Yin]

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
> http://lists.osafoundation.org/mailman/listinfo/design