jump to navigation

Our experience with enterprise tagging terminology May 22, 2006

Posted by Steve in : enterprise, tagging, terminology / 2 comments

We’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…

Tags:

Cleaning up the tag soup May 18, 2006

Posted by Steve in : enterprise, tagging / 7 comments

In previous articles I’ve shown that “consuming” taggers prefer to use their own vocabulary, while “publishing” taggers have an incentive to match their audiences’ vocabularies. At the same time, the network benefits of social bookmarking depend on enough publishers agreeing upon a common vocabulary. Although these forces are somewhat in opposition, things work out pretty well for most topics. Equilibrium is quickly reached as everyone agrees on a few common tags.

But when it comes to new, complex, or very specific topics, tag-based solutions break down - everyone starts speaking their own language. For instance: what are the right tags to find content related to this blog? “Enterprise” is too broad; “tagging” encompasses too many applications; “delicious” is too application-specific (and misspelled mispunctuated, at that); and “social” + “bookmarking” isn’t a generally accepted term yet. Relevant searches end up requiring a complex tag intersection, which most tag search apps don’t handle very well.

This confusion results in huge variations in the way people tag things - or maybe vice-versa. What can we do to clean up the mess?

Getting past the tag mess (and making tagging palatable to a more controlled enterprise environment) starts with the recognition that for any particular piece of content, not every tag has the same value. If you want to encourage a certain subset of tags, expose tag values to publishers. Their natural desire to reach an audience means that they will gravitate towards the most valuable tags. But this doesn’t just mean showing a tagger the previous tags that people have used. Assuming “value” is based on whether this tag will help your audience find this content, then the tags that people are already searching for must be worth much more – even if fewer people are currently using those tags.

The idea of an open marketplace for keywords is already working very well — and very profitably — in a real-world application: Google’s AdWords program. Ad publishers choose the most appropriate search terms to advertise on, because they’re given very good feedback about the value of keywords with regards to their particular ad. (AdWords goes further, preventing tag spam by factoring in things like content relevance and click-through rates. These concepts may eventually help tag search too, but require a lot of control over how tags are being exposed to users.)

Note that what’s being searched for is not the only way to measure value – it’s just the most commonly available metric on the web today. In an enterprise scenario it really depends on the application in which tagging is integrated or exposed - in other words, the consumer’s day-to-day environment. For instance, bug numbers would have higher value when tagging a bug DB, while in CRM it’s probably account names that will help people find your content. The best tag valuation algorithm would factor usage data from many applications, supplement that with existing or desired corporate taxonomies, and finally integrate the resulting tags back into all those applications.

One problem is that for many kinds of newly published content, there may not yet be a lot of usage data. For instance, most conference organizers (semi-)blindly choose a canonical tag during the event, because search patterns don’t exist yet. Unfortunately, it’s really hard to guess at user behavior and it’s pretty much impossible to force it on a large scale. For every person that attended the conference, there may be 10 or 100 or even more who search for conference content after it’s over. Those people don’t know the suggested tag, so they choose their own way to search, and most likely they’re going to have to try several tag searches before they find the content – that is, if all event participants even managed to use the same tag. Depending on search behavior, there might not even be one right tag!

Some new services are extending basic tag search to address this problem. RawSugar is one great example: they’ve introduced tag clustering as a new way to browse tagged directories (specifically, blogs, but it seems like anything that can produce a well-formed feed would qualify.) I’m bullish on clustering, since we’ve successfully used it to produce automatic expertise profiles in our enterprise product. I have no doubt it will help tag search, but RawSugar faces an uphill battle. They need to get their cluster-based browsing in front of the users who are, for today, visiting applications written by competitors that are probably not amenable to integration. I think this solution may fare better in the enterprise, where app integration is the normal scenario.

