Labels and Tag Clouds - Part 2

Last Week

Last week we talked about the basics of Tagging - Tags and Labels, Tag Clouds, and Implementing single-entity tagging and multiple-entity tagging using a SQL database. The SQL queries were easier than you'd think.

You can read the part 1 article here: http://www.fastechWS.com/tricks/web/labels_and_tag_clouds.php

This week we're focusing on more advanced features of Tagging that you can add to your web site with a fair amount of work.

User Interface - Associating Existing Tags, Creating New Tags

How will tags be entered into the system? Usually tags are entered by people, so we need a nice user interface. You want to make it easy to utilize all existing tags, yet let them create new tags at any time.

You could simply have a text-input box and tell the user to "enter tags, separated by commas". This is OK, however people naturally make mistakes sometimes when typing. Or some people will use plural, and others singular. You'll see some articles tagged with "books" and others with "book". The meaning is the same, but being 1 letter off, they're two completely separate tags. Now if people click the "book" tag, they won't see anything tagged with "books". If you count the quantity of things tagged with "book", it doesn't include "books".

You can get around this problem 2 ways:

UI Method 1 - Select Menu with related Input Box

Give them a SELECT menu of all currently existing tags to choose from, so they don't make typos. Also, give them an input box if they want to create a whole new tag. This is the quickest and easiest way for a web site to accomplish the task, however, as you get more and more tags, the giant-scrolling-menu of tags may become irritating to use.

(Some web sites resort to bubbling the person's most recently used tags to the top of the list, so that they can re-use familiar tags more easily; you'll have to decide if you want that feature, and how much work it will be to track recently-used-tags with every user).

UI Method 2 - Predictive Typing

Use AJAX to help the user complete what they're typing. Once they've typed part of the word, such as "bo" for book, you display all known tags beginning with those letters by sending an AJAX query to the server, which does a database query and returns the list of choices. They can see whether "book" or "books" is the right tag to use, that way. This will take many hours of programming and debugging though, to do it right, even if you use a pre-existing AJAX library.

Since the predictive display will contain a varying number of choices, you'll need room to display all those choices, that can grow/shrink. That can easily be done with a DIV tag, and javascript updating its contents. The best method is to make a DIV area that floats above the main web page by using the style "z-index" set to a number greater than 1.

You'll need to show/hide the DIV so it doesn't obscure something else on the page when it's not in use. When they leave the current input field, hide it; when they type a character in the input box, do the ajax query, show the DIV, and display the resulting choices.

You'll want to let people mouse-click on the choice they want, in that DIV area; some Javascript will copy the tag name to the current input field right where they're typing.

You also may want to let them navigate by keyboard; up/down arrow keys to move the selection between choices in the list, and TAB or ENTER to auto-complete the currently selected choice. That can be done in Javascript too, with the onKeyDown even handler interface.

Different users behave differently with input systems like this, you want it to feel good for most everyone who tries these standard behaviors with your web site, even though it means extra programming for you.

In order to not return too many choices, one strategy is to avoid doing the ajax query until they've typed at least 2 or 3 characters.

This Method #2 is a lot of work, but definitely the most impressive way to implement tags. Plus, if you write and debug all this code once, you can probably use it again and again in future projects.

To play with a good version of this, install Google Toolbar in your web browser if you don't have it yet, and try doing searches from it. Google has implemented a predictive-typing system, and displays your recent searches above the suggestions coming from the mass of other people who have done searches in the past.

One web site I developed used the Yahoo UI javascript library for the AJAX part (the "Connector" interface). I ended up writing a PHP script that takes 1 URL argument (the partially entered tag name), queries the database, and returns any matching tag names as pure text data rather than HTML. That's the AJAX lookup backend code.

Then I simply connected the tag input field's "onKeyUp" event handler to a javascript function that calls the Yahoo UI, to do the AJAX query and write the results into the DIV of possible choices each time they type a character in the tag input box. It worked quite well, but took quite a while to fully debug.

I use Firefox's Firebug plugin to debug Javascript, it has good error messages and even lets you single-step thru code and set breakpoints - its a real debugger.

Tag Cleanup / Combining Duplicates

For the best working web site, it's best if you have some way to monitor what tags people have entered in the system, edit their spelling, and combine tags to eliminate duplicates.

For example, Last.FM has these two tags currently: "synth pop", and "synthpop". I'm sure those have the same meanings, but somehow, people created these two separate tags. Some items in the database are tagged with both, some with only one, some with only the other. An administrator should really be watching and notice things like that, and clean it up.

