tree structures should be chopped down (continued)

Mentioned an experiment the other day.

Now we have it - in a very simple form. Here. No manual, no hints, not much to look at, confusing, takes awhile to get head around, etc., use your imagination :)

What you'll find there is a CMS (Content Management System, management part hidden), like a blog, or a web site, a personnel overview, or - if you stretch your imagination - a data repository.

All of the above have articles, posts, comments, data, persons - as objects. Deposited in a database.

Now, where/how to find such objects?

Standard is of course tree-structures (two dimensional). Add some cross-tagging like 'categories' or 'archives-per-dates' (three dimensional), sometimes made more useful with search.

Enter tags.

Now, that we know from say Technorati. Quite the same as categories within most blogging systems.

So far so good. But not good enough.

Even with tags we easily become overwhelmed and would require some data-structure to find our way. Technorati follows 1.3 million tags now!
Every person on this planet has a tag; name or social security number etc. 6.45 billion of them.

This experiment:

Uses multiple tag choices to choose and find.

And so what?

Using multiple tags, about 20 tags would cover the 1.3 million single-use tags at Technorati.

Using multiple tags, about 33 tags could give a unique identity to every person in the whole world.

(Quite a few years since I studied statistics, believe I'm in the ballpark, but anybody out there who could corroborate?)

And 20-30 tags are less cumbersome to navigate than 1.3 million, or 6 billion!

Multiple tags can replace any single tag, however unique that is.

You're tagged with your name. That does not say much, does it? Unless I know you of course.

Now try multiple tags. Add 10 tags, red hair, tall, birthplace etc. and you may be one of 153,000 with exact same tag set. Add yet another one that says more about you, say 'Italian speaking' - voila, you got only 9,675 individuals with the same tags. Add one more, now 634 identicals. Add two more and 'highlighting' exactly those 14 tags gives one return; you.

Ditto for plants, ditto for file structure on your computer, goodbye folders and search. Etc.

Add that a set of tags gives immediate (and complete!) information about the object. Far beyond what a two dimensional system may give (First and middle name, family name, does not give much information that).

And that is what knowledge is all about. Expand on that.

Time for a remake of Carl von Linné's work?

BTW, search is fine but not the same. Write a document, search by keywords and you'll get lots of irrelevant documents up on the screen. Or you may never mention the relevant word even if the whole oeuvre is about that theme, thus a search would be moot.

So go over here and have a look, try etc. But keep in mind it's just for the fun of it!

[NOTE: The content in the "experiment" has been lifted from thingamy.com just to fill it up with something... ]

Comments

[dl]

Deceptively powerful, reminiscent of the 'Guess the Dictator or Sit-Com Character' game (http://www.smalltime.com/dictator.html) in its all-conquering 2^n logic.

[Ric]

Hah - at last something to play with! A good example of using tags to search.

Questions ... while I think you're right, and it is possible that 14 tags will uniquely identify me (and 2^33 will cover 8.5 billion possibilities) - they have to be the *right* tags.

And is there a potential privacy/identity issue in so "easily" identifying someone (even 14 random but sensible tags will probably uniquely identify someone, and it would take less than that to narrow it down to a manageable list)?

Still - as a demonstration of the idea it works well. Do you still have a better (beta?) demo of Thingamy coming?

[Alex]

Sig,

This is almost exactly like what I implemented as a File System. The only difference I had was I could tag files and I could link files to other files too.

I commented on this on your previous post hoping to engage you in conversation. Your interface is very elegant, much more so than mine was, but it is essentially the same. It looks like this idea's time has finally come...

Alex

[sig]

Ric, it was done so you would have something to play with while waiting :-D

The next issue I think we're already discussing in the next post...

And yes, lets do some demo/playing soon... unless Thomas-the-chap-with-head-in-code stumbles we'll have something end-of-day (read.. eh...soon?)

[sig]

Alex, you're right, the time has come - and you taking on file systems is so point-blank in where one should start, that's where people 'lose' overview all the time!

And if users can start getting their head around the thinking by practical use, file systems would be the place!

[sig]

Ahh, and Alex, appreciate your praise for the interface - it just hit me that I may unwittingly (?) be basking in the glory of the neat javascripts and php code while in fact it was my son serving his 'work experience week' at the end of the schoolyear doing the coding! (It says jr. next to the name on the bottom of the site... discretely...)

That's what I call 'good work experience' :-D

So I meekly cede the glory to a true geek...

[Alex]

In the hierarchical model tags (folder names) hide content. In a tag based search, all content that matches a search should be visible.

The question is how do you get prompted to go from a large list to a small list (in which you can actually find what you are looking for) by adding tags to your filter? One approach I tried that was useful, was the idea of recommended tags.

The idea works like this. You look at the set of items that match your current tag filter and you look at what other tags they are related to and you recommend them as tags to use if further filtering is necessary.

Imagine this scenario you have 6 files:
Z:\Fun\Photos\image1.jpg
Z:\Fun\Photos\image2.jpg
Z:\Fun\Movies\movie1.wmv
Z:\Fun\Movies\movie2.wmv
Z:\Serious\Photo\image3.jpg
Z:\Serious\Movies\movie3.wmv

Imagine for the sake of this example that folder names are synonymous with tags:

If you were inside a hierarchial system and you were in the Z:\FUN folder all you see is two folders you don't see the actually files.

If however you are using a tagging system you see all the 4 files which are tagged FUN, the folders/tags aren't visible though.

Notice that in a hierarchy the meta data obscures information, while in a tagging system it doesn't. Despite this the meta data is still useful.

So I suggest that rather than showing all available tags you only show those that apply currently to objects that satify your current filter.

These are your recommended tags.

What do you think?

[sig]

Alex,
the moment you use relationships you end up in the same tree-structure and suddenly sequence and precision is important. Think tags as 'ill defined blobs', actually with different meaning for different people - look for the intersection, that's where even iffy blobs can produce precise results.

The object-creator should add as many tags he could think of, then let the object-searcher use whatever his logic steers him to. That way an object could have say 14 tags while one chap uses 3 to find it and another uses 5 different tags to find the same...

And when it comes to method / technology: The 'experiment' is precisely that - choose any tag, get a long list, highlight another and see the list go smaller, add another and list goes even smaller, de-highlight the first and it grows again... and so forth. Sequence is of no importance any more, intuition and logic can follow as you look at tags and results, highligh, dehighlight.. play around follow your instincts... :-)

[Alex]

Sig,

I understand the idea of a tag Sig. I understand order is not important, etc... what I was trying to do is show how you could relate tags to a hierarchy. And how you can use your current filter to decide which tags you need to display as options for further filtering.

Maybe I just wasn't clear about it in my example:

When I said Z:\FUN\Photos\image1.jpg what I mean is:
1) A old fashioned hierarchical model: this is an example of one path in a file system that could be used to capture two pieces of meta data 'FUN' and 'Photos'. Problem is in the in a file system documents typically have ONLY one path, i.e. order is important.
2) A tagging solution: if this is translated to a tagging model it means image1.jpg is tagged with both 'FUN' and 'Photos', which of course means order is not important.