There are two remaining solutions to the tag mess, assuming you’re sticking with standard methods of tag browsing: 1) re-tagging content later based on observed usage, and 2) tag equivalence (or at least tag migration.) #1 isn’t going to happen, so let’s focus on the more practical #2. What this means is that users can tag items with some original term, but if another term becomes more popular, the first term can somehow be declared equivalent to the new term, so searchers will find the intended content. Whether automatically applied or added manually, this equivalence can greatly increase the network benefit of a bookmarking application.

Applied generally, this can even solve another problem: the disparity between individuals’ vocabularies. Already, “tag clouds” can be studied to find people with similar tagging interests. Similar analysis can be applied to the tags themselves. There’s nothing that says public tags exist in the same “vocabulary space” as the ones an individual uses to tag his items. The direct correspondence between local and global tag spaces can and should be removed and replaced with indirect {user,tag}-to-{public term} relationships that are much more powerful. [Related: Alex Barnett came to a similar conclusion in February.]

The simplest form of relationship is, of course, the direct one that results when two people use the same tag. But there’s no reason to stop there. Relationships can be found between tags that often appear on the same items. Relationships can be forced by way of translation & dictionary equivalence. And there are many more ways to improve searches once you’re past the idea that public collections only contain items tagged with that exact term. With enough indirection, everyone can tag using their own terms, but still be found in searches for globally popular terms.

(Of course, this all assumes you disagree with Clay Shirky’s ideas on the exact meanings of tags, as I do. :) Otherwise you might be worried about assigning tag equivalence. Still, that could be factored into how you generate relationships.)

This level of indirection should be a basic requirement of any social bookmarking application, but it appears in surprisingly few of them. Today, del.icio.us offers “your inbox”, which lets you aggregate several users’ specific tags into a single feed. That’s a one-off that doesn’t solve the problem for multiple public collections. Some bookmarking sites, such as simpy, provide new concepts like public “Groups” which go part-way towards achieving this, but it still isn’t the standard for public tagging – you have to be invited into groups before you can contribute. Overall, the previously-mentioned RawSugar team seems to be making the most strides in this area.

Solving this problem is one of the goals of our own enterprise bookmarking application, so I’ll dedicate an upcoming post to our solution. I think this an area in which there is still incredible room to innovate!

So, to solve the tag mess:

Can you think of ways that these lessons could be applied to your favorite bookmarking service? Do you know of other services that are tackling this problem? I’d love to hear…

Related: tagging organization

Tags:

What are the personal benefits of tagging? (Part 2)

Posted by Steve in : enterprise, tagging / add a comment

The most common statement I read about the benefits of tags is that publishers should tag posts so they can be found more easily by searchers. I can see why people would think that, but I don’t really buy into it myself.

I’ve already mentioned that I rarely use tag search, so maybe I’m missing some hidden value. But my reasoning is this: if tag search were really working and delivering lots of click-throughs to web pages, wouldn’t there be more tag spam? It’s incredibly cheap to add any number of tags to your posts. Yet there’s no apparent problem on well-established social bookmarking apps like del.icio.us and in tag-trackers like Technorati. (Has Technorati introduced any advanced “PageRank”-like algorithms to keep spam out?) This can only be because tag search hasn’t been adopted by anyone but power users yet.

There probably is some search benefit around tagging “hot topics.” After a conference, product release, etc. you would expect to see a lot of activity around tags relating to that event. Use of these tags would increase for a while, and either establish a new common search term, or slowly fade out. But in this case, I’m not sure it’s the tags themselves that make such a difference – rather the date-ordering of tag search results probably helps the most. And overall, this seems like a minor benefit that’s only useful after tagging has already been generally accepted.

I don’t mean to completely dismiss tag search, but it doesn’t seem like a killer app that will gain enterprise adoption by itself, especially in the face of competition from regular search. So why else might publishers tag their content?

In my opinion, the real benefit is a counterpart to tag search: the ability to easily organize and publish collections of content. Instead of (or in addition to) using tags to be found in search, it’s possible to use them to push content to interested people through integration and syndication. While this may cause most readers to think of RSS feeds, that’s not the only way that data can be syndicated. In fact, it probably doesn’t even register in the enterprise yet - the most common form of syndication in today’s enterprise is sending documents and links in e-mail, a low-tech solution that works pretty well for sending single items.

When you need to publish a set of related content, though, it’s actually quite difficult to do. Sure, we’ve been using databases, content management apps, file shares, etc. for a long time to distribute collections of information. Maybe soon there will be larger enterprise adoption of blogs and wikis. But in all of these, the typical sharing model is to copy a bunch of content into the application (or create it there originally), and then send people there to find it. The user has to overcome a lot of barriers just to start a new content collection, much less keep it updated over time.

Everything changes when you’re able to easily add tags to content at its original source. The use of tags introduces a separation between content’s repository and the collections it’s in. Tags can be used to collect content from multiple repositories, just like a federated search engine indexes keywords across several sources. New collections can be created with no more effort than thinking of a new tag term. After the collection has been created, bookmarking services allow you to send entire sets of links, usually providing nice compact URLs to ease the process. Even when the feed is primarily designed for your own consumption, it can just as easily be shared with others should the need arise. Better yet, the collections keep updating as you continue tagging.

This can often be done without any special integration work, as long as repository content is addressable through an URL or something like it. But there’s no doubt that integration into the content’s native environment helps adoption, as evidenced by the number of bookmarklets and browser extensions used by frequent bookmarkers.

Even deeper integration is available through service APIs. For instance, a small plugin I wrote replaces links to del.icio.us tags with an inline list of the most recent articles I’ve tagged with that term.

In the end, whether or not users understand that they are creating “syndication feeds” by tagging, the unmatched simplicity of tag-based aggregation is a huge benefit to publishers! (I’ll address feeds in more detail in an upcoming post.)

Still, to reach a larger audience, you can’t count on always pushing. You have to figure out how to be where your potential readers are looking. Unlike a consumer’s tagging, there’s much more incentive for publishers to try to use a public vocabulary when tagging. Even if tag search doesn’t work so well yet, publishers are still much more likely to connect to users with similar interests via common tags. In fact, since people will use terms from their own vocabulary to browse and search, publishers should attempt to tag using the specific vocabulary of their audience.

This means not just using commonly accepted terms, but digging deeper into synonyms, misspellings, misunderstandings, and the like in an attempt to reach readers who might not even know those common terms. Unfortunately, this often leads to an incredible mess of tags, further diluting the value of tag search. Here’s how to clean up that mess!

Tags:

What are the personal benefits of tagging? (Part 1) May 15, 2006

Posted by Steve in : enterprise, tagging / 1 comment so far
Page [1, 2, 3, 4, 5] of this series:

As I mentioned in my previous article about social bookmarking, we’d like to ensure that the social aspects of our application achieve significant enterprise adoption, so we’re attempting to follow a lesson learned from del.icio.us: that personal value precedes network value. I’m hoping that others might benefit from our thoughts on value, or contribute new ideas, so I’m speaking them out loud here…
I don’t think it’s possible to state the value of tagging to a uniform “application user”, rather, it’s important to consider a full spectrum of participation roles:


(This image is from that excellent article, by Ross Mayfield)

To simplify things a little for this article and the next, I’m going to approach tagging from two perspectives – a consumer’s and a publisher’s – which cover the spectrum pretty well. In each case, I’ll try to isolate benefits that are immediate and specific to each particular role, rather than the more general “social” benefits everyone gets from sharing.

Benefits to consumers

So, first, what great personal value can “read-only” consumers get by tagging their bookmarks?

The most obvious reason for a bookmarker to tag is so that he can categorize and organize collections of bookmarks. Anyone who’s saved more than a handful of links can see the benefit, and quickly picks up the metaphor: tagging is like putting a bunch of items into a shared folder. Note however, that new enterprise taggers may take a bit of time to get used to the fact that items can be in more than one folder, especially if some of their folders (public tags) can contain items that they didn’t put there themselves! (In an upcoming article, I’ll talk about some specific challenges that we’ve faced over about two years of enterprise “tagging”.)

