One of the “hot topics” related to micro-blogging, activity streams, and social networking in general has been the concept of “following”. The concept is not actually without precedent ? instant messaging (IM) systems have included the notion of “presence” for some time. By adding co-worker’s to a “buddy list”, people can “follow” changes in a colleague’s status (e.g., available, in a meeting, out to lunch, on vacation). While simplistic, “watcher agents” within an IM system send updates to a back-end hub that propagates updates to all buddies (i.e., followers) of that individual. If we take a broader view of “following” for a moment, a wide variety of applications over the years have adopted alerting features (e.g., auto-generated e-mail messages) to notify people that there was a state-change in whatever it was that someone had wanted to “follow” (e.g., an inventory level, documents within a workspace). So just for purposes of noting its historical evolution, the concept of “following” is not completely new. Past incarnations however were perhaps so subtle and housed within a particular use case scenario or application context, that we never really thought about how the model could be leveraged in a very broad and compelling manner.
Social network sites (defined by boyd and Ellison for consumer sites in 2007 and extended by myself (while at Burton Group) to apply to enterprise sites in 2008), were instrumental in making follow models more prominent. Two models have become popular: symmetric following and asymmetric following. Just to level-set for those not familiar with the different styles:
-
In general, Facebook implements a symmetic follow model where Person-A requests to “friend” Person-B. If Person-B agrees, a bi-directional agreement is formed that enables both parties to see a flow of event updates from each other, places into their respective news streams.
-
In general, Twitter implements an asymmetric follow model where Person-A can decide to “follow” Person-B without any need for Person-B to either agree to being followed, or for Person-B to necessarily “follow” Person-A in return.
Note: These are simple descriptions; each social network site has additional features (e.g., privacy controls) that can alter the behavior of either follow model.
Current enterprise social networking trends favor the asymmetric approach. The overhead associated with a symmetric model is considered too burdensome. With a symmetric model, people are forced to process potentially be a large number of follow requests, which can also create a steady stream of interruptions. Not only does this model create productivity concerns, but a social etiquette one as well. For instance, people may feel compelled to “friend” people in management, or feel that they are creating an awkward situation when declining a co-workers request. The asymmetric nature Twitter approach has been generally accepted as the better practice. Note: security-related needs may complicate both a symmetric and asymmetric model (e.g., require approval, or limit information sharing based on role, permission levels, etc).
While the asymmetric model has apparently won, it seems that we have not taken a moment to think more broadly about what it means to “follow someone”. We should be striving to move beyond duplicating an enterprise Twitter where “following” someone results in you seeing everything a person posts. Right now, the follow model is application-dependent. If someone you follow updates their status, shares a link or file, “retweets”/replies to a post, then those updates become visible to all followers ? if all parties are using the same social network site or application (with some brute-force integration exceptions). If I am using Vendor Product A, I either have to visit my home page to see an activity stream of posts or there may be a lightweight front-end application that provides a dedicated activity stream view. From these two user experiences, I have the ability to “follow” other co-workers or perhaps items in the activity stream.
Technically, most solutions rely on their own application interface as well. A proprietary API means that any third-party system that wants to post into that stream needs to write to that vendor’s interface. It is likely that each vendor will have different formats, and data requirements to work with their own activity stream, making this approach difficult to scale and sustain over time as point-to-point integrations carry a lot of overhead. While there is a standard for activity streams, adoption by enterprise software vendors remains embryonic. Clearly, there is a problem brewing ? two problems actually. The first issue relates to the interoperability. The second relates to user experience. I’ll deal with the user experience issue below. The interoperability issue I’ll postpone to another time ? or you can simply visit the activitystrea.ms site.
User Experience: The Need For A Universal “Click-to-Follow”
Earlier in 2010, Twitter announced @Anywhere. The capabilities would allow other sites to embed Twitter features without users having to go to the Twitter site. The key capability was the ability to remotely follow someone from “anywhere” without having to take that action from the Twitter site or from within a dedicated front-end application (e.g., TweetDeck). When designing a “follow” model for use within the enterprise, this capability offers tremendous value. In fact, I would add “click-to-follow” to the list of other “click-to-xxx” actions we are embedding pervasively throughout our applications and web sites (e.g., click-to-call, click-to-IM, click-to-conference).
A follow model has two major dynamics. First, it enables people to create their own filtering and signaling mechanism as they follow people, activities, topics, etc. In this mode, it has tremendous personal value. Secondly, it is also an informal means for people to lurk, share, and network over time as they interact around the things they are jointly following. In this mode, it has intriguing community-building value. If we want to leverage these modes more consistently, and broadly, then we can start unifying the social network site follow model with the ones we have already implemented ? and look for new contexts to surface the capability.
For example, within an IM buddy list, it would be helpful to have an option to follow a person’s activity stream, including any micro-blogging posts. In fact, there would be interesting ways to extend IM and conferencing clients to reveal that information (in a manner similar to Xobni perhaps). Other application-specific user experiences could be made more compelling by allowing people involved in the process to be followed (e.g., by task, by role, by activity). We should be able to follow an exception handling situation, or the subject matter expert as they investigate the exception.
A similar user experience could be designed into e-mail clients as well ? we might want the capability to follow someone as we correspond with co-workers, or even people outside the organization. In a similar manner, having the option to follow someone as you’re reading a document they’ve written, or responding to a post they authored (blog, forum), could have real value. Even including the option to follow people as part of a calendar invitation might be helpful for people to learn more about meeting participants beyond a link to their social network site profile. Even including a follow option within the results of a search query might be a sound design technique as “people search” becomes more popular.
While are these examples are explicit ? spreading the opportunity to follow ? there should be a centralized platform that enables systems to suggest objects to follow as well. For instance, if I follow “John Doe” and “John Doe” is in not in my buddy list, the next time I go to my IM client, the application should prompt me if I also want to add him to my buddy list. If he is already on my buddy list, it should allow be to escalate my view to include activity stream information. You could also have an elaborate recommendation engine underneath as following information is aggregated and correlated across all the different means of “following”.
These scenarios may seem over the top and that is by intent. I wanted to show how expansive the concept of following within the enterprise could be viewed ? well beyond the social network site, micro-blogging, and activity stream examples we have today. We should be thinking of “following” more along the lines of Twitter’s @Anywhere vision ? as a user experience that spans all sites, applications, content, and devices. While the design would need to address issues related to information overload and attention disruption, the benefits are compelling. Not only could the capability become a more natural work style that mimics consumer use of social media, but a well-designed framework can be a strategic means of making work more observable (see #owork), and enabling more effective community-building and social networking.
