Summary

This is a working list of use cases and behavior with support Ted development of the item collection spec for 0.6. This is NOT a complete list and will be iterated on by Ted, Mimi and Sheila. These notes summarize the behavior that exists in the app currently as well as targetted for 0.6.

Status

PLEASE NOTE: This list of use cases does not include the design modifications we are going to have on the sidebar in order to emphasize the calendar collections for 0.6. Therefore, so of these details will probably change, particularly around what collections are available out of the box in Chandler and how this interacts with the app bar buttons. Ted is aware of this and we will be iterating and updating this information accordingly.

PLEASE NOTE: The last 2 use cases are not yet targetted for 0.6. We may need to address some of these details but this will be better defined once we nail down the sidebar design for 0.6. Once again, all stakeholders are aware of this as well.

Use Cases and Behavior

Use Case #1: Running Chandler

• 1. Run Chandler for the first time.
  • The All collection on the sidebar is selected.
  • The summary table view displays the contents of the All collection and the first item is selected.
  • The detail view for the item selected in the table view is displayed.

• 2. Run Chandler a subsequent time.
  • We maintain the app bar button selection from when we closed Chandler.
  • We maintain the sidebar collection that was selected when we closed Chandler.
  • The summary table view item (or calendar view) selection is also maintained with the appropriate detail view displayed.
  • If there was nothing displayed in the summary table view (or calendar) - blank detail view, this is also maintained.

Use Case #2: Selecting app bar buttons

