[Design] [Proposal] Rationalizing Overlay behavior in the Sidebar

[Mimi Yin]

There have been a number open issues floating around on the design  
list that are related to the Sidebar spec, including:

1. What's the story for overlays in the non-Calendar App areas?

2. What's the relationship between the Dashboard and overlayed user- 
defined collections?
+ Do users live in their Dashboards or in a particular configuration  
of overlayed user-defined collections?
+ How does the answer to the previous question differ from App area  
to App area?

3. How do we accommodate both users who don't want to be distracted  
by newly arriving/created Items and users who have a hard time  
separating NEW from NOW?

I spent a couple of hours chatting with Jeffrey this morning and we  
managed to work out a proposal to:

1. Provide a coherent narrative of how users will use the 'OOTB  
collections' versus 'User-defined collections and Overlays'; with  
what frequency; and for what reasons.

2. Rationalize overlay behavior:
+ Across all App areas; and
+ Between the OOTB and User-defined collections areas of the Sidebar...
...by making overlays usable in table view as well as calendar view.  
(The alternative is to disable overlays for collections that display  
in table view.)

Note: The proposal below is for 1.0. It is meant as a starting point  
for a conversation with Engineering to figure out how to phase  
functionality in a way that makes sense from an engineering  
perspective and provides a coherent virtuality model for users in the  
Alpha and Beta timeframes.

The end-result of these conversations will be documented in the  
Sidebar and Dashboard specs.

=====
ASSUMPTIONS
+ Users think of their user-defined collections and the Out of the  
box (OOTB) collections differently for a number of reasons:
-- The Out of the box collections are what we've been calling Library  
collections, aggregate views of user data with very specific purposes. 
-- The Dashboard is designed for processing new pieces of information  
and for maintaining focus on the task(s) at hand. David Allen would  
call it the Runway view of your life.
-- The In and Out collections are there as reference collections to  
helps users find information based on whether they received it or  
sent it.
-- The Trash is self-explanatory

+ User-defined collections on the other hand are a way for users to  
organize, categorize and wrap their head around their information.  
They are a way to extricate yourself from the Runway view and get a  
more elevated perspective on things. More forest, less trees.

We believe that most if not all of use cases for overlaying  
collections have to do with user-defined collections and NOT with the  
OOTB collections.
+ Overlay my Home and Work calendars to get a complete picture of  
what my schedule is
+ Overlay my personal calendar with my spouse's personal calendar to  
figure out a good weekend to host a housewarming
+ Overlay the Project Foo task list with the Project Bar task list to  
see how much overlap there is, where the dependencies are

When users switch from a grouping of overlaid user-defined  
collections to the Dashboard, In, Out or Trash however, they're  
switching modes...NOT, adding on another layer of data to compare and  
contrast with the information that's already in-view.

For example, in the Task App area, a user might always have their  
Home and Work tasks overlaid. However, when they go look at the Task  
Dashboard, they're switching modes: 'Now I will go look at the new  
Tasks that's come in and process it.' (e.g. New Task requests from  
other people, New Tasks they've entered but haven't filed into a  
particular collection yet)

A DESIGN THAT ACCOMMODATES DIFFERENT WORK STYLES

Treating the OOTB collections as something wholly separate from the  
user-defined collections is a definite shift from the way we've been  
imagining user workflows thus far. Users may actually spend more time  
sitting in and FOCUSING on a few user-defined collections (aka areas  
of responsibility) that are important to them and only periodically  
look at the Dashboard to process new information.

However, different people will have different work habits and this  
design allows us to support all of them without forcing users to  
explicitly change the UI via preference panels.

+ Some people will never create any user-defined collections and live  
entirely in a big soup of data called the Dashboard. (In other words,  
some people prefer to have their nose to the Runway all the time.)

+ Some people will want to shelter themselves from the influx of new  
Items in the Dashboard and live in the relatively stable world of  
their user-defined collections, periodically dipping into the  
Dashboard every few hours to process new Items

+ Some people will want to sit in the Dashboard and once a day or  
once a week, review their areas of responsibilities and tidy up their  
project plans.

