[Design] Proposal for 0.7 dashboard phases

[Mimi Yin]

>> Also, though I agree the bi-directionality issue (having items  
>> "knowing" in which collections they appear rather than just  
>> collections knowing which items they hold) needs to be solved, I  
>> don't understand how the 2 sub features (context click to create  
>> collection or dnd to create collection) help with this issue. May  
>> be these 2 features were not intended to be sub issues of the bi- 
>> directionality issue and should simply be moved to the left.
>>
>> I also understand that those 2 features are ways to create "search  
>> collections", i.e., a collection that will have all items for  
>> which the clicked or dragged field has the value the current item  
>> has. Is that correct?
>
> I will let Mimi respond to this one.

In a NON-bi-directional universe (where Items don't know what Folders  
they are in, but Folders know what Items they have), there is a  
distinction between Folders (containers) and Rules (the things that  
populate those containers).

A Search Folder (container) named "From_Karen" might have a Rule on  
it that says, find all the things "From: Karen" and put them into  
this folder. Or you could think of it as: Search for all things  
"From: Karen" and then save the Search results into this container  
and name it "From_Karen".

In a bi-drectional universe, distinguishing between Containers and  
Rules quickly becomes recursive and non-sensical.

Because...in a world where Items reflect what Collections they belong  
in...If the user creates a Search Collection called "From_Karen",  
defined by the rule "From:Karen", member items would show 2 labels:
+ From: Karen (the original Attribute defined in the Rule)
+ Collection: From_Karen (the Container for the Rule)

Now, if you imagine that a single Item could appear in a limitless  
number of collections, this sort of set-up quickly becomes  
unsustainable.

Instead, we can easily think of the Label "From: Karen" as the  
collection itself. So if you drag the Attribute:Attribute_value pair  
from the detail view to the sidebar, you are demonstrating the "one- 
in-the-sameness-bi-directionality" of that Label. The Item points to  
the Label, which IS the same thing as the Collection in the Sidebar.  
And the Collection in the Sidebar points back to the Item.

Aside from avoiding duplicate labels, the real reason for striking  
down "superficial" distinctions between Container and Rule is to  
elevate the "Semantics", as in the Attribute of the collection (ie.  
This is a Project collection. This is an Agenda collection. This is a  
Timeframe collection) above the bland generic identification that  
this is a "Collection".

This begins some of the "But I don't understand how a single item  
could be in more than one Collection" problem that you brought up a  
few weeks ago on the list. If the Collections are clearly  
"orthogonal" to each other, as in they represent different  
Attributes, it becomes easier to understand why the same item might  
appear in 2 "locations".

It also helps to "chunk down" or group collections into different  
types, which begins to address some of the "How to grok a lot of  
data" problems, also previously discussed on the list.

===

Now this doesn't limit more complex rules, for example: Take any Item  
with the Labels "From: Karen" OR "To: Karen" AND also "Label it" aka  
"Put it into the Collection" "Project: Launch".

Which means that "Project: Launch", has a rule that populates it.  
However, that rule only adds things into the "Project: Launch". It  
doesn't prevent users from making exclusions or inclusions.  
Essentially, de-Labeling or Removing an item from "Project: Launch"  
even though it is technically "From: Karen" OR Labeling or Adding an  
item to "Project: Launch" even though it is neither "From nor To:  
Karen."

The reasoning behind this is that it is incredibly hard if not  
downright impossible most of the time for a user to construct a rule  
that exactly meets their needs. Rules are more useful to get to the  
80% of what you need in a particular grouping. The remaining 20%  
requires the personalized touch of a human brain.

===

Mimi :o)