[Design] linking and grouping items

Mimi Yin mimi at osafoundation.org
Mon Aug 8 08:56:30 PDT 2005


Please see comments in-line...

> Regarding clustering, I find the drawings on the notes
> you linked to unnecessarily cluttered in appearance.
> The problem appears to be that some items may belong
> in more than one category and the drawings are
> appearing to try and form graphical links to all of
> these interconnections.

Hi Selva, are you referring to the drawings on this page?:  http:// 
wiki.osafoundation.org/bin/view/Projects/AdhocCollectionsWorkflow

Yes, these are simply conceptual drawings to help illustrate the  
architectural model behind the idea. There is a wholly separate  
problem of how to effectively present data and data relationships to  
people which I am working on in a separate paper right now.

> It’s sort of like trying to
> graphically represent a series of hyperlinked HTML web
> pages which can be very confusing with all the
> interlinks running back and forth between different
> sites.  As far as the role of a PIM is concerned, it
> should allow for such interlinks if occasionally
> required.

The drawings might make more sense if they were perhaps more  
specific? If the relationships were labeled with specific attributes?

> However, this should not be done at the
> expense of sacrificing a tree / cactus structure for
> viewing purposes.

Ah I see, a cactus structure is simply another way to say tree  
structure. Sorry to be slow about this, I wasn't sure if there was  
something particular to cactus structures that perhaps didn't apply  
to tree structures.

> Otherwise, the mental picture
> tends to get less organized for many like myself!  One
> way to handle items that may belong to more than one
> category may be use “aliases” the same way Apple does.

I think this method also has its problems:

1. Browsing through the tree, it looks like you have more items than  
you actually do and it's hard to wrap your head around the scale of  
your data set.

2. Users gets confused about aliases versus the original item and  
deletion versus removal becomes a hairy issue. We're definitely  
grappling with this right now in Chandler as we implement deletion in  
our virtual collections.

3. You don't get a mental picture of how your categories or facets of  
categories interact with each other, which categories heavily  
overlap, which ones are completely unrelated.

In other words, when you look at the whole of your data structure (be  
it a tree or a venn diagram drawing), what kind of extra-data  
information can you extract from it?

I could go on for a year about this, but I'll save it for a more  
coherent wiki page.

>  Hence, if a file belongs to more than one category,
> then an alias (which is essentially a hyperlink to the
> original file) could represent the file in the second
> category.  This way, branches of a graphical cactus /
> tree structure don’t get intertwined trying to
> represent all the different interconnections.This is
> also usually the way most people plan and organize
> things on paper and imitating paper is usually a
> fantastic goal for software to try and simulate.

I'm not sure that this is true. If we look at the notes that people  
draw on paper for meetings, it's far more likely to see something  
like a mind-map where there might be a single item with many spokes  
radiating from it, point to other things, than a strict tree  
structure. Duplicating items as aliases in many places on a single  
page of notes or across several pages of notes would seem like a time- 
consuming activity...and wouldn't give you a sense of how things are  
connected from the item's perspective.

>
> The other notion of being able to view these clusters
> (I prefer branches with use of aliases when needed)
> along a third axis for time dependent filters such as
> Now-Later-Done triaging might be something worthwhile
> to look at as well so that we could get an overall
> view of all projects we have going on in various
> aspects of our lives, which areas need to be focussed
> on first, and how these all relate to our overall
> goals.
>
> Regarding the notes on stamping, I guess a dedicated
> stamping button may be useful for some people -
> especially those with larger monitors who don’t mind
> looking at a lot of buttons.  However, the mechanisms
> I had described might be considered as a preferences
> set up option for those that want to minimize buttons
> on their apps.

The notion of stamping buttons is for groups of attributes, not for a  
single attribute at a time. One common use case might be to "stamp"  
an email to put it on the calendar, because the email is really an  
invitation to an event. This would add all the calendar attributes to  
the item. You're right, we don't imagine that Stamping would be the  
way users would assign "categories" or labels to items.

Stamping buttons wouldn't go much beyond 5 or 6 at-least at the top  
level of the Stamping structure. We're imagining that Stamping might  
be a shallow 2-level hierarchy of Kinds. At the top level, there  
would be: Communications, Tasks, Events, Resources, Media, Profiles  
or Directories.

>
> The other options for stamping access I had mentioned
> was right clicking the title bar of the item window,
> and Shift-Clicking the already available
> sub-application launch bar buttons.

I wonder how discoverable this feature would be.

> The tiny
> sub-compact notebooks I saw at the Sony store recently
> had some pretty small screens and this type of set up
> option may be particularly useful on devices like
> this.  Also, here’s an interesting article that
> touches on use of buttons in applications that may be
> relevant here as well:
> http://www.icefox.net/articles/kdeosx.php

Thanks, I'll take a look.

>
> The other main difference between my discussion on
> stamping and that on the link is that in the system
> described in the link seems to deal mainly with
> changing the format of an existing item rather than
> adding the contents of a displayed item to the
> contents of another pre-existing item.  In the system
> I had described, this could be quickly done by
> Shift-Clicking the Cactus sub-application launch
> button to locate the pre-existing item or document.

Yes you're correct, clustering not stamping would be the main  
affordance for pulling together already existing items.

>
> (If the pre-existing item is not already filed in the
> Cactus then this may be more complicated as the item
> may first need to be opened up and perhaps something
> like Shift-dragging the new item’s title bar over the
> pre-existing item window could then add the contents
> of the new item at the end-point of the cursor on the
> old item.)
>
> The other main difference between my discussion and
> the stamping discussion on the link is that the link
> discussion does not really address where exactly the
> quickly jotted down, unfiled notes would be found.

Yes, apologies, that is discussed in other design pages on the wiki  
(I didn't want to overwhelm the list with too many links). Newly  
created items get automatically dumped into the Now section of the  
Dashboard or (All my items collection), unless explicitly in a  
different sections: Later or Done.
>
>
> I had suggested that they may be filed. by default,
> under an “unclassified” branch of the Cactus
> sub-application so that they may be easily located and
> then, if necessary, dragged to the appropriate
> classification along the cactus / tree.

We're assuming that the majority of the user's items will remain  
"unclassified" with the exception of Triage status. The supposition  
is that most PIM data doesn't actually need to be classified beyond  
Triage status and that it is only the "important" items that need to  
get "filed" or collected into special Project views or specialized  
cluster threads.


More information about the Design mailing list