Social Design for the Enterprise Workshop in Washington, DC Area
I am finally bringing workshop to my home base, the Washington, DC area. I am putting on a my “Social Design for the Enterprise” half-day workshop on the afternoon of July 17th at Viget Labs (register from this prior link).
Yes, it is a Friday in the Summer in Washington, DC area. This is the filter to sort out who really wants to improve what they offer and how successful they want their products and solutions to be.
Past Attendees have Said...
“A few hours and a few hundred dollar saved us tens of thousands, if not well into six figures dollars of value through improving our understanding” (Global insurance company intranet director)
From an in-house workshop…
“We are only an hour in, can we stop? We need to get many more people here to hear this as we have been on the wrong path as an organization” (National consumer service provider)
“Can you let us know when you give this again as we need our [big consulting firm] here, they need to hear that this is the path and focus we need” (Fortune 100 company senior manager for collaboration platforms)
“In the last 15 minutes what you walked us through helped us understand a problem we have had for 2 years and a provided manner to think about it in a way we can finally move forward and solve it” (CEO social tool product company)
Is the Workshop Only for Designers?
No, the workshop is aimed at a broad audience. The focus of the workshop gets beyond the tools’ features and functionality to provide understanding of the other elements that make a giant difference in adoption, use, and value derived by people using and the system owners.
The workshop is for user experience designers (information architects, interaction designers, social interaction designers, etc.), developers, product managers, buyers, implementers, and those with social tools running already running.
Not Only for Enterprise
This workshop with address problems for designing social tools for much better adoption in the enterprise (in-house use in business, government, & non-profit), but web facing social tools.
The Workshop will Address…
Designing for social comfort requires understanding how people interact in a non-mediated environment and what realities that we know from that understanding must we include in our design and development for use and adoption of our digital social tools if we want optimal adoption and use.
- Tools do not need to be constrained by accepting the 1-9-90 myth.
- Understanding the social build order and how to use that to identify gaps that need design solutions
- Social comfort as a key component
- Matrix of Perception to better understanding who the use types are and how deeply the use the tool so to build to their needs and delivering much greater value for them, which leads to improved use and adoption
- Using the for elements for enterprise social tool success (as well as web facing) to better understand where and how to focus understanding gaps and needs for improvement.
- Ways user experience design can be implemented to increase adoption, use, and value
- How social design needs are different from Web 2.0 and what Web 2.0 could improve with this understanding
More info...
For more information and registration to to Viget Lab's Social Design for the Enterprise page.
I look forward to seeing you there.
June 26, 2009 in Access to Info, Community, Enterprise, Folksonomy, Information Architecture, Information Creation, Interface, Knowledge Management, Research, Social Software, Usability, Web, Web/Tech | Permalink | Comments (0) | TrackBack (0)
SharePoint 2007: Gateway Drug to Enterprise Social Tools
Overview
The last couple of years I have had many conversations with a broad selection of mid-sized to large organizations. Some of these are customers of mine or potential customers while others are conversations I have had, but all having the similar discussion about social tools in the enterprise. What follows is a collection of snippets from those conversations regarding Microsoft SharePoint 2007, most are not publicly attributed as they were not intended to be on the record.
One common element from all of the discussions is the frustration nearly all of these organization have with their experience with Microsoft SharePoint 2007. The comments are based on those spending one month to a year with the tool (the six month to one year club with tools offer best insight).
SharePoint does some things rather well, but it is not a great tool (or even passable tool) for broad social interaction inside enterprise related to the focus of Enterprise 2.0. SharePoint works well for organization prescribed groups that live in hierarchies and are focussed on strict processes and defined sign-offs. Most organization have a need for a tool that does what SharePoint does well.
This older, prescribed category of enterprise tool needs is where we have been in the past, but this is not where organizations are moving to and trying to get to with Enterprise 2.0 mindsets and tools. The new approach is toward embracing the shift toward horizontal organizations, open sharing, self-organizing groups around subjects that matter to individuals as well as the organization. These new approaches are filling gaps that have long existed and need resolution.
Broad Footprint
What SharePoint 2007 Does Well
Microsoft SharePoint 2007 seems to be in every enterprise I talk to, at least somewhere. It is used if a variety of different ways. When SharePoint is included with addition of Microsoft Office Online (MOSS) is a helpful addition for simple use of these older prescribed methods. MOSS is also good at finalizing documents that are the result of a collective, to group, to collaboration knowledge work process. MOSS and SharePoint are not great at anything but the last step of formalizing the document for distribution in another workflow.
A recent report from AIIM that was written-up by CMS Wire in Study Finds SharePoint Primarily Used for File Sharing states 47% use it primarily for file sharing (and/or as an internal Portal 47%).
How Did We Get Here?
There is one common point I have heard with nearly every company I have talked with over the last couple years, MS SharePoint 2007 is nearly ubiquitous in deployment. Nearly every organization has deployed SharePoint in some form or another. Many organization have tested it or have only deployed pieces of it. The AIIM survey reported by CMS Wire states: 83% currently use, or planning to use, SharePoint.
Organizations either sent their IT out for training on SharePoint 2007 and/or brought in consultants to help build an implementation that fit their requirements. Most of the requirements IT departments started with were rather thinly informed, as they have nearly all stated after using SharePoint for a month, most realize after six months or so, their requirements are vastly different than what their initial requirements were, as they have learned more deeply about social tools in the enterprise.
Many who deployed SharePoint, thought it was going to be the bridge that delivered Enterprise 2.0 and a solid platform for social tools in the enterprise is summed up statement, We went from 5 silos in our organization to hundreds in a month after deploying SharePoint. They continue, There is great information being shared and flowing into the system, but we dont know it exists, nor can we easily share it, nor do much of anything with that information. I heard this from an organization about 2 years ago in a private meeting and have been hearing near similar statements since. This is completely counter to the Enterprise 2.0 hopes and wishes they had for SharePoint. They were of the mindset that open sharing & having the organization and individuals benefit from a social platform.
MS Marketings Promise
The Microsoft marketing people seem to have performed their usual, extend what the product can do to the edges of its capabilities (and occasionally beyond) to map to customer stated desires. In 2006 and 2007 the advent of social computing on the web (Web 2.0) had entered the hormone raging stage gathering attention in boardrooms and IT departments who had been playing around with the ideas of bringing these tools inside the firewall in an official manner. The desire for social software to be part of the enterprise was an interest and desire.
The Microsoft marketing materials they focus on collaboration and social computing, which is more of a document management and workflow process tool that they put the more fashionable moniker on. But, it is this Microsoft marketing that engendered many organizations to the idea of the value and promise of social computing inside the firewall and Enterprise 2.0. Microsofts marketing legitimized the marketplace, but in typical Microsoft form did not exactly deliver on the promise of marketing.
Part of the promise of SharePoint is a malleable platform, which many developers who work across platforms complain is one of the least malleable and easy to develop on platforms. There are many constraints built into SharePoint and developers for SharePoint are not cheap. Development cycles for SharePoint as said to be about one third to half longer than most other options. At the Enterprise 2.0 Conference this past Summer in Boston, Lockheed Martin had a session demonstrating what they had built on top of SharePoint and it was quite impressive. But when asked about costs and resources, they said: It took about one year, 40 FTE, and 1 to 5 million U. S. dollars. Very few organizations have those type of resources with availability to take on that task.
What Microsoft marketing did well was sell the value that social tools bring into the enterprise. They put the ideas in the minds of those building requirements (at a minimum to be included in pilot programs) as well as the values derived from using this new generation of social software inside an organization.
Multiple Micro-silos
At various conferences, across many industries, I have spoken at I have been asked to sit in on the SharePoint sessions, which turn into something like group therapy sessions (akin to group therapy in the first Bob Newhart show). There is much frustration and anger being shared as people try to resolve how to share information between groups and easily merge and openly share information once it has been vetted. These groups consistently talk about going directly to their Microsoft support & SharePoint Experts with these problems only to be told it is doable, but far from easy and may break some other things. Finding relevant information or even the inkling that something is happening in some group is nearly impossible. The promise of setting up ad hoc open groups by employees across silos is nearly impossible with out getting authorization.
Information Locked
One of the largest complaints is the information is locked in SharePoint micro-silos and it is nearly impossible to easily reuse that information and share it. Not only is the information difficult to get at by people desiring to collaborate outside the group or across groups, but it is not easily unlocked so that it can benefit from found in search. The Microsoft SharePoint model is one that starts with things locked down (focussed on hierarchies) then opens up, but unlocking is nowhere near as easy a task as it should be.
SharePoint Roadmap Marginalized Over Time
Where do people turn that have gone down the SharePoint route? Well most start by adding solid functionality they had thought SharePoint was going to provide or wished it had. SharePoint has acknowledged some of this weaknesses and has embraced outside vendors that make far superior products to plugin as components.
Some common social tool plug-ins to SharePoint are Socialtext, Atlassian Confluence, and Connectbeam (among with many others). Then there are those who build on top of Sharepoint, like Telligent and News Gator Social Sites. While others are more prone to full platforms that deliver much of the functionality out of the box, like Jive Clearspace.
Plug-ins Extending Functionality to SharePoint
Microsoft makes great promises, or hints at them in its marketing materials for SharePoint along the lines of social software in the enterprise. The first step many organizations take with SharePoint after realizing it does not easily, or even with an abundance of effort, do the expected social software components is to start getting solid proven services and start plugging them in. Many tool makers have taken their great products an made it quite easy to plug them into the SharePoint platform. Want a great wiki tool, not the horrible wiki template, then Confluence or Socialtext is added. Need a great social tagging/bookmarking tool that ties into search (this starts enabling finding the good information in SharePoints micro-silos), then Connectbeam is added.
This list goes on with what can be plugged-in to Sharepoint to extend it into being something it hints strongly it is quite capable of doing. What one ends up with is a quite capable solution, but built on top of one of the more pricy enterprise platforms. In most cases the cost of all the plug-ins together is less than the cost of SharePoint. It is from this point that many organizations realize all of these add-ins work wonderfully with out SharePoint (however, getting all of them to work together as easy plug-ins to each other is not always easy).
Full-Suites On Top of SharePoint
Another option that organizations take is to move in the direction of putting a fully functional social platform on top of SharePoint. Tools like Telligent and NewsGator Social Sites. These are options for those who find value in what SharePoint offers and does well (but and therefore getting rid of it is not an option), but want ease of development and a lower cost of development than is the norm for SharePoint. These full-suites also provide the ease of not having to deal with working through plugging together various different best of bread solutions (this really reminds me of the path content management systems went down, which was less than optimal).
Not only is the Lockheed Martin example of building on top of SharePoint an example of expense of that platform, but the recent AIIM survey surfaces high cost of development as a rather common understanding:
Another area of interest is the required effort to customize SharePoint and integration other third-party solutions. In this case, 50% of survey respondents indicated custom solutions required more effort than expected (33% somewhat more and 17% much more). The integration challenges focused on a lack of training/documentation and integration with non-Microsoft based repositories and existing applications. From CMS Wire: Study Finds SharePoint Primarily Used for File Sharing.
Fully Replacing SharePoint
There is a third option I have been running into the last year or less, which is removing SharePoint from the organization completely. I know of two extremely large organizations that are removing SharePoint from their organization this year (once these organizations are public with this I can be). The reasoning is cost and under performing as a social platform and what is does well is easily replaced with other solutions as well. In one instance I know the people who brought in SharePoint are being let go as well as the whole team of developers supporting it. I am hearing business operations looking into having their IT department find something that is meets their needs and were promised by IT that SharePoint was that solution. This was echoed by Lee Bryant via Twitter [http://twitter.com/leebryant/status/1099413469]: […]problem is many IT depts just dont care - it is a simple solution for them, not their users
When removing SharePoint some organizations are going the piece by piece approach and stitching together best of breed or are going the route of full-service social platform, like Jive Clearspace. The cost per users of such solutions is less, the time to install to up-and-running fully is reportedly a about a third and maintenance staffing is also reportedly lower.
SharePoint is not Enterprise 2.0
What is clear out of all of this is SharePoint has value, but it is not a viable platform to be considered for when thinking of enterprise 2.0. SharePoint only is viable as a cog of a much larger implementation with higher costs.
It is also very clear Microsofts marketing is to be commended for seeding the enterprise world of the value of social software platform in the enterprise and the real value it can bring. Ironically, or maybe true to form, Microsofts product does not live up to their marketing, but it has helped to greatly enhance the marketplace for products that actually do live up to the hype and deliver even more value.
March 11, 2009 in Access to Info, Community, Enterprise, Folksonomy, Knowledge Management, Local InfoCloud, Portability, Social Software, Technology, Travel | Permalink | Comments (27) | TrackBack (1)
LinkedIn: Social Interaction Design Lessons Learned (not to follow) - 2 of 2
This is the second of two posts on the subject, the first post LinkedIn: Social Interaction Design Lessons Learned (not to follow) - 1 or 2 gives the lead-in to this post.
Lessons To Learn
Sadly, the new social functionality has broken much of worked well as an ambient social tool. More problematic was LinkedIn did not seem to grasp what it had: so to build on top of very good start, but it seemingly looked at Facebook for inspiration, but Facebook does not seem to be aware of good social interaction design practices.
When building social tools for broad audiences (more than 3,000 people) — which open services on the web are — there is a progression of 3 things that must be accounted for in the planning stages: 1) Velocity; 2) Volume; 3) Relevance.
As social tools start getting used they go through a progression one of them are these three stages of concern. Velocity of information is how quickly information is added by the community and has turn over on the in the frameworks. Volume is the mass of information that accumulates over time that will force how information is shared, found, and used. Relevance becomes essential when there is large volume and filtering is needed for information flows and for allowing people using the service to have a manageable stream of information that is relevant to their needs.
Many social services can go through these three stages in a few short months if they have 50,000 users or more. LinkedIn does not seem to have considered getting to and beyond the first stage in their planning.
Social Interaction at Scale & Volume
As LinkedIn has added social features they have created more streams of information in their flow. More streams lead to more velocity of information. This can be good if the basic concepts for understanding monitoring these streams as well as providing methods for moving things out of the flow so they can be acted upon or set into a personal task flow.
It seems as if the new social features are aimed at the roughly 80 percent that have 100 or fewer connections, not the moderate or heavy connectors who are the unpaid evangelists that have helped LinkedIn grow. Not understanding the value various segments bring to a service and how to satisfy those groups is rather short sighted
Social Tsunami on Homepage
The one thing that started the frustration with LinkedIn’s shift was the flood of unrelated social items on the homepage. Much of the social content shared is personal ID focused and not group or work focused (even when shared in groups or work related settings - a quick look at activity summaries regularly shows this).
One of the task flows I had with LinkedIn was to accept a connection or get notification of a connection then go to their profile page and download their vCard. The social tsunami that took over the front page of LinkedIn made that task all-but impossible. Part of it is the velocity of information running through the front page for connections increased, velocity the design did not account for.
Additionally, the new social components started eating up valuable real estate on that page and had no simple interaction design convention for minimizing, hiding, or turning off that module of functionality from the page.
Eventually the ability to turn off notifications to the social tools was added to the Settings page, but there is no notification of that functionality on where the problem exists, the pages where this container shows up (we learned this in software design in the early 90s). Also problematic is the social elements are clustered by task/tool relevance and not person or subject. Including pivots could greatly improve this as well as allow for shifting context by the person using LinkedIn.
Focal prioritization is essential to include in initial planning, as this becomes critical when dealing with the relevance stage or even handling a scaling volume of information. Each person using a service is going to have a slightly different set of priorities for relevance and focus. This is going to require some malleability of the system interface to allow for personal optimization of their relevance and streams.
This is not emergent behavior but the reality of what happens when systems scale. LinkedIn is built “;like a classic chamber meeting where networking is orchestrated”;, as stated by Margaret Rosas. Sadly, LinkedIn is not built for flexibility that is needed as systems scale to or beyond the volume stage. It is built as if this was a surprise, which prior to 18 months ago LinkedIn’s careful approach was much smoother with their growth of features and functionality.
LinkedIn changed its layout and structure of its pages to account for the coming new functionality, which is quite smart. But it did so in a manner that seemed to consider all notifications and functionality should have the same focus.
If you remove notifications, there is no ambient notification to let you know there is really any activity. The front page is part portal and part dashboard, but the distinct concepts around these two approaches seem to have baffled the interaction designers and developers.
LinkedIn: Social Node or Social Hub?
LinkedIn also seems quite schizophrenic as to its social purpose. It has built part of the social framework as if the rest of the web only allowed limited interaction with it, which it would make it just a node on a network. This destination framework does not account for people having any other service that provides social features that could easily be shared in or out.
The other side of LinkedIn is a hub, which information flows though. Inbound status messages from other services show up in LinkedIn’s pages as to the “applications”, but using connecting identity in a manner that permits not having Twitter messages I read elsewhere show up in LinkedIn would be more than helpful (yes, part of this is OAuth, which Twitter and many other have not deemed valuable yet (come on Twitter this is not rocket surgery). The applications and information it allows in is limited to a relatively small number of services. Having a small number of services integrated should allow for contextual relevance of the objects, but that would be assuming again LinkedIn was well thought through. This interaction with services would also benefit form LinkedIn offering OpenID as well as OAuth integration to ease the pain and security.
LinkedIn does not have an open API as of yet (this should have happened when they launched status and some other social elements). The LinkedIn API for status would allow LinkedIn to be a sharing out hub as well as the partially capable in-bound hub it already is. LinkedIn is a business focussed social environment, but has not realized its DNA is business based and there are task flows and workflows to enable that would make a lot of sense.
LinkedIn Forgot the “Me” in Social
All social begins with me. Social interaction is about an individuals intentions, actions, and their activities. What things a person wants to share with others and how interact with is one part of the social framework. Another other is consumption and working with the flows of content generated by others. LinkedIn did a decent job with flow until it started adding the more social features in the last 18 months. What LinkedIn did know (focus and purpose) they now show little grasp of understanding as their features have created more flow and more velocity for the information ebbing through the service with no planning for it. It takes very little understanding of social tools to know that this will likely happen and there are interaction elements that are going to be required to handle this, for example moving things out of the flow.
Many people want to see those they have just connected with, things they just published/shared and responses. There is also the desire to hold on to things that are relevant to the individual. This holding on to things requires a means to favorite or put it in place where things can be collected and worked on later. These things could be single comments in group discussions, people’s names/profiles who are surfacing, notifications, etc.
With the velocity of information increasing in LinkedIn the capability to perform a task and drop back into the flow where you were is gone. Any decent interaction designer for social tools knows this reality and had a stack of solutions to set in place from the outset.
Social Context in Groups
The math of social software for people is the mostly the one-to-one relationships and being able to see those. But, social software occasionally is about communicating to groups.
LinkedIn added group discussions, but did this as if the last 10 to 15 years in forums and groupware platforms never existed. The group discussions are not threaded nor do they offer the option to turn on threading for the discussions (this has been default for off-the-shelf forums for over 8 years at least). Also lacking is the capability to hold on to and collect valuable items found in discussions, let alone a means to personally contextualize them.
Another thing LinkedIn fails to grasp is contextual relationships to people in the discussions. For example, if someone I know has started or commented in a group discussion the service should highlight this. There is a potentially higher social contextual relevance for that piece of information. When information starts turning from a stream into a flood this becomes insanely important.
Once this reality of contextualizing is realized, there are a couple of options that are likely to be needed quite quickly after. One is adding new people in the discussion that we interact with; this context could be surfaced in the discussion or used to augment the rational surfaced in the recommendations.
Email from groups should not be from the organization name of the group as that looks like it is from the organization. I get official information from organizations, but lacking the understanding of contextual information for e-mail makes an even greater mess of e-mail and group interactions when this is lazily designed. The “from” should begin with LinkedIn group or some other notation.
Context for Events
When LinkedIn added events, I started getting invitations to attend them. But, the wording of the invites made it sound like they were personal invitations, which is not the context they were intended. It took quite a few rather embarrassing e-mails for many events, if they were really requesting my attendance or if it was just an announcement of the event. Understanding a modicum of social interaction and social etiquette would have saved those embarrassing e-mails.
Events also launched with many bugs (many have been ironed out, but most were of the rather blatant variety). One downside of events is there are already an over abundance of event tools, which work rather well (this is a really tough tool set to get right and build). Nearly everybody I talk to has wondered why LinkedIn did not use something like Confabb to license it or buy it (there are many event services available), rather than using their own resources on something that is not up to the level of competing products. Lastly, with regard to events, while the recommendation for connections is good in LinkedIn, the recommendations for events is absolutely horrid. If that is who LinkedIn thinks I am I need a new service now.
Models for Messaging Flows
One of the things that has been flawed in LinkedIn for quite some time is messaging flows. I liked that they pushed messaging out into e-mail and I could respond to a person from my e-mail. One thing that is missing is LinkedIn not updating their messaging flows. Looking in LinkedIn it is quite often impossible to sort out. When I stated I continually have this problem, Jess Leccetti stated, “I’ve had that exact problem! I thought it was my comp being buggy!” Messaging across various media channels is tough and most often fractured. But, when offering a solution it is important to get it right.
Profile Comments Go In...
Finally LinkedIn added the capability to for people using the service to add their own private comments on to other’s profiles. This is a great addition as it allows the means to add context to files. Sadly, it does not seem to surface that information in any other manner other than going to the individual pages.
This lack of functionality outside each profile page is really mind blowing, as it leaves out the capability for using it for tagging, contextual grouping, search aggregation, and use these aggregations for sharing up dates or filtering what is shared. There are emergent activities that could evolve out of these functionalities, but again this seems to not be well thought through.
One approach is a nice simple personal tagging or labeling interaction layer with clickable aggregation interface option. This would allow simply applying glue to personally thread items together through light aggregation. The current comment system only creates islands of context that have chasms between it and other relevant or related items.
Next Steps
LinkedIn needs to get some people in that grasp social interaction design. They purportedly have some, but I am not sure they have influence or the depth of knowledge needed (either is problematic). The LinkedIn service seems to be proof something is horribly wrong along these lines.
LinkedIn also seems to be a victim of not sorting-out what it wants to be. If it wants to be a Facebook for business, the route they are taking is not going to work well for the business users as it is greatly lacking solid functionality and cohesive interaction design with task flows enabled. LinkedIn needs to be LinkedIn and not a Facebook for business.
As many on Twitter have stated, one seemingly viable option is LinkedIn’s social additions of the last 18 months should all be thrown out and simply start over. The only piece that seems to have much positive feedback is the Q&A section, which is not something that I have interest in, but seems to work passably for others.
More coherently, a real reality check is needed at LinkedIn. They must to stop adding features and functionality until they learn to fix what they have added. They need to begin with understanding how social interaction happens, how it scales, and how people need it to work at scale. Stop looking at Facebook for what features to add. LinkedIn has some deep value as a work and business focussed social site, but that is going to require a different focus that what has been applied in the last year to 18 months.
I have deep fear that LinkedIn views what is happening is emergent (emergence happens when things are used in an unpredictable manner: whether wholly unpredictable or unpredictable in that context). What is happening in LinkedIn is not emergent. It is quite predictable: This is what happens at scale with social systems and their information flows.
A grasp of social systems and their uses at various levels of scale (and potential for various interactions and needs) is really needed at LinkedIn. The slowness to act (or, sadly, react as if this was an unknown potential) and fix what they have is not a great sign of encouragement for the organization. Hopefully having Reid Hoffman back as CEO and with Jeff Wiener as President can pull this into focus and set things on a sane path.
February 10, 2009 in Attraction, Community, Enterprise, Folksonomy, Identity, Information Architecture, Interface, Refindability, Social Software, Usability, Web | Permalink | Comments (1) | TrackBack (0)
LinkedIn: Social Interaction Design Lessons Learned (not to follow) - 1 of 2
Why LinkedIn Needs to Have a Better Grasp of Social
A heavy user of LinkedIn, I have been hearing identical complaints to my own as regular business networking event conversation fodder for the last six months or more. Light users of LinkedIn as well as those of us who have over 600 connections have nearly identical problems.
At its core the social interactions design is severely flawed and poorly thought through. LinkedIn integrates social interaction components and features as if they were playing a game of "me too" with Facebook. This is problematic as much of the Facebook social interaction design is poorly executed. I have stated how Facebook's DNA does not support business use (in Facebook for Business or LinkedIn Gets More Valuable. Oddly, now LinkedIn seems to be building the poorly thought-through Facebook interactions, implementations which are directly counter to their reason for being.
Wake-up LinkedIn! You may have money to get you through some sort of recession that lasts for a while, but your business relevance requires you to get these things right and get them correct now.
Too Many New Features, Too Fast
LinkedIn now has conflict and confusion about its primary focus as a service and what is the primary social object. Prior to 18 months ago LinkedIn was more or less a live resume and work connections site. The social object was the individual person and the focus was clear and social actions, while limited, were clear and focussed too. The addition of more social interaction and services has completely lost that sense of focus and could be one of the causes of poorly built social tools.
The last 18 months or so has LinkedIn seeming like it wants to be more of a Social communication site, workplace social platform, and/or general social site like Facebook with a quasi-focus around work-life.The lack of central understanding of what LinkedIn is also has increased the scatter shot understanding of social and voice (based on really confounding contexts for understanding). The inclusion of social elements that bleed into LinkedIn, with similarities to Facebook, are executing on the same social understanding of social interaction design that acts as if the last 8 to 15 years in digital social interaction design and knowledge did not exist.
This is a compilation of things that have been increasingly bothering me with the rollout of LinkedIn's social features. They seem to roll out features that are not fully baked. Then, they release new features rather than fixing the poorly thought through functionality already deployed. I have delayed writing this as I have heard many of these items were going to get fixed (but have not after far too long). I also have many friends at LinkedIn and have not wanted to rock their boat (but many of them have publicly and privately encouraged me to write this publicly).
Another reason for posting this is I am seeing these mistakes many places. Far too many "social x gurus" are just users of less than optimal systems. They don't grasp the less-than-optimal features are holding back the tool adoption, in addition to a lack of social interaction design.
This muddled social mess triggered Jonathan S. Knoll to proclaim on Twitter, "LinkedIn: the online community of people you don't really like."
What Worked Well
LinkedIn worked well for me as an ambient social network for business contacts. The last 3 or 4 years LinkedIn has been one tab that was always open in my work browser (until a couple weeks ago when I got fed up). I would watch the ambient flow of who changed jobs, titles, connections, and what they were seeking. These were social business clues that I used as opportunities to reconnect with people and see where I could help out.
LinkedIn was a great tool for strengthening business relationships. Quite often I would offer help to someone job seeking or send congratulations on new role or job. The communications often lead to chatting about working together, which had a really good business upside for me.
Watching people connect has value in finding people I already knew and had not connected with, as well as having some understanding of who outside a community is looking for help (those who say they can tell everything about a person by who they connect to don't understand social interaction dynamics very well, particularly around business relationships and business growth).
LinkedIn's recommendation services for finding others to connect with have been really good. The only other service that is this strong in my opinion is Plaxo, which is a service that increasingly has taken the place of LinkedIn for me. Plaxo understands volume, various levels of relationship, and keeping contact information current where you need it (in address books, not is disconnected services). LinkedIn is also really good for capturing and making recommendations of one's work.
Something LinkedIn has done rather well is its iPhone application, which really should be extended to other mobile platforms for smart phones. It finally enabled the ability to use contact information in a use context that matters and outside their service (mail does some of this but it is broken as in LinkedIn responses and external responses are not coordinated).
LinkedIn's question and answers section has been done rather well. Many people find it valuable and get good use from it. There are many things that could be done to augment it, particularly around using it to build an understanding of reputation around subject matter. It also could use the ability to easily hold on to (and annotate for one’s self) good suggested answers. This is the sign of a decently thought-through social platform.
The second part to this post, LinkedIn: Social Interaction Design Lessons Learned (not to follow) - 2 of 2 looks at some specific lessons learned from LinkedIn.
February 9, 2009 in Access to Info, Community, Identity, Interface, Personal Info, Social Software, Usability, Web, Web/Tech | Permalink | Comments (0) | TrackBack (0)
Optimizing Tagging UI for People & Search
Overview/Intro
One of my areas of focus is around social tools in the workplace (enterprise 2.0) is social bookmarking. Sadly, is does not have the reach it should as it and wiki (most enterprise focused wikis have collective voice pages (blogs) included now & enterprise blog tools have collaborative document pages (wikis). I focus a lot of my attention these days on what happens inside the organization’s firewall, as that is where their is incredible untapped potential for these tools to make a huge difference.
One of the things I see on a regular basis is tagging interfaces on a wide variety of social tools, not just in social bookmarking. This is good, but also problematic as it leads to a need for a central tagging repository (more on this in a later piece). It is good as emergent and connective tag terms can be used to link items across tools and services, but that requires consistency and identity (identity is a must for tagging on any platform and it is left out of many tagging instances. This greatly decreases the value of tagging - this is also for another piece). There are differences across tools and services, which leads to problems of use and adoption within tools is tagging user interface (UI).
Multi-term Tag Intro
The multi-term tag is one of the more helpful elements in tagging as it provides the capability to use related terms. These multi-term tags provide depth to understanding when keeping the related tag terms together. But the interfaces for doing this are more complex and confusing than they should be for human, as well as machine consumption.
In the instance illustrated to the tag is comprised or two related terms: social and network. When the tool references the tag, it is looking at both parts as a tag set, which has a distinct meaning. The individual terms can be easily used for searches seeking either of those terms, but knowing the composition of the set, it is relatively easy for the service to offer up "social network" when a person seeks just social or network in a search query.
One common hindrance with social bookmarking adoption is those familiar with it and fans of it for enterprise use point to Delicious, which has a couple huge drawbacks. The compound multi-term tag or disconnected multi-term tags is a deep drawback for most regular potential users (the second is lack of privacy for shared group items). Delicious breaks a basic construct in user focussed design: Tools should embrace human methods of interaction and not humans embracing tech constraints. Delicious is quite popular with those of us malleable in our approach to adopt a technology where we adapt our approach, but that percentage of potential people using the tools is quite thin as a percentage of the population.. Testing this concept takes very little time to prove.
So, what are the options? Glad you asked. But, first a quick additional excursion into why this matters.
Conceptual Models Missing in Social Tool Adoption
One common hinderance for social tool adoption is most people intended to use the tools are missing the conceptual model for what these tools do, the value they offer, and how to personally benefit from these values. There are even change costs involved in moving from a tool that may not work for someone to something that has potential for drastically improved value. The "what it does", "what value it has", and "what situations" are high enough hurdles to cross, but they can be done with some ease by people who have deep knowledge of how to bridge these conceptual model gaps.
What the tools must not do is increase hurdles for adoption by introducing foreign conceptual models into the understanding process. The Delicious model of multi-term tagging adds a very large conceptual barrier for many & it become problematic for even considering adoption. Optimally, Delicious should not be used alone as a means to introduce social bookmarking or tagging.
We must remove the barriers to entry to these powerful offerings as much as we can as designers and developers. We know the value, we know the future, but we need to extend this. It must be done now, as later is too late and these tools will be written off as just as complex and cumbersome as their predecessors.
If you are a buyer of these tools and services, this is you guideline for the minimum of what you should accept. There is much you should not accept. On this front, you need to push back. It is your money you are spending on the products, implementation, and people helping encourage adoption. Not pushing back on what is not acceptable will greatly hinder adoption and increase the costs for more people to ease the change and adoption processes. Both of these costs should not be acceptable to you.
Multi-term Tag UI Options
Compound Terms
I am starting with what we know to be problematic for broad adoption for input. But, compound terms also create problems for search as well as click retrieval. There are two UI interaction patterns that happen with compound multi-term tags. The first is the terms are mashed together as a compound single word, as shown in this example from Delicious.
The problem here is the mashing the string of terms "architecture is politics" into one compound term "architectureispolitics". Outside of Germanic languages this is problematic and the compound term makes a quick scan of the terms by a person far more difficult. But it also complicates search as the terms need to be broken down to even have LIKE SQL search options work optimally. The biggest problem is for humans, as this is not natural in most language contexts. A look at misunderstood URLs makes the point easier to understand (Top Ten Worst URLs)
The second is an emergent model for compound multi-term tags is using a term delimiter. These delimiters are often underlines ( _ ), dots ( . ), or hyphens ( - ). A multi-term tag such as "enterprise search" becomes "enterprise.search", "enterprise_search" and "enterprise-search".
While these help visually they are less than optimal for reading. But, algorithmically this initially looks to be a simple solution, but it becomes more problematic. Some tools and services try to normalize the terms to identify similar and relevant items, which requires a little bit of work. The terms can be separated at their delimiters and used as properly separated terms, but since the systems are compound term centric more often than not the terms are compressed and have similar problems to the other approach.
Another reason this is problematic is term delimiters can often have semantic relevance for tribal differentiation. This first surface terms when talking to social computing researchers using Delicious a few years ago. They pointed out that social.network, social_network, and social-network had quite different communities using the tags and often did not agree on underlying foundations for what the term meant. The people in the various communities self identified and stuck to their tribes use of the term differentiated by delimiter.
The discovery that these variations were not fungible was an eye opener and quickly had me looking at other similar situations. I found this was not a one-off situation, but one with a fair amount of occurrence. When removing the delimiters between the terms the technologies removed the capability of understanding human variance and tribes. This method also breaks recommendation systems badly as well as hindering the capability of augmenting serendipity.
So how do these tribes identify without these markers? Often they use additional tags to identity. The social computing researchers add "social computing", marketing types add "marketing", etc. The tools then use their filtering by co-occurrence of tags to surface relevant information (yes, the ability to use co-occurrence is another tool essential). This additional tag addition help improve the service on the whole with disambiguation.
Disconnected Multi-term Tags
The use of distinct and disconnected term tags is often the intent for space delimited sites like Delicious, but the emergent approach of mashing terms together out of need surfaced. Delicious did not intend to create mashed terms or delimited terms, Joshua Schachter created a great tool and the community adapted it to their needs. Tagging services are not new, as they have been around for more than two decades already, but how they are built, used, and platforms are quite different now. The common web interface for tagging has been single terms as tags with many tags applied to an object. What made folksonomy different from previous tagging was the inclusion of identity and a collective (not collaborative) voice that intelligent semantics can be applied to.
The downside of disconnected terms in tagging is certainty of relevance between the terms, which leads to ambiguity. This discussion has been going on for more than a decade and builds upon semantic understanding in natural language processing. Did the tagger intend for a relationship between social & network or not. Tags out of the context of natural language constructs provide difficulties without some other construct for sense making around them. Additionally, the computational power needed to parse and pair potential relevant pairings is somethings that becomes prohibitive at scale.
Quoted Multi-term Tags
One of the methods that surfaced early in tagging interfaces was the quoted multi-term tags. This takes becomes #&039;research "social network" blog' so that the terms social network are bound together in the tool as one tag. The biggest problem is still on the human input side of things as this is yet again not a natural language construct. Systematically the downside is these break along single terms with quotes in many of the systems that have employed this method.
What begins with a simple helpful prompt...:
Still often can end up breaking as follows (from SlideShare):
Comma Delimited Tags
Non-space delimiters between tags allows for multi-term tags to exist and with relative ease. Well, that is relative ease for those writing Western European languages that commonly use commas as a string separator. This method allows the system to grasp there are multi-term tags and the humans can input the information in a format that may be natural for them. Using natural language constructs helps provide the ability ease of adoption. It also helps provide a solid base for building a synonym repository in and/or around the tagging tools.
While this is not optimal for all people because of variance in language constructs globally, it is a method that works well for a quasi-homogeneous population of people tagging. This also takes out much of the ambiguity computationally for information retrieval, which lowers computational resources needed for discernment.
Text Box Per Tag
Lastly, the option for input is the text box per tag. This allows for multi-term tags in one text box. Using the tab button on the keyboard after entering a tag the person using this interface will jump down to the next empty text box and have the ability to input a term. I first started seeing this a few years ago in tagging interfaces tools developed in Central Europe and Asia. The Yahoo! Bookmarks 2 UI adopted this in a slightly different implementation than I had seen before, but works much the same (it is shown here).
There are many variations of this type of interface surfacing and are having rather good adoption rates with people unfamiliar to tagging. This approach tied to facets has been deployed in Knowledge Plaza by Whatever s/a and works wonderfully.
All of the benefits of comma delimited multi-term tag interfaces apply, but with the added benefit of having this interface work internationally. International usage not only helps build synonym resources but eases language translation as well, which is particularly helpful for capturing international variance on business or emergent terms.
Summary
This content has come from more than four years of research and discussions with people using tools, both inside enterprise and using consumer web tools. As enterprise moves more quickly toward more cost effective tools for capturing and connecting information, they are aware of not only the value of social tools, but tools that get out the way and allow humans to capture, share, and interact in a manner that is as natural as possible with the tools getting smart, not humans having to adopt technology patterns.
January 24, 2009 in Enterprise, Folksonomy, Information Architecture, Interface, Knowledge Management, Social Software, Tools, Usability | Permalink | Comments (1) | TrackBack (0)
Tale of Two Tunnels: Web 2.0 and Enterprise 2.0
Yesterday I made a few comments in Twitter that prompted a fair amount of questions and requests for more information. The quips I made were about the differences between Web 2.0 (yes, an ambiguous term) and Enterprise 2.0 (equally ambiguous term both for the definition of enterprise and the 2.0 bit). My comments were in response to Bruce Stewart's comment The whole "Enterprise 2.0" schtick is wearing thin, unless you've been monitoring real results. Otherwise you're just pumping technology.. In part I agree, but I am really seeing things still are really early in the emergence cycle and there is still much need for understanding of the social tools and the need for them, as well as how they fit in. There are many that are selling the tools as technologies with great promise. We have seen the magic pill continually pitched and bought through out the history of business tools. (For those new to the game or only been paying attention for the last 15 years, a huge hint, THERE IS NO MAGIC PILL).
Tale of 2 Tunnels
One comment I made yesterday is, "the difference between Web 2.0 and Enterprise 2.0 is like the difference building a tunnel through rock and tunnel under water".
That this is getting at is Web 2.0 takes work to build to get through the earth, but once built it can suffer from imperfections and still work well. The tunnel can crack and crumble a little, but still get used with diminished capacity. We can look at Facebook, which has a rather poor interface and still gets used. Twitter is another example of a Web 2.0 solution that has its structural deficiencies and outages, but it still used as well as still loved (their Fail Whale is on a t-shirt now and a badge of pride worn by loyal users).
The Enterprise 2.0 tunnel is built under water. This takes more engineering understanding, but it also requires more fault testing and assurances. A crack or crumbling of a tool inside an organization is not seen kindly and raises doubts around the viability of the tool. The shear volume of users inside an organization using these tools is orders of magnitude less than in the open consumer web world, but faults are more deadly.
The other important factor is perceived fear of the environment. Fewer people (by pure numbers - as the percentages are likely the same, more on this later) are fearful of tunnels through land, they may not have full faith in them, but they know that they will likely make it safely on all of their journeys. The tunnels under water have greater fears as one little crack can cause flooding and drowning quickly. Fears of use of social tools inside an organization is often quite similar, there may be many that are not fearful, but if you spend time talking to people in organizations not using tools (it is the majority at this point) they are fearful of open sharing as that could lead to trouble. People are not comfortable with the concept as they are foreign to it as they are lacking the conceptual models to let them think through it.
Enterprise 2.0 is not Web 2.0
Another statement yesterday that garnered a lot of feedback was, "Web 2.0 does not work well in enterprise, but the approaches and understandings of Web 2.0 modified for enterprise work really well." The web is not enterprise or smaller organizations for that matter. The open consumer web has different scale and needs than inside organizations and through their firewalls. A small percentage of people using the web can get an account on a tool have have appear to be wildly successful correctly claiming 70 million or 100 million people are or have used their tool. But, even 100 million people is a small percentage of people using the web. Looking at real usage and needs for those tools the numbers are really smaller. Most darlings of the Web 2.0 phase have fewer than 10 million users, which is about 5% of the open consumer web users in the United States. On the web a start-up is seen as successful with 500,000 users after a year or two and is likely to have the capability to be self sufficient at that level too. Granted there are many players in the same market niches on the web and the overall usage for link sharing and recommending for Digg, Mixx, or Reddit is much higher across the sum of these tools than in just one of these tools (obviously).
These percentages of adoption and use inside organizations can make executives nervous that their money is not reaching as many employees as they wish. The percentages that can be similar to the web's percentages of high single digit adoption rates to the teens is seen as something that really needs more thinking and consideration.
Enterprise 2.0 is more than just tools (see my Enterprise Social Tools: Components for Success for better understanding) as it also includes interface/interaction design for ease of use, sociality, and encouragement of use. The two biggest factors that are needed inside an organization that can receive less attention on the web are the sociality and encouragement of use.
Understanding sociality is incredibly important inside an organization as people are used to working in groups (often vertical in their hierarchy) that have been dictated to them for use. When the walls are broken down and people are self-finding others with similar interests and working horizontally and diagonally connecting and sharing with others and consuming the collective flows of information their comfortable walls of understanding are gone. A presentation in Copenhagen at Reboot on Freely Seeping Through the Walls of the Garden focussed just on this issue. This fear inside the enterprise is real. Much of the fear is driven by lacking conceptual models and understanding the value they will derive from using the tools and services. People need to know who the other people are that they are sharing with and what their motivations are (to some degree) before they have comfort in sharing themselves.
Encouraging use is also central to increased adoption inside organizations. Many organizations initial believe that Web 2.0 tools will take off and have great adoption inside an organization. But, this is not a "build it and they will come" scenario, even for the younger workers who are believed to love these tools and services and will not stay in a company that does not have them. The reality is the tools need selling their use, value derived from them, the conceptual models around what they do, and easing fears. Adoption rates grow far beyond the teen percentages in organizations that take time guiding people about the use of the tools and services. Those organizations that take the opportunity to continually sell the value and use for these tools they have in place get much higher adoption and continued engagement with the tools than those who do nothing and see what happens.
Gaps in Enterprise Tools
The last related statement was around the gaps in current and traditional enterprise tools. At the fantastic Jive Enterprise UI Summit in Aspen a few weeks ago there was a lot of discussion about enterprise tools, their UI, and ease of use for employees by the incredible collection of people at the event. One of the things that was shown was a killer path of use through a wide encompassing enterprise toolset that was well designed and presented by SAP's Dan Rosenberg who has done an incredible job of putting user experience and thinking through the needed workflows and uses of enterprise tools at the forefront of enterprise software planning. Given the excellent design and incredible amount of user experience thought that went into the tools behind the SAP toolset in the scenario (one of the best I have seen - functioning or blue sky demoed) there are still gaps. Part of this is identifying of gaps comes from traditional business thinking around formal processes and the tools ensure process adherence. But, the reality is the tools are quite often inflexible (I am not talking about SAP tools, but traditional enterprise tools in general), the cost of time and effort is beyond the gain for individuals to document and annotate all decisions and steps along the way. The hurdles to capture information and share it are often too large for capturing one to 10 quick sentences of information that can be retained for one's own benefit or shared with other where it is relevant.
There is another gap in business around the collective intelligence that is needed, which can lead to collaboration. Most businesses and their tools focus on collaboration and set groups, but at the same time wonder why they do not know what their company knows and knowledge is not all being captured. First there is a difference between collective and collaborative activities and the tools and design around and for those different activities is more than a nuance of semantics it is a huge barrier to capturing, sharing, and learning from information that leads to knowledge if it is not understood well. Enterprise has gone through its phases of knowledge management tools, from forms for capturing information, forums for sharing, and up to enterprise content management systems (ECM) that encompass document management, content management, knowledge management, and information harvesting. But, the gaps still exist.
These existing gaps are around conversations not being captured (the walls of the halls have no memory (well today they do not)) and increasingly the ubiquitous communication channel in organizations, e-mail, is being worked around. Quick decisions are not being documented as it is not enough for a document or worth completing a form. As the iterative processes of development, design, and solution engineering are happening at quicker and smaller increments the intelligence behind the decisions is not being captured or shared. This is largely because of the tools.
As has always been the case large enterprise systems are worked around through the use of smaller and more nimble solutions that augment the existing tools. Even in Dan's incredible demo I saw gaps for these tools. The quick tools that can fill these gaps are blogs, wikis, social bookmarking, tagging, Twitter type sharing, Veodia type video sharing, instant messaging, etc. There are many avenues to quickly capture information and understanding and share it. These tools get out of the way and allow what is in someone's head to get digitized and later structured by the individual themselves or other people whom have had the information shared with them in a community space. This turns into flows through streams that can be put into many contexts and needs as well as reused as needed.
Another point Dan stated at the Enterprise UI Summit that is dead on, is organizations are moving out of the vertical structures and moving to the horizontal. This is having a profound effect on the next generation of business tools and processes. This is also an area for Enterprise 2.0 tools as they easily open up the horizontal and diagonal prospects and tie into it the capability for easily understanding who these newly found people are in an organization through looking at their profiles, which eases their fears around sharing and unfamiliar environments as well as their related tasks.
August 27, 2008 in Applications, Community, Enterprise, Folksonomy, Information Creation, Knowledge Management, Refindability, Social Software, Technology, Tools, Weblogs | Permalink | Comments (5) | TrackBack (2)
Stewart Mader is Now Solo and One to Watch and Hire
There seems to be many people that are joining the ranks of solo service providers around social tools. Fortunately there are some that are insanely great people taking these steps. Stewart Mader is one of these insanely great people now fully out on his own. Stewart Mader's Wiki Adoption Services are the place to start for not only initial stages of thinking through and planning successful wiki projects, but also for working through the different needs and perspectives that come with the 6 month and one year realizations.
Those of you not familiar with Stewart, he wrote the best book on understanding wikis and adoption, Wikipatterns and is my personal favorite speaker on the subject of wikis. Others may have more broadly known names, but can not come close to touching his breadth nor depth of knowledge on the subject. His understandings of wikis and their intersection with other forms and types of social tools is unsurpassed.
I welcome Stewart to the realm of social tool soloists experts. I look forward to one day working on a project with Stewart.
August 18, 2008 in Enterprise, Information Creation, Knowledge Management, Social Software, Tools | Permalink | Comments (0) | TrackBack (0)
"Building the social web" full-day workshop in Copenhagen on June 30th
Through the wonderful cosponsoring of FatDUX I am going to be putting on a full-day workshop Building the Social Web on June 30th in Copenhagen, Denmark (the event is actually in Osterbro). This is the Monday following Reboot, where I will be presenting.
I am excited about the workshop as it will be including much of my work from the past nine months on setting social foundations for successful services, both on the web and inside organizations on the intranet. The workshop will help those who are considering, planning, or already working on social sites to improve the success of the services by providing frameworks that help evaluating and guiding the social interactions on the services.
Space is limited for this workshop to 15 seats and after its announcement yesterday there are only 10 seats left as of this moment.
June 11, 2008 in Community, Conferences, Enterprise, Folksonomy, Knowledge Management, Refindability, Social Software | Permalink | Comments (1) | TrackBack (0)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=c367bb8b-4652-46bc-bc0d-996c1a2d5205)