Several tag-as-folder patterns have emerged to store common collections: “save for later” tags, shopping lists, etc. These patterns will be just as applicable to enterprise users, and are great examples of user needs that haven’t yet been met by other applications, but can be easily built on top of the generic folder-ness of tags.

Many people also use tags as a way to summarize bookmark contents. Familiar with this usage on sites like Flickr, as well as any number of legacy apps with keywords or synopsis fields, they adopt key document phrases as tags. The end result is that the tag line of such entries often reads like a mini-abstract of the article. Tom Coates of Yahoo suggests that this method of tagging may be becoming more common, but I’m not sure that this practice is actually that useful. I see little return on the investment of extracting keywords, when search engines do a far better job of it. On the other hand, a quick analysis of my own tags suggests that I originally tended to tag this way, even if I don’t find benefit from it!

Another use that I’ve observed among more organized bookmarkers is the use of tags to store metadata where no specialized fields have been provided. I’ve seen tags that encapsulate authorship and/or location, company names mentioned in the article, referring connections (“via: whoever”), etc. Again, I haven’t yet found much value in doing this. It feels to me like exactly the kind of usage that only punishes you for not doing it 100% of the time, especially when a search index has already ferreted out most of those pieces of information. Perhaps not coincidentally, though, the heavy users of metadata tags tend to be librarians. They definitely know more about organization and recall than I do – maybe I’m just missing something?

Once a particular installation has built up enough of a bookmarking profile, social effects that were previously a long-term, group benefit may create immediate, personal benefits to new users. For instance, users adding bookmarks to a well-populated system can immediately receive similar item recommendations. As with folder-like usage of tags, this is a personal benefit that increases over the user’s lifetime of usage, as well as with the maturity of the system itself. This is also a distinct area of improvement for most social bookmarking systems, where the extent of “relatedness” is sharing a common tag. Better group-similarity analysis will make a huge difference in the next generation of social systems (more about this in a later post…)

Finally, I’ve seen some very interesting analysis of tag clouds that go far beyond the original uses of tagging. For instance, Jon Galloway has started using his metadata cloud as a way to discover trends in his own attention that he might not have otherwise noticed. Juice analytics does something similar. Have you come across any similarly ingenious applications that directly benefit the tagging consumer? Let me know!

One thing that the most useful of these reasons all have in common is that they allow the user to express tags using personal vocabulary. It takes a lot of work to settle upon a public vocabulary for any particular topic. As evidenced by endlessly recurring “what tag should we use for this?” conversations, the right terms might not even exist at the time of tagging! A purely selfish tagger has very little incentive to use common, group-accepted terms over words he uses every day. So one thing to assume while developing an enterprise app is that users do not want to be taught how to tag, at least not before they’ve gotten enough personal benefit to start accepting tagging.

Benefits to publishers

The next post in this series tackles the value of tagging to a publisher… Meanwhile, do you think I’ve missed any interesting uses of tags?

related: tagging benefits

related: tagging visualization

Tags:

New Google products and their impact on the enterprise May 12, 2006

Posted by Steve in : enterprise, search, bookmarking, google / add a comment

It’s probably worth taking a quick break from enterprise del.icio.us and mentioning some recent “products” that are very relevant to enterprise bookmarking and information sharing:

Google Search History

Since early 2005, Google has (optionally) been automatically saving all of your searches, if you’re logged in to a google account (gmail, etc.) Automatic saving provides desktop-search-like “Web History” indexing to the internet product… it also provides them with all sorts of data for later use in personalization features. And there’s one other side effect: it gives you an easy way to gather and annotate results from your past searches. Items can be starred, after which they will appear in a Bookmarks section, and they can be tagged with keywords. I have read that search history can also recommend similar pages, but this isn’t showing in my history. Overall, the implementation of this feature is actually pretty slick, but not well promoted so I doubt many people are using it… yet.