I am not suggesting (1) is better than (2). Quite the contrary I am trying to illustrate a technique I used to improve (2).

Now the point I was trying to make is that if someone already has 'FUN' in their filter it makes no sense presenting any tags, as options for further filtering, unless those tags are currently used to tag something that is already tagged with 'FUN'. Why? because filtering on a tag like that would return an empty set. Hence the crux of my suggestion: Tags that DO tag items current viewed should be your 'Recommended' tags.

[Alex]

Forgot to mention:

Why are Recommended tags important? Because as you said if you have 1 million tags or even just 100 tags (I ended up with about 200 tags in my personal tagging filesystem), how do you show them all on the interface? Answer you can't. But you can show the ones that make sense given your current filter.

Alex

[sig]

Alex, got the point... I think. And I agree that it will be a problem with lots and lots of tags, navigationwise and for the overview.

Classes of tags has been mentioned. Tagging tags (it's there already in the 'experiment') could also be a way forward. In some sense that could be the path to a practical and flexible solution for applying 'recommended tags'... 'core tags'... 'prime tags'...

Although 'recommended tags' etc. risks reinstating the issue of object-seeker having to assimilate the logic of the 'object-creator - and that's a no-no :)

But I'm not sure... think I will tinker with the issue by trying it out in the 'experiment'... expect some new twists when we get around to it... nothing is better than trying an idea in real life :-D