On Jan 31, 2006, at 9:35 AM, Mimi Yin wrote:
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.
Possibly -- if the Apps team has time for such a pane. Otherwise, if
we treat the "sharing log" as a collection of Notification items,
then we could just use the existing list view (assuming we get
sorting). I don't know about the free-busy views.
Could the sharing log be merged with a general activity log?
Absolutely -- I hinted below that multiple logs could exist, and
those could feed into a "master" log so the user could see all types
of Notifications in one place. Or the user could view one log
collection at a time to see only certain Notifications.
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?
Well, the detail view of a ConflictNotification item definitely needs
some discussion. Under the hood I was imagining that there is really
one item -- the one containing the changes that "won" (determined by
the conflict resolution policy). The ConflictNotification item would
contain the following information about the conflict: which item had
the conflict, the attributes, and the "losing" values. How we then
take that information and render a detail view is TBD, and I'd have
to get the attribute-editor experts involved. :-)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
