Jeffrey, Grant and I met last week to hash out Dashboard, Sharing, Recurrence, Communications issues. Here is the outcome of that meeting.

---

Dashboard and Modifications

WHEN DO WE KEEP TRACK OF Who modified what, when?

• When Triage status changes (by explicit user acton)
  • When Triage status is changed automatically, we should keep track of that as a system change: Edited by: Chandler on xxx
• Communications status: Read/Unread/Needs reply
• This is in addition to normal modifications to other attributes in the detail view

• When items are modified, the 'Modification field' in the detail view updates to show who modified the item and when they modified it.
• The Who column in the table also updates accordingly
  • Created by
  • Edited by
  • Sent by
  • Updated by
• (See Stamping spec for more details: http://svn.osafoundation.org/docs/trunk/docs/specs/rel0_7/Stamping-0.7.html

• Implementation detail: Modifications need to be tracked by Chandler, not the Sharing layer. Otherwise, users won't see that they edited something until they sync.

---

---

Dashboard and Sharing

WHO MODIFIED WHAT, WHEN & SHARING

Edited by xxx on xxx needs to be maintained on a per-user basis.

• Workflow Example
• Helen the Hub is sharing 2 task lists, 1 with Bart the Busy Body/Coordinator and a second with Ivan the Individual Contributor
• Helen is sharing Triage status with both Bart and Ivan
• Helen is sharing Communications status (Read/Unread/Needs reply) with only Bart
• There is heavy overlap between the two task lists, many of the tasks are on both lists.
• When Helen changes Triage status on an item that is in both task lists, the item in Helen's Chandler shows that she edited the item
  • When Helen syncs the task list she shares with Bart, Bart's Chandler/Cosmo UI shows that Helen has edited the item.
  • When Helen syncs the task list she shares with Ivan, Ivan's Chandler/Cosmo UI shows that Helen has edited item.
• When Helen changes Communications status on an item that is in both task lists, the item in Helen's Chandler shows that she has edited the item.
  • When Helen syncs the task list she shares with Bart, Bart's Chandler/Cosmo UI shows that Helen has edited the item.
  • When Helen syncs the task list she shares with Ivan, Ivan's Chandler/Cosmo UI does NOT show that Helen has edited item because they are not sharing Communications status.

---

SORTING BY TRIAGE STATUS

Note If we DON'T do this for preview, we also shouldn't do the Purge workflow. Instead, we should just have a slight delay on purging items (e.g. wait until the user clicks away to a different item before re-sorting by triage status).

Definitions

• Section triage status: Which triage section an item shows up in
• Real (color) triage status: Triage status of the item
• Purge: Rationalizing Section triage status so that it is the same as Real triage status.

• Updates insert themselves at the top of the NOW section of recipients ONLY. The Updat-er and other sharees do not see the Updated item move to the top of their NOW sections.
• Edited and shared items show up as Unread for sharees. The Editor's version of the edited item remains Read.
• However, if Communication status is shared, then the edited is marked as Unread for everyone.

• Explicit order is maintained on a per collection-view basis. Each collection and each collection-overlay combination stores its own explicit order.
  • This means that an item could be on the top of the list for a Group Dashboard, yet at the bottom of your personal Dashboard and in the middle of the Group + Somebody else's personal Dashboard overlay combo.
  • Explicit order is shared along with Triage status

• For simplicity's sake, if users are sharing triage status, Section triage status is NOT shared and is maintained ACROSS collections within a single user's repository.
  • Syncing a collection should share items as if the collection had just been purged (but shouldn't actually cause a purge to take place)
  • This also means that users don't have to think to hit purge before syncing
  • However, the Purged version of the shared collection that is synced should not override the non-Purged Section triage status of other sharees. This means that if a sharee is in the middle of triaging a shared collection and hasn't Purged it yet and along comes background sync, their items shouldn't be moved around willy-nilly by the Sync. Instead, their Section triage status should be preserved until the sharee explicitly Purges.
  • User motivation This allows us to do things like insert Updated items at the top of the NOW section to alert recipients of Updates, but not bother the Updat-er and other sharees that are simple subscribed to the collection with Updates.

• If there are Unread items that are about to be purged, we should throw up a dialog: Are you sure you want to purge? There are newunread items that will be purged.

• Items with a Section triage status that does not equal their Real triage status do not permanently affect the explicit ordering of the collection. This means:
  • The position of the item in the list changes as soon as the user clicks Purge.
  • The position of the item in the list is not shared.

• However, ticklers and start date/times that auto-triage the item and triage status changes invoked by explicit user action DO permanently affect the explicit and ARE shared.

---

SUMMING UP TRIAGE STATUS AND SHARING

• If Triage status is shared, then explicit order is shared as well
• However, Section triage status is not shared
• If Triage status is shared, then Alarms must be shared, otherwise we will have dueling Triage status

• Start date/time affect both real (color) and section triage statuses
• Alarms affect both real (color) and section triage statuses
• Triaging before purge only affects the (color) triage status.
• Dnd reorder (nice to have) affects both real (color) and section triage statuses.
• Purge means that real and section triage statuses are reconciled.

• Sort order for the individual user is derived from Section triage status.
• Sort order for sharing is derived from the Real (color) triage status.

---

---

Dashboard and Recurring Events

CREATING NEW EVENTS AND EVENT SERIES

via CLI:

• Mark as Unread.
• Attempt to auto-apply Triage status, if there is a date
• Place at the top of the NOW section Even if auto-triage has made the event DONE, right? -- JeffreyHarris - 09 Oct 2006

via in-place creation on the Calendar canvas or in the Dashboard table view

• Mark as Read
• Auto-triage appropriately

• If the user continues to change the start and end date/time of the event, auto-triaging of events should continue so long as:
  • The user has not explicitly set the triage status; OR
  • The item has not been auto-triaged to NOW because an alarm went off or the start date/time rolled around
  • For more details, see: http://bugzilla.osafoundation.org/show_bug.cgi?id=7184

---

DASHBOARD AND RECURRENCE

• To add to the spec The instance of the recurring event that appears in the Later section displays the the start date/time of the next occurrence in the Date column of the table.

COMMUNICATIONS STATUS AND RECURRENCE

An Unread item is defined as

• Item you created in the CLI
• Newly created item
• Item changed by somebody else

That means, items are NOT marked as unread when...

• An item is auto-triaged from LATER to NOW because an Alarm or Start date/time rolls around

In the case of a recurring event series, when an user 'Reads' an item or marks an item as 'Unread', we should mark all instances of the recurring event that look just like it. (Ignoring differences in Triage status and Date/time metadata.) This is true in both the Dashboard and the Calendar. -- Actually, after talking with Mimi today, instead of doing "events that look just like this", for now we'll just mark EVERYTHING in the series, because this is an easy first step. -- JeffreyHarris - 13 Dec 2006

The reason we want to make an exception for date/time metadata is because we don't want users to have to mark Read/Unread status for each individual instance in a recurring event series.

The reason we want to make an exception for Triage status is because we don't want users to have to remark Read/Unread status for recurring events just because the event series straddles multiple triage status (some occurrences are happening in the future - LATER, 1 is happening right this instant - NOW and some have already happened - DONE).

The fallout of this is that un-modified instances in the event series might have Read/Unread statuses that are different from modified instances.

Conveniently, this allows us to model Updates to individual instances in a smart way, even though for Preview, we will not be able to support Updates to individual instances in a recurring event series or the This and Future subset of a recurring event series.

Instead, recipients of Updates will receive the entire event series (under the hood), even if only a single instance was updated. However, in the Dashboard, Update recipients will ONLY see the edited instances at the top of their NOW section, marked as Unread. All other instances of the recurring event will stay put in the Dashboard and remain marked as Read.

So while, under the hood, we can't support edit/updates to individual occurrences, at the UI level, we will be able to simulate it.

This of course assumes that the above proposal is doable in the Preview timeframe. ;o)

COMMUNICATIONS AND RECURRING EVENTS

In the Preview timeframe: Send, Update, Forward and the Addressing fields will only apply to the entire event series.

In order to achieve this simplification, we need to be able to keep track of edits on a per attribute basis. Grant and Jeffrey are working through the details of this as I write.

This will be new functionality.

Currently if I change the Title of a single instance of an event series, the event becomes 'detached' from the series, which means that if I then go to edit the Location of that event, I can no longer apply my change to the entire series.

Similarly, if I apply a global edit to the Location field from a different instance in the event series, that global edit will not apply to this 'detached' instance.

When/if we support per instance, per attribute modifications to recurring events, then we will be able to do things like modify an attribute on a single instance, while still applying global edits to the series on all other attributes.

How should forward work on recurring events? What do we display in the Notes field when forwarding a recurring event series that has modified instances in it?

• Can we just display the attribute values from the Master event?

Open issue: How should reply work on recurring events?

• Can we reply to individual instances of a recurring event, or the 'This and Future' subset of a recurring event series?
• If so, can we mark individual instances of a recurring event or the 'This and Future' subset of a recurring event series as 'Needs reply'?

Replying to an individual instance or the 'This and Future' subset of a recurring event series would mean the following:

• Displaying the right thing in the Notes field of Reply message:
  • If you are replying to the entire series, display the metadata from the master event
  • If you are replying to a single instance, display the metadata from that single instance
  • If you are replying to the 'This and Future' subset of the recurring event series, display the metadata from the
• Allowing users to choose between All, Just this event, and This and Future when marking an item as 'Needs reply'.
• Post-preview, it will mean keeping track of which instances, or which subset of instances have been 'Replied to'.

Please see Alpha 4 email spec for more details about what 'display the metadata from' means: http://svn.osafoundation.org/docs/trunk/docs/specs/rel0_7/Email-0.7.html

---

TRIAGE STATUS & EDIT AND UPDATE WORKFLOWS

Workflow

1. I send you an event series.
2. The entire event series arrives at the top of your personal Dashboard's NOW section, with whatever Triage status was set by the sender. This means that you could potentially have 3 separate items for past instances, right now's instance and future instances. Additionally, any modified instances will appear as separate items as well. ( I'm flagging this as a known issue. The recipient could potentially receive a lot of items for just a single event series. Imagine that someone sends you the last 2 years of daily status meetings where each meeting was modified with it's own meeting notes. However, this is probably an edge case and can/will be solved when we have cluster support: Event series should really be sent and received as clusters of items that can opened and closed in the Dashboard.)
3. You edit 2 instances of that series and click Update (which under the hood, Updates the entire event series).
4. I receive the entire event series again, however, only the 2 edited instances show up at the top of my personal Dashboard's NOW section, marked as unread with whatever Triage status you assigned them.

---

---

Post-Preview

Sharing cloud

• Sharing communications status
  • Open issue Sharing Read/Unread status versus Needs reply

Provide richer metadata about modifications to distinguish between different types of modifications

• When an item has changed from Unread to Read: Viewed by xxx on xxx
• When a tickler/start-time has fired and an item is auto-triaged to NOW: Auto-triaged by xxx on xxx
• When a user explicitly marks an item as Unread: Marked as Unread by xxx on xxx
• When a user explicitly sets triage status to LATER: Triaged to Later by xxx on xxx
• When a user explicitly re-orders an item: Re-ordered by xxx on xxx
• If an user performs multiple edits in a single session (without clicking away from the item), then the last edit wins.

Refinements on the Purge workflow

• Purge applies to all items in the open sections of currently selected and overlayed collections on a per user basis. This means that an item that shows up in multiple collections will be purged in all collections as soon as it is purged in 1 collection.
• The Purge button in the toolbar is only active if there are items in the selected and overlayed collections that have mismatched Section triage status and Real triage status

DND, REODERING OF RECURRING EVENTS IN THE DASHBOARD

• For Preview we will disable this functionality. When users try to drag and drop recurring events in the Dashboard to explicitly re-order them, we will pop up the following dialog: Currently, Chandler does not support dragging and dropping of recurring events. [ ] Never show this again. [Okay] [Cancel]

ADD OPTION TO NOT IMPORT ANYTHING MORE THAN ONE MONTH OLD

• As a performance boost we should offer users an option to not import events that are more than a month old.

-- MimiYin - 09 Oct 2006