Google Notebook

This feature is taking direct aim at del.icio.us and friends. After notebook is enabled, all Google.com search results pages have a “Note this” link that allows you to bookmark them with a single click. These links are saved in Notebooks, and notebooks can be exchanged with other people, but I don’t believe they can be tagged per se. Still, this is an important addition because Google has recognized that people are basically creating collections when they bookmark, and they’ve provided tools to do so without the complication of tagging. Even more important is the browser integration that Notebook offers through firefox and IE plugins. It complements Search History by providing a way to gather and annotate results directly from the search UI and result pages, saving you the step of going into the History. I don’t know whether the stars from search history will eventually be consolidated with notebook’s notes.

Google Co-Op

This one is sort of the wildcard of the bunch. Co-Op consists of two parts: the ability to create and/or subscribe to OneBox templates, and the ability to “label” websites with tags defined in those templates. This is a very ambitious project which will result in thousands of new OneBox templates being written to easily expose information in lots of sources; the main winner will be content producing sites who can expose their interface right at the top of Google’s search results!

This post by Philipp Lenssen does a good job clarifying what’s going on, although in my opinion it is slightly inaccurate in that he doesn’t make the distinction between what happens out of the box vs. only after subscribing, and he also overstates how much search federation and clustering is really happening.  Also, labeling is clearly not an end-user play when you have to upload XML files to tag something, so for now it exists only as a way to refine a OneBox template.  [* see below for my response…]

There’s already a lot of progress towards this in the enterprise product; in fact it seems that Co-Op may have been based on that work, with the subscription feature having been added to prevent spam and OneBox overload. My guess is that there will have to be at least one overhaul of the subscription feature before CoOp reaches popular use - it’s already being overrun with junk. This isn’t a concern in an enterprise product, where all users can be automatically subscribed to appropriate, sanctioned OneBoxes.

The takeaway for enterprise use:

Just as Co-Op emerged from the enterprise product, there’s no doubt that the other two features will be integrated into their enterprise and desktop search products, and probably sooner rather than later. Having added all three, their enterprise or desktop search product would make great inroads into the personal benefits provided by an “enterprise del.icio.us”, with the added advantage of that functionality being directly available in search – no need to switch to a new application.

Anyone building an enterprise bookmarking application is on a direct collision course with Google… (and not just bookmarking)

* Updated - here is my response to Philip’s Co-Op article, extracted from his comment section:

Hi Philip, I think you’ve done a great job of explaining the complex Co-op product, but there are some distinctions I feel could be made clearer:

First, Co-Op is basically two components –
1) the ability to build a OneBox element, and
2) the ability to label URLs in support of clusters
But when it comes down to it, these are really the same thing… (more in a bit)

Second, Co-Op is visible in two ways –
1) What you will see out of the box, and
2) What you get after subscribing
It’s important to make this distinction because frankly, it will be a very tiny % of Google users who will ever be subscribing to CoOp templates, given its current form.

The ability to make a new OneBox is really powerful and will be very helpful to sites with lots of content – you can basically expose your entire site through an element at the top of Google! But there are two huge limitations that will keep this from popular use: #1 – it’s not really search federation, since as you’ve demonstrated in your example you basically have to send over your entire entity list in the template XML file. This means you have to do scheduled updates, etc. #2 – No one benefits without subscribing, and I suspect only very techy people will subscribe to things for now. There are some things they can do to make this easier for end users and I’m sure it will improve over time, but right now it’s targeted squarely at high-volume sites.

Clustering and labeling is just junk right now. It’s basically a specialized type of OneBox which allows you to define a topic & vocabulary, and then support it with XML labeling files. This isn’t “tagging” in the popular sense, as again is not targeted at end users. Rather it is done this way so that the OneBox “moderator” (whoever created the cluster) can distribute his work among many publishers. It also faces the #2 problem above – no one will benefit from clusters until they subscribe. (At least in this case they can automatically enable certain clusters for all users after they’ve been reviewed for quality)

