Jeffrey posted a question about persistence of selection across views in Chandler to the list: http://lists.osafoundation.org/pipermail/design/2006-April/004654.html

I replied:

Hi Jeffrey,

You've unrooted a workflow issue that's been bugging me since 0.4, so I'm glad we finally have an excuse to talk about it.

The question of persistence of selection boils down to whether the user is expecting to

1. Continue a workflow when switching contexts/views; OR
2. Interrupt one workflow to pick-up another previously interruped workflow (basically progress through multiple workflows in parallel).

The first is more common in Calendaring (I think because overlays + the linear flow of time provide a single, continuous, spatial context, melding what would be separate worlds, e.g. Home and Work calendars, into a unified space.)

The second is more common in Email. e.g. Work on a Draft. See that I got new email. Check my Inbox. Go back to reading the Design list. Go back to Working on a Draft.

This issue is also relevant to how we treat selection in the summary pane AND selection/activation in the sidebar across App areas.

Are people continuing a single workflow when they go from All to Calendar? Calendar to Task? OR Are they switching modes.

PLUS, keep in mind that in Chandler, the ability for a single item to APPEAR in multiple collections AND to BE of multiple KINDS and therefore appear in multiple App areas provides the user with a workflow/navigation path across collections and App areas that is not possible in existing software.

As usual, the answer is probably: All of the above. The real question is:

1. What's the most common usage scenario?
2. How do we provide separate, 2nd-class affordances for the less common ones?

Right now, my feeling is that we're using the App bar buttons incorrectly. They function as "Item Kind Filters" rather than Physical Destinations/App areas.

However there is clearly a need for Item Kind filters in addition to App areas.

Our ambiguity on this matter is reflected in the naming scheme: + Mail (Item Kind), + Tasks (Item Kind), + Calendar (App area).

As opposed to:

• Mailboxes
• Task lists
• Calendar

I need a little more time to pull together a more well-considered proposal(s) to address this issue. In the mean time, does anyone else have examples of use cases that demonstrate the two types of context switching described above?

1. You switch collections to start a new workflow
2. You switch collections to continue your current workflow

E.g. An example of use case type 2: I go to the PPD calendar and select next weeks' PPD meeting. I need to reschedule it and put it somewhere that doesn't conflict with the rest of my Work schedule. I switch collections in the sidebar to Work so I can move the PPD meeting around in the context of my Work schedule.

Thx, Mimi

---

Assumptions

When switching from the Calendar to Tasks, I almost never want the same set of Collections to be Activated/Selected.

• In Calendar, I always have Work Selected and then Home, PPD, and Office calendars Activated.
• For Tasks, I would want to see either Home or PPD.

If I receive an Invitation in the Dashboard (All App area), I do want to see it on the Calendar (which was the original reason why we switched to the model of "Persisting Item Selection across App areas, whenever possible"), but maybe we can find a different way to do that (e.g. A button in the detail view of the item for: Show me this Event on the Calendar)

When I have multiple Collections overlayed, I think of the entire view as a single entity, sub-divided by Collection. So when switching between overlayed Collections, I expect things like Selected Item(s) to persist seemlessly across Collections.

However, if I don't have Collections overlayed and I switch Collections, I'm really switching back and forth between two separate modes: Home tasks and Work tasks. And I want to be able to pick up where I left off when I return to a Collection.

PROPOSAL

We treat the App areas as Physical Destinations:

• Mailboxes
• Task lists
• Calendar

Each App area has it's own persistent set of:

• Activated Collections (checked, not checked)
• Selected Collections

When you have Overlays within an App area

• Item Selection(s) persist when you change Collection Selection in the sidebar, if possible*. Otherwise, de-select.
• By if possible, I mean at least 1 of the selected Items must belong to the newly Selected Collection. (Jeffrey has already said this is hard to do when there are multiple Items selected, so it's a Nice-To-Have in that situation.)

When there are NO Overlays

• Item Selection(s) change when you change Collection Selection in the sidebar
• Whatever Item(s) was/were last selected in the newly selected Collection is/are now selected. If no Item(s) was/were selected, then no Item(s) is/are selected.

When focus is in the Calendar Canvas (Overlays or NO Overlays)

• The date-range of the calendar canvas NEVER automatically shift to re-center itself around the selected item, regardless of whether there are Overlays or not.

However, when focus in in a Table view and there are Overlays

• The scroll bar always tries to center itself around the selected Item; OR if there are multiple Items selected, the Item that was selected last.

When focus in in a Table view and there are NO Overlays

• The scroll bar re-positions itself with respect to where it was the last time you were in the "newly" Selected Collection.

In addition, we need to have a way for users to:

• Find/View an Event Item on the Calendar (focus the date-range of the Calendar canvas on that Event), BOTH 1) From somewhere else on the calendar canvas; and 2) From a table/list view. (e.g. Show on Calendar button in the Detail view)
• Filter down Collections to Section and Show/Hide parts of a Collection by Kind

-- MimiYin - 27 Apr 2006