jump to navigation

Tagging vs. Searching May 23, 2006

Posted by Steve in : tagging, search / 1 comment so far

Two recent articles have helped me reframe my thinking a little regarding the relationship between tagging & search.
Quoting Tony Karrer quoting me:

I personally have found that because I’ve switched to Yahoo MyWeb that has full-text search across my bookmarked pages, I’ve come to use tags mostly to represent two things:

  • Actions - I tag items with “blogthis” if I plan to come back an write it up in a blog.
  • Sharing - I tag items that I plan to share with a specific tag so that others in my group can find it.

So for me, it’s not quite the folksonomy effect that most people talk about, but based on these articles, I’m starting to think that’s what other people are finding as well.

And from Bill Ives’ Where Tagging Works and Where Tagging Doesn’t Work:

If I want to search on a key word, I will still go to Google as the most efficient way. If I have the time to go exploring through multiple links and see the interrelations between key words, I might go to del.icio.us. However, if I want to set up a way to store and share links on a particular topic, I will use del.icio.us which I have done already in co-authoring an article.

A lot of people (myself included) have tended to more or less equate tagging with “del.icio.us”. Delicious doesn’t search well, and google doesn’t tag well. That creates some kind of artificial distinction between “tagging” and “searching”. As a result, people get distracted trying to demonstrate the (re-)findability value of social software (perhaps because search is so generally useful that impact on search has become the easiest measurement of value?)

But when you use a service like Yahoo MyWeb the two are no longer so separate. That scenario better demonstrates the (IMHO) best uses of bookmarking/tagging:

Search benefits from these but (in my opinion) that really isn’t the intended purpose of tagging. And search isn’t the only point of integration that will benefit from the addition of social features…

Tags:

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:

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: