The Appnel Group We didn't write the book on Movable Type -- just the manual

On Tagging Interfaces and Usability

Over on the Signal vs. Noise weblog a post highlighted the different tag input interfaces used by some of the major players and asked Can't we all just get along? This post touches on a topic I've been putting a lot of thought into these days as I plan out the next version of Tags.App, my tag-enabling plugin for Movable Type. I thought I'd highlight some of the observations made in that post and go on to present my own findings.

The post shows examples from Del.icio.us, Flickr, 43 Things and Amazon. Del.icio.us uses single word tags separated with spaces. Flickr follows a similar path, but allows for spaces by optionally wrapping multiple words in quotes. 43 Things uses commas to separate multi-word tags instead of spaces eschewing the need for quotes. Amazon allows spaces and avoids commas and quotes entirely by restricting one tag per text box instead of the one box holds all like the others. Amazon also blow out the interface with an auto suggest interface widget.

The post concludes, when you've got a new technology, inconsistency is to be expected. With all these different formats still be around a year from now or will a standard emerge?

I wouldn't consider tags a technology, but I do believe this type of interface experimentation is a necessary part of evolving user experience.

Trying to discuss and settle on one tag input standard is, as one commenter put it, a can of worms. Personally I don't see these different formats consolidating ever. Perhaps overtime one will prove to be more popular then the others, but I am doubtful that one will win out for a range of reasons.

The biggest is choosing which standard. As the comments to the SvN post attests there is no consensus. Many had their preference based on the tag-enabled app they used most and most didn't seem open to embracing another form. That brings me to my other main reason. There is little motivation for tag-enabled systems such as Del.icio.us and Flickr to make a change that may break compatibility nor does it provide any value to its existing user base which has already been trained to a specific way of inputting tags. So the toothpaste is out of the tube with little hope for one standard.

This said, these various approaches to tag input raises issues of usability and purpose that still have not been fully explored.

One of the best observation in the discussion of what characters to permit and how to separate tags came in the form of an excellent question. Commenter Andie asks when do tags lose meaning as tags? Later she expands here question, are tags useful when they are no longer tags but whole sentences, and does that do to search behavior and usefulness?

I think Jeff Veen addressed this during a Web 2.0 conference panel when he said, tags work because they suck. During the discussion he pointed out how other mechanisms like categories, folders and ontologies have existed for quite some time yet they didn't gain acceptance like tags did in these social software applications.

In an email to me (reprinted with permission) he explained:

...they work because they ignore all the professional taxonomy hang-ups you point out - controlled vocabularies, thesauri, etc etc. When people are organizing their own content (posts, bookmarks, photos) they aren't interested in choosing from a predefined set of approved category terms. They just type what works for them, even though that's the sort of behavior that scares the crap out of librarians, who typically believe the value comes from control. Ironic, really.

Tags are just good enough.

