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)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