So I guess I would have chosen different words than your bullet list, explaining how this will help publishers build OneBoxes & specialized clusters, rather than mentioning the masses, who won’t yet benefit much. (I do think the feature will improve over time of course!)

related: google search history

related: google notebook

related: google coop

Tags:

What’s the personal benefit of social bookmarking?

Posted by Steve in : enterprise, search, bookmarking / 5 comments
Page [1, 2, 3, 4, 5] of this series:

One of the common claims I hear about the value of bookmarking sites like del.icio.us is that “bookmarking benefits the user first.” It’s often said in support of the Del.icio.us Lesson (even if they don’t use that particular term) and the corollary is that after people find enough value in personal bookmarking, they will go on to share information, get recommendations, etc. The individual benefit, in this case, is “re-findability.” Since I’d like to make sure our product reaches widespread enterprise adoption, I’m trying to make sure we have a good personal use case before tackling the social part. And I’m curious: does social bookmarking really offer the benefit of re-findability?

The reason I ask this is because I never use tag search. It’s partially because tag search often doesn’t combine with regular search. Del.icio.us doesn’t index the contents of pages, just the title, tags and notes you’ve saved. This means you have to remember exactly how you tagged something; that’s not always an easy task (and it’s probably worse for a beginning tagger, who likely tags with a few very general tags.)

Even assuming a service that stores and indexes full page content, such as furl or Yahoo MyWeb, I still have a more reliable helper when finding an article I know I’ve seen before: I turn to desktop search. It almost always returns the right thing much faster than I could have found it on del.icio.us, and searches through more content repositories. Better yet, it turns up things that I hadn’t thought to bookmark yet… This is incredible return for zero investment.

If tag search doesn’t work well for me yet, perhaps the list of saved items improves my ability to re-find articles? I’ll admit that I originally joined the service in search of a way to easily synchronize bookmarks between my work and home machine - clearly a personal benefit. However, when I look at my own habits since adopting del.icio.us, I find that I don’t ever use my saved links as bookmarks. For instance, there’s a webpage with a great CSS guide that I revisit a lot. Yet I don’t get there by going through my del.icio.us “css” tag. Why not?

First, getting to my saved links and clicking through takes longer than I’m willing to wait for a very common operation. This could probably be alleviated with a browser extension, although the best Firefox plugins I’ve found don’t solve this problem well yet. The other problem is that I’ll often save new CSS links, pushing my favorite link further down the page, until eventually it’s on page two - at which point it might as well not exist any more. ;) This too could possibly be prevented through some sort of new “sticky” feature in an extension. But really, in the context of a potential enterprise application, it’s a bit optimistic to imagine many people using Firefox, much less extensions.

So if social bookmarking a) isn’t better than desktop search for (re-)finding articles, and b) doesn’t offer the best way to visit my favorite links, then why am I such an active bookmarker? Because I’m often marking up collections of items, usually without highlighting any one article over the others. If you look at the use cases for furl, for instance, you’ll see people saying basically the same thing. Sometimes I’m making the list for myself, more often I’m doing it with the intention of sharing. Sometimes the list is even being automatically created for me, which I’ll talk more about in a later post.

As I see it, this is (part of) a need that everyone has, which isn’t already best served by browser bookmarking or desktop search, and that’s what makes it work learning a new behavior and/or new application. So I don’t see our application as being for social bookmarking as much as it is for social list-making. To me, such an app isn’t really tasked with re-finding, except in the general sense of being able to survey all the items I’ve collected in a particular list. Maybe this is a bit of a very fine distinction… but in my next few posts I’ll explain why I think it’s an important one.

First, I’m looking for feedback. How do you use social bookmarking sites? Have I overlooked a way in which bookmarking benefits you personally?

