Tag Archives: filter

Filtering in Social Software: Protective Bubble v. Serendipitous Awareness

Bubble Boy DavidThere was an interesting conversation on Twitter yesterday about the personalization of information via algorithm-based filters. It was started by Megan Murray, and Thomas Vander Wal, Gordon Ross, and Susan Scrupski quickly joined in with their viewpoints. Rachel Happe and I were late to the conversation, but we were able to interact with some of the original participants.

.The gist of the conversation was that some consumer social services (i.e. Facebook, Google Search, Yahoo News) have gotten rather aggressive about applying algorithms to narrow what we see in our personal activity streams. As a result, we aren’t able to see other information that might be useful or entertaining in our default view; we may only digest what the algorithm “thinks” is important or relevant to us. Or we must switch to a different view to see additional information (e.g. Live Feed v. News Feed in Facebook). Even worse, in some cases, the other information is simply not available to us, because the service doesn’t provide a way to override the algorithm that excluded it.

It was also noted in the Twitter conversation that the current crop of enterprise social software lacks sophisticated personalization facilities. In fact, it works the opposite way of consumer social services; the entire activity stream is usually exposed to an individual, who then has to narrow it by manually selecting and applying pre-defined filters. IBM, Jive, NewsGator, and others are beginning to use algorithms to include certain status events and updates in the stream, and to exclude others, but their efforts will require fine tuning after organizations have experimented with these nascent (or yet-to-be released) personalization features.

The default view of an enterprise activity stream should be highly personalized to the context in which an individual is working (e.g. role, business process, location, time, etc.) Optional views should allow individuals to override the algorithmically chosen results and see information relevant to a specific parameter (e.g. person, group, application, task, tag, etc.) Finally, an individual should be able to view the entire stream, if he or she so desires.

Why is the latter important? It introduces serendipity into the mix. Highly personalized information views can increase productivity for an individual as they do their job, but at the expense of awareness of what else is occurring around them (I wrote about this earlier this week, in this post.) This condition of overly-personalized information presentation has been called a “filter bubble”. The bubble is a virtual, protective barrier against information overload that is analogous to a plastic enclosure used in hospitals to shield highly vulnerable patients from potential infections.

Organizations must consciously balance the need to protect (and maximize the productivity of) their constituents from information overload with the desire to encourage and increase innovation (through serendipitous connection of individuals, their knowledge and ideas, and information they produce and consume.) That balance point is different for every organization and every individual who works in or with it.

Enterprise social software must be designed to accommodate the varying needs of organizations with respect to the productivity versus awareness issue. Personalization algorithms should be easily tunable, so an organization can configure an appropriate level of personalization (for example, InMagic’s core Presto technology features a “Social Volume Knob” that allows an an administrator to control what and how content is affected by social media. Different kinds of social content from certain people can carry different weight or influence.) More discrete, granular filters should be built into social software so individuals can customize their activity stream view on the fly (I made that case, just over a year ago, in this post.) A contextually personalized view should be the default, but enterprise social software must be designed so individuals can quickly and easily switch to a different (highly specific or broader) view of organizational activity.

What do you think? Should personalization be the default, or applied only when desired? What specific filters would you like to see in enterprise social software that aren’t currently available? What role does/could portal technology play in the personalization of organizational information and activity flows? What other concerns do you have about information overload, filter bubbles, and missed opportunities for serendipity and innovation? Please weigh in with a comment below.

This entry was cross-posted from Meanders: The Dow Brook Blog

Image © 2003 Texas Children’s Hospital

LinkedIn Signal Demonstrates The Power of Role-Based Activity Stream Filters

LinkedIn today announced Signal, a new feature (currently in beta) that lets members see an activity stream that combines LinkedIn status updates and Twitter posts from other members who have opted-in to the feature. LinkedIn has licensed the Twitter firehose to incorporate all of its members’ tweets into the site, not just tweets with the #in hashtag embedded, as is current practice.

While it is hard to imagine anyone other than corporate and independent talent recruiters will make LinkedIn their primary Twitter client, Signal does have an element that is worthy of emulation by other social networks and enterprise social software providers that incorporate an activity stream (and which of those does not these days!) That feature is role-specific filters.

I wrote previously in this post about the importance of providing filters with which individuals can narrow their activity stream. I also noted that the key is to understand which filters are needed by which roles in an organization. LinkedIn apparently gets this, judging by the screenshot pictured below.

LinkedIn Signal screenshot courtesty of TechCrunch

Notice the left-hand column, labeled “Filter by”. LinkedIn has most likely researched a sample of its members to determine which filters would be most useful to them. Given that recruiters are the most frequent users of LinkedIn, the set of filters displayed in the screenshot makes sense. They allow recruiters to see tweets and LinkedIn status updates pertaining to LinkedIn members in specific industries, companies, and geographic regions. Additionally, the Signal stream can be filtered by strength of connection in the LinkedIn network and by post date.

The activity stream of every enterprise social software suite (ESS) should offer such role-based filters, instead of the generic ones they currently employ. Typical ESS filtering parameters include individuals, groups or communities, and workspaces. Some vendors offer the ability to filter by status as a collaborator on an object, such as a specific document or sales opportunity. A few ESS providers allow individuals to create custom filters for their activity stream. While all of these filters are helpful, they do not go far enough in helping individuals narrow the activity stream to view updates needed in a specific work context.

The next logical step will be to create standard sets of role-based filters that can be further customized by the individuals using them. Just as LinkedIn has created a filter set that is useful to recruiters, ESS providers and deploying organizations must work together to create valuable filter sets for employees performing specific jobs and tasks. Doing so will result in increased productivity from, and effectiveness of, any organization’s greatest asset – it’s people.

Enterprise Social Software and Portals: A Brief Comparison of Deployment Patterns

In my last post, I examined whether or not Enterprise Social Software (ESS) is the functional equivalent of enterprise portal applications as they existed ten years ago. My conclusion was:

From a functional perspective, ESS is quite similar to enterprise portal software in the way that it presents information, but that does not tell the whole story. ESS lacks critical personalization capabilities, but provides better collaboration, process, publication and distribution, categorization, and integration functionality than portals. In my judgment, ESS is somewhat similar to portal software, but mainly in appearance. It makes more functionality available than portals did, but needs to add a key missing piece – personalization.

In this post, I will focus on the observation that ESS resembles enterprise portals in another regard – how and why it is deployed.

Enterprise v. Smaller Deployments

Portals were initially marketed as a tool for enterprise-wide communication and interaction, with each internal or external user role having its own personalized set of resources available in the user interface. While there were some early enterprise-wide deployments, portal software was deployed far more often at the functional level to support specific business processes (e.g. sales, procurement, and research portals) or at the departmental level to support operations.

Enterprise social software has also been touted as most valuable when deployed across an organization. However, like portal software, ESS has most often been deployed at the functional level in support of activities such as marketing, customer service, and competitive intelligence. As a result, the promised network effects of enterprise-wide deployments have not been realized to-date, just as they were not with most portal deployments.

Internal- v. External-Facing Deployments

Most early portal deployments were internally-focused, as shown in this InformationWeek summary of market research conducted in 2001. Not only was there a smaller number of externally-focused deployments, mixed-audience deployments did not begin to appear until the portal market was extremely mature. ESS deployments have followed this same pattern, and we are just now seeing early efforts to blend inward- and outward-facing business activity in common ESS environments.

Internal Use Cases

Portal software was often deployed in response to a specific business need. Among the most common were:

  • intranet replacement/updgrade
  • self-service HR
  • application aggregation
  • document/content management
  • expertise location
  • knowledge sharing
  • executive dashboards

