[Design] Fwd: About Organizing Information Using Browser Bookmarks

[Mimi Yin]

Hi, Mimi,


> I liked your approach to a more ground-up approach to creating pseudo-
> facets...basically concepts become facets if they start popping up in
> more than one place. The system on the whole allows for more
> flexibility in organizing data without completely throwing structure
> out the window, the way Tagging systems do.
>

One of the important contributions of my paper, I think, is that people
are inconsistent in tagging and classifying, and the way they do so
evolves over time, and the system has to accommodate these changes
easily and gracefully.  A method for creating structure from the actual
data set itself lets you restructure anytime without pain.

One of the problems with tagging, that its proponents have not been
talking about yet, is that when the tag collection gets too large, say a
few hundred or thousand tags, then you can't find the tag you want, and
you have to start classifying, organizing, and searching the tags.  You
also cannot keep using the tags consistently, because you cannot
remember the details of their semantics(although at the time you created
a tag, you thought that the semantics were clear!).  Now you are back
where you started before tags appeared.


> Currently, I'm trying to put down on paper some ideas around how to
> visualize all these various relationships in a top-down way that
> makes sense to people and isn't overwhelming.
>

Yes, the perennial problem!  One reason I wrote my topic maps engine was
to explore these issues.  But I don't have the answers yet...


> How do you visually distinguish between different types of
> relationships...
>      True parent-child relationships
>      Sibling relationships
>      Overlapping siblings
>      Overlapping facet relationships
>      Thread relationships (where the order of things is of primary
> importance)
>

I'm not convinced that these particular kinds of relationships are all
that important to most people most of the time.  What I think *is*
important is to be able to come up with all sorts of grouping and
ordering schemes, and to be able to display them as hierarchical lists
(where appropriate), or annotated lists (ditto), and to be able to show
links and their content when the view is not essentially hierarchical.

IOW, a general capability.  Then you or the user can make use of the
general capability to show "true parent-child relationships", or
whatever.


> ...And see them all from an eagle-eye perspective, in the same way
> you can open up an entire tree and have a static map of all of your
> data and data containers. The proposition is that something like this
> needs to be available in order for any of these systems to succeed.
> Some way to create a static map of all of your data and all the ways
> in which the data is grouped...and all the ways in which the
> groupings and the data itself are related to each other...
>

You know the best thing I have ever seen that relates many different
aspects or facets of a subject?  The IBM Glass engine.  If you haven't
been lucky enough to encounter it, go at once to

http://www.philipglass.com/glassengine/

It presents all kinds of information about the music of Phillip Glass.
It works in Firefox (it's a java applet), except that the audio doesn't
play on my machine.  The audio does work in Internet Explorer.  The
different facets of the data are represented by horizontal bars, which
you drag to scroll to explore the parameters you want.



>  From this static map, you can zoom in and inspect things with more
> detail, but without this static map, flying around from grouping to
> grouping can be incredibly disorienting.
>
> You address this issue in part, by always providing context...ie if
> an user click on a Facet of a grouping: "Articles", they see a list
> of Contexts for "Articles". In other words, the user is never plopped
> into some new environment with no sense of how they got there and
> where it is in the context of their organizational structure...But I
> wonder if giving people a sense of how the conceptual grouping:
> Articles fits into the context of all of their data and all of their
> data groupings might be even better.
>

The thing is, much of the structure is adhoc, and not particularly
ordered.  If it could be ordered, we could probably coerce Google Maps
(e.g., assign pseudo lat-long values to "points" in the context) to be
our UI.

I've attached two screen shots from my bookmarks engine that show my
current approach (I hesitate to say "solution") in this area.  This is
an evolution of the material in my 2003 paper.  The first one shows, on
the left-hand panel, terms (I call them "indexing terms", but they are
really derived from the bookmark folders and the paths to the folders,
as described in my paper).  In this case, the terms are all related to
the term "Agent".  The path expressions give the "context".

Below that, you can see a section marked "perspectives and facets".
Those are really leaf folder names, divorced from their contextual path.
If any such "facets" show up in more than one place, these links will
let you discover this - i.e., it helps with serendipitous discovery.
This demonstrates that sometimes you want to transcend context.

On the right, unrelated to the left panel (in this particular screen
shot), is the result of a search, in this case for "glass" - of course,
I wanted to find that IBM Glass engine.  The thing I want to point out
is that I return search results for *both* URLs and terms (folder names,
basically) that match the search, and I keep them separate but easy to
look at.

I think that this approach is very useful, although my particular
implementation is kind of crude visually.

The second screen shot shows a context view of the term "Article".  You
can see that I use it in a lot of different contexts.  You talked about
"the conceptual grouping:Articles".  I'm not clear just what kind of
conceptual grouping  "Articles" is in my bookmark collection, but I
don't need to know because my system finds it and treats it
appropriately anyway.

An extension of these techniques would be to introduce some kind of
automatic clustering or association mechanism.  I'm quite interested in
that notion, and the paper I gave at Extreme the following year (2004)
presents a novel approach that might turn out to be useful. -

On-the-fly Clustering As A Novel RDF Query Mechanism
http://www.mulberrytech.com/Extreme/Proceedings/html/2004/Passin01/EML20
04Passin01.html


> I will send something your way when the paper is in a more coherent
> form.
>

Thanks, I'm looking forward to it.

Tom

-------------- next part --------------
A non-text attachment was scrubbed...
Name: bookmark display_2.gif
Type: image/gif
Size: 33605 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/design/attachments/20050804/f16eca4c/bookmarkdisplay_2.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bookmark display_3.gif
Type: image/gif
Size: 35854 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/design/attachments/20050804/f16eca4c/bookmarkdisplay_3.gif
-------------- next part --------------