Then, in my next post: does this really require tagging?

Tags:

Content roles and the Del.icio.us Lesson May 10, 2006

Posted by Steve in : enterprise, tagging / 3 comments
Page [1, 2, 3, 4, 5] of this series:

I’ll soon toss out a lot of my own ideas about how the use of social bookmarking — any or all of the features of del.icio.us, plus more? — could benefit an enterprise. But as I mentioned in my previous post about adoption, creating a seemingly beneficial product doesn’t guarantee that it will actually be used…

A lot of people point to del.icio.us as a great example of how to quickly jump-start adoption, by leveraging the work of early users of the site to make the app increasingly attractive to new users. At first, people were using the system to store their personal bookmarks, then tagging them to organize them into their own taxonomies. Once enough people started tagging, a kind of collective intelligence emerged from the “tag soup”, automatically creating communities around certain tag keywords, which in turn attracted more users (or so it’s said - I’ll comment in a later post about this.)

This is the kind of thing that can only work if an app is really “sticky” even for the first users of the system. And it’s true, you can benefit from use of a social bookmarking system without needing anyone else to participate, but each added participant makes the whole system more valuable. This recognition that personal value precedes network value is now commonly being referred to as the “Del.icio.us Lesson.”

So if you’re hoping for a similarly viral spread of your application, it’s a no-brainer to check any new application for immediate personal benefit to its users. But as obvious as it may be in hindsight, it’s very easy to misapply this lesson during design. After all, most products claim “individual benefit” to some degree, are they all going to take off so quickly? Before we can count on the same kind of feedback cycle working, we at least need to know: who are the individual users, and how will they benefit?

We’ve been tracking participation metrics in our product for over six years. Our first version was a web application with millions of monthly visitors. The more recent enterprise version of our product has been deployed to thousands of employees at multiple F500 companies. Interestingly, both versions showed very similar relative levels of participation: what we found was that for every person who visits, about one in ten sticks around to read more; about one in ten of those signs up; about one in ten of those starts contributing content… and so on. Out of the far end of this diminishing pipeline emerges a community of very active participants who continually add new content throughout the application’s entire taxonomy, which in turn validates the application as a useful source of information for new visitors.

Perhaps that’s why this interesting post by Bradley Horowitz of Yahoo was no surprise to us! His view of Yahoo community content properties (including del.icio.us) is that their potential for success lies in their ability to leverage the work of a small percentage of users (the “creators”) to provide benefit to the rest (the “consumers”). He even claims approximately the same relative participation proportions that we observed, that one in ten users take the next step towards becoming creators. Note that this is not exactly the same as the del.icio.us lesson, but it can be assumed that the users have to first find personal value before they make the effort to advance through the pipeline.

A similar distribution appears in Ross Mayfield’s post about the power law of participation. He presents a great list of the roles in a typical collaboration app: Reader, Commenter, Subscriber, Writer, Moderator, etc. versus the exponentially increasing amount of “engagement” required. I’m not sure every one of them is positioned properly on the chart (and I disagree that this is related to Chris Anderson’s Long Tail - not every curve has a long tail!), but the article is one of the best I’ve read about this phenomenon.

This is a really useful way to think about the users of most social applications: it’s really about scaled levels of content production. How do you encourage viral effects in social sites? Obviously, benefiting users at the more common end of the distribution would directly help the most people! But if your application depends on new user-generated content then it’s important to tend to the publishers, thus indirectly benefiting more users. Or better yet, reduce the effort required to for users to move up the curve.

Does enterprise bookmarking and tagging depend on user-generated content? I think many proponents of del.icio.us and its Lesson would claim that personal bookmarking and tagging is its immediate individual benefit, and that since most of its content is links to external resources, del.icio.us can afford to bypass the content-production end of the spectrum. In my next couple of posts, as I talk about specific features and benefits, I’m going to try to show that none of that is true…

related: del.icio.us lesson

related: collaboration roles