ESS has been deployed for many of the same reasons, especially intranet replacement, application aggregation, expertise location, and knowledge sharing.

External Use Cases

Portal software was deployed externally to provide self-service access to corporate information. In some cases, access to selected application functionality was also provided to key business partners. Retail and B2B portals enabled customers to purchase goods and services online. Process acceleration, revenue growth, and cost reduction were the key business drivers behind nearly all external portal uses.

ESS doesn’t seem to have the same goals. I have seen some, but little, evidence that external communities are being leveraged to accelerate business processes or reduce costs. Peer support communities are a good example of cost reduction via ESS. The goal of most outward-facing ESS deployments seems to be customer engagement that translates (eventually) into increased innovation and revenue for the deploying organization.

Conclusions

ESS deployments today strongly resemble portal projects that were undertaken ten years ago. Few, if any, ESS deployments have been enterprise-wide. Instead, ESS is deployed to many of the same department and functional groups, to support the same business processes, and to drive many of the same business results as portals were a decade ago (and still are.)

What does this commonality with early portal deployments mean for ESS? I will examine that in my next post. Until then, I would love to hear your reaction to what I have presented here.

Enterprise Social Software: The Second Coming of Enterprise Portals?

Enterprise Social Software (ESS), at first glance, is eerily similar to the portal software that was the hot enterprise toolset 10 years ago. That became very clear to me during the Enterprise 2.0 Conference in Boston last month, even though I was only able to attend the first 2 (of 4) days of the event.

I have noticed and commented on the parallels between the portal software market as it existed a decade ago and today’s enterprise social software category in a previous post. However, the notion of their similarity was reignited by a comment that I overheard as I walked through the exposition space at this year’s E2.0 Conference. One individual said to his companion something to the effect that if the branding was removed from each vendor’s ESS demo, one would be hard pressed to say which offering came from which specific provider. In other words, there was very little differentiation of user interface (UI) layout or functionality. In fact, every screenshot and live demo that I saw looked like a portal, in that the UI was a collection of data and unstructured information aggregated into a single interface and presented through a number of widgets.

Similarities in Functionality

In 1999, Delphi Group published a portal architecture diagram, which depicted the layers of functionality that the firm thought were required of a robust enterprise portal solution.

Examining each layer of the portal architecture model and commenting on its applicability to ESS as it exists today will allow us to determine whether ESS really is just another incarnation of portals or if there is something significantly different being offered.

Presentation: In portals, data, unstructured content, and application functionality were  aggregated from multiple sources and presented in widgets, whose layout on the screen was usually customizable by individual users. ESS strongly mimics this UI design, including, in some cases, the ability to customize which widgets are displayed. Most ESS providers are beginning to offer application stores stocked with widgets that can be run in their offerings, exactly like portal software vendors rolled out portlet libraries for their users a decade ago. Finally, portal access on mobile devices was big deal 10 years ago, as is mobile access to ESS functionality today. So portals and ESS certainly appear to be the same.

Personalization: The primary value-add of portal software, in addition to it aggregation capabilities, was its ability to personalize (and, thus, filter) information based on a user’s unique digital identity and organizational role. ESS needs to improve vastly in this area; currently, most information must be manually filtered. This typically occurs via selection of one or more parameters ( to narrow the organization’s activity stream) or by following an individual, group, space, or tag. ESS should apply more profile information and use heuristics to dynamically effect what information is applied on an individuals dashboard or home page.

Collaboration: Some portal deployments embedded collaboration workspaces or their individual elements (IM or chat, discussion forums, polls) into the UI, but, in general, most deployed portals fell short as full-fledged collaboration tools. ESS is a definite improvement here. The array of available collaboration tools is richer and they are more usable, which results in higher adoption.

Process: There was a lot of ink spilled about process portals, but the promise was never fully realized, although there were some exemplary deployments. Process portals had workflow (BPM) either embedded directly into the portal technology or available though an integration with a stand-alone process engine. Similarly, there has been much talk about the need to process enable ESS. The good news is that we might actually execute on the vision this time around. We are beginning to see process-related notifications generated by applications integrated with ESS appear in activity streams. The next step will be to add lightweight activity and information coordination functionality (not full-blown, rules-based BPM) to ESS.

Publishing & Distribution: Portals were (and are) used to publish links to documents, syndicated content, and web clippings. ESS is also used heavily to publish and distribute content and goes well beyond what was possible in portals 10 years ago by adding additional content sources such as status messages, shared bookmarks, blogs, and wikis.

Search: Despite the push nature of information flow in portals, the ability for individuals to find and pull information was also very important for portal users. Search is equally important in ESS and, generally speaking, has under-performed, as it did in portal implementations. So, unfortunately, the similarity in this aspect between portals and ESS is negative in effect.

Categorization: Taxonomies were widely used in portals deployments to aid information personalization. They are still important in ESS, but their new relative, Tagging, is equally valuable in its ability to aid information personalization, browsing, and recall. We now have more tools at our disposal to apply to the information overload challenge than we did 10 years ago.

Integration: Integration of other enterprise applications and content sources was key to realizing the value that portals offered through their ability to aggregate information into a single interface. Portal integration was accomplished using a combination of hard-coded connectors, XML, and JSR-168/WSRP standards. The ESS value proposition also seems to be closely tied to the integration and aggregation model. However, ESS makes better use of defacto integration standards, including REST, RSS, and OpenSocial.

Conclusions

From a functional perspective, ESS is quite similar to enterprise portal software in the way that it presents information, but that does not tell the whole story. ESS lacks critical personalization capabilities, but provides better collaboration, process, publication and distribution, categorization, and integration functionality than portals. In my judgement, ESS is somewhat similar to portal software, but mainly in appearance. It makes more functionality available than portals did, but needs to add a key missing piece – personalization.

Are there similarities in deployment patterns between ESS and portal software as it existed 10 years ago? If so, what do the functional and deployment affinities between the two software categories mean for the evolution of the ESS market? I will attempt to answer those questions in my next post. Until then, I would would appreciate any comments or questions you have on my analysis of their overall functional likeness and differences.

More on Microblogging: Evolution of the Enterprise Market

Following my post last week on the need for additional filters in enterprise microblogging tools and activity streams, I participated in an interesting Twitter conversation on the subject of microblogging and complexity. The spontaneous conversation began when Greg Lowe, a well-respected Enterprise 2.0 evangelist at Alcatel-Lucent, asked:

“Can stand alone micro-blogging solutions survive when platform plays introduce the feature?”

I immediately replied:

“Yes, if they innovate faster”

Greg shot back:

“is microblogging autonomy about innovation, or simple elegance? More features usually leads to lower usability?”

And, later, he asked a complementary question:

“is there a risk of Microblogging becoming “too complicated”?”

Is Greg on to something here? Do more features usually lead to lower usability? Will functional innovation be the downfall of stand-alone microblogging solutions, or will it help them stay ahead of platform vendors as they incorporate microblogging into their offerings?

One of the commonly heard complaints about software in general, and enterprise software in particular, is that it is too complicated. There are too many features and functions, and how to make use of them is not intuitive. On the other hand, usability is a hallmark of Web 2.0 software, and, if we make it too complex, it is likely that some people will abandon it in favor of simpler tools, whatever those may be.

But that dichotomy does not tell the entire story. Based on anecdotal evidence (there is no published quantitative research available), early adopters of Web 2.0 software in the enterprise appear to value simplicity in software they use. However, as a colleague, Thomas Vander Wal, pointed out to me yesterday, that may not be true for later, mainstream adopters. Ease-of-use may be desirable in microblogging (or any other) software, but having adequate features to enable effective, efficient usage is also necessary to achieve significant adoption. Later adopters need to see that a tool can help them in a significant way before they will begin to use it; marginal utility does not sway them, even if the tool is highly usable.

Simple may not be sustainable. As I wrote last week in this post, as enterprise use of microblogging and activity streams has increased and matured, so has the need for filters. Individuals, workgroups, and communities want to direct micro-messages to specific recipients, and they need to filter their activity streams to increase their ability to make sense out of the raging river of incoming information. Those needs will only increase as more workers microblog and more information sources are integrated into activity streams.

In the public microblogging sphere, Twitter provides a solid example of the need to add functionality to a simple service as adoption grows in terms of registered users and use cases. As more individuals used Twitter, in ways that were never envisioned by its creators, the service responded by adding functionality such as search, re-tweeting, and lists. Each of these features added some degree of complexity to the service, but also improved its usability and value.

In the evolution of any software, there is a trade-off between simplicity and functionality that must be carefully managed. How does one do that? One way is to continuously solicit and accept user feedback. That allows the software provider and organizations deploying it to sense when they are nearing the point where functionality begins to overwhelm ease of use in a harmful manner. Another technique is to roll out new features in small doses at reasonable intervals. Some even advocate slipping new features in unannounced and letting users discover them for themselves. Hosted deployment of software (whether on-premise or off-site) makes this easier to do, since new features are automatically switched on for people using the software.

So back to the original question; can stand-alone microblogging solutions fend off the collaboration suite and platform vendors as they incorporate microblogging and activity streams in their offerings? My definitive answer is “yes”, because there is still room for functionality to be added to microblogging before it becomes over-complicated.

Based on the historical evolution of other software types and categories, it is likely that the smaller vendors, who are  intensely focused on microblogging, will be the innovators, rather than the platform players. As long as vendors of stand-alone microblogging offerings continue to innovate quickly without confusing their customers, they will thrive. That said, a platform vendor could drive microblogging feature innovation if they so desired; think about what IBM has done with its Sametime instant messaging platform. However, I see no evidence of that happening in the microblogging sphere at this time.

The most plausible scenario is that at some point, small, focused vendors driving microblogging innovation (e.g. Socialcast, Yammer) will be acquired by larger vendors, who will integrate the acquired features into their collaboration suite or platform. My sense is that we are still 2-3 years away from that happening, because there is still room for value-producing innovation in microblogging.

What do you think?

Filtering Microblogging and Activity Streams

The use of microblogging and activity streams is maturing in the enterprise. This was demonstrated by recent announcements of enhancements to those components in two well-regarded enterprise social software suites.

On February 18th, NewsGator announced a point release to its flagship Enterprise 2.0 offering, Social Sites 3.1. According to NewsGator, this release introduces the ability for individuals using Social Sites to direct specific microblogging posts and status updates to individuals, groups, and communities. Previously, all such messages were distributed to all followers of the individual poster and to the general activity stream of the organization. Social Sites 3.1 also introduced the ability for individuals to filter their activity streams using “standard and custom filters”.

Yesterday (March 3rd), Socialtext announced a major new version of its enterprise social software suite, Socialtext 4.0. Both the microblogging component of Socialtext’s suite and its stand-along microblogging appliance now allow individuals to broadcast short messages to one or more groups (as well as to the entire organization and self-selected followers.) Socialtext 4.0 also let individuals filter their incoming activity stream to see posts from groups to which they belong (in addition to filtering the flow with the people and event filters that were present in earlier versions of the offering.)

The incorporation of these filters for outbound and incoming micro-messages are an important addition to the offerings of NewsGator and Socialtext, but they are long overdue. Socialcast has offered similar functionality for nearly two years and Yammer has included these capabilities for some time as well (and extended them to community members outside of an organization’s firewall, as announced on February 25th.) Of course, both Socialcast and Yammer will need to rapidly add additional filters and features to stay one step ahead of NewsGator and Socialtext, but that represents normal market dynamics and is not the real issue. The important question is this:

What other filters do individuals within organizations need to better direct microblogging posts and status updates to others, and to mine their activity streams?

I can easily imagine use cases for location, time/date, and job title/role filters. What other filters would be useful to you in either targeting the dissemination of a micro-message or winnowing a rushing activity stream?

One other important question that arises as the number of potential micro-messaging filters increases is what should be the default setting for views of outgoing and incoming messages? Should short bits of information be sent to everyone and activity streams show all organizational activity by default, so as to increase ambient awareness? Perhaps a job title/role filter should be the default, in order to maximize the focus and productivity of individuals?

There is no single answer other than “it depends”, because each organization is different. What matters is that the decision is taken (and not overlooked) with specific corporate objectives in mind and that individuals are given the means to easily and intuitively change the default target of their social communications and the pre-set lens through which they view those of others.

UPDATE (03/04/2010, 5:10pm Eastern): A commenter on this post at the Gilbane Group Blog made a really great point about how updates from Social CRM systems change the nature of activity streams. Here is his comment and my reply:

Why I Am Ignoring Google Buzz

Note: This post is purely personal opinion based on my preferences and work style. If your are looking for an analysis of Google Buzz based on methodical primary research, abort now.

I have heard many people say that their email inbox is the mother of all social networks. For me, however, email is  the antithesis of a well-built, functioning social network, because it is a communication channel, not a collaboration enabler.

I value my social networks because I can work with members of those communities to get things done. When I worked at IBM, a very large company, my email inbox was more of a proxy for the organizational hierarchy than an instantiation of my social graph. Too much of my email activity was about low value (or value-less) communications and interactions imposed by command and control culture and systems. When I needed to communicate something up or down IBM’s or a project’s chain of command, I used email. When I needed to get something done, I contacted collaborators on Sametime (IBM’s instant messaging product), the phone, or BlueTwit (IBM’s internal-only, experimental microblogging system). In short, the contacts in my large corporation email address book were more reflective of the organizational structure than of my collaborative networks.

That is precisely why Google Buzz is a non-starter for me. The Google Contact list on which it is based does not represent my collaborative network, on which I rely to get work done. Very few of the people with whom I collaborate are represented, because I don’t interact with them via email. At least not often. A quick analysis of my Google Contacts list shows that Google Voice usage contributes more actionable, valuable additions to the list than does Gmail. My Gmail inbox is filled with communications, not action items, and most of them are low-value messages from application and service vendors whose tools I have downloaded or use online.

Google’s design of Buzz demonstrates ignorance of (or disregard for?) the reality that many social interactions happen outside of email. Had I wanted to use my Google Contacts list as a social network, I would have imported it into FriendFeed months ago. Strike One.

I just mentioned FriendFeed, which was my primary social network aggregator for several months. One of the reasons I backed away from heavy usage of FriendFeed was because it became little more than another interface to the Twitter stream. Yes, it is easy to inject updates from other sources into the FriendFeed flow, but, in reality, the vast majority of updates cam from Twitter (and still do.)

I see the same thing happening with Buzz. Too many people have linked their Twitter accounts, so that everything they tweet is duplicated in Buzz. And Buzz doesn’t allow for integration of the vast number of information resources that FriendFeed does. Talk about low-value. Strike Two.

I have not taken enough swings at Google Buzz yet to have recorded Strike Three. So, for now, I have not turned Buzz off. However, I am ignoring it and will not experiment again until Google provides integration with more external social networks.

In the meanwhile, I am still looking for a social tool that blends contacts and information streams from many sources, but lets me filter the flow by one or more sources, as desired. That would allow me to work both formal organizational and informal social networks from the same tool. Gist is promising in that regard, but needs to be able to capture information from more sources with corresponding filters. Hopefully, someone will read this post and either point me to an existing solution or build it. Until then, I will have to continue using multiple tools to communicate and collaborate.