Our experience with enterprise tagging terminology May 22, 2006
Posted by Steve in : enterprise, tagging, terminology / 2 commentsWe’ve been tagging (well, sort of – read on!) in our knowledge sharing product for quite a while now. I thought I’d share some observations about how our enterprise users have adopted tagging, and what problems have arisen. We’ve learned a lot and are applying these lessons to our next product.
Terminology
Our application allows publishers to choose a category in which new content will appear. Originally, each item could be published only in a single category, a legacy of our dependence on a Yahoo-like directory structure. A few years ago, after hearing from enough customers that this was too restrictive, we added the ability to put content into multiple categories. We retained the hierarchical aspects of categories, so parent topics could contain child topics, but gained the ability for those categories to overlap. Readers could even forward something to a new category rather than depending on the publisher to put it there. (Note: The specific term “category” is customizable; many of our customers have switched to using community or other phrases.)
At the time, I described this internally as moving from “content-location space” to “content-attribute space”:
Looking at it now, I’d call the right-hand drawing tag space. Ours wasn’t a folksonomy, because the category list was locked down, but it did benefit from the same distributed collaboration that emerges from tagging. People could now help organize information ( = “add tag”) regardless of the original author, or browse topic-based “slices” of the entire knowledgebase ( = “browse by tag”.) Even the user interface was fairly similar to today’s tagging services.
Adoption
People took to this new functionality very quickly. It was a natural extension given the strong parallels between category recipients and e-mail “distribution list” recipients. Between initial assignment of categories and the ability to forward, a lot of content began to appear in multiple categories.
Publishers loved the freedom of being able to drop information into as many categories as they could conceive might be relevant. Category owners and administrators could quickly pull a bunch of related content into their category, even if the publisher hadn’t been aware of it when posting. Most importantly, users’ favorite categories became much richer with the addition of all the new content, and trails to related categories were more easily exposed.
All of this probably isn’t any surprise – the benefits of tagging (or the “semi-tagging” we were doing) are pretty well understood. But there were definitely some downsides to our particular implementation…
Issues
As I’ve pointed out previously, readers naturally prefer to tag with their own terms. By forcing our users to use a canonical, company-approved set of categories, we made participation more difficult, and as a result only the most active (invested? engaged?) users participated in the process. This, in turn, slowed the emergence of “collective intelligence” from the network… It still happened given enough time, but required a lot more work than freeform tagging does to get the same effects.
There was also confusion surrounding security. While users approached categories as a new way to send content to multiple groups, categories still acted somewhat as “file folders” - in other words, as containers of content – for purposes of browsing, etc. Users therefore had certain expectations of categories, most notably that you could set permissions on a category which would protect all content in that category. As you can imagine, that’s difficult to support when content doesn’t really exist in any one category.
We resolved this by introducing a set of permission rules, focused on ensuring sure that private content did not get read by the wrong people - a major concern at a large company. Each rule helped resolve some aspect of visibility, for instance in the case that a piece of content is filed into both a “private” and “public” category. Combined, the rules were thorough, logical, and unfortunately, completely baffling to the typical end user.
For example, one unintended result was that content you had already read might disappear from your view after being forwarded into a restrictive category – an action intended to let more people see it, not less! There were plenty of other examples, so a dozen corner cases combined to produce a big mess. You know things have gotten too complex when testers occasionally file a bug against correct behavior…
We also saw several UI-related issues, but since this functionality was implemented several years ago, I’m not sure that the feedback is still relevant. For instance, it was difficult for first-time users to add categories by full name – AJAX typeahead controls, etc. should solve that. I’m not sure that modern bookmarking services have created the perfect UI yet either…
Lessons
First, the lesson we learned from this is not that we should have “just used tagging.” There’s no real evidence yet that simple tagging leads to widespread enterprise adoption. A free-form folksonomy may not meet the needs of our customers. And tagging’s pedigree as a method for organizing public content means that it hasn’t really been tested in a security-conscious environment.
What we did learn is that the expectations created by your tagging terminology matter just as much as the implementation. Should a “tag” specify a metadata value? A container/location? A recipient audience? A set of permissions? The answer is: any or all of these, depending on how you plan to portray tags to your users… which of course depends on what your users are used to. So it’s a bit of a chicken and egg problem, as adoption of any new concept is.
In re-thinking our approach to tags for our latest product, we’ve decided that it’s best to separate the terminology between personal (ie. not necessarily private, but self-focused) and public tagging activities. Personal/selfish tagging will follow a familiar folder-based metaphor, while public tagging in our system is really syndication based on semi-automatic relationships, which I discussed previously and will detail further in a future post. We’re going to use terminology appropriate to the respective metaphors – personal “folders” and public “channels” are what we’ve been using so far, rather than tags or categories.
Note that through our UI, this separation occurs without requiring users to make a huge distinction about whether they’re personally or publicly tagging something. We do want to leverage existing tagging habits when users already have them. But we also expect that most people will be tagging for personal benefit, and can count on semi-automatic routines to syndicate them publicly.
You’ve probably noticed that several companies are experimenting with tagging terminology, too. At Google, for instance, the preferred term for a tag seems to be label. I think it’s a good word because it clearly sets appropriate expectations that content is not actually contained by the tag. Unfortunately, our informal polling indicates that average users don’t yet have a good concept of this idea. To them, “folders” are containers to be used while browsing, and all other metadata is “keywords” to be used while searching. Still, Google has enough presence and clout that perhaps this will change. (Note: Google Notebook introduces a new term - notebooks as containers – but it sidesteps tagging by not allowing content to exist in multiple containers at once.)
Have you seen any other terms for tagging that you think work well?
Finally, we decided that there’s just no easy solution when integrating container-like behaviors into public tags, unless those behaviors are completely composable. Since permissions aren’t, we’re not going to try…
In part because we’re focusing tagging activities around personal use, we’re now able to avoid giving tags any special behaviors, such as access rights restrictions, approval requirements, etc. All of these will exist separately as explicit metadata on the content itself. However, we are going to leverage a typical tagging UI for these, whereby a single text entry field can add metadata that’s rich in meaning. In that sense, we’ve moved one step towards a OneBox interface in the same way that, say, 30Boxes simplified event input.
Hopefully this will all make total sense when I get a chance to show off our application! 
Meanwhile, are you facing similar issues? I’d be really interested to hear how you’re tackling them. And if you have specific questions, I’m sure I can think of some more lessons we learned…
