[Design] [Proposal] Selection behavior when choosing different collections

[Mimi Yin]

Well,

I'm the only one dogfooding the other silos as far as I can tell, so  
it's my feedback ;o)

The other way of dealing with this issue is by having a story for  
overlays in the Summary Table View (e.g. throw up a column to display  
collection colors + grey out items in activated, but not selected  
collections...How hard is that?)

Mimi


On May 4, 2006, at 3:03 PM, Philippe Bossut wrote:

> Interesting. On one hand I feel it could confuse the user by  
> recreating the "silo" experience (though it's not but it can be  
> used to feel that way). On the other, it's certainly closer to how  
> people expect to see the application behaving.
>
> I like the idea though it seems like a pretty wide change. I'd like  
> to hear Jeffrey and John chime in.
>
> One question: beyond Jeffrey's initial impetus, has there been any  
> dogfooder requesting Chandler to be changed in such a way?
>
> Cheers,
> - Philippe
>
> Mimi Yin wrote:
>> When yous have a moment, could you take a look at this thread?  
>> http://lists.osafoundation.org/pipermail/design/2006-April/ 
>> 004654.html
>>
>> Below is the proposal I've put forth. This affects how selection  
>> works across App areas in the sidebar (both selection in the  
>> summary pane and selection/activation in the sidebar).
>>
>> In a nutshell, I'm proposing we move to more of a "Destination"  
>> mode where the App areas function more as separate areas and less  
>> as filters or ways to switch views (e.g. table to calendar).
>>
>> Thx :o)
>>
>> Begin forwarded message:
>>
>>> *From: *Mimi Yin <mimi at osafoundation.org>
>>> *Date: *April 27, 2006 4:20:11 PM PDT
>>> *To: *Chandler Design list <design at osafoundation.org>
>>> *Subject: **Re: [Design] [Proposal] Selection behavior when  
>>> choosing different collections*
>>>
>>> Can we try this and see how it feels in Alpha3 with some  
>>> experimental usage of the Dashboard? Mimi :o)
>>> *
>>> *
>>> *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 and progress in a linear fashion  
>>> 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.
>>>
>>> *W**hen 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
>>>
>>> Read it on the wiki: http://wiki.osafoundation.org/bin/view/ 
>>> Journal/SingleVersusParallelUniverses
>>>
>>>
>>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>>
>>> Open Source Applications Foundation "Design" mailing list
>>> http://lists.osafoundation.org/mailman/listinfo/design
>>