• 1. Select the All app bar button.
  • The text for the All collection in the sidebar changes to All my items.
  • The text for any collections in the sidebar that contain no items is gray.
  • Appropriate icons appear to the left of All my items, In and Out.
  • We should have an indicator to the right of all collection names indicating the number of items of all kinds. The current proposal is (#).
  • The summary table view displays a list view for the contents of the All my items collection.
  • The list displays all items in the collection regardless of kind.
  • Nothing is selected in the summary table view and the detail view is blank.

• 2. Select the Mail app bar button.
  • The text for the All collection in the sidebar changes to All my mail.
  • The text for any collections in the sidebar that contain no items is gray.
  • Appropriate icons appear to the left of All my items, In and Out.
  • We should have an indicator to the right of all collection names indicating the number of items of this kind. The current proposal is (#).
  • The summary table view displays a list view for the contents of the All my mail collection.
  • The list displays only items that are of kind=mail.
  • Nothing is selected in the summary table view and the detail view is blank.

• 3. Select the Task app bar button.
  • The text for the All collection in the sidebar changes to All my tasks.
  • The text for any collections in the sidebar that contain no items is gray.
  • Appropriate icons appear to the left of All my items, In and Out.
  • We should have an indicator to the right of all collection names indicating the number of items of this kind. The current proposal is (#).
  • The summary table view displays a list view for the contents of the All my tasks collection.
  • The list displays only items that are of kind=task.
  • Nothing is selected in the summary table view and the detail view is blank.

• 4. Select the Calendar app bar button.
  • The text for the All collection in the sidebar changes to All my events.
  • The text for any collections in the sidebar that contain no items is gray.
  • Appropriate icons appear to the left of All my events, In and Out.
  • We should have an indicator to the right of all collection names indicating the number of items of this kind. The current proposal is (#).
  • The calendar view (day or week) displays the contents of the All my events collection.
  • Depending on whether or not we are in day or week view, only the events for that day or week are displayed.
  • Nothing is selected in the summary table view and the detail view is blank.

0.6 Collection and Item selection persistence across Appbar areas

Selected item succeeds

1. User selects the All mode.
2. User selects the Home collection in the All mode.
3. User selects an event in the Home collection.
4. User switches to the Calendar app area
5. The Home collection is still selected.
6. The same event is still selected and "in view" (displayed in the appropriate date range) on the Calendar.

Selected item fails

1. User selects the All mode.
2. User selects the Home collection in the All mode.
3. User selects an note in the Home collection.
4. User switches to the Calendar app area
5. The Home collection is still selected.
6. No event is selected. The Calendar displays the persisted "date range" of the selected collection.

View settings persistence between collections in a single Appbar area

• 1. What happens when users change collection selection in the sidebar
• Selected item changes
• Scrollbar position changes
• Date range in the calendar summary view changes
• Day v. week view settings in the calendar summary view changes
• Mini-cal selection changes when the user is in the Calendar app area, otherwise it doesn't change
• Mini-cal month range changes to show mini-cal selection when the user is in the Calendar app area, otherwise it doesn't change
• In the Calendar app area, the first time this happens (ie. when the collection is created), the newly selected calendar collection inherits all view settings from the previously selected calendar collection, except for "selected item"

• 2. What happens when users overlay collections in the sidebar
• Selected collection in the sidebar doesn't change
• Selected item doesn't change
• Scrollbar position doesn't change
• Date range in the calendar summary view doesn't change
• Week v. day view settings in the calendar summary view doesn't change
• Mini-cal selection doesn't change even when the user is in the Calendar app area
• Mini-cal month range doesn't change even when the user is in the Calendar app area

Mini-cal across app areas

• Mini-cal month range and Mini-cal selection doesn't change across App areas except...
• If the user switches to the Calendar app area while selecting an event, the mini-cal selection changes to match the main-cal display: week view, showing the week of the selected event.
• If the user switches to the Calendar app area while selecting a non-event, the mini-cal changes to match the main cal.
• Mini-cal in All, Mail and Tasks can only select a single day at a time.
• If the user switches from the Calendar app area to another app area, the mini-cal selection stays the same. If the mini-cal was in week view selection mode, then it selects the Monday of the selected week.

• Basically in all scenarios, the main cal overrides the mini-cal
• The user's interactions with the mini-cal in the All, Mail, and Tasks app areas:
  • Persist across all collections
  • Persist across all 3 app areas and
  • DON'T affect the main-cal
• However, the main-cal's view settings always override the mini-cal's view settings (ie. when the user switches from a non-Calendar app area to the Calendar app area)

Overlays interaction

• Users can click anywhere between the collection icon and the sharing status icon to select a collection
• Users must click to the left of the collection name in order to check-off a collection to be persistently displayed
• The UI affordance to check-off a collection appears when the user mouseovers the collection row in the sidebar
• The UI affordance to check-off a collection only sticks around if the user actually clicks on it, otherwise, it disappears when the user mouses off of the collection row
• Directly checking off a collection does NOT automatically select the collection
• The summary pane displays the sum total of all:
  • Checked off collections
  • Selected collections
• Selected collections are temporarily overlayed with checked off collections

What kind of view appears in the Summary pane

• In the All, Mail, and Task Appbar areas, the Summary pane displays a
• In the Calendar Appbar area, the Summary pane displays a Calendar summary view EXCEPT:
• In the In, Out and Trash collections of the Calendar Appbar area, the Summary pane displays a Summary table view.

Use Case #3: Selecting collections in the sidebar

• 1. Selecting the All collection
  • The summary view contents change according to the rules above depending on what app bar item is selected.
  • If we have the Calendar app bar button selected, we display a calendar view, not a list view.

• 2. Selecting the In collection
  • The summary table view displays the list view format of all items in that collection regardless of what app bar button is selected.

• 3. Selecting the Out collection
  • The summary table view displays the list view format of all items in that collection regardless of what app bar button is selected.

• 4. Select a user-defined collection
  • The sidebar text for this item collection DOES NOT change according to the app bar button selection.
  • If we have the Calendar app bar button selected, we display a calendar view, not a list view.
  • For all other app bar selections, the list view is displayed.

• The selection in the summary view or calendar view is NOT preserved when we click through the collections in the sidebar. The detail view is blank.

Use Case #4: Editing the item in the detail view and summary pane

• 1. Editing any field in the detail view should automatically update the corresponding field in the summary pane upon clicking or tabbing out of the field. [OI^?] Just wanted to confirm that we still can't make commits in real-time?
• 2. Editing any field in the detail view should NOT move the item out of or within the summary pane UNTIL the user clicks away from the item in the summary pane.
• 3. Editing any field in the summary pane should automatically update the corresponding field in the detail view.
• 4. Editing any field in the summary pane should NOT move the item out of or withint the summary pane UNTIL the user clicks away from the item in the summary pane.
• [OI^?] Ted, do you want me to go through each field individually for all the different kinds, making thing anytime events etc?
  • TedLeung - you don't need to do that unless there's something really different, like "a date picker widget pops up" or something like that. I'm assuming that any visual details for the affected areas are already on "List 1".

Use Case #5: Stamping and Unstamping items

• 1. If we are looking at All items in the collection (All app bar button), stamping or unstamping the currently selected item might causes the stamp column to change in the summary table view. This happens immediately when we stamp or unstamp.
  • [OI^?] TedLeung - what about an app bar button other than All?
• 2. Unstamping an item of a particular kind does not cause the item to disappear from the summary table view or the calendar view until we leave the view (change app bar button selection) and come back.

Use Case #6: Removing and Deleting items

• 1. Selecting an item in a collection (summary table view or calendar view) and selecting remove should cause it to disappear immediately from the list.
• 2. Selecting an item in the summary pane of a collection and deleting it should "suck" the item out of all other collections and MOVE it to the trash. (Same behavior for Junk in the future.)

Use Case #7: Updating items in a collection

• 1. Collections should be updated when the user goes to view them. The status bar should give the user
  • 10 messages were added by ShareeUser^?
  • 5 events were deleted by AssistantUser^?
  • 3 messages were deleted by you in a different email client, etc...
  • 14 items were added because they were marked as Done
  • [OI^?] Ted asked: Are these example feedback messages or are they specific messages that we expect to see? I'd like to see the set of message we expect to see, so we can make sure that the lower levels of the system actually provide enough information to construct these messages.
    • MimiYinI^? think I would need to work on this with you and Brian K and Morgen. I'm not sure I know what all of the scenarios are for why items would appear or disappear from any given collection. Not only do we need to understand what the scenarios are, but we also need to know how much Chandler can actually figure out. For example:
    • An item might disappear because the user deleted it from a different IMAP client.
    • Would Chandler know who deleted it? if it was deleted via IMAP or Sharing?
    • When it was deleted?
    • What client was used to delete it? etc...
    • Caveat For .6, we can probably focus mostly on the Sharing scenarios and worry less about email.
    • [OI^?] TedLeung - we should probably work with Morgen / Brian K to get a first cut at the list of reasonable messages.
• [OI^?] TedLeung - are use cases 6 and 7 also supposed to cover changes via background tasks? I think that the answer is yes, but just want to be sure.

Use Case #8: Search collections

• 1. When users search within a collection, we should display the # of results in the sidebar next to the collection. The # of search results should update in real time as items are found. (John said this fell out naturally.)
• 2. It would also be nice if we could simultaneously search across all collections in the sidebar and display the # of search results found in each collection next to each collection name in the sidebar. The # of search results should update in real time as items are found.
• 3. When we have email, we will need to be able to display the # of unread messages in each collection. This should be updated in real time
  • As well as Mail is synced
  • As rules are fired
  • When users add and/or remove unread items from collections
• [OI^?] TedLeung How much search is in scope for 0.6

[OI^?] TedLeung - How/When do we decide whether use cases 9 and 10 are in 0.6. While I like having them documented and being able to think about the issues, I want to be careful about keeping the scope narrow for 0.6

Use Case #9: Quarantining items from the user's other rule-based collections [Not necessarily a requirement for .6 unless it makes sense to do]

• 1. Users can designate certain collections to be "quarantine collections" meaning that items that are created directly IN the collection are not added to the user's other non-quarantined collections UNLESS they are explicitly dragged in by the user. (This is essentially a cheap way to solve our need to distinguish between "Public v. Private" information.)

Context Originally we were thinking we only needed to quarantine items that arrived via Inbound Shares. However, we quickly realized that it would be quite useful for the user to be able to distinguish between Public and Private spheres of information on any kind of collection (ie. RSS feeds, the events on Blue's outbound, shared Conference Room calendar, etc.) We also realized that it was not enough to simply mark items as quarantined as they came into the collection, but that users really needed a sense that the "collection" itself was a quarantined place, so that items created in the quarantined collection were automatically quarantined as a result of having been born inside the quarantined collection. Still, we need to allow users to selectively "unquarantine" items without removing them from their original "quarantined" collection.

A good example of this is the OSAF calendar. Generally speaking you may want most things that get added to the OSAF calendar by other sharees and by yourself to be quarantined from your personal collectios. However, once in a while, you may explicitly drag and item from the OSAF calendar and add it to your own calendar, because it is actually relevant to you, effectively unquarantining, but without removing it from the OSAF calendar. Conversely, you may also want to take an item that already lives on your calendar and Add it to the OSAF calendar (ie. Days you plan to be on vacation.) So the OSAF calendar is "generally" quarantined, but can contain exceptions to the quarantine rule when the user explicitly drags items in and out of it.

• Requirements for quarantining items
• Users can designate collections as quarantined
• When a collection is quarantined all of the items that were already in it are "sucked" out of all non-quarantined collections. [OI^?] TedLeung - do you mean at the exact moment in time that you activate the affordance for quarrantining? There's no need to remember which items were quarrantined after that, is there (like the exclusions list)?

• What happens when items are added via explicit user action*
• All items created IN-PLACE in the collection are automatically quarantined.
  • Users can create items IN-PLACE either by: D-clicking in the calendar summary view OR
  • Creating an item of the appropriate Kind from the New item Menu item (ie. If a user creates an Event while they're in the Calendar app area, Chandler will add the item to the the currently selected collection. If a user creates an Email in the Calendar app area, Chandler will plop them into the All collection in the All app area.)
• HOWEVER, all items that are added to a quarantined collection from non-quarantined collections are not quarantined. They are added, not moved.
• All items that are added to a non-quarantined collection from a quarantined collection ARE UNquarantined. They are added, not moved.

• What happens when items are added via automatic mechanisms
• All items that are added to a quarantined, shared collection by other sharees are automatically quarantined, UNLESS the same item already exists in another non-quarantined, shared collection.
• If a collection containing an RSS feed is quarantined, then all items that are automatically added as a result of the RSS feed are automatically quarantined, UNLESS the same RSS item or RSS feed exists in another non-quarantined collection.

* General principle Basically the "unquarantined-ness" of an item always trumps the quarantine-ness of an item.

• IN THE FUTURE, we will have to worry about what it means to "add a mailing list" or "attach a rule" to a quarantined collection. I think the way we model RSS feeds would extend quite nicely to these scenarios.

Use Case #10: Filtered shares (Not necessarily a requirement for .6)

• 1. Users can share any intersection of the Appbar and Sidebar as a separate shared collection. (ie. the All collection intersected with the Calendar app area, aka the "All my events" collection)
  • The shared collection should arrive in the Sharee's Chandler as a root collection in the All app area
  • The shared collection should interact with the Sharee's App bar in the normal way, generating 3 App-based filtered collections.
  • Any items the sharee adds to the shared collection will be shared with everyone, even if they don't match the original App area designated by the Sharer. (ie. Sharee adds a task to a "All my events" share.)
  • The shared collection displays an "Inbound Share" icon to the right of the collection name across all App areas on the sharee's machine.
  • HOWEVER, on the Sharer's machine, the shared collection displays
    • A "Partially shared Outbound Share" icon to the right of the collection name in the All App area
    • No sharing icons in the Email and Task app areas AND
    • A "Fully shared Outbound Share" icon in the Calendar app area
• Caveat I'm making all kinds of assumptions as to what's hard and what's easy, so the requirements here are much more flexible than I'm making it out to be.
• [OI^?] TedLeung - If this is in for .6, then we need to spend some more time fleshing this out.