[Dev] Chrome design follow up

[Donn Denman]

On Nov 3, 2004, at 8:30 AM, John Anderson wrote:

>
>
> Donn Denman wrote:
>
>> Mimi and I continued the design discussion from today's meeting about  
>> how the Kind Selector, Sidebar, and other Chrome views should work.  
>> We settled on a feature set for the 0.5 milestone, and I /think/ it  
>> can be easily be implemented with the Trees-Of-Blocks model we're  
>> currently developing within CPIA. This is just a first pass, but it's  
>> worth discussing.
>>
>> In general terms, here's what we'd like to propose: Data navigation  
>> revolves around the Sidebar, which is a collection of item  
>> collections. For each item collection, including the Sidebar, there  
>> are four different views - applying the four Kind Filters. I think  
>> this was Katie's idea in the meeting. You can think of the result as  
>> a two dimensional grid with a Kind dimension across the top and a  
>> Collection dimension down the side. /Each entry in the grid is a  
>> separate view onto the selected item collection, whose items are  
>> pre-filtered by the selected Kind/. Changes that the user makes fall  
>> into two categories: changes that modify the data affect all views on  
>> that collection, changes that modify the view don't affect any other  
>> view.
>
> I think a possible snag with this proposal -- if I understand it -- is  
> that there currently isn't a way to filter items by a view, we can  
> only filter by modifying an ItemCollection. Perhaps we could redesign  
> ItemCollection/Query somehow, but making the filter part of the View  
> seems difficult because it has to scale to very large lists.
Good point - we'll have to create a filtered ItemCollection to support  
the filtered view, with the current model.  I had hoped that we'd only  
be building views for each kind.  We have a plan to build views on  
demand, but not to build collections on demand.

>
>>
>> | All Cal Mail Task
>> ------------- | ------- ------- ------ ------
>> All | All Cal Mail Tasks
>> Received | In E. Invites InBox Chores
>> Sent | Out Events OutBox Requests
>> Trash | Trash Past Es Junk, etc Done Tasks
>> |
>> Home | H.All H.Cal H.Mail H.Tasks
>> Work | W.All W.Cal W.Mail W.Tasks
>> Travel | T.All T.Cal T.Mail T.Tasks
>> Kibble | K.All K.Cal K.Mail K.Tasks
>> Collection | C.All C.Cal C.Mail C.Tasks
>>
>> Certain familiar views fall out of this model. Like the InBox of a  
>> mail program - it's your received Mail. Likewise you have pre-built  
>> views for your home and work calendars, by selecting the Cal kind and  
>> the Home or Work collection. To see both calendars at once, you must  
>> select the All collection, and then you get all Calendar items.
>>
>> We've made some simplifications for 0.5.
>> 1) The kind filter is not changeable. If you want to do your own  
>> special filtering, you should start with the All Kind and edit the  
>> query from there.
>> 2) There's no layout selector - the layout is based on kind, with  
>> Calendar showing a graphical view, everything else showing a table  
>> view.
>> 3) No multiple selection will be supported for either kinds or  
>> collections.
>> 4) Each grid cell has its own independent view.
>>
>> Each dimension is open for expansion: The user can create new Item  
>> Collections, which appear on the sidebar. Four pre-filtered Views are  
>> created for the user collection as needed. In theory, a 3rd party  
>> parcel such as Photos, could be written which adds another Kind to  
>> the toolbar. Then a photo-filtered view would be created for the  
>> sidebar and when needed for each Item collection.
>>
>> Complications: The Tab views complicate the picture a little, but  
>> basically work the way they do today. Also, Mimi thinks there needs  
>> to be some sharing between views vertically, but hasn't got that all  
>> figured out, so we'll defer that till the next cycle.
>>
>> I think this design could work pretty well. Do people see major  
>> issues? Does this make sense?
>>
>> - Donn Denman
>>
>> ---------------------------------------------------------------------- 
>> --
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/dev
>>