These views lead me to conclude that simplicity and ease is essential to the effectiveness and usability of tags. In mainstreaming tags I sincerely hope this does not get lost. So from my vantage point I become wary when I see elements that will subtract from these essential attributes by adding complexity and taking the tag out of tags. For instance some called for support of the full comma-separated values (CSV) scheme that has been in use for decades. Thing is CSV is a surprisingly complex format (trust me I'm a developer) and too confusing for the average user to input correctly.

While I have my own specific preferences, I do see the need for differing forms. A couple of commenters pointed out that Del.icio.us is about keywords while Flickr and 43 Things are about keyphrases. An notable distinction.

timb posted a link to a good defense of the single word tag limitation found on the Tagified site. The article points out there are two approaches to using tagging usage -- faceted and holistic -- whose difference lies in the relationship of tags to the content.

In the holistic tagging approach the tags themselves are content. 43 Things is an example of holistic tagging that also proves multi-word tagging can work. In the faceted approach, made popular by Del.icio.us and used by Tagified, tags are only aspects of a separate object and are useless by themselves.

This distinction shows that there are reasonable cases for both single and multi-word tags. When applying tags to a system designers will need to make to make this determination in order to apply them effectively.

As I mentioned earlier I've been thinking about tag input and usability for the next version of Tags.App. Now I'll go into the thinking I put into my applications design. Coincidentally I came to a similar conclusion for my software as Tagified post explains.

Tags.App supports single word tagging because tags are attributes (facets) of a post and not content themselves. This is not the only reason alone though. Making them easy to enter and easy to read where also key factors.

Single word tags require the least amount of key strokes and don't require the user to think. Do I need a quote now? Do I need a comma here or next word? These are relatively trivial thoughts, but they still degrade the overall usability tags.

Being single words input is not only simplified, but so is
cognition by consumers of tagged content.

Quick, what are the tags in this list? How many?

 open source bayonne python open office perl

Now try this:

 opensource bayonne python openoffice perl

Wasn't that much easier? The difference is subtle, but notable.

As web usability guru Steve Krug put it, don't make me think. Keeping thinking to a minimum when inputting or reading tags was the primary motivation behind my decision play to use single word tags.

Another positive attribute that lead me to my decision was that they encourage tags to be concise and are more easily remembered by taggers. Relatedly, SvN post commenter Tim remarked, the more cumbersome you make the saving of tags the less likely a user will do it.

Single word tags also reduce the potential variation in spellings and decreases the possibility of tag junk. While another positive attributeof single word tags, this wasn't really applicable to Tags.App because tags are only applied by one or a few weblog authors at most keeping varying tagging styles to a minimum.

In my consideration of tag interfaces I also came to this conclusion: Inputting and managing tags is most effective as a keyboard driven task. Anything else degrades the power and usability of tags.

While the players highlighted in the SvN post do have keyboard driven interfaces not all help support the user. Worse off is the interfaces for managing tags -- delete, rename, splits. While not as common as inputting or reading tags, management of tags is still significant because over time users will occasionally need to clean up their folksonomy as topics evolve and terminology changes.

Let's look at a couple of examples of tag management interfaces from Flickr and Del.icio.us.

Flickr uses an mouse-driven interface that is laborious if you are doing more then a single rename or delete. In this interface you find a tag in the list and click edit or delete. You are then presented with another screen were you complete the action. Everything except for entering the new name for a tag is mouse driven.

The Del.icio.us interface is partly a keyboard-driven interface however single tag input is in a pulldown menu that is stuffed will all your tags. Depending on your system usage this list can be quite long. (Mine is.) If you select the pulldown you can type a character to jump to the first entry beginning with that character. You can enter new or existing tags in the rename. This interface also supports a split by allowing one tag to be split into two or more.

So taking these things into consideration I began experimenting with various interface approaches. I was looking for something that could be highly flexible, compact and keyboard driven for rapidly entering tags. After some thought I came up with this idea of merging autocomplete (ala Goggle Suggest) with the unique attributes of tags -- large quantities of single words. TagSuggest if you will.

I've setup an example page of TagSuggest here. (Safari users will need to switch to another browser currently. Sorry.)

Keyboard input is left intact within the standard form text box, but it is enhanced with a dynamic list of suggestions that can be easily selected using the up and down arrow keys along with the tab key. I like that it can fit into a relatively tight space and cuts down on the potential for misspellings and alternate spellings being unintentionally introduced without taking your hands off the keyboard. You can select a suggestion from the list using your mouse if you choose though. This doesn't completely address the single tag input scenario in the Del.icio.us tag management example above. I'm still thinking about that and how such a widget like TagSuggest might be applied in a usable way.

The TagSuggest library is released under a GPL license for others to use, modify and (hopefully) improve. Suggestions, bug fixes and improvements are welcomed over here. (Not below or in email please.)

This library is mostly based on an autocomplete example by Joe Kepley. Joe's code was very readable, well documented and exactly what I needed to try out my ideas. The Safari issues persist there also -- if anyone wants to help me work through what ails that browser I would appreciate it. My JavaScript knowledge is not extensive, but I'm a quick learner.

Uncharacteristic of this weblog I've opened up comments on this post as I would appreciate hearing the thoughts of others on this topic. I think its an important one that requires further exploration.

I agree with the notion of don't make me think -- BUT, asking someone to separate tags with a comma doesn't make you think, its quite simple.

I don't like the Del.icio.us way becuase I always have to think about how to concatenate multiple words (do I use a dash, underscore, or simply use no word separator?) Since most people think in terms of phrases and not concatenated words, the del.icio.us way makes you think. I really believe that non-geeks will struggle with tags that require multiple words to be meaningful -- example: new mexico.

I don't like Flickr either, because its not consistent -- use quotes here but not there. It makes you think.

That's I would prefer a comma-separated method. People are used to writing lists of things separated by commas. For this reason, doesn't make you think. And because tags are always separated by commas, its consistent. I am not suggesting that the full CSV format needs to be supported, as I don't know what complexities may exist there -- and neither do most people -- but that doesn't change the fact that it is dead simple to seperate a list of words or phrases by commas. It doesn't make you think.

My 2 cents.

Ps. The suggest widget sounds cool, very nice.

Mark: I understand what you are getting at, but at the same time I can just as easily make a good argument for why another way is better then using commas. Simplicity and ease can vary somewhat based on the users prior experience. For instance, some users said the Flickr style was easier and more natural because that is the way Google search works.

My main point is there is no one true way and its all relative to the individual system applying tags. In other words, we would be much better off to discussing the different purposes of tags in a system and which forms support those specific goals better then others.

My intent for explaining my decision making process with Tags.App was to provide some insight and an example of this individual system evaluation. If I were designing a system more akin to 43 Things I would have no problem using multi-word tags.

Can't all systems play nicely with each other? If I use commas in my tags string, the system should simply say, oh, he's using commas, and react accordingly. The same applies for no commas in a 'traditionally' comma based system. The system should just shrug its shoulders and deal with it. Quotes should create multi-word tags. This doesn't make the system any easier to develop... but thems the breaks.

I take it by your comments that you aren't a developer then. :)

The one problem that I think you overlook is the performance hit such a thing would put on a system. Users won't be too happy if the system crawls while the machines can do all of this crunching to figure which tags are the same. I'm sure if I did enough searching there would be some fringe cases where one tag is mistaken or the same as another.

This seems like an awful high price to pay so users don't need to follow a specific convention.

As 37 Signals puts it flexibility is overrated.