Morgen Sagen wrote:
(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.
I don't like this idea of an RSS collection to post what are basically activity log info. Internally, I'm fine with having those info treated as items (of a relevant kind as mentioned here above) but, from an end user standpoint, this is a very different kind of info, not relevant to "tasks" or "projects" but rather to the internal health of the application/system.
I'd prefer to have these info reviewable in a specific panel/drawer. Looks like this could be a first incarnation of the "Activity Viewer" proposed by Jeffrey earlier. We could also have other status and failure info, currently fleetingly displayed in the status bar, being logged there (see recent IRC discussion on the subject).
(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.
I first choke on the "conflict resolution detail view"... After reflection however, one could imagine little icons (a la "!" that Excel for instance displays on cells for some minor auto fixed issues) that once clicked would give the various conflicting versions for the field and a choice. OK for small fields though, not OK for the notes... Hmmm...
Anyway, I agree on "as automatic as possible", so +1 on (2). Cheers, - Philippe _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