(We've had discussions in the past about whether we should have a  
separate "NEW" section in the Dashboard - I think this design  
addresses many of the same issues in a more elegant and intuitive way.)

ONE FINAL ASSUMPTION
+ Another important assumption is that workflows across the App areas  
are very different. The collections I want to see overlaid when I'm  
engaged in Calendaring may be very different from the collections I  
want to see when I'm doing Task management.
-- For example Task management and Communications are often more  
personal than Calendaring. I'm much more tolerant of seeing other  
people's meetings than I am of seeing other people's Tasks and  
Communications.

===
PROPOSAL

Legend:
Bold= Selected Collection
[x] = Activated/Checked Collection

FOR THE SIDEBAR ACROSS ALL APP AREAS
+ OOTB collections have collections icons that do not have rollover  
or checked states
+ Collection icon for Dashboard changes per App area
+ OOTB collections are separated from user-defined collections by a  
dividing line
+ User-defined collections have collections icons that do have  
rollover and checked states
+ Selection carries across all App areas (If I have Home selected in  
the Calendar App area and I switch to the Task App area, Home is  
still selected)
+ However, overlays are persisted on a PER APP AREA basis

===
ASCII MOCK-UPS

+ User's focus is in the user-defined collection area.
+ The collection called 'The line' is selected.

[ICON] Dashboard
[ICON] In
[ICON] Out
[ICON] Trash
--------------------------
[  ] User-defined
[x] Collections
[  ] Live
[x] Below
[  ] The line
[  ] And can be
[  ] Overlaid


+ User's focus shifts to the OOTB area.
+ Dashboard is selected.
+ Checkbox icons in the user-defined collection area de-activate:
-- The checked icons grey out, which is reflected by [-]
-- Nothing happens when you rollover the user-defined collection icons
-- However, you can still select a user-defined collection in order  
to return focus back to the user-defined collection area

[ICON] Dashboard
[ICON] In
[ICON] Out
[ICON] Trash
--------------------------
[  ] User-defined
[-] Collections
[  ] Live
[-] Below
[  ] The line
[  ] And can be
[  ] Overlaid


+ User's focus is back in the user-defined collection area

[ICON] Dashboard
[ICON] In
[ICON] Out
[ICON] Trash
--------------------------
[  ] User-defined
[x] Collections
[  ] Live
[x] 'Below'
[  ] The line
[  ] And can be
[  ] Overlaid


+ USER SWITCHES APP AREAS
+ The same collection is selected: 'Below'
+ However, different collections are checked
-- 'Below' is no longer checked
-- 'User defined' and 'Live' are checked

[ICON] Dashboard
[ICON] In
[ICON] Out
[ICON] Trash
--------------------------
[x] User-defined
[  ] Collections
[x] Live
[  ] Below
[  ] The line
[  ] And can be
[  ] Overlaid


=====
WHAT DO WE NEED IN ORDER TO MAKE OVERLAYS WORK IN THE SUMMARY TABLE VIEW
+ Add a column to display an Item's collection colors (matches  
calendar colors)
-- Differentiate between an Item's primary collection color  
(equivalent to an event lozenge's fill color) and it's secondary  
colors (equivalent to the little color blocks on event lozenges)
-- An Item's primary collection color is the color of the first  
activated collection in the sidebar that the Item is a member of. If  
the Item is a member of the selected collection, then the color of  
the selected collection always wins.

+ Change the selection highlight color in the summary pane to match  
the collection color
+ There are 2 classes of highlight colors:
-- Highlight color for the selected Item (more saturated)
-- Highlight color for Items in the same cluster as the selected Item  
(less saturated)
-- Cluster highlights aren't limited to Items in the selected  
collection (e.g. see Item highlighted in green in the mock-up)

+ Lighten the font color for Items that are members of activated  
(checked) collections, but NOT members of the selected collection  
(50% grey)

+ Clicking on an Item that is not in the selected collection, changes  
the selection in the sidebar (this behavior is identical to the  
calendar canvas)





-------------- next part --------------
Skipped content of type multipart/related