[Dev] Chrome design follow up

[Morgen Sagen]

On Nov 3, 2004, at 12:34 AM, 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.
>
>                	|	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_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>

I have some comments/questions:

A) Are Home.All, Home.Cal, Home.Mail, and Home.Tasks separate 
ItemCollections (each with separate rules, results, etc)?  I believe 
from what you have proposed they are not; in that case, how does this 
affect sharing?  For example, if I am in Cal mode and I share Home.Cal, 
what gets published, all the items currently displayed in the  Home.Cal 
view, or the entire Home collection?  Taking this example further, 
after I have shared Home.Cal and I go back to All mode, what does the 
sharing status indicator icon display for Home?

B) I'm worried that adding new kinds to Chandler has become a 
"heavyweight" operation in terms of the UI.  There are probably three 
new kinds that will be appearing quite soon: Photos, RSS entries, and 
yes, Contacts (if we don't add Contacts, someone will).  All this is 
just my opinion, but it would be a big win if somehow our 
app-bar/kind-filter was "scalable", and that supporting new kinds 
(potentially many) didn't cause UI real estate problems.  I suppose 
there will always be this tension between Chandler the PIM and Chandler 
the extensible app framework, and it's probably pretty obvious which 
way I lean.  :-)

C) How do we define new ItemCollections and edit their queries?  I 
think knowing the plan for this will help me better understand the next 
point, (D).

D) It's hard to say without going through the experience of using 
Chandler day-to-day, but I imagine that once a user has gotten into a 
routine, there will be  some (probably small) set of "pages" (think 
"some set of items" plus "how they should be displayed") that they will 
switch between frequently.  Concrete example:  say I switch back and 
forth between the following 6 "pages":

1) combined personal and work calendar
2) combined view of all my personal email accounts inboxes
3) work email inbox
4) personal tasks
5) work project 1 tasks
6) work project 2 tasks

Page (1) is easy because I can click on the Calendar app bar button, 
and if I had previously selected the Personal and Work collections 
together, they would still be selected, and their combined items would 
appear in a calendar layout.  Pages (2) and (3) require just a bit more 
work to get to since I first click on Mail in the appbar, and then I 
get to page (2) or (3) by either multi-selecting all my personal 
account inboxes, or by clicking on Work.  Pages (4) (5) and (6) follow 
a similar pattern of clicking the presentation method/filter, then 
selecting the collection.

I think that slicing and dicing in this manner is powerful, and one of 
the great features of Chandler, but I imagine that once a user has 
sliced and diced their items the way they like, they will prefer to 
"remember" those settings and be able get to those with a single 
gesture (in fact I hope we can bind keyboard shortcuts to each of these 
"pages").  If placing each of these pages into tabs is the way to 
accomplish this, then I guess that works, but I'm still hoping for the 
equivalent of a "bookmarks bar" somewhere, where a bookmark represents 
"some set of items" plus "how they should be displayed".

~morgen