Tags:

Enterprise adoption of social bookmarking and tagging May 4, 2006

Posted by Steve in : enterprise, tagging / add a comment
Page [1, 2, 3, 4, 5] of this series:

Assuming enterprise del.icio.us to be a useful application, we’ll still face some challenges in getting corporate adoption.

When using the internet at home, we’re used to web sites as the format for public information sharing, paired with email for private or limited groups. More than that, we’re used to using different web sites depending on:

As a result, it hasn’t been very hard for us to adapt to using one or more social apps, such as del.icio.us and flickr. When we see a website we like, we just click on a bookmarklet (or increasingly likely, a Firefox extension) and save it away.

When we’re at work, on the other hand, there are usually only one or two kinds of public sharing:

These present huge barriers to adoption, both technical and behavioral.

First, unlike the web where most data can be retrieved from an URL, people in an office typically work with data in dozens of repositories. Each of these has its own addressing scheme, that is if data can even be referenced at all from outside the app.

Where data can be shared, it’s not always seen as a good thing - enterprises put a lot of effort into controlling access to data. One of the most common questions we get about our knowledge sharing application is what can be done to prevent information from being shared with the wrong people!

Finally, people - especially non-techies - are just not interested in adopting a new destination site or separate application, probably because their experience indicates that this results in more work. The reality is that a new application will not be widely adopted unless it integrates into the current working process (or better yet, directly into their current applications), and appears to make that process easier.

Sure, there will always be some people who take to anything new, but most people will ignore it as yet another mandated time-waster. Any new app will have to show value with, let’s say, only 1% of its potential audience actually using the app. Where some new apps have found greater traction, notably search and team/project portals, it’s usually because they’ve significantly simplified something that employees are already doing.

Worse yet for someone who wants to build this application, there’s no ad-revenue supported business model for the enterprise ;) Enterprise customers will typically put the application through its paces with a limited pilot audience, and expect to see some measurable result on the bottom line.

So, if we’re going to create an enterprise bookmarking application, and want to see adoption, we’ll have to overcome, at least:

  1. the natural resistance to new applications
  2. the variety of existing technologies, platforms, and data formats in an enterprise
  3. the differing process, taxonomy, and security requirements of any company
  4. the need to demonstrate clear “ROI”

In my follow-up posts I’ll present my own ideas about how these can all be addressed through social bookmarking and tagging, and why it’s not “enterprise del.icio.us”. At least, not exactly…

(But first, I’m off to LA for a few days - I’ll pick up after I get back)

related: enterprise adoption

Tags:

Enterprise del.icio.us May 2, 2006

Posted by Steve in : enterprise, tagging / 2 comments
Page [1, 2, 3, 4, 5] of this series:

Judging by these recent articles, among others, there’s a growing interest in what might be called “enterprise delicious.” I’ve been working on something like this for a while, so I’m excited to see this ;) However, if a recent discussion at Seattle MindCamp was any indication, there isn’t consensus about exactly what this app might be. So before discussing how to create an enterprise del.icio.us, it’s probably helpful to define a few things, starting with:

What is “del.icio.us”?

I assume you’re already familiar with the site itself ;) But there are many aspects of delicious that one could be talking about copying:

(We might also be hoping to duplicate the active community of taggers, without which some of the previous items would not be as useful. The social and community aspects of this app might even be more important than the technical ones. Although the design of del.icio.us addressed problems with previous, failed bookmarking attempts, don’t underestimate the effects of early adoption by influencers like Jon Udell on its popularity. But how to create a community is another topic… I wish I knew more about that!)

That said, re-creating del.icio.us exactly is probably not what we’re talking about, anyway. So for the rest of my posts in this series, to disambiguate from the specific implementation of del.icio.us, I’ll talk about “enterprise tagging” and “enterprise bookmarking” instead. I’m pretty sure those aren’t the best terms either - but I’ll explain that later.

related: enterprise delicious

Tags: