Social software seems to defy industry consensus and a concise definition.
Social software seems to defy industry consensus and a concise definition. Characterizations vary, sometimes widely. For the most part, people "know it when they see it” (e.g., blogs, wikis, social bookmark services, social networking). But in many aspects, social software is not something completely new, much of its roots date back to historical research that resulted in the Internet and Web. For those curious as to how we got into this dilemma, there is a well-written history of social software by Christopher Allen here. In the posting (scroll down to the end), Clay Shirky defines it as “software designed for group interaction”. I like his definition because of its simplicity but it leaves the door open for many technologies to be included which tends to obfuscate things at the same time. IBM and Microsoft approach the topic from a slightly different perspective, categorizing much of its related research in this area under the banner of social computing. It has some benefit. I found that it acknowledges certain non-software considerations for instance. So as I look at social software and related trends, I find myself coming back to five attributes (at least at the moment of this posting) that seem to reoccur:
• Designed to be recombinant • Enables a collective user experience • Augments informal interaction • Aggregates information from community-influenced networks • Spans work and lifestyle
Designed To Be Recombinant
Social software should be designed not only to be personalized or customized within a known design framework (as is most traditional enterprise software) but to also be extended and recombined with other software services to produce usage scenarios that are unforeseen by its original designers and contributors (e.g., mashups).
Enables A Collective User Experience
Social software should be designed for groups. That means a design point that is not so singularly about an individual user experience (a design-point common in transactional and pseudo-transactional applications) but around the group as an entity in and of itself (perhaps in mindset more similar to game design where group participation and immersive interfaces are core tenets). It should also endeavor to represent social context (e.g., natural interaction, visual cues). Finally, social software should support some level of peripheral vision. That is, a quick glance at “something” should allow users to maintain situational awareness of group activity or determine whether their attention should be diverted.
Augments Informal Interaction
Social software should emphasize and amplify informal interaction. This does not preclude intensive use of applications by users rather the design point is not to simulate traditional applications that are data-entry oriented, workflow-driven or overly-formal in regards to role, user status and privileges. Groups connected through social software are likely bonded by both strong and weak associations to many different topics with interaction characterized by varying levels of shared interest. Participation may ebb and flow for whatever reason so use of the social software is often non-deterministic. In this sense, social software provides cohesion between activity-based collaboration (e.g., more formal workspaces that are outcome-driven), communities (e.g., groups coming together coherently to share information and know-how around some interest or practice) and networks (loosely coupled connections between people based on a variety of interests, associations or relationships).
Aggregates Information from Community-influenced Networks
Social software should promote the exchange of perspectives (e.g., opinion, actual know-how) from community-influenced networks. Some community structures are formal and visible to an organization (e.g., a community of practice) but many remain invisible and are more socially-oriented and loosely coupled (e.g., personal networks, professional relationships). These silent networks are important to those within them but existence of these networks is often not publicly known and information from these exchanges is rarely captured or leveraged outside its participants (often due to privacy concerns). Social software should provide trust-based connection mechanisms that surface such associations and relationships.
Social software should also look at ways to aggregate metadata and information that is casually produced through informal interaction and community-influenced participation. There are plenty of ways for people to classify and share information on a formal and structured basis. There is no need for social software to implement a better taxonomy, document management, workflow management or e-mail system. Instead, the design should be complimentary to these systems, enabling a more natural capture and categorization of information on a mass basis. Community interaction and influence (whether explicit or inferred) should help determine how relationships and information are connected, organized and visualized (a more organic approach). This reinforces the focus of social software on the choreography that occurs within and across groups rather than on the specific types of tools being used.
Across Work and Lifestyle
Social software should presuppose that users will utilize an ensemble of devices that they themselves acquire as well as those that are provisioned to them by the enterprise. Social software should not be constrained only to online-to-online interaction but also facilitate offline engagement. Social software should not assume artificial boundaries around concepts of “workplace” (the domain of traditional enterprise software) as a design point. Those constraints should remain external parameters that could govern social software behavior. Social software should assume pervasive connectivity but also accommodate disconnected and/or offline usage scenarios. The point of considering work and lifestyle as attributes is to encourage thinking about social software as having a role in mediating face-to-face engagement as well as online interaction and to acknowledge the important role of devices, form factors and networking. In some social software use case scenarios, value might be derived from wearable computers that facilitate face-to-face personal gatherings. The focus should not always be on the Internet.
IT's Reputation: What the Data SaysInformationWeek's IT Perception Survey seeks to quantify how IT thinks it's doing versus how the business really views IT's performance in delivering services - and, more important, powering innovation. Our results suggest IT leaders should worry less about whether they're getting enough resources and more about the relationships they have with business unit peers.
What The Business Really Thinks Of IT: 3 Hard TruthsThey say perception is reality. If so, many in-house IT departments have reason to worry. InformationWeek's IT Perception Survey seeks to quantify how IT thinks it's doing versus how the business views IT's performance in delivering services - and, more important, powering innovation. The news isn't great.
InformationWeek Must Reads Oct. 21, 2014InformationWeek's new Must Reads is a compendium of our best recent coverage of digital strategy. Learn why you should learn to embrace DevOps, how to avoid roadblocks for digital projects, what the five steps to API management are, and more.