"The Wisdom of Crowds" is one of the driving principles of Web 2.0. The idea, explored in James Surowiecki's influential book, is that decisions made by large numbers of people together are better than decisions that would have been made by any one person or a small group. This principle has powered the wide adoption and success of tools including including Google, collaborative filtering, wikis, and blogs. One common technique, following the Wisdom of Crowds principle, is the use of ratings. The hope and expectation is that by enabling large numbers of people to express their opinion, the best will rise to the top. In recent years, rating techniques have been put into practice in many situations. The learnings from real-life experience have sometimes been counterintuitive and surprising.

The failure of five-star ratings

Many sites including Amazon, Netflix, and Yahoo! used five-star ratings to rate content, and this pattern became very common. Sites hoped that these ratings would provide rich information about the relative quality of content. Unfortunately, sites discovered that results from the 5-point scale weren't meaningful. Across a wide range of applications, the majority of people people rated objects a "5" - the average rating across many type of sites is 4.5 and higher. Results from YouTube and data from many Yahoo sites show this distribution pattern. Why don't star ratings provide the nuanced content quality evaluation that sites hoped for? It turns out that people take the effort to rate primarily things they like. And because rating actions are socially visible, people use ratings to show off what they like.

How to use scaled ratings effectively

So, is it possible to use scaled ratings effectively? Yes, but there needs to be careful design to make sure that the scale is meaningful, that people are evaluating against clear criteria, and that people have incentive to do fine-grained evaluation. Examples of rating scales with more and less clear criteria can can be found in this Boxes and Arrows article - the image from that article is an example of a detailed scale. There are tradeoffs between complexity of the rating criteria and people's willingness to fill out the ratings. Another technique to improve the value of scaled ratings is to weight the ratings by frequency and depth of contribution, as in this analysis by Christopher Allen's game company. This techniques may be useful when there is a relatively large audience whose ratings differ in quality.

Like

The simpler "thumbs up" or "like" model, found in Facebook and FriendFeed has taken precedence over star ratings systems. This simpler action can surface quality content, while avoiding the illusory precision of five-star ratings. The vote to promote pattern can be used to surface popular content. This technique can be used in two ways - to highlight popular news (as in Digg) or to surface notable items in a larger repository. Several considerations regarding the "like" action: this sort of rating requires a large enough audience and frequent enough ratings to generate useful results. In smaller communities the information may not be meaningful. Also, the "like" action indicates popularity but not necessarily quality. As seen on Digg and similar sites, the "like" action can highlight the interests of an active minority of nonrepresentative users. Or the pattern can be subject to gaming. Another concern is the mixing of "like" and "bookmark" actions. Twitter has a "favorite" feature that is also the only way for users to bookmark content. So some number of Twitter "favorites" represent the user temporarily saving the content, perhaps because they disagree with it rather than because they like it! Systems that have a "like" feature should clearly differentiate the feature from a "bookmark" or "watch" action.

The risks of people ratings

Another technique that sites sometimes use, in the interest of improving quality and reliability, is the rating of people. Transaction sites such as Ebay use "karma" reputation systems to assess seller and buyer reliability, and large sites often use some sort of karma system to incent good behavior and improve signal to noise ratio. The Building Reputation Systems blog has a superb article explaining how Karma is complicated. The simplest versions don't work at all. "Typical implementations only require a user to click once to rate another user and are therefore prone to abuse." More subtle designs still have an impact on participant motivations that may or may not be what site organizers expect. "Public karma often encourages competitive behavior in users, which may not be compatible with their motivations. This is most easily seen with leaderboards, but can happen any time karma scores are prominently displayed." For example, here is one example of karma gaming that affected even in a subtle and well-designed system.

Participant motivations, reactions, and interactions

When providing ratings capabilities for a community, it is important to consider the motivations of the people in that community. In the Building Reputation blog Randy Farmer talks about various types of egocentricand altruistic motivations. Points systems are often well-designed to support egocentric motivations. But they may not be effective for people who are motivated to share. Adrian Chan draws distinctions between the types of explicit incentives used in computer games, and the more subtle interests found in other sorts of social experiences, online and off. People have shared interests; people are interested in other people. The motivations come not just from the system in which people are taking these actions, but from outside the system - how people feel about each other, how they interact with each other. In a business environment, people want to show off their expertise and don't want to look stupid in front of their peers and superiors. They may want to maintain a harmonious work environment. Or in a competitive environment, they may want to show up their peers. These motivations affect the ways that people use ratings features as well as how they seek and provide more subtle forms of approval, like responses to questions in a microblogging system. Thomas Vander Wal talks about the importance of social comfort in people's willingness to participate in social systems, particularly in the enterprise. People need to feel comfortable with the tools, with each other, and with the subject matter. The most risky form of ratings, direct rating of people, typically reduces the level of comfort. Depending on the culture of the organization and the way content rating is used, content rating may feel to participants like encouragement to improve quality, like a disincentive to participation, or like an incentive to social behavior that decreases teamwork. Even with good intentions and thoughtful design, the results may not be as anticipated. In that case, it is important to monitor and iterate.

Scale effects

The familiar examples of ratings come from consumer services like Amazon, Netflix, and Facebook, with many millions of users. With audiences as large as Amazon's, there are multiple people willing to rate fairly obscure content. In smaller communities, such as special interest sites and corporate environments, there are many fewer people: hundreds, thousands, tens of thousands. While the typical rate of participation is much higher - 10-50%, rather than 1-10%, that is still many fewer people. With a smaller population, will there be enough rating activity to be meaningful. If an item has one or two ratings, what does this mean? Smaller communities need to assess whether the level of activity generates useful information.

Summary

Ratings and reputation systems can be very useful at surfacing the hidden knowledge of the crowd. But their use is not as simple as deploying a feature. In order to gain value, it is important to take into account lessons learned: * Think carefully about the goal of the ratings system. Use features and encourage practices to achieve that goal * Use an appropriate scale that addresses the goal * Consider the size of the community and the likelihood of useful results * Consider the motivations and comfort level of the community and how the system may affect those motivations and reactions Then, evaluate the results. The use of a rating system should be seen not like a "set and forget" rollout, but as an experiment with goals. Goals may include quantitative measures like the volume of ratings and the effect on overall level of contribution, as well as qualitative measures such as the effectiveness of ratings at highlighting quality content, the effect on people's perception of the environment, and the effect on the level and feeling of teamwork in an organizational setting. Be prepared to make changes if your initial experiment teaches you things you didn't expect.

For more information

The Building Reputation blog, by Randall Farmer and Bryce Glass, is an excellent source of in-depth information on this topic. The blog is a companion to the O'ReillyBuilding Web Reputation Systems. Other good sources on this and other social design topics include: * Designing Social Interfaces book and companion wiki, by Christian Crumlish and Erin Malone. * Chris Allen's blog * Adrian Chan's blog

• |
• Permalink

A few weeks ago, Gabe Wachob and I attended a meetup at Google HQ in Mountain View about Enterprise OpenSocial. It was a good time to take stock of the progress of OpenSocial in the Enterprise.

Where we started

Last Fall, when we launched Socialtext 3, we made a big bet on OpenSocial, a standard designed to make application functionality run across multiple websites. With hundreds of thousands of Google Gadgets, a developer base as wide as the internet, and a straightforward model for adding new ones, OpenSocial appeared to be a major advance over proprietary tools for creating extensions, and over heavier-weight standards that had relatively low adoption.

From beginning, Socialtext bet our company on the adoption of Web technical and social architecture in the enterprise, and OpenSocial looked like the next step. We used the Gadget container as the base for our Dashboard module, which lets individuals personalize and administrators customize a tailored interface for collaborative work. Other layers of the OpenSocial standard, including OAuth, the social graph and profile representations were less easy to fit into an enterprise environment. We chose to wait until there was more to build on in these areas.

Widget adoption


For Socialtext, the use of widgets (as we call them, following the common industry terminology) has been a big success. Customers - including large enterprises - have developed their own OpenSocial gadgets to provide corporate data for business users, in the context of their collaborative workflow. Customers are using a wide variety of available widgets. When customers are interested in some small tool, chances are really good there's a widget available for it.

State of the industry: all about Gadgets

The meeting had representatives from Google, IBM, Cisco, SAP, Oracle, Atlassian, Afresco, Exo, and Lockheed Martin. As with Socialtext, the bulk of the OpenSocial development in the enterprise to date centered on the use of the standard and framework to develop widgets for business dashboards. The alternatives are JSR-168, the Java Portlet standard, and SharePoint web parts, with custom development within the SharePoint stack.

Regarding gadget development, there was a lot of discussion about standards conformance and portability. There was discussion about developing a conformance suite (including test widget, backend, rest api implementation), in conjunction with the upcoming 1.0 of the spec (the next step was discussion on the OpenSocial mailing list)

There has been little adoption of other aspects of the stack, but a lot of interest. At the the meeting, we discussed aspects including: activity streams, friend representation, authentication, authorization.

The conversation centered on changes to OpenSocial that will make it a better fit for the enterprise.

* OpenSocial is planning to incorporate the ActivityStrea.ms standard to represent activity. The standard has a well-developed draft, and has already been implemented by Facebook, MySpace, Windows Live, and Opera. An important next step there is a JSON representation of ActivityStrea.ms content. The Enterprise group agreed to have representation in ActivityStrea.ms (disclosure, that's Ryan Boyd of Google and me).

* The definition of "friend" was updated to make it clear that it supported relationship definitions that make sense in the enterprise. The language about the "friend" representation the standard covered the symmetrical relationships that are common in consumer applications such as FaceBook and MySpace, and business applications that deal with loose ties, such as LinkedIn. But the symmetric friend model makes less sense within the enterprise. What does it mean to ask to be friends with a corporate VP, or for your boss to ack to be friends with you? The asymmetric model used by Twitter, where each individual chooses people to follow, to manage their own attention. It wasn't clear to the folk at the meeting - including the people from Google, that the Friend definition could actually be used to cover the asymmetric friending suitable in the enterprise. We updated the definition to make it clear that asymmetric friend lists were acceptable within the standard.

* Single Signon and Security. Security and trust models are not well agreed upon or understood by the vendors. There was lack of shared understanding about how or whether to use OAuth, and how authentication and single signon might work with a multi-layer model including gadget contents, container, application server, and corporate directories. In particular, there was a lot of discomfort with the assumption that the container (server side) could hold tokens for widgets to use to access external apps on behalf of a user. One person from Cisco said that they could basically not do that at all. The next step is for the conversation to continue on the OpenSocial mailing list.

* Intergadget communication. There was a fair amount of interest in intergadget communication, in particular the relationship between work done by the OpenAjax alliance and Google's work on pubsub. Mark Weitzel of IBM has the ball to submitting a spec proposal on this topic.

* Other technical development. There are ongoing development efforts with technologies such as Google secure data connect (which can be used for tunneling through firewalls), Shindig (the opensource server and client reference implementation of OpenSocial), and Caja (sandboxed JavaScript). The next step is for Chris Schalk of Google to arrange webinars on SDC, Shindig, and Caja development.

* Web standards are gaining adoption in the enterprise, and more information is needed for enterprise developers about the benefits and options available to them. The group took on a task to write a White Paper on OpenSocial in the Enterprise (Disclosure: Gabe Wachob is one of the authors)

The Enterprise developer perspective

In a room full of vendors, the most interesting presentation was Shawn Dahlen and Chris Keohane at Lockheed Martin, about how they were actually rolling out OpenSocial as part of Enterprise 2.0 initiatives in their organization.

Dahlen and Keohane reported on some very interesting learning experiences. The main lesson was that one size does not fit all. The initial strategy centered on SharePoint, but they found in practice that SharePoint is good for group document management and little else. SharePoint platform development turned out to be time-consuming and resource-intensive - Gadgets were a lower-cost, platform-indepentent way to extend a shared platform. Policy also needs to be tailored for the group and the use - the HR department did not want its employees to create sides, but the IT and R&D groups strongly encouraged employee-generated sites and content. Since one size does not fit all, they need lightweight solutions that tie multiple systems together with portability.

Meeting Notes

Meeting notes taken by group members at the session can be found here:



See you at Enterprise 2.0

I'll be talking about OpenSocial in the Enterprise at the Enterprise 2.0 conference coming up in November, and hope to see you there!

• |
• Permalink

Socialtext customers have recently been asking us our thoughts about Google Wave. It is still in the lab. What the world saw in May was a demo, not a product, and Google has been upfront about that. Google Wave represents a bold experiment at mashing up real-time, messaging, and document models into new forms of communication and collaboration. The way these models are blended could pose significant issues for user understanding and adoption.

What is Google Wave? Over the last decade, wikis, blogs, social networks, social messaging, social sharing apps, Google docs and other tools have been providing lighter weight, faster vehicles for collaboration and communication that the old lumbering battleships, office documents and email. Now Google's Wave is a torpedo aimed at the battleships. Google Wave is based on a powerful technical concept, using a realtime chat protocol and stream model as the foundation for communication and collaboration applications. For these reasons, Google deserves a lot of credit for pushing innovation, rather than simply cloning the old models using servers in different closets. Fundamentally, Google Wave is technology-driven innovation. And Google Wave raises some pretty large questions about the cognitive and social models that people will need to understand and use Wave-based tools.

Conceptual Model The first big set of questions relate to the conceptual model. Wave attempts to mash up email threads, documents, and streaming communication. Each of these is familiar and not that hard to understand. The combination seems a bit mind-bending.

Email and forums are clunky in many ways, but they mirror conversational exchanges in an understandable way. Albert says something, and Betty replies. However, when replies are interspersed between paragraphs, and the conversation digresses, it can get difficult to follow. Wave uses a collaborative document-like model to make the changes visible in real time. This is cool and clever. It also needs a rich combination of social conventions and features to not get completely incomprehensible. Communities using wikis rely on rich social conventions and gardening tools to dispense with the need for inflexible pre-defined workflows. Wave is a toolset with even more flexibility than a wiki, with even more interactive content. This poses even greater challenges to help people understand how to use it and be productive.

The model of time has perhaps the greatest potential for confusion. In an email or forum thread, the latest contribution appears at the top of the thread. In a document, including a collaboratively edited document, there is a "face" to the document that appears as a working model of a final version. In a chat room, the latest comments appear at the bottom of the screen. In a rich "Wave", it's harder to tell which items in the wave are newer, older, more or less definitive, without scrolling through the whole process from the beginning. It is easy to imagine getting seasick.

Another conceptual innovation is "replaying" a wave. In the conventional model, there are known techniques to reflect the current state of understanding. When there are comments interspersed between paragraphs in email/forum threads, it can be difficult for newcomers get the gist of what has occurred. But there is a time-honored way to bring people up to speed - summarize the conversation to date. The summary has a social purpose, too, it steers the discussion toward a state of current understanding. A document or PowerPoint presentation can look deceptively finished, and close off potentially warranted conversation. A document is an artifact that reflects the end of a collaborative process. But a document can also be summarized and skimmed.

The presenters crowed, and the audience cheered, when the demonstration showed new participants using "playback" to recap a wave to date. But this seems like world's most inefficient way to get up to speed - to understand the end result of a conversation, you need to spend nearly as much time as the initial participants did in getting to that point. A streaming audio/video/screencast presentation, or a realtime chat, can be quite rich, and can be played back, but it isn't skimmable or summarizable. It's not clear that introducing that model to summarizeable documents and threads is a great thing.

My biggest areas of doubt about the Google demo in particular is that in some ways the hybrid combines the worst traits of its parents. Does the result have hybrid vigor or mutant weakness? What mental models are needed to understand this psychedelic blend of realtime, threaded, and document content?

Missing social model The second set of questions relates to the social model. The Google Wave demo truly begged a large number of questions about social models for wave-based tools. The demo seemed to use a fairly primitive concept - an individual's address book that lets that person add a new person to an email thread.

As someone involved in designing social models for tools used by organizations, this model is an intuitive way to start, but does not go very far. First of all, who has the ability to add people to the conversation? Is it everyone, or only the person who created it? Can invitation be delegated? Can a person add himself or herself? Do these permissions vary by wave? What about existing group and networks? In social sharing tools like Facebook, sharing a message or object shares it with one's social network (or a defined subset). Twitter, sharing is easly visible to followers, and visible with a little more effort by everyone. In organizations, there are pre-defined groups (say, the marketing team) that one might want to share with. The differences between these models make a vast difference between how the tools are used and what they are good for.

Another issue is social scale. Adding people and making interspersed comments could be intuitive in small groups, but could easily get confusing or chaotic in large groups. Long ago, Roberts Rules of Order were invented to facilitate orderly conversations with large groups of people to debate contentious topics. Group blogs and forums have developed reputation and rating tools to address the signal to noise ratio on large groups. What sorts of rules, tools, and processes will be needed to have socially effective communication and collaboration in larger groups when Wave is used in the world?

What the world saw in May was merely a demo. The Google team was up front about the state of affairs. They weren't doing FUD-style theater claiming to have already created a completed application to scare competitors and stop other developers in their tracks. They were describing a prototype application built on a new platform, and encouraging developers to explore and extend the concepts they demonstrated.

Next Exploratory Steps. The reality of open-ness has not yet lived up to the promise. In order to join the developer program, developers need to tell Google exactly what they plan to build with the new platform. Which is rather hard to say when you haven't had the chance to play with it yet. Google is also promising to open source the technology. Open source works well when there's a community engaged with the technology and contributing. It will be interesting to see if Google can be successful in turning its as-yet-private code and process into something that others participate in.

In order for the social practices and designs to be worked out, people need to be using the technology. Google needs to get this technology out of the lab and into the hands of users and developers so people can start to figure out how and whether the conceptual and social model issues can be addressed.

But it's early days. As someone wisely observed on Jerry Michalski's Yi-Tan call, an audio online salon that addresses emerging technology topics, it took three years for Twitter to get to critical mass, and Twitter has an extremely simple usage model and a trivially easy model for extensibility. Google Wave isn't even out in the world yet, and is a lot harder to grok for users and developers. One of my favorite quotes is from Paul Saffo, "never mistake a clear view for a short distance." Like hypertext did, the concepts embedded in Google Wave could take decades to make their way into common usage. As with hypertext, there may be many years of tools that instantiate concepts of real-time blending before achieving mainstream adoption. Google's tools and apps may or may not be the catalyst that gets us there.

In the mean time, this is pretty deep food for thought about how and where to integrate real-time communication and collaboration into regular work and life. Much praise is due to Google and the Wave teams for pushing the boundaries instead of cloning familiar models.

• |
• Permalink

Recently, media critic Jay Rosen mocked this post as dumbest newspaper column about Twitter ever. In the column, a game critic blogger at the New Orleans paper attempted to parody Twitter by writing his review of an xbox game in 140 character increments. The reason the reviewer's approach is silly is that the columnist misses the complementary relationship between Twitter and blogging. If you are writing an article, you don't write the article itself on Twitter. You write a normal essay, and then share the link on Twitter with a catchy phrase.

Is Twitter really killing blogging? There is a common meme Twitter is killing blogging, since bloggers are now spending their time and sharing their ideas on Twitter. As Robin Hamman observed last fall in this Headshift post, Twitter (and Facebook) are siphoning off a lot of the energy from personal diary blogging - the proverbial post about what I ate for lunch - or blogging for simple link sharing. Anecdotally, some bloggers observe that they post less frequently because they tweet ideas more often.

While Twitter may be siphoning blog energy from very short posts, Twitter also increases interest in more substantive blog posts and discussion around blog ideas. An increasing amount of blog traffic is driven by status updates from Facebook and Twitter. Through link posting and "retweets" - the social custom of forwarding a link or quote to one's Twitter followers, , the social network is used to share and spread interesting posts and call attention to good bloggers. Essentially, Twitter is the new headline.

Professionals use social messaging to develop ideas. On the public internet, reactions and conversation about blog post ideas are taking place in Twitter, in comments on Facebook status updates, and on FriendFeed, a site that aggregates and enables discussion about links and updates from many social media sites together. A number of online journalists are developing rich processes for developing ideas using these social media. Journalism professor Jay Rosen uses phased process, using Twitter for mindcasting short thoughts and links, Friendfeed for assembling links and ideas together with discussion, and his blog to publish long-form essays based on the ideas. Scientist and science blogger Bora Zivkovic writes about a similar social journalistic workflow, carrying the process from ideas shared in Twitter through composing articles and books. Yahoo social design expert and blogger Christian Crumlish has used the workflow starting with Twitter and extending through writing a book, using a wiki as a tool for book editing and feedback for O'Reilly's Designing Social Interfaces. Using these workflows, these professional journalists and bloggers are developing higher quality ideas and documents through turbo-charged idea sharing and peer review.

Value in the Workplace The relationship between social messaging and blogging can be particularly valuable in the workplace, where social messaging is used to call attention to timely and relevant work-related posts and updates. Sharing blog posts, links and wiki updates using Socialtext Signals enables timely discussion without interrupting people's work day.

Making it easy to share and discuss motivates people to write useful posts, and update information on wiki pages, because they know they know the content will be shared, discussed and used with colleagues - they are not just contributing content into a black hole. Socialtext Signals is designed to facilitate this sort of sharing - when adding new content, writers are prompted to share a summary of the update on Signals. And we're sensitive to business confidentiality - only people who have permission to see the content can see the Signal about the new content.

In summary, social messaging and blogs are highly complementary. The role of Twitter and Socialtext Signals isn't to limit thoughts to what can can be expressed in 140 characters or less, it's to call attention to longer-form writing, and to improve those ideas within the social network. Using the techniques of turbo-charged peer review being developed by professional bloggers and journalists, organizations can use social tools to be smarter and more responsive.

• |
• Permalink

Josh Porter predicts at his Bokardo blog that Facebook will go asymmetric. Until now, Facebook has had a "symmetrical" model of social network, where in order to establish a relationship, both sides need to have each other as connections. When you send a "friend request", the recipient must friend you back so you can see their profile and activity. By contrast, Twitter has an "asymmetric" network. People can follow you, and you don't need to follow them back for them to see your updates.

Porter calls out two key reasons why Facebook may go asymmetric. Asymmetric networks are a a good fit for anyone with a level of community fame, not just organizations, consumer brands and popular bands. Facebook is making it's "Pages" feature more robust - these are pages that a brand or organization can set up. People can choose to be "fans" of that organization, and the organization does not need a mutual connection. In addition to helping popular organizations and people, asymmetric networks help people manage their attention. If you are even modestly popular, with over 100-200 followers, the number of updates from followers can be deafening. In an asymmetric network, you don't need to pay attention to every update from everyone following you.

There are a couple of other key reasons why asymmetric networks scale better, in addition to helping the popular. In Twitter there are a number of ways where asymmetry in a public network provides good returns to scale, as I noted in a post on my personal blog on premature predictions of peak Twitter

• In Twitter, it is common to "Retweet" an interesting link or quote, to share it with your followers. Retweets disseminate information across social networks
• Twitter searches makes it easy to find information outside of one's personal network
• Visible "mentions" - the feature that shows that shows when someone mentions you even if you're not following them, allow you to hail and engage people in conversation, and have others start conversations with you, even if you're not following them.

These features mean that the more people who join the network, the more interesting information will be amplified through it, and the more potentially interesting people you may discover. The level of context is fairly high - you can see what someone else has been Twittering, and see if they are interesting and relevant to you. And the level of obligation is low (you can follow someone without giving them the burden of accepting or rejecting you). In Facebook, I can see when someone that I don't know has commented on the update of someone I do know, but then I need to "friend" a stranger in order to learn more about them. Facebook's mostly-symmetrical, mostly closed network makes it hard to learn new things and meet new people outside your existing network.

So, the reasons for asymmetry aren't just about supporting fame, but enabling discovery with low social expense.

This is an edited version of a post that first appeared here.

• |
• Permalink

Who are the effective people you know? They're not just smart and good at what they do. They know how to get things done. In an organization, they know how the system works in ways that aren't written down. They know who really knows what (and that may not be the person with the title). They may not know everything, but they know who knows what. They don't have all the skills and contacts themselves, but they know how to find the key people. In an organization, functional relationships and functional skills are only a part of what makes people successful.

Being successful takes network skills. The org chart is not the network.

This principle is bolstered by classic studies of social networks. Healthy social networks are characterized by "strong ties" in the core of groups, and a set of "weaker ties" to individuals in other groups. The strong ties enable groups to get things done with social cohesion and skill. The weaker ties enable the organization to be responsive to new information and changes to processes. See: weak ties and diversity in social networks and weak ties for social problem solving in enterprise 2.0

Traditional enterprise software is about making the org chart more efficient, by automating the functions and processes within org chart. Sales automation, support automation, marketing automation, finance automation. Access control is a primary concept - the pattern is to restrict information to the smallest number of people of have permission to see the information. These patterns are important and continue to be important. Strong processes are critical for organizations to work effectively and cost-effectively. There are legitimate needs for confidentiality in HR, finance, and other areas.

A good part of the magic of enterprise social software is that it's a network overlay on top of the org chart.

What does this mean?

• it means that you can see people in your org chart group and outside
• it means that you can make connections to people in other groups and see their activity
• it means that you can work collaboratively in org chart groups and cross-functional groups
• it means that you can build "strong ties" with people in your group and "weak ties" with people in other groups

People who design and configure enterprise social software need to be aware of the org chart and the network.

• you want to enable information sharing by the org chart, but not constrain it to the org chart
• you want to enable the creation of groups by the org chart, but not constrain it to the org chart
• you want cross-functional contribution, without confusion and chaos

Successful design and implementation of enterprise social software requires taking into account the benefits of the org chart and the benefits of the network, and design a system that takes the best advantage of both.

• |
• Permalink

Twitter has taken off on the public web, and there are a variety of vendors who are offering "Twitter for the Enterprise." As with social networking, it's not enough to simply clone Twitter and deploy it for business users. Here are some of the key ways that enterprise microblogging is different. This is part two of a series on what's different about enterprise software. Part 1 is crossposted here and here.

Links to real identities and work activity

With public Twitter, people use nicknames. Many people add a profile link that identifies who they are in the real world. Many do not, and tweet pseudonymously. In a business setting, the signal is tied to the user's real-world identity, derived from their company directory entry and business activities. You can navigate from a signal to a profile, and discover a lot about the person in their work context. A significant part of the value the people get from enterprise social software is finding the smart and plugged-in people in their organization. Microblogging helps discover the interesting people, and the links to rich work-context profiles reveal more about what the person does and what they know.

Sharing links in the intranet

With public twitter, one of the common usage patterns is to share links. Well-informed, insightful people scan the news, and share interesting tidbits with their followers. This valuable pattern on the public net gains power inside an organization. People can share links and commentary about to documents they are working on, for example, a marketing plan or a budget. And they can share private commentary about public links. For example, there can be a company-private discussion about a move by a competitor. Enterprise microblogging allows users to share links to private content, and to share private discussion about public content.

Confidentiality

The main difference between Twitter and enterprise microblogging is confidentiality. You're not sharing information with the big wide world, only with your colleagues. As in personal life, confidentiality frees people to share more openly about nonpublic topics. Of course, people need to be still cognizant about what they share, as they do in meeting rooms or around water coolers. Inside an enterprise, microblogging has a different balance of transparency and privacy than email. With email, your message is visible only to the people you choose to send it to. With enterprise microblogging, the recipient chooses who to follow, and whose messages to see. This provides useful "ambient transparency" in an organization, for example spreading useful knowledge about products in development and customer relationships. Enterprise microblogging is more private than public Twitter, and more transparent than email.

The Art of Enterprise Social Software

As you can see, it's not enough to take an existing piece of social software and run it behind the firewall. Adapting social software to the enterprise requires consideration about how business and social environments are different, and how social software can be used to provide business value.

• |
• Permalink

When people talk about "enterprise social software", they envision "Facebook for the enterprise" or "Twitter for the enterprise. But creating enterprise social software is a matter of adapting patterns from the public web, not copying identically.

What is "Enterprise Social Networking"

In the public web, social networking software has become embedded in people's lives, as a way to stay in touch and to coordinate. Similar patterns will bolster collegial connections, expertise discovery, and collaboration. However, there are some significant differences between a social network on the web and a network behind the enterprise firewall.

What is Friending?

In a public web social network, the primary gesture is identifying others as "friends". The graph of friends delineates the boundaries in which each individual shares information. Contact information is assumed to be private unless shared with a friend. But in a business social network, the lines of visibility are defined differently. In a plain-vanilla corporate directory, the assumption is that every employee has the right to see contact information for everyone else. You don't need to mark "Dale" in marketing as a friend in order to see his phone number. More than that, what on earth is a "friend"? Will people simply go around "friending" high-ranking executives? Should I need to have to specifically mark my colleagues in the product group as "friends"? What does it mean if someone is not my "friend." The gesture of explicit friending doesn't have much value, and has plenty of potential annoyance and harm. In Socialtext, we use the "following" gesture common to Twitter and Friendfeed, and don't support "friending."

Where does Profile data come from?

In public web social software, people type in their contact information, alma mater, significant others, pets. In an organization, there is often already a repository of basic contact information in the corporate directory. HR and IT departments share responsiblity for keeping that information up to date. Therefore, a business social network needs to draw on corporate systems of record for basic contact information. Admins need to decide what information comes from the corporate directory, and what information users should add themselves.

What are the Activities in an Activity Feed

One of the features that's most compelling about Facebook is the ability for people to see updates on their friends activities. Talia is dating / no longer dating / once again dating Jeremy. Bob just watched xyz movie. Scott is reading xyz book. This activity stream is compelling inside the firewall, for a different set of activities. People will be interested in updates on what their colleagues are working on, what documents they have edited, what key events have happened in enterprise systems. For example, "Shawn closed the support escalation ticket for Major Customer Q." It would be nice, and foster adoption, to have some "small talk" applications that enable people to stay in touch regarding ordinary life. It can be highly valuable for the business to be able to be notified of important work-related updates. In social networks, the context of the activity feed is one's social life. In an enterprise social network, the content is one's work activities in enterprise systems, documents, and processes.

What does an admin do?

In private label social public social networks, administrators do things like configure the available features and the fields in a profile. In business social networks, administrators integrate the social network with existing directories and applications. They play a greater role in defining communities and creating social boundaries. In a consumer social network, the individual assumes that she has control over privacy and disclosure and there is controversy if those assumptions are violated by service providers. In a business social network, the administrator has more control. In some cases, this level of control is good and appropriate. Competing customers shouldn't see each others information, and the activities of the M&A groups should be secret. An appropriate level of business confidentiality, like an appropriate level of personal confidentiality, increases sharing and honesty. In some cases, admins are familiar with applications deployed on a "need to know" basis, and want use these familiar practices to set up applications designed to gain value by increased sharing. There are gray areas that will need to be worked out in software design, effective practice, and cultural evolution. Next in the series: What's different about enterprise Twitter

• |
• Permalink

Ross Mayfield, Tracy Ruggles and I presented at the Silicon Valley Product Management Association. Ross gave a high level picture of some core social software principles of connected collaboration. Tracy and I talked about how we live those principles every day, using Socialtext tools to do distributed agile product development with Socialtext tools.

Social scientist Valdis Krebs has observed that a healthy social network has a strongly connected core, and a more weakly connected periphery. The densely connected core reflects a well-functioning collaborative process; while the weaker ties to the periphery enable the organization to respond to the the environment and learn.

In the clip, I describe how we use Socialtext's wiki for tight, fast, iterative collaboration with product management, design, development and QA. The transparency and participative contribution fostered by the Socialtext toolset enables a broader network of weaker ties with customers and customer-facing folk in sales, marketing, support and professional services. The broader network of weaker ties helps Socialtext understand our customer's needs, and the short development cycle lets the leadership team flexibly prioritize what's needed for the business. A key principle of agile is adapting your process to the your current processes and needs, and a key principle of Socialtext is a set of tools that let you adapt your processes to be responsive to change.

In a presentation, the most interesting thing is often the questions, which aren't in the video.

• One product manager asked about having "stories" in development be visible to the whole company, and customer feedback be gathered in view of the whole company. Doesn't that cause a problem with "too many cooks"? The answer is leadership and signoff. It's PM's job to turn the gas cloud of input and goals into a set of stories and roadmap, and ultimately the CEO's job to make sure we're going in the right direction.

• One product manager asked a really telling question - how would Socialtext technology help me make the QA people on the team to read the pages in my PM documents? The answer is, that's the wrong question. At Socialtext, QA folk pro-actively read stories, add corner case tests, and sign off, because they co-own the process. We sometimes have passionate disagreements, but not indifference. Tools can help with collaboration, but the culture needs to create it.

The video and slides are here. The distributed agile process that I talk about is a collaborative creation of the whole Socialtext product development team.

• |
• Permalink

Data sharing and privacy are seen as black and white opposites in conventional wisdom. Everything is locked down, private, non portable. Or everything is open, public, and free-flowing.  But data sharing and privacy are not black and white. In real life, people share and present information based on social context. There are gradations of privacy and information sharing.

At the recent Data Portability Summit, there was some excellent discussion about data sharing, privacy and context.

Truly Private information

There are times when it is right to share data in a way that preserves privacy. Family members use different photo services, and want to share photos with each other but not the rest of the world. A group working on mergers and acquisitions absolutely needs to keep information confidential. In these cases one give permission to family, friends, or business associates based on membership in a group.

Signal to noise, social context

There are many circumstances where information isn't truly private. But people choose to share with smaller groups. Someone doesn't want to bore all of their friends with information about knitting or rock climbing, when that information is relevant only to a few. Information about one's political or religious affiliation isn't a secret, but it may not be the information one chooses to share when meeting new people at a professional conference. In these cases, it would be useful to have the ability to create tags for the relevant groups, and share by tag. The tags can capture the nuances of subgroups: knitting hats vs. knitting sweaters, say.

Progressive disclosure

There are circumstances when people want to start by sharing with a smaller group, and invite more people. Or start by sharing a little bit of information about common interest, and later share more sensitive information.

Stream filter

The signal to noise and progressive disclosure patterns are about the person sharing information. Stream filtering is for the recipient. Sometimes one wants to "people watch" a diverse stream of information. And sometimes one wants to focus on the current work project, or upcoming social events. Stream filtering is used by individuals who want to apply a context to the information they receive.

Persona

People use identifiers -- dress or email address -- to represent more than one persona. The same person wears different clothes, with co-workers, at a customer meeting vs. a barbecue.

Personal vs. organizational control

In organizations, there are some things that an individual may want to control, and some things that admins want to control. A person might want to share soccer pictures with the soccer league. An admin may want to ensure that people aren't sharing the sports illustrated calendar widget.

These ideas emerged from the session, co-moderated by Kevin Marks plus pre- and post-conversations with Joseph Smarr and Thomas Vander Wal

• |
• Permalink