[Design] Fwd: About Organizing Information Using Browser Bookmarks
Mimi Yin
mimi at osafoundation.org
Thu Aug 4 16:09:30 PDT 2005
Hi Tom, please see comments in-line...
On Aug 2, 2005, at 8:03 AM, Passin, Tom wrote:
>
> 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.
>
Well I think this is where proponents of tagging might say that the
way you deal with tag collections that are too large is that you use
"tag collections that intersect that tag collection" as a way of sub-
dividing the original "too large" collection (a la fac.etio.us)
I think your second point about the loss of tag semantics is more
compelling. When you have potentially dozens if not hundreds of tags,
which only have this very crude notion of "tag-ness" associated with
them, it's very hard for mere mortals to comprehend such a chaotic
mess (especially if the tags are shared, as they are in folksonomies).
It brings us to the fundamental problem of things being "too
generic." Tags are too generic, just as the notion of "related tags"
are too generic. Both beg the same sort of questions:
How does this tag apply to this item? (This is another way of saying
that you want to be able to tag the tags with attribute names.)
Why are these two tags related? In what way are these two tags related?
This is why I called out the different types of relationships.
When all you have is: These 80 tags are related to this 1 tag, 80
things are too many things to comprehend all at once. The 80
relationships need to be chunked down into maybe 4-5 different types
of relationships.
ie. Economics and Sociology are related siblings: both are Areas of
study or Disciplines.
Modern, Occidental, Fine arts are independent facets that happen to
overlap.
Toes and Toenails are dependent facets and therefore can be construed
as having a variant strain of Parent-child relationships. All things
that have Toenails also have Toes, but all things that have Toes,
don't necessarily have Toenails (I'm not actually sure if this is true.)
"Email 1" and "re: to Email 1" is yet another type of relationship
that is neither Parent-child, nor facet, although it is usually
modeled as a hierarchy. Instead it is a thread relationship where
ordering is of primary importance, but the items themselves are on
equal or sibling footing.
I think differentiating between these different types of
relationships is crucial for helping people understand the varied
nature of their information and how they relate to each other.
In truth, in the "real world" there is no such thing as the generic
"isRelated" relationship. Whenever humans talk about relationiships,
there is always some context to the relationship to make it
comprehensible. It's only when we're "fuzzy" about why 2 things are
related that we resort to generic descriptions: "I don't know why,
but in my gut, I feel like these two things have something to do with
each other."
So, a "fuzzy" understanding of their data is what users get out of
software that presents data relationships to them as generic
"isRelated" relationships that are agnostic to relationship type. And
sometimes "fuzzy" quickly turns into overwhelming or incomprehensible
or I give up even trying to really understand this, I'll just click
around and see what I end up with.
I think this is actually what happens to all of us, even when we
interact with software we're reasonably happy with. But this is only
because we don't really expect very much out of the software to begin
with. We don't really expect to be able to wrap our heads around all
that data and understand what it all means at a high level. We're
satisfied if we can just click around and find the one thing we
thought we were looking for and maybe chance upon something
interesting and related along the way.
But the information or rather knowledge is there, it just needs to be
realized in a tangible way that users can understand and interact with.
I will check out the Glass Engine, it sounds very interesting...
Best,
Mimi
More information about the Design
mailing list