[Design] Marking events as relevant to me & Determining thatcollections behave like categories

[Mimi Yin]

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 <mimi at osafoundation.org>
>>         To: Chandler Design list <design at osafoundation.org>
>>
>>
>> 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.
>