[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