[Design] Determining that collections behave like categories

[Alec Flett]

Philippe Bossut wrote:
>
> So the solution (for UI) is to break out of the location metaphor 
> altogether as you said. May be that's precisely the real breakthrough 
> that "tags" and "folksonomy" have achieved recently and a reason of 
> their success. Not something really new (from a computer science 
> standpoint, we've been using links and queries since years) but at 
> last an efficient metaphor for complex semantic linking that consumer 
> level users can use without being confused.
>
I personally wish that I could just have a delicious-like interface for 
all my mail - I mean ultimately, I don't need to see all my mail folders 
in my sidebar - I need some subset of collections that give me quick 
access to important messages.

Part of that dream is that someone has gone and already tagged my 
thousands of e-mail messages with relevant tags, and so forth. But I 
always wondered - say we fast forward some number of months/years to 
when chandler is usable as a mail client and we have this world of tags 
and collections, how does my mail get from hierarchical mail folders to 
this neat folksonomy?

One thought I had is that there is actually a lot of meta-information 
stored in mail that we could sort of auto-create collections from... 
essentially, what if chandler sort of auto-tagged your e-mail and then 
also made some special collections based on data collected during the 
auto-tagging?

For instance:
1) Folder name. I have some folders in hierarchies (I'm using the 
delimiter '.' as we do on the OSAF server), "MailingLists.dev" "bugs", 
"Sent", "Sent.2005" and so forth. I think we could more or less tag each 
message with all the components of the path. For instance a message in 
"MailingLists.dev" would get tagged with "MailingLists" and "dev" 
automatically. Messages in "bugs" would get tagged as "bugs". We may be 
able to develop heuristics for making a good guess at which tags to 
create collections for in the sidebar. For instance, if all messages in 
the "bugs" folder are also from "bugzilla-daemon at osafoundation.org" then 
maybe that tells us something else about what the "bugs" tag means.

2) Sender/Recipients. We wouldn't need to tag anything based on this, 
but we could auto-create collections for the "top people" - i.e. I have 
a few specific friends who I probably exchange at least 30% of my 
personal e-mail with. We could create collections for these "top people" 
- I think we could probably come up with some pretty decent heuristics 
for determining who those people are.

3) Mailing lists - there are multiple ways to identify mailing lists, 
from well-known RFC822 headers, to looking for [xxxxx] in subject lines, 
to noticing that MY e-mail address doesn't appear in the To or CC 
headers. We could again develop some heuristics to filter out the noise 
so that if I have 1000 messages with [....] in the subject line, but 
only 2 of them have [ACLFW] then I'm probably not on a mailing list 
called ACLFW and might just have some messages from them, or a friend 
used [ACLFW] in a subject line when sending a message.

4) Date - we could easily auto-create some collections for "more than 1 
year old" or "last month" - because honestly, I don't care where my 
really old messages are, as long as I can find them by searching.

Anyway, you get the idea. I really like the idea of at least giving the 
user a "best guess" when transitioning from another mail system into 
chandler. The same principle could apply for importing calendars from 
iCal, RSS feeds from BlogLines, or whatever.

Alec

> Radical idea for Chandler's UI: move away from the "storing places" 
> metaphor (folders) and move into a "tags" (categories) metaphor. This 
> will mean a different way of presenting the sidebar and may be a 
> change in vocabulary in the UI.
>
> The good news is that Chandler's collections are actually closer to 
> "tags" than to "hierachical folders". It's also consistent with what 
> you propose.
>
> Cheers,
> - Philippe
>
> Mimi Yin wrote:
>
>> 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
>>
>> On Jan 25, 2006, at 8:56 PM, Philippe Bossut wrote:
>>
>>> Grant Baillie wrote:
>>>
>>>> A "+" button next to the "Appears In..." item in the detail view as 
>>>> a  clue?
>>>
>>>
>>> Or making the whole "Appears In..." field editable.
>>>
>>> Anyway, I remember that we played with a similar idea in Entourage 
>>> and implemented "search folders" so that, indeed, emails appeared in 
>>> different places (instead of being filtered and moved). This feature 
>>> tested terribly. It's somewhat disorienting for people to have one 
>>> thing appearing in 2 places at the same time...
>>>
>>> Cheers,
>>> - Philippe
>>>
>>> PS: on the subject of locations (places) and items, it seems that 
>>> some of it is so hard wired in our brains that using it is the best 
>>> memory strategy known. See:
>>>    http://news.bbc.co.uk/2/hi/health/3152502.stm
>>>    http://www.newscientist.com/article.ns?id=dn3181
>>>
>>>
>>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>>
>>> Open Source Applications Foundation "Design" mailing list
>>> http://lists.osafoundation.org/mailman/listinfo/design
>>
>>
>> ------------------------------------------------------------------------
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Design" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/design
>>  
>>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design