Please see in-line...
On Feb 4, 2006, at 7:37 AM, Seth Johnson wrote:
Mimi Yin wrote:
I thought the way Bobby described his scenario was a good example of
how the line between
1) "labeling or marking up items" with metadata AND
2) creating collections of items
is fuzzy at best.
When you're scanning the office calendar, figuring out which events
are relevant to you...or when you're looking through a pile of
invitations to meeting, you are in the "marking up mode"...primarily
because you are focused on the individual items.
When it's time to step back and review your schedule, you're in
"collection mode" where you want to gather up all the events you
marked as relevant into a single view and overlay it with your
personal schedule...
I'd like to add this issue to the list of "Design Session" topics we
tackle post 0.7 planning...along with a more general exploration of
"Organizational" workflows.
Yes, I heartily agree. I think Jeffrey's proposal for an item tray is
1 possible solution for this scenario, as is mindmapping.
http://lists.osafoundation.org/pipermail/design/2006-January/003948.html
I'd add to this a third kind of collection mode where you aren't
marking up items, just grouping them (and perhaps marking them up
after the fact). Collecting without programmatic semantics
beyond grouping as parent and children. This is useful for
starting with a mass of unorganized data and trying to make sense
of it gradually (not to harp on it, but this is what mindmapping
facilitates).
This mode does create (if not mindmapped) long list-mode outlines
of heterogeneous data. But this process of grouping by hunch and
guess and feel is important. After awhile, you get a more firm
handle on what groupings mean, and that's when markup of a
different sort comes into play. The markup you and Bobby
describe is more clear about a specific task you're aimed at:
what's relevant to me, to make a schedule of my own.
You should also give people the ability to plan how attributes
and categories are being used, so people can develop strategies
for using common attributes across contexts. So you can list and
work out what contexts you want to have a "relevant to me" or
"impacts my schedule" category or attribute for.
Could you provide some specific examples? (ie. I wouldn't want to see
this attribute on this Kind of item...)
As people move towards working with and shaping up data that's
been deferred, they would have access to established attributes,
organized in themselves such that they can better see a plan for
reusing attributes that have already been devised.
This does not necessarily mean attribute types of Who What When
Where Why How, but also giving attributes and categories scopes
of relevance and outlinability in themselves.
Could you elaborate on what you mean by outlinability?
I went back to the previous thread on "Determining that
collections behave like categories" to see what that was about.
Now, I posted a series of images of a highly flexible "universal
application" interface at
http://wiki.osafoundation.org/bin/view/Journal/
TheProblemWithHeterogeneousInformation
. . . not because these images represent the greatest interface,
but because they show how generic concepts can help you work with
information across "applications." I was dealing there with how
to deal with heterogeneous data in different applications, so I
left out a couple of images that show how categories fit into
this scheme. I've posted those images now at:
http://wiki.osafoundation.org/pub/Journal/
TheProblemWithHeterogeneousInformation/Seek2.jpg
http://wiki.osafoundation.org/pub/Journal/
TheProblemWithHeterogeneousInformation/Seek3.jpg
These two show a menu for seeking a specific review instrument
(the current application type) by categories relevant to the
current "application."
While the interface once again may not be the one you want, you
might find this concept helpful.
Okay, I think I understand what you're getting at now. Do you think
that defining attributes per Kind is enough? OR are there other usage
scenarios that wouldn't be covered by such a generic treatment?
ie. If I receive an Email from Joseph (from the modeling agency),
then I want the following attribute to show up:
+ Hair color
+ Height
+ Weight
+ Ad account
Mimi
Seth
-------- Original Message --------
Subject: Re: [Design] Determining that collections behave like
categories
Date: Thu, 26 Jan 2006 11:32:12 -0800
From: Mimi Yin <[EMAIL PROTECTED]>
To: Chandler Design list <[email protected]>
Thanks for the links to the articles Philippe:
===
From: http://www.newscientist.com/article.ns?id=dn3181
"The team at University College London found that the master
memorisers have neither higher IQs nor special brain structures
to explain their talent. Instead, when debriefed after the
memory tests, many admitted they always use an ancient Greek
mnemonic technique known as "method of loci".
This involves visualising yourself walking along a well-known
route, depositing images of to-be-remembered items at specific
points, then retracing your steps during recall." So clearly,
by having collections in the sidebar that can accommodate a
single item appearing in multiple collections, we're
undermining the brain's "location-based" mechanisms for 1)
remembering where things are and 2) general orientation.
WHAT CAN WE DO ABOUT THIS IN THE SHORT-TERM: I'm wondering if one
way to understand why users get disoriented by having 1-item
appear in 2-places is the cognitive dissonance that arises from
trying to jam virtual concepts into physical metaphors. (ie.
search folders, where folders connotes
Because OTOH, people can be incredibly flexible and agile when
navigating concepts and ideas. I think very few people would be
confused by the idea that:
Joan would show up in both of the following lists: + Gender:
Female + Hair color: Brown
Instead, the model that is put forth with search folders is Joan
can be found in both: + Folder: Female AND + Folder: Brown
"Folder" is not a very helpful description of the semantics
underlying "Female" and "Brown". But the ability to define
"Female" and "Brown" as more than just generic Folders, the
ability to define them in terms of an attribute (Gender: and Hair
color:) helps the user to understand that they are simply
different characteristics or facets of items.
Another reason why the ability to "attri'bute at'tributes" to
collections helps to orient users is simply the "chunking"
benefits it affords. Instead of a long list of "Folders" you can
now segment the list into "categories of categories: categories
based on Gender, categories based on Hair color."
In Chandler, we're proposing to take this "chunking down" of the
sidebar one step further, which is to group the "attributes" into
attribute types: Who v. When v. Where v. What, etc.
The final step (in the short-term) is to provide graphical-visual
indicators (aka icons) that expose these various
"characteristics" of collections (ie. This is a Who-based
collection).
http://wiki.osafoundation.org/bin/view/Journal/
LookingToThePhysicalWorld
WHAT'S THE REAL SOLUTION? These are short-term "compensatory"
measures for helping people navigate a virtual landscape
organized in terms of conceptual grouping as opposed to physical-
location-based groupings. I say short-term because I am assuming
that we aren't going to reinvent basic UI structures (ie. the
triumvirate of sidebar-summary pane and detail view).
In the long-term however, it may make much more sense to allow
people to navigate this conceptual landscape in a way that
doesn't "duplicate or triplicate" items into multiple "locations"
simply because the "locations" are defined along conceptual axes.
Instead... + items are arrayed on a canvas that itself has
semantic meaning (ie. like a map or a calendar) + items are
displayed with visual cues exposing key metadata (ie. an avatar
for "who" an email is from, color for "hair color", size for
"file size" or "task size")
In this model, items would never "appear in" multiple locations,
thereby violating the "method of loci" described in Philippe's
articles. Instead, items remain singular and various ways to
"slice and dice" or "group" items emerge from visual groupings. +
All green stuff + All big stuff + All stuff in the upper-right-
hand quadrant
We already have this kind of view for calendar. It would be
interesting to explore a similar UI framework for more generic
and heterogeneous displays of data.
For more detailed descriptions of what I'm proposing, see:
http://wiki.osafoundation.org/bin/view/Journal/
LookingToThePhysicalWorld
Mimi
--
RIAA is the RISK! Our NET is P2P!
http://www.nyfairuse.org/action/ftc
DRM is Theft! We are the Stakeholders!
New Yorkers for Fair Use
http://www.nyfairuse.org
[CC] Counter-copyright: http://realmeasures.dyndns.org/cc
I reserve no rights restricting copying, modification or
distribution of this incidentally recorded communication.
Original authorship should be attributed reasonably, but only so
far as such an expectation might hold for usual practice in
ordinary social discourse to which one holds no claim of
exclusive rights.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