To do this right, there needs to be some kind of console where the admin can view all the tags by scrolling alphabetical list OR by searching with partial-matching. When 2 or more tags are identified as identical, the admin must choose 1 to keep and 1 to delete. They can always edit the spelling of the one they keep later.

The algorithm to clean them up is:

1. Query DB for all item IDs that are tagged with the tag we want to delete AND NOT tagged with the tag we are keeping.
2. Connect each of those to the tag we're keeping (insert recs into the join table)
3. Remove all recs from join table with the tag-ID we're deleting
4. Delete the tag itself from the tag table, now that it's not used anywhere anymore.

Tag Aliasing

What if there are two common names for the same thing, and you want either one to work when people type them? Internally, we only want a single tag to be used for both. We should be able to have 2, 3, 4, or more names associated with any given tag. For example if a music band changes its name, both names should be recognized, because we know some people will type one, some will type the other. If we measure popularity as quantity of uses per tag, we don't want that group's popularity to be split between its two names.

There's a few ways to handle this situation. One is to create a tag-alias table containing alternate names of a tag, each one pointing to the real tag's ID number. Then, when we let the user enter a tag, we must match against both tag names and alias names.

When we see the user typed an alias, we associate the real tag to the item. The down-side is, the user may say "what the..." when they see the web site changed the name of the tag they typed. Hopefully they'll understand the logic of it; we're just trying to standardize tag names - keeping the database as clean as possible.

Alternatively, you could simply add another field to your Tag table - an "alias_id" field, or something like that. If the field is NULL, then this row is a real tag. If it's NOT NULL, then it's the ID number of another tag row which is the real tag - this row is simply an alias that people might refer to, when they really mean the other tag.

This has the advantage that you can mark the tag.name field as "unique", so the database won't allow any duplicates to be put in the system. With the separate Alias table, there's always a chance that a bug would allow the insertion of an alias whose name is the same as that of an actual tag.

Interestingly, there are two duplicate artist entries on Last.FM, "IAMX" and "I Am X", which are obviously the same band. I clicked on "IAMX", and it had all the info about the band as usual. Then I clicked on "I Am X" and it displayed a page that said,

I Am X is a mistagging of the artist IAMX, please update your tags.

That's a pretty good way to handle the issue.

Category Trees Implemented with Tags

If your customer insists on a tree-structure of categories, you can implement that with tags. Your "tree" is no more than a list of already existing tags, and parent/child relationships! You just need a special table for the parent/child part in your database:

Each category has a name - the tag name, via tag_id (left-join the tag table to access the names).

The top category(ies) of the tree have a "parent_id" of NULL. Each sub-category has a parent_id which is simply the category id of the category above it in the tree.

When a customer clicks on one of the categories, you simply fetch all rows in this same table where parent_id is that id. Thus you're asking "show me all categories whose parent is this one here."

You can left-join the tags table to return the tag name with each category record. You can do a normal join to get all the products/articles related to that category/tag, if you want.

Multi-tag Matching

If you're displaying the results of all things that are tagged with "cars", the visitor might want to sub-search on another tag, such as "mitsubishi". Then they might want to restrict the search again to "wheels".

You can do that by displaying all the tags related to the items having the specified tag. The SQL for searching for any number of tags needs to be generated by PHP, or some other dynamic language like it. You'll have to think about the SQL for that one, the concept is basically, "show me all TAGS related to all PRODUCTS whose TAGS match T1 and T2 and T3, but don't show tags T1,T2,T3 in the results."

Types of Visitors

Remember that you'll have all types of visitors to your web site. Beginners want to get an understanding of "what's going on here", and see the basic information they're looking for. Less complexity is best, for new visitors.

Regular returning visitors want to home-in on what they're specifically looking for. They want to play with more advanced features, see the more sophisticated parts of your web site. Adding great tools for them gives them more power, but also adds complexity.

It can be challenging to find the right blend between power/complexity, and simplicity/ease-of-use. This is why most search engines like Google and Yahoo have a very simple interface for beginners that everyone sees first (enter words, click a button!), yet they also have an "advanced mode" with tons of useful features to choose from, for their more advanced users.

It's worth pondering these two opposites - complexity and simplicity - when designing any web site.

Resources

What I describe above is from my own experience, but there are books out there now about developing with Tags:

Tagging: People-powered Metadata for the Social Web
by Gene Smith
http://safari.oreilly.com/9780321550149?a=103644

and

Building Tag Clouds in Perl and PHP
a 48 page PDF by O'Reilly and Associates
http://safari.oreilly.com/0596527942?a=103644

Don't miss the latest web tips and tricks!
Subscribe to our low-volume mailing list:

Privacy Policy

See other tricks:  Web | Unix | Perl | SQL | General