Slack is more than chat: Why it is the trojan horse to better enterprise

During the last couple of years, since Slack has been publicly available, it has taken off like wildfire. To many it is "just a chat service", which gets derided and belittled like most chat services do. This is until they find that chat has not only a place in organizations it has lasting value in organizations, proven out over the last 5 to 8 years (if not longer). Slack, much like prior chat services, do really well in organizations. As a "presence service" (is the person at their desk or available) and a means to ask a quick question or have a quick discussion (synchronously or asynchronously). Over the last 5 to 8 years chat and messaging services took off in organizations. This is not they took off and became popular in pockets of organizations, but have become standard tools everywhere. Messaging not only became the norm, but in many (if not most) organization the messaging platform is second most used service behind email (often Outlook) that is centrally supplied and supported (I know a few organizations where messaging is used more than email and is their most used application / service).

If the email client is Outlook, more than likely the messaging service has been Lync (now rebranding to Skype for Business). The downside to Lync isn't that it is used heavily, but it isn't supported well enough with archiving and with solid search capability. Many IT shops say all the messaging (even if just text based) would eat loads of space to store it. It is a capacity problem in IT's perspective, which when broken down on a per person level it is less than a few gigs of text per year that are created from active users. The last few years Lync has been used heavily for internal voice and video (where allowed) messaging, which not only eats storage at a faster rate, but voice search is still not commercially available with good enough accuracy at a low enough price to be viable for voice in practice. The last issue has little to do with capacity, but is compliance focussed and storing of messages isn't seen as compatible with the organization's policies, which means many of their other knowledge capture capabilities are likely crippled to some degree as well. But, for organizations that believe storing messages and supplying really solid search is limited by capacity constraints a tool like Slack becomes the organization's dream.

So, Slack is a better messaging service?

Well, Slack didn't become popular (these days try and find an organization that isn't using Slack in it somewhere and paying to use it) because it was just another messaging service. There are loads of chat and messaging services for business and enterprise, like HipChat (the largest most similar product), Lync / Skype for Business, Jabber based services, or other less capable services that were developed by those who misbelieve chat is just simple and easy to make. What has Slack standing out is (similar to HipChat) syncing across all platforms, from your pocket, to your desk, or on your coffee table / sofa. But, unlike HipChat, Slack stood out for being not only easy to use, but fun to use. Part of this is the helpful Slackbot that guides users and provides assistance with a playful, yet helpful personality (personality that fits a service and need is incredibly helpful with bots is it help discern with service and bot you are interacting with in our lovely human brains) as well as the myriad of other bots that are available to add in.

Why is Slack people's buddy?

But, this isn't the whole reason Slack is being used, spreading widely, and relatively quickly. Slack is more than chat, which can be used quickly to interact with others and keep information out of email. But, Slack and its personality(ies) address some most acute pain points that are in every organization: Knowledge capture and retrieval; Search; and Interoperability / integration. All three of these organizational maladies not only have long been problematic most of the "solutions" for them over the years suck (to put it politely) for the people using them.

It is important to keep in mind Slack is founded and built by game developers who focus on creating fun and engaging environments. They deeply get staying away from creating pain points for customers / users, as well as reducing them - this isn’t the clicksperts gamification, it is real game mechanics and game design models / theory at work.

Knowledge capture and retrieval

Email has for more than a decade or two been known as the death bed for knowledge in organizations where things are captured and shared are never to be seen again. Yes, think of the cesspit that is email (we've known this problem for 20+ years) with each email little envelope not as that nice friendly symbol but as a tombstone for the dead / never to be live again knowledge within it. It is now you have got the reality of the last 20 plus years. But, more open systems that allow for capturing, sharing, and most importantly searching have really good value to move things forward.

Many organizations value capturing the knowledge they create and have within it. They also have interest in having that knowledge shared and found by others who can benefit from it, so the organization gets smarter faster. The key pain point is capturing what is known, often this is set as a separate set of actions and activities from what people do in their regular workflows and conversation / interaction models. This separation of flow and spaces decreases the use of the knowledge services. These separate services have their place and value as spaces and places for focussed (either team task focussed, project relevant investigations, or subject interest focussed) discussion and development of ideas. But, the conversations that happen in the flow of work are valuable to capture as they happen, then have them addressable / linkable and searchable.

Services that capture conversation and communication in open, historically captured, and addressable spaces have long been far more valuable than email. This value is replicated often with the ever present situation of bring somebody new into the team, project, and / or conversation. The context and history is there to be seen, the important items can be marked or pinned in a manner so they stand out as well as getting context around those items in their original context. Getting a new person conversant and in the flow of things (as well as not out of the loop in conversations that are current) is incredibly valuable when trying to get things done and done well.

Slack provides that means to capture the conversations as they happen. It provides the means to pin (and now with emoji responses, a hackable means) relevant valuable chunks of the conversations and streams.

Good search (yes, you read that right)

Search in and across enterprise, is often painful as it is not very good at finding things. One of the benefits of Slack for many is the search is quite good. Not only is Slack good at retrieving past messages and conversations, but anything that is linked to in Slack or attached as shared objects (text related or with text metadata) in Slack all become searchable. When the linked items or objects are returned in search they are surfaced within the context of the conversation they were shared. People using Slack in organizations have been amazed with the quality of search for finding and refinding shared knowledge and resources, but also relating the item to why and how it was shared. To those who are deprived of viable search in organizations Slack is a real treasure.

Most enterprise search provides success in only 4 of 5 attempts (this adds up to being roughly $375 of cost for unproductive / counter productive time per employee per year when looking at it through an extremely conservative lens (others estimate 4 to 10 times this cost per employee per year). Just the value of improved search, as well as bringing information into context and having it searchable ads greater value from moving the dark matter into the searchable light.

Search in Slack is most often better than the enterprise search that people use across their organization. But, it also is often better than the search that is built into various platforms that are used in and across the organization, including enterprise social networks (some exceptions to this include KnoweldgePlaza, which has really good search within it, as that is a large part its purpose). This improvement in search finds what is needed and the search result surfacing the item in context is really special. Slack has also designed this really well, which adds to the ease of use and enjoyment.

Integration and Interoperability (What? Really?)

Another big pain point in organizations is integration and interoperability. There are disparate systems which many people have to pay attention to metrics, messages / alerts, and charts from various services across them, which is not efficient and rarely is there an integrated view (nor a means to interact across different systems from one interface). But, rarely is there a means to search within and across the services to do quick comparisons or easily bring those things into a more unified view. Often IT has the integrations far down on their prioritized to do list or in the "can not be done category" for reasons of feasibility or difficulty. But, one of the beauties of Slack is it integrates with other services relatively easily through a variety of methods (many can be done in a day or two in side-project time), if there is access to an API or even a means to see a screen so it can be parsed for values and meaning. Groups have been able to pull together their own aggregated and searchable views (sometimes in their own channel to view / review and search within or as a system with an identity that chats and shares things out as a bot). The solution that is cobbled together in side-project time to meet the needs of employees meets their jobs to get done and need that access requirements, which make Slack far quite efficient and usable. While IT has their requests slowly (if that) moving through the prioritization process, employees have been able to drastically reduce the pain points that nudge them to consider looking employment opportunities that value their getting work done.

Sane payment models

One of the last, often overlooked, elements goes completely against the trend of "evil" enterprise service payment models of paying for seats (used or unused). This model is loved by nearly all enterprise software vendors (or their boards - somebody has to love it as it surely isn't the customers who know they are being taken for a ride).

Slack treats paying for their software / services differently. It runs on a freemium model, but has high conversion rate to paying customers for its offerings. It is not that paying users get full search of the a complete archive and more plug-ins, but also quite good support (yes there are a few others that give quite good support - though this isn't the norm). The pay model provides improved search powers and interoperability / integration, which being severe pain points in organizations make it worth paying for and the pricing per user makes that a bargain (hey Slack don't go changing the price though).

Yet, what really makes Slack's payment model special and different is you only pay for accounts used that month. (Did I hear a collective "WHAT?") Yes, you don't pay for the number of prospective seats nor tied into long contracts that go beyond the needed time span. Ever try to get a reduction in seats paid for after a few months when you have realized only 60% of the seats paid for are used and that doesn't look like it will shift over the next 18 to 30 months of the life of the lock-in? Slack understands that pain and opted to not partake in that model of pain.

In short Slack reduces pain and increases efficiency and value

So, the reasons why Slack seems to be at the tip of many business and enterprise tongues (as an inquiry or recommendation) is focussing on what is delivered, its ease, and the value people get.

Slack aims at delivering a usable (and friendly) service as a means to communicate to get and share information and knowledge. But, in doing this also knocks out some nasty pains people in organizations really don't like and have long wanted resolved. Slack is basically the un-enterprise solution as it focusses on being easy to use, reduces pain points, and tries to be friendly. Yes, this is software for the enterprise, or for the parts that don't relish pain.

So Slack is perfect and the cure all?

Um, no. Slack is far from perfect. It isn't trying to be everything. So, you are wondering what are the pain points or limitations?

Slack isn't going to scale to meet your hundreds or thousands of employees needs today

Slack works relatively well up to a few hundred people (there are many hundreds using in one installation (instances well over a thousand as well), but that isn't optimal). And even with keeping an installation under a couple hundred people it is still going to be a bit noisy. Many of these installations with more than 100 people in them use the channels for creating smaller groups / teams / projects / targeted conversations.

While improvements are need to get to solid filtering, this does help so important things don't get missed, or conversations that could use a person's input gets their attention when they weren't specifically called out. The ability to move conversations to and between channels (in a manner that leaves a trail behind where the conversation started).

It also needs the ability to more easily tie conversations threads together and tie related discussions together through tags (yes, I said the tags word) [the addition of each entry now having the ability to get emoji responses has been getting used to aggregate related content in some organizations in a "visual tagging" way, but lacks clarity in understanding, even with "what each emoji means" charts]. Also, finding related threads and discussions across channels can be cumbersome in search when different terms (synonyms / fungible technical terms) are being used, even if search is good.

Not everything nor everybody works in the open

In organizations there are viable and valuable reasons to have some things not shared openly. Legal, regulatory, compliance, and some things are best tested and considered among a few people and honed / vetted before sharing more widely and other needs for improving social comfort are often lacking in the enterprise social platforms.

Many mature social platforms for enterprise now offer private spaces for groups to share information, and if it seems viable or gets honed / edited it is shared it out more broadly. Many even follow the social progression of fire model where trends in the messages / sparks and comments are seen as being connected and possibly need more investigation, then moved to or collected in a small comfortable space / campfire to investigate before sharing more broadly / campfire (if it is deemed worthy of moving it forward), and then honed through collaboration and perfected to be put into production / torch.

By the way - Slack does offer the capability of not remembering things for paid users as some organizations require this for compliance. There is a forget quickly, forget in a week or so, and keep everything capability to meet a variety of needs / requirements of organizations [this forgetting negates the incredibly helpful search, but organizations that require this often have bigger troubles that they are dealing with]. But, global forgetting isn't the same as quiet comfortable groups with permeable walls that work well for many people in larger organizations with cultures heavy on the Western European and North American sensibilities.

Slack doesn't replace everything

There have already been some rather poorly considered (mostly through the lack of understanding the diversity and complexity of social - no it isn't simple nor just complicated) "we are going to use Slack to replace..." attempts. Understanding the category / class of tool that Slack falls into is essential. It isn't a replacement for the collective, curation, nor team / group workspaces like Jive and others (yes, there is one service in this category / class that nearly everybody wants to move away from as fast as they can, but Slack isn't the tool to move to as a replacement). Slack does well to sit alongside those services for conversational interactions and sharing results out of them. It isn't going to replace a social search and collective aggregation service like KnowledgePlaza. Slack not only integrates things into itself, but also can have what is in it as fodder to integrate out, so conversations and things shared in Slack can be honed and more deeply framed and considered in other services and then have results and outcomes of those considerations shared back into Slack.

Slack is not going to replace your document management service. It is a good partner for it to add context and easily drop documents that are relevant from the service into Slack. But, Slack isn't going to replace document management, even if its search is good, the versioning, permissions, and access controls for compliance and other valid needs aren't there in Slack. Your document management service could become more pleasurable to use though.

Enterprise is a complicated beast

Having worked in and around social software for enterprise for about 20 years now, it is a wicked space. There are a lot of "needs" that Slack doesn't comply with yet. There are a lot of issues that aren't on Slack's horizon yet, it may not want to place them there.

Enterprise also brings with it a diversity of needs, mental models inside, use cases, workflow models, and more that should be and could be addressed, but Slack isn't there yet. I'm not sure Slack even has all of them fully on their radar - many organizations don't centrally have them on their radar yet either. But needs arise when divisions and groups underserved by centrally chosen tools in an organization that doesn't fit their needs. When this happens groups often will go in search of services and tools that meet their needs to help them get the job done.

Working with enterprise means working with organizations that don't understand how they themselves actually work nor operate in workflows nor knowledge flows. Many social platforms aren't in the business to help organizations understand their needs, problems, pain points, and gaps yet these are the first steps to understanding the right fit for tools. Analysts, for the most part, aren't in this business, nor are most consultants (selling solutions based cookie cutter decision models makes more profit than the deep understanding the problems before considering solutions model). Perhaps Slack could embrace this model of helping organizations understand themselves, as they aren't focussed on "winning" as much as helping solve problems and address needs (another reason Slack stands out and has a good helpful product).

So what should you do?

The first step is to take Slack seriously. It is doing a lot of things really well, as well as weekly and monthly iterations making things even better.

Also understand not only what Slack is, but what it isn't. Understand how your organizations works (if you need help with that reach out to me, as helping organizations see clearly through the fog of complexity is what I do) and sort out how a service that focusses on reducing pain points and increases people's ability to get things done can fit.

Second, start early thinking about filtering to cut through the noise for alerts and reducing "noise". Work out a community guide and plan. Also, sort out the flow models that can work well with the other services in the organization.

Running Podular Teams

Running Podular Teams

One of the things that has brought happiness from the Connected Company book being out for nearly three years (now in paperback), is getting the idea of podular teams and organization out there for a wider understanding. From 2001 onward I ran my product and project teams in a podular manner. Since then I have helped many organizations I have worked with as clients adopt this approach so to be more nimble, efficient, productive, and keeps the teams members happy as well as management.

This works well where there are a diversity of projects that have different cycles that need different skills for a duration, or are short to mid-range in length (less than 6 to 9 months). This does work well for longer projects as it helps with staffing when their is any turnover in the pod.

What is Podular?

When I started running my teams I had a fixed set of people working under me in my program area and a wider set of projects. The team members had a wide variety of skills and various depths of strength and experience in those skills. The simple overview is, to stay on top of my team and project needs I set up a simple spreadsheet with the names of team members on the horizontal rows and skills running along the top of the columns. In each cell I put a 1 to 5 ranking (5 being the highest) for that person’s skill and expertise level. To build a project team I would assess the skill needs of the project and the project timeline and review the program’s team to right fit a team to each project.

Other program managers and my upper management called this matrixed team management, but outside of this the term matrixed organizations had a very different meaning. When working with Dave Gray on the Connected Company book he brought up the conflict with the term matrix (matrixed organizations were in the “bad thing cycle”) and started calling them podular teams, which worked well as that is how they functioned, as a self-sustained pod.

The teams when set up could mostly run themselves autonomously, mostly because of the people I had in the program team. But, often there was a person senior enough that could keep an eye on how things were progressing. If things were not running well I would get a heads up as a manager and help sort out a solution. Many times I was on the team, not as a manager, but taking one of the roles that needed depth of a skill set for a duration.

How to Set It Up

Setting up podular teams can be done in a spread sheet, but a couple times I have built quick web applications to serve the purpose. The assessment of skills (all of them) is essential. This can be through professional assessments, team review by peers, and / or a managers assessment. Keep in mind that over time the skills ratings will change. It is best not to work off of job descriptions as those are most often very off target. It can be good to sit with each person and run their assessment by them. Keeping to a 1 to 5 rating makes the reviewing with people a little easier. Don’t assess the top rating for a skill based on their being the best in the pool of talent as there may be a need for somebody with deeper skill and experience at some point.

When you have the individuals rated on their skills and you are sure you have all the skills listed (keeping to relatively broad categories can be helpful) it is good to color code the ratings and look to make it easier to see the gaps or potentially thin areas in the pool.

Next take a couple projects that are have been running and map the people to the the team and look at what sort of skills are needed. Look at the make-up of the teams as well as the pool of candidates. Look at where there may be weaknesses in the pods at times based on cyclical needs. You may find that there is two days of work for a skill at a level 5 each quarter, so starting to map the pod over various durations of time is helpful, from weeks, months, and quarters.

Next Steps

There are a few of things that running a podular team environment needs that make it a little more complicated. The first is maturity cycles of a project. Projects have three distinct stages: 1) Creation; 2) Iteration; and 3) Maintenance. Initially when I added this I kept it as a column in the spreadsheet for each person, but I found it really applies to each skill. The skills and capability to fit into the stages is essential as each stages takes very different mindsets and approaches, as well as personality type / temperament to handle that stage well. Shifting somebody with a “4” skill rank that has only done maintenance to a creation stage role is often a quick way to start trigger problems in the pod on a project.

The second is growing skills. One of the things that quickly jumps out when running teams in podular environments is overlap of skills, as well as gaps at various levels. Another thing over time is the skill levels for individuals change, which changes the make-up of the podular teams and the pool of people over time. I started keeping a second sub-column in each ranking to track this change over time. At one point I turned the second column into the individual’s goal column, which was set during formal reviews and casual reviews to learn what the skills that person had a desire in improving. Eventually, this turned into a third column and I brought back the rating change column. This meant I had a “Last Review”, “Current”, and “Goal” column for each person’s skill ranking. The “Goal” column really helped with setting podular teams to take somebody with a high skill ranking and pair them with someone wanting to improve their skills in that area. The person there to shadow and get some hands on experience form someone with more skill and experience nearly always was in that pod because of some skill they had a skill match for on that project.

Tracking things in this way also means traditional reviews are relatively easy to do as progress can be tracked as well as contributions. In working with other organizations, those that have team members providing feedback across a project makes review and assessment easier as well.

The third is hiring into the pool. Running any group over time leads to hiring people. This can be to replace somebody who is leaving or for newly created roles / positions. Running things in a podular manner and keeping track of projects, pods, people, and their skills means there is a really good view into what skills are needed at what level to fill that new opening. With monitoring people’s growing skills (as well as atrophy) looking at a pool of people, their skills, and the needs on projects means seeing the needs of the new hire is rather clear. This can be difficult in organizations with strict job descriptions and roles that are only updated every two to five years. But, most often it means the role is easy to write and right fill, if skill levels and other fit can be determined well.

Building Pods

When the framework is set the next is taking projects and teams and converting them to pods. The big shift is going to be the pods most likely are going to be a little more fluid than they were prior, so to match changing skill needs over the life cycle of a project or team needs at various points. Turning them into pods often means these pods will run a little more autonomously over time.

This means the role of the person managing, if they are are not a contributing member at all, is going to change. Their role is going to be less managing what happens in the pod and focussing on clearing the way for the people in the pods to do their work. The manager will openly check with the project owner as well as those in the pod to ensure things are running smoothly and assess upcoming needs or smooth out any bumps that arise. Often the number of people and projects that are being managed will rise. The manager is often the person who will work to help get resources and answers to needs as they arise. The manager is also the one keeping an eye on budgets and burn rates, which becomes essential when bringing people in and out of the pod to get the best skills mix as needed.

The pods will need a really good platform for team communication, coordination, and collaboration. This needs to be open to the person managing as well as fully open to people that drop into the pod to fill in roles. Email doesn’t work as a part of podular environments. Getting a tool that works well can be a less than easy task, but it is an important task to ensure the right fit. The client or project owner may or may not have full access to the tool, but a good view into progress, deliverables, needs, and probability of completion is a good view to offer.

Putting a pod together can be done in a self-selected manner, in a curated approach, or one that is mixed. While many organizations find success with self-selection, where the pod has the opportunity to self assemble, the downside is this only works with some skill sets, personality types, and work environments. Where self selection really falls flat, if not fails spectacularly is skills that are often strong with people who are introverts and needing those skills in the pod. In many organizations this can be more than 70 percent of the teams and pods that are needed to be assembled. Self-selection also tends to favor those who have working knowledge of others, which makes new hires and others that don’t have experience in the pool on the outside, with pods often choosing a known, but poor fit, rather than a better fit that is unknown. The upside of self-selection is pods get built with people who tend to work well together.

The curated approach where a manager or pod builder works to assemble a pod with the right skills, levels, and availability. The availability is often tricky and can take some negotiation to get a key role filled with the right person for a duration that is needed. The curation approach mixed with some self-selection can work well also, and is often a really good way to do things over time.

Really Understanding Needs

The biggest hurdle to this is deeply understanding needs. This is understanding all the roles needed and skills. One thing that becomes quickly clear is there are often skills needed beyond what traditionally has been considered. With podular environments the ability to bring in people with skills that fill these gaps becomes second hand and seems natural. This leads to the pod looking to optimize their output and try to understand things that are less than optimal. This short fall in skills and gap in skills continually arises when implementing and deploying social / collaboration / communication platforms in organizations as there are 14 essential roles needed and most are trying to cover it with 2 or three of these skills roles.

Over time the skills needed in the pods becomes clearer, but often bringing in a consultant with experience in podular environments and the domain areas becomes a huge time saver to get things running smoothly early in this transition.

The One Social Way - Or not - to Doing Social Really Well in Enterprise

One of the interesting things, having been at the heart of social and collaboration for business a good long while (since 1996, no I'm not kidding), is seeing how large organizations who are doing and have been doing social well (more than 80% of employees are active users (more than once a week (often daily) checking in and taking an action (setting status, commenting, posting something, etc.)) with many of them doing a majority of their interacting with team and work colleagues inside the tools and services) actually do this.

The interesting thing is most organizations who are doing social and collaboration well are not using just one service or platform. They are using two or three, often with some small solutions for niche situations (niche for them). They are also not planning on migrating to one solution, well at least for any foreseeable future.

There is No One Way

The reality of doing social well is embracing the understanding there is no universal, no master narrative, and no one right way. Yes, we are all human, but we are not all wired exactly the same. The different personality types, different mental models, and many different cultures in an organization (and world outside their doors) that comprise reality, which requires embracing that reality with more than one approach.

No organization started out to do this, it just happened. What IT often wants to do is have just one solution that works for everybody, as that makes their job more manageable. But, many organizations needed something far better than the mess that email created in their organizations so to clearly communicate with and within their teams and departments. Reality is people roll in and out of projects and people stopped using just corporate sanction tools to get work done with colleagues. Often what IT provided for the organization didn't work well enough for them, as it didn't meet their needs nor mental models. The last 5 to 8 years getting a good social / collaboration solution for a team up to a division that ran in the cloud (didn't need IT) and could fit on a credit card for the team or a division's PO that was small enough to fly under the radar has been easy. Not only was it easy, but it has worked rather well, as it fits the needs and people use them rather heavily.

Where this has ended up after 2 to 8 years is many different social and collaboration services in an organization, that haven't really talked to each other well. Teams, groups, divisions, etc. need to talk and work together and so IT was getting back involved to get everybody on one solution. The trouble is, you can't remove what works.

Why There is More Than One Solution Working Well

When you try to remove a well used solution you realize it is really difficult to move to one platform. It is not the porting of the data, interactions, and differing privacy models that is hardest, it is a pain, but not the most difficult piece. It is not retraining people (if heavy retraining is needed something is really not right, but this is just a symptom of the real issue).

The biggest hurdle is there isn't one universal model. There will never be a universal model that works, unless is it heavily based on adaption and no vendor remotely close to that yet.

Most of the well used social and collaboration platforms have understood they need to really understand their users well. They did user testing and mapped their products to their user's mental models. But, the thing is their users are not universal and are tied to the people and personality types that have long bought their software / services. The users they researched and tested on have been those parts of the organizations that buy their products. This is not the whole of the organization that they focussed on, but the slice that is their customer base.

This is why Salesforce Chatter works really well for sales and marketing, but the other 65% to 80% of the organization won't go near it nor live in it the way sales and marketing people do. Similar for Yammer and SharePoint as they are honed (and really not well) for tech centered folks who are willing to work with less than optimal tools. Jive works really well for knowledge workers (and even information workers), and for the innovation and leading edge teams and groups (no it doesn't scale up yet) there is Slack (there is no chance in hell you can remove Slack and they are likely the best minds and change makers in one's organization whom you really don't want to piss off and have leave - if you don't think you have Slack users you either don't have highly productive innovation folks or you aren't looking hard enough). There are a myriad of smaller targeted solutions for a wide variety of roles and personality types that are perfect for their niches (some with millions of users - with around 2 billion technology enabled people on the planet it is quiet easy to have a niche of a few million users).

So, What Do We Do Now

Organizations that are moving toward doing social and collaboration well fall into two camps: 1) One social platform that has good, but not great usage (Jive is a solution that adapts the most broadly and is one of the few actually pushing forward to improve and get to do a better job at having a product that is social as humans are social) is doing great in parts of the organization, but untouched in others; 2) There are many many platforms in the organization and there is a strong need to get people working together across the now disparate groups.

The first step is realize there is no getting to one. Be fine with that.

Now, the harder goal, which is getting things to work together, which is beyond just simple traditional integration. To do this well it takes deeply understanding the different personality types, roles, and mental models in the organization and not just following a tech schematic that most integrators use as their blueprint.

The first step is to bring in people who understand the differences between social platforms beyond what the checkboxes say. These people usually have strong social science backgrounds, have worked in large organizations along the way, and have been working (helps if managed, designed, and / or developed) with social and collaboration more than a decade. Outside? It is rare this person will be inside, but if so many organizations have rules against using platforms outside the organization that there will be a need to have an external party research to get honest insight and feed back with good research non-disclosure guidelines in place.

"We Have One Solution" Organizations

If you are one of those "we have one solution" organizations, I'm hoping that one solutions is one that plays well with others, as those are a great starting points. Right now the best of these is Jive, as it seems they understand they are not out to rule the world, but play very well with the world and all the needed tools and services that employees use to get the job done. Jive also has a well laid out plug-in and module mindset that includes Open Social (this only is a partial solution so far as it isn't full interoperation capable yet) to get outside content in. But Jive and Salesforce Chatter can integrate and work relatively seamlessly with each in their own platform and well honed interface for their own user's mental models. This is a really good example of where the future resides.

With the one solution that may not have really broad adoption, work to sort out who in the organization is not participating or has lower use rates. Spend time gathering the data and mapping patterns. It will likely start to frame divisions, roles, and personality types that are rather clear to see for those not using it (also refine the understanding of who IS using it, as you don't really want to mess those types of employees along the way).

Mapping the gaps where people are not using the tools, as well as why not, will help be a guide. In this mapping and research, particularly if done by people outside the organization, there will be other solutions used that may not be known (sometimes these are used widely - beyond 10% of the organization is where wide starts) and capturing and understanding what they are and why is going to be essential. Finding and understanding the myriad of options out there to map to roles, sub-cultures, and personality types, as well as interoperation will be essential. Trying a few different options and having change management and internal communications involved will help things as well.

"We Right Fit Solutions" Organizations

The first step with many known solutions is to do a full capture and audit of all platforms and services used, as there are likely more than what is known. Also be comfortable with the reality that there will likely be more than one solution at the end, but hopefully they will play well together.

In the capturing what is being used and by whom, learn what they do, how they do it, and why. Learn, what could they live with out and what is essential. Watch people work. One of the most important things is discern if they are working in closed groups, open groups, or if they are using one of the rare platforms that allows reseting permissions so to start closed and once honed share more openly (this is a valuable capability in a solution). Map the differences between groups and tools (a serious benefit of having outsiders do the research and mapping).

Once everything is captured and mapped the hard work begins. The solutions is going to be different for each organization, but interoperability is going to be a key component. There will likely need to be a tool or service at the center that other in, out, and around. Understanding the cultures, differences, capabilities, privacy, security, user work needs, underlying data models, and availability of APIs are going to play roles in working through to a workable solution. Depending on the organization mobile, what tools (the non-collab and social services) it integrates with and how, organizational make-up (including if an organization that has been acquiring other companies and / or has plans to), virtual work environments and needs, data / document storage models, adaptive to change, and much more are going to play very important roles in working to a good way forward.

Shift Happened - Part 2: Small Apps Loosely Joined

What are Small Apps Loosely Joined?

There has been a large shift in how many people work today and part of that is in the tools that they use to get work done. This shift in work patterns mirrors the shift that many had in their personal lives around social interactions and productivity.

Late one night many years ago (long before the iPhone), a group of us were talking about web and mobile and opportunities to work in a variety of similar tools that were all interconnected. The mash-up culture was a year or two behind us with Paul Radamacher’s first map mashup HousingMaps and the salient understanding that surfaced from that was the ability to have different interfaces for different needs and uses that could work as a workflow, or even similar interfaces for different personal needs of the users. We talked about Twitter and its heavy reliance on third-party developers to build web and mobile apps and services on top of its services and the Twitter API (the application programming interface, which is a standard data and interaction layer that sits behind the scenes bring data back and forth between the service). This approach allowed anybody to build an interface for seeing and interacting with Twitter or create an interface that provided greater ease of use for tasks. With tongue in-cheek (paraphrasing David Weinberger’s “Small Pieces Loosely Joined”), I said this model was small apps loosely joined.

What joined these apps together was a common data layer that fits a standard data model (or, as is common in APIs, a data model that self describes). The Twitter model allowed people to interact with the service through a mobile app with full functionality of the Twitter site, or to see many different Twitter lists in something like TweetDeck, or monitor and respond through different accounts in something like HootSuite, while tracking follows and drops in other monitoring services.

This same idea is more prevalent now across our mobile devices and the apps and services that they connect to and use. Not only are today’s mobile apps and services interacting with the APIs on the internet, but they are working with standard file formats on the backend and apps that meet the needs of users’ context and workflows. Some of the common app and service types that people have been shifting to the small apps loosely joined model are: Calendar, email, photos, text / documents, and to do lists / reminders (a closer look at these follows).

Who is Doing This?

The small apps loosely joined concept is nothing new in the technical geek and productivity nerd community (as part of both tribes, i use the words geek and nerd lovingly), as well as for early adopters. These uses and patterns with small apps loosely joined started surfacing around ten years on the web and mobile devices, all interconnected to the internet.

We understand innovation and broad adoption can take quite some time, roughly 10 years for innovations and new ideas to take hold broadly. We are about 10 years into this way of working and interacting with information and applications, so it was not exactly a surprise to hear research (done in-house to better understand the mobile market) that 60 to 70 percent of military members and their families surveyed use more than one app for a task types. They used calendars, email, and weather as examples. I checked with others who do surveys of employees inside organizations if they were looking at the question and found that they were. Their responses were also in the 60 to 70 percent range for calendar, to do, and text apps on mobile devices.

So, while this small app loosely joined focus and obsession within technology and productivity communities has been more than a decade old, it is something that is now rather mainstream. Over the last five years or so, when I am traveling or in a dank gym for club basketball, I often ask people next to me what apps and services they like the most on the mobile devices that is in their hand. Their answers often surface apps related to tasks and workflows for a data type (calendar, document, etc.) and the person would qualify how and in which circumstances they use it. Quite often, the app did one or two things really well that others didn’t cover or did not do well in their perspective.

Why are People doing this?

There are a lot of reasons why people started embracing small apps loosely joined. The primary driver has been mobility and looking for small mobile or tablet apps that do a specific, needed task. Mobile and tablet uses often have quite different contexts for use, including a mix of creation and consumption, but the affordances and agency in these apps is a driver too. Having applications work across platforms is helpful, but it is more essential to have open file formats and standards that work with apps that can pick up the file and provide use on another device with the constraints and augmented capability mobile and tablets provide.

There are additional relevant benefits of the file formats and standards working across devices. The ability to easily share files with others with whom you are working or communicating is a great benefit, as the platform doesn’t matter, just the ability to grab an app (often inexpensive and sometimes free) to read and modify the file is key. Being able to easily share files leads to always having needed files accessible, as they can be kept of an internet directory (the kids, okay grown-ups, call this cloud storage).

The last benefit that is driving people to the world of small apps loosely joined is the value of non-proprietary files, which isn’t as hippy and give-it-to-the-man as it sounds–it’s really about ensuring that the files will work on any device with an application that handles that type of object. Having to keep two or three versions of the same software around so one can work across file differences, or open files in a different version of the software so it can be saved down into an older version, is silliness we can leave in the inefficient old days. Many of the file structures that are based on around text, including calendars, can be opened in any text application and read and edited there.

Where are People Doing This?

Most people (particularly outside the geeks) started down this path when smartphones and the modern class of tablets entered their lives. They looked for ways to replicate how they worked on laptops and desktops, but often the same apps weren’t there and they had to improvise. Word of mouth also spread ideas and options for getting things done. But, often people go exploring small, focused apps that are inexpensive or free to see what they do. The small targeted apps, often in the “does one thing well” class of app or small app that is does a few things simply and easily, have filled made it easy to try quite a few different apps to find something that works. People often find a few apps that fit into a workflow that targets a few small tasks to get things done while standing in line, stuck in traffic, or sitting at your desk waiting for one’s computer to finish updating and reboot.

As a result, often people find that this small focused app model helps them do the things they need to do, and it can be more efficient than digging around large cumbersome software. Often this can be more efficient as the person is not digging around large cumbersome software. Once this becomes a habit or a way of working on mobile, the expectation is that it should also work on the desktop / laptop as well. People look for similar apps and services that fit their more efficient workflows that started on their “devices that are too small and limited to do any real work on” and want that same type of focussed application where they “do their real work”.

This change is also being driven by more than just shifts in devices–people are trying apps and services in their personal life to help manage their schedules or work simultaneously with club or event organizers crafting an email or newsletter. Our personal lives used to trail our work lives as far as technology and services
augmenting what we do, but now what we’re doing in our personal lives has greatly surpassed the capabilities of many of our work offerings.

The Types of Apps that Often Fit the Bill

The starting place for many people who try a variety of apps on their mobile and tablet devices are weather, text, and calendar. We don’t modify weather apps as they are mostly just a display of provided content, but there are much variety among the offerings, such as <give a good, standard example> and DarkSky, which offers micro-location weather with how many minutes until precipitation starts or stops.

Text apps

Text apps is where many start seeing the concept and value of small apps loosely joined. People want something more than just simple notes application to jot ideas and sync them to other devices. They want to be able to read and do a little editing of text that they or others started writing on their “work” devices, all while standing in line or during other available moments that permeate our day. Soon this “little bit of editing” seems like it isn’t all that bad to do and they start picking up things they started writing elsewhere and knock out more on their mobile device or tablet. Or, they have an idea when they are not near their “work” device and start jotting a few notes in a text app, and soon it has turned into a couple or few paragraphs. The accessibility and convenience of these capabilities has switched on a lightbulb. Talking and comparing notes with friends and colleagues, they find there are apps that are not just simple text, but can add annotations for structure (headers and outlines), hooks for style (bold and italics), and more. This often leads to learning that some apps have more robust writing tools (dictionary, thesaurus, writing analytics, etc.). Those who write with a workflow of first getting ideas out of their head and then working with them to hone them are often most prone to the small apps loosely joined way of doing things. But, others also like the ease of just getting words and ideas out in one app, then editing elsewhere by just opening another app and grabbing the same text file from a cloud sync service or sharing between apps directly. These text apps, particularly when those that are markdown friendly, can take that initial text and turn it into a styled PDF, a Word doc, HTML to post, RTF (rich text format), or more.

Calendar apps

Calendars are another gateway drug, er application type, that leads to embracing the small apps loosely joined way of doing things. The calendar files are a set file type that is easy to move from app to app (except when working across platforms that have proprietary hooks that break compatibility). Smartphones and tables all come with calendar apps, but they rarely fit the full range of needs. Some people want a calendar to have a certain look or layout format that helps them see and evaluate their day, and there is an abundance of options on all platforms for visual display. But, the real gems are the small apps that shine with certain tasks like Fantastical does on Apple products with its natural language parsing that turns spoken words into an almost always bang-on calendar entry.

Other calendar apps start adding other intelligence and agency (applications doing things on our behalf to ease our work). Donna (rest her digital soul) was a favorite of mine for evaluating time between events and different modes of transport and calculating time to leave based on weather and traffic conditions (and if you were really stuck in a jam, it offered to help you get Uber). Donna was a gem for the space between meetings, but was an incredible help with coordinating kid pick-up and leave times related to their various events. Other apps that are helpful agents are Tempo (it came out of the same SRI lab as Siri), which is one of the fullest featured and most helpful calendar apps around. Tempo monitors your mail not only for events, but pulls the relevant emails, documents, location and contact information, and relevant transportation needs into one simple calendar entry–and all you had to do was place it on your calendar or say yes to an event invite. Tempo offers the ability to send an “I’m running late” notification to those with whom you are meeting, as well as the expected arrival time.

One the the interesting things about calendars in the small apps loosely joined set is that most of these class of apps do something else–they augment and clean-up the calendar entry. Say I open Tempo and it doesn’t recognize the location that is in the calendar entry - say it only has Ray’s Pizza in NYC (oh, you too have gone down this crazy path of meeting somebody at Ray’s Pizza in NYC only to later realize (not soon enough) that there are more than one and nearly a billion permutations of Ray’s, Ray’s Original, Original Ray’s, etc.)… so Tempo offers suggestions to sort out the exact location and then enters the address in the calendar file’s location field. Bingo! We have clarity, but not only does your calendar have clarity within Tempo, but in all other calendar apps that read that event file. Not only does Tempo do this, but other apps may also do this. We learn quickly the apps that don’t play well with others and hoard the clean up information (Mynd app has done this in the past, but it seems to be more friendly after its last update). Additionally, some apps give you the option as to which mapping and directions app you would like the calendar to open when you are actually on your way.

Email apps

One of the things that mobile and tablets reinforce is how painful email is in our lives (on both the work and personal sides). Being able to live in email and work with it easily in some managed way from a mobile device or tablet is critical. The small apps loosely joined concept really takes hold with email for many people. Some tools work as easy, light triage, such as Mailbox, to quickly filter through your email based on importance and time-relative needs. Also, some tools that manage attachments in email (or, more appropriately, files that would have been attachments, such as Hightail (formerly YouSendIt), which stores files and documents for your email to link to securely. The only requirement for most of the email apps is the email account must run on IMAP, which is pretty much the norm these days.

Photo apps

The quality of photos has improved drastically on many mobile devices and even tablets. This along with the adage, “the best camera is the one you have with you” (and most people always have their phone with them), has led to the reality that a lot of photos get taken on mobile devices and tablets. The photos are a common file type and there is an abundance of apps that can take a photo and modify it to improve its quality, add filters to change the look, add text, or turn into something that looks a lot like a watercolor painting. The photos can also be scanned and OCRed, as well as uploaded as a document and later searchable (as many do in Evernote.

Standards and Access

The key to many of the apps loosely joined use types mentioned (and the many not covered here) is that the files passed among apps follow a set or ad hoc standard. Text files that use Markdown (or Multi-Markdown that extends the capabilities to add footnote, tables, and more) are all human readable, but also any text app can read them and edit them. The file sizes are small, which is incredibly important for mobile devices and tablets in limited mobile bandwidth locations (be that Manhattan at 5:15 on any weekday or the outer suburbs of Accra).

Access to the files is the other important characteristic of small apps loosely joined. Working between apps may not require internet access, but working between devices that are not in bluetooth range, or sharing files to collaborate requires data access (most often through the internet). Small file size, which those of us working with mobile a long time know is still an essential for actually getting things done reliably.

Common Use Traits

These apps have a core set of functionality that stem from the capabilities of:

• Viewing
• Creating
• Honing
• Agency
• Features / functionality augmentation

Viewing is a common characteristic of all the apps, but the ability to create is where the real difference in these apps start to have real value for people using these apps and working in a small apps loosely joined workflow. The small apps can also provide the ability to hone what has been done in another app or on another device. This honing may be editing or adding data or an element to improve use. Agents that look out for us and do work we would be having to do is quite helpful, particularly when they are getting to the near bulletproof reliability some are approaching these days. The features and functionality augmentation in apps really helps when working with light apps that are focused and easy to use. Adding grammar checks and tools that can improve our work or creations, much like we would at a laptop or desktop, have shifted many people to this small apps loosely joined life.

App Traits

There are a few core traits in these apps. First off, as mentioned, they work on open document types that are are commonly used as actual or de facto standards.

Another trait is the apps are light (a few features and functionality sets), focus on simplicity, and are easy to use. Mobile devices do not have the screen space for complicated or complex interfaces, and, in reality, given where and how these devices are used, the user’s full attention is not on the app or device. Good mobile and tablet designers and developers understand this limitation very well and understand just how far they can push the limited human constraints that come into play when interacting with the apps.

The last related trait is that the apps are focused. When listening to how people use and interact with their devices and apps, it is interesting how they understand and parse functionality that fits their needs across apps. With calendaring, some people love Fanstastical’s UI for display of the day’s and upcoming events, while other people love how easy it is to input information and create events from a chunk of copied, typed, or spoken text (and getting it right). It was interesting talking with other Donna calendar app users as many of us would open Donna to get just travel-related information and / or honing the address, then close it and open another calendar app for its different functionality. The apps do a few certain things really well and those that live in the small apps loosely joined workflow are quite fine with that.

Wrap-up

The small apps loosely joined workflow and expectation has moved from mobile devices to the laptop / desktop world. The small apps that were just on mobile devices are showing up on the more fully powered devices. The output created from these apps have supporting services on the web that can augment this practice much further. Many who work in small apps loosely joined have learned to like the focused task and mindfulness of that targeted approach–they get things done far more efficiently and are more productive more of the time, and, as a result, they can often get more uninterrupted time to focus on living life beyond devices and apps. The goal going in was just to get things done on the device I have with me, but it is not a bad benefit for those whom value it.

---

Shift Happened Series

• Part 1: More Productive Not Using Productivity Tools
• Part 2: Small Apps Loosely Joined
  
• Part 3: Capturing Decisions in Social
• Part 4: The One Social Way (Or not) to Doing Social Really Well in Enterprise

Getting Beyond Simple Social

“Social is hard!” is something I hear repeatedly by most of my clients and those I talk to. It is one of the issues I continually run across in my work with organizations trying to better understand social software and collaboration tools for their organization as well as helping vendors better understand their gaps and how to close them as social scales.

I have my “40 Plus Social Lenses” that I use to set foundations and understandings to better see issues, gaps, and understand the potential ways forward. Everything requires testing and rarely does the good solution work everywhere as there are no best practices, because what we are working with is humans and how they are social. Humans and how we interact is not simple, we are not simple social creatures.

In January I quickly cobbled together a presentation for the UX Camp DC (a Washington DC User Experience community BarCamp) that I quickly titled “Getting Beyond Simple Social”, which I used as a frame for why most organizations are stuck with social (it is embedded at the end of this). Most organizations are stuck as they came to social thinking there are just a handful of things to understand and this social stuff is simple. I had a meeting with the senior partner at a huge global consulting firm who only wanted to know the best tool and if I could just boil down the 40+ Social Lenses to 2 or 3 as 40 is a bit tough (not only did the meeting end in my head at that point, but so did much of my respect for that firm), I explained to the end users and customers social needs to be simple, but in reality it is very complicated and complex and somebody has to work through that, which is what people hire consultants to work through for them and guide them through.

So, I cobbled together a few items from the 40 social lenses that I have presented prior, but included 2 new slides of things. The first is “Getting to Mainstream” (slides 4 through 8) and “5 Beginning Social Questions”.

Getting to Mainstream

Much of my work is helping organizations with social inside their firewall, which means bringing it to mainstream. In my years of working with social and collaboration services and platforms (since 1996) the tools haven't really changed much, other than now the tools get out of the way much more (in the 90s the answer to improving the tools was adding form fields, which is rarely ever the right answer, our technology has moved beyond that, we should too). But, the following are the reality setting steps I take with organizations and that took me years to grasp.

Inside the firewall the goal for social is ultimately 100 percent of the employees and/or partners. The measuring stick is often email, which is ubiquitous and a very familiar tool for everybody in the organization. Email is social and is something that everybody understands and has their face in at some point during the day. Many look at what is happening in social web services and seeing ease of communication and interaction, often in the open, which solves some of the pain points that are tied to email and email is everywhere.

What is lacking in the 100 percent goal is the understanding that email often took 5 years in most organizations to reach roughly 100 percent adoption and use. Having lived through the inception of email in a few organizations and then talking with friends about their organizations where they worked or consulted, the 5 year threshold was fairly normal. I don't know anybody who was actually measuring this broadly in their organization (Connections: New Ways of Working in the Networked Organization is a great book that will get you close to this as it walks through adoption and use patterns of email in companies).

Focus on Social

The focus is often on social by those looking for a solution uses the viewpoint of social web. But, much of what they see and have explained is not mainstream usage, but usage by early adopters and innovators (in the framing terms of Geoffrey Moore's Crossing the Chasm which uses a modified version of the Technology Adoption Lifecycle). The downside of much of the understanding around social through the view of early adopters or innovations, from their own perspective or others watching, is that is far from mainstream. The personality types and traits of this roughly 5 to 10 percent of the population are quite different from the norms of more mainstream users who follow later. Much of the understandings of the clicksperts who followed the trends and tried to make sense of things (often labeling themselves “social media gurus”) failed to grasp they were trying to explain the edges as the norm.

One of the most telling examples of this is from Twitter who explained 40 percent of our active users simply sign in to listen to what's happening in their world..

Understanding How the 90 Percent are Social

If we are going to focus on social for everybody we need to understand how the 90 percent who are not innovators and early adopters are social. Most people do not interact the way social is described by the clicksperts, social media gurus, or most of what is written up in Mashable (I spend so much time undoing what is written in Mashable as “understanding” - this was the impetus for my coming to grips with Popular - Thinking about it, which also applies to so many other things).

As we saw with email in the 1990s, social tools can reach the 100 percent. The BBCs wiki usage passed 100 percent adoption after 5 years of use. It takes time for adoption to happen, but it also takes guidance and modifying tools for use by mainstream. Euan Semple, who started and guided the BBC initiative as their head of knowledge management as a fantastic book out now, Organizations Don't Tweet, People Do: A Manager's Guide to the Social Web, if you want a good understanding from somebody else who has been living this.

5 Beginning Social Questions

Where I started getting to the reality of social and collaboration in 1996 I was managing a private Compuserve forum for 3,000 lawyers for a legal trade organization. I was continually running into issues pertaining to social problems. Having a solid academic background in social sciences with organizational communication and communication theory undergrad and public policy for grad school looking at human social interactions, particularly at social scale scale was something I had training for and experience with. But, having a mediated interface through a whole new perspective to think through.

I quickly realized there were a high level set of 5 questions I was continually coming back to so to try and solve some of the issues I was seeing with use and non-use of the service (I also spent a lot of time with the Compuserve product people talking about issues and means to resolve them). The 5 questions I asked started with trying to resolve, “Is it:…”

• The person
• How humans are social
• Cultural influences - or cross cultural issues
• Organizational constraints
• Problems with the tools / service

Never was the problem just one of these elements, but it was a mix of two or more of the elements. On very rare occasions it was just the person, but like many things where there is one instance there will often be more. These 5 simple beginning social questions get intermingled and tangled very quickly and are just the tip of the iceberg for all things social software that would follow for me.

The Person

The person is often the most common place to point with there is a problem or issue with social software. If it is seemingly a one-off problem keep good track of what it is, as quite often you are looking at social software's equivalent “patient zero” (also known in epidemiology as the index case) and understanding that one person's problems and issues as much as possible will help sorting out the real issues then if and what could or should be done to resolve the issues.

The downside with focussing on just the individual is everybody is different with their make up is different and has different experiences, has different cultural inflections, is a different personality type, has a different social role, as a different work role, and many other variables that influence who they are and their social interaction needs. Many of these variable or elements can be clustered with others with similar traits so that we are not dealing with an “every snowflake is different” syndrome, but need to at the core of it understand why every person (snowflake is different).

How Humans are Social

Understanding with some broad and unfocussed grasp of human sociality we need to look at if the problem at hand or the need in front of us is viewed from how humans are social. When we think in this perspective it is best not to use an innovator or early adopter perspective as they do things that are out of the norm (think of Mark Zuckerbergs egregious claim that people want to be openly social and nothing can be farther from the truth for most of human social experience, most humans normally are not wired to share everything openly and looking at those of us who are broken should not be mistaken for the norm). Thinking of how humans at scale or broadly generalized are social can help is a helpful perspective, but knowing what the real norm is, or the norm is for the relative cultures is helpful.

Cultural Influences - Cross Cultural Clash

How humans are social is often problematic as the norms we consider do not really translate well across cultures and particularly inside organizations. We do know that people with interact with others in smaller more comfortable venues, but who is included nor not included in the conversation or even simple sharing of things doesn't universally translate. I have twice run across people who have been working to solve lack of use of collaborative platforms that are shared between US/UK portion of the company and their Japanese counterpart. The core problem is in the forum groups the US and UK employees will share more openly and freely if their managers are not part of the discussion and do not have access to the group, but in Japan not having your manager in the discussion is seen as highly disrespectful and is something that employees should never do.

Not only does culture come from global cultural differences, but understanding an organizations culture is also essential as many times the organization has its own ingrained ways of handling things and its culture is broadly adopted through learning or other less formal enculturation patterns. Understanding what happens in the organization when something goes wrong is often a really good pulse point. Having the depth of understanding from change management professionals is helpful for sorting through an organization's baseline culture and the possibilities for modification to that existing perspective.

How and organization is managed and controlled is really helpful to understand as it often is echoed in how social software and collaboration tools are used and adopted. How malleable that corporate culture is will be very important to grasp at the stage of tool selection, because each tool and platform has its unspoken social interaction model that it echoes. Getting the wrong interaction model mapped to an organization's culture that runs counter to that organizations broad culture you will have issues. It is also important to keep in mind most organizations have many subcultures, which often makes one social interaction model difficult for adoption and optimal use.

Organization Constraints

Every organization not only has its own cultural fingerprint, but it is often constrained by external pressures, particularly if it is a publicly traded company, an organization in a heavily regulated industry, or has a lot of oversight as governmental and NGOs have with their public view and those that gave and review their charter. The external oversight along with rules and regulations as to what can be said, who can see it, who shouldn't see it, and formal record keeping all play an important role in use, as well as tool selection and its implementation.

This is also often intermingles with cross-cultural issues of roles in organizations as some, by their role (legal, HR, mergers and acquisitions, etc.) are far more restrictive and not prone to sharing or cooperation outside the bounds of their small trusted and approved collaborators working within their known bounds of permissions and sharing. Where as those in marketing roles are often far more comfortable interacting more openly and broadly and are willing to cooperate, but you take the sales slice of that marketing and you hit people who are heavily competitive and often have personality types prone not to share and are also rewarded and encouraged to be competitive (often with the mindset, you share with me as much as you want, but I'm am still competing heavily and sharing is not in my best interest at all - yes, heavily stereotypical and often for a reason).

Is it the Tool or Service

The medium that all of this social interaction takes place to get the work down plays a tremendous role in what works and doesn't work. As I pointed out recently in Social Reticence of a Click things as simple as a star to favorite things (as the only option for one of three different social intentions) can lead to serious problems (serious if getting fired is serious)). Most (I have yet to find one that actually grasps this, but I am open to being surprised) of the analyst firms out there have simple check boxes that do a tremendous dis-service to social software and collaboration services as the things that actually matter and are needed to be understood are not included in any of the check box mindset understandings of the world. The magic quadrant and other farcical measures don't help understand what is needed to make good choices and this often leads organizations to purchase the wrong tools for their needs.

Often the tools get in the way from our optimal interactions as many of the elements that are important to grasp as put forward above (as simply and thinly as they have been conveyed) were not grasped in the consideration, selection, purchasing, nor implementation and honing of the service. Far too often the tools have been created outside of the depth of understanding of human social interactions and implemented by IT whom, as was brilliantly broad brush stated by Maciej Ceglowski of Pinboard, is as relevant to do the work as having a Mormon bartender (having spent much of my professional life within IT and dealing with social this is as apt a metaphor as any).

The tool is often one of the pain points, as most do not embrace human social needs as they run counter to how humans are social. But, the tools is not always the part to blame.

It is A Mix

As it is with many things, it is not the individual pieces of this 5 part question looking to find a simple answer, but it is almost always a mix of some, if not all of these five elements. Our poorly thought through understanding that social is simple quickly hits reality that we must get beyond simple social understandings to understand how it is complicate and complex to we can move beyond. Looking at these five elements knowing which ones play what roles as part of the foundation of the problem set is essential, but having good data and understanding is needed, but also a solid understanding in of this panoply of intertwingled elements and how to best make an adaptive service that meets the needs of the people who have been waiting for a long time for a good social and collaborative service that meets their needs of business as it takes a larger step to better interactions in the work environment. Yes, most don't know they have been waiting, but most know the tools they have been strapped to in the past and often currently are not anything that they should be and often the tools and services are not really usable and IT spent money to create a problem rather than taking large strides to solve it. It is time to get beyond that, but doing so takes moving beyond the model of simple social.

Getting Beyond Simple Social

View more presentations from Thomas Vander Wal

Understanding the Cost of We Can't Find Anything

One problem I often hear when talking with any organization about new solutions is understanding the cost and inefficiency of their existing way solutions, processes, or general way of doing things. In the past year or two I have used various general measurements around search to help focus the need for improvement not only on search, but the needed information and metadata needed to improve search.

We Can't Find Anything

There is nothing more common that I hear from an organization about their intranet and internal information services than, "We can't find anything." (Some days I swear this is the mantra that must be intoned for an organization to become real.)

There are many reasons and potential solutions for improving the situation. Some of these involve improved search technologies, some improved search interfaces, or But, understanding the cost of this inefficiency is where I find it is valuable to start.

The first step after understanding you have this problem is to measure it, but most organizations don't want to pay for that they are just looking for solutions (we all know how this turns out). The best method I find is walking through the broad understandings of the cost of inefficiencies.

The Numbers...

At Interop 2009 I presented "Next Generation Search: Social Bookmarking and Tagging". This presentation started off with a look at the rough numbers behind the cost of search in the enterprise (see the first 16 slides). [I presented a similar presentation at the SharePoint Saturday DC event this past week, but evaluated SharePoint 2010's new social tagging as the analysis focus.]

Next Generation Search: Social Bookmarking and Tagging

View more presentations from Thomas Vander Wal.

Most of the numbers come from Google white papers on search, which gets some of their numbers from an IDC white paper. I also have a white paper that was never published and is not public that has slightly more optimistic numbers, based on the percentage of time knowledge workers search (16% rather than the Google stated ~25% of a knowledge workers time is spent searching). There are a few Google white papers, but the Return on Information: adding to your ROI with Google Enterprise Search from 2009 is good (I do not endorse the Google Search Appliance, but am just using the numbers used to state the problem).

I focus on being optimistic and have I yet to run into an organization that claims to live up to the optimistic numbers or total cost of inefficiency.

• Few organization claim they have 80 percent of or better success with employees finding what they need through search
• That is 80 percent success rate
• Or, 1 in 5 searches do not find what is they were seeking
• A sample organization with 500 searches per day has 100 failures
• An average knowledge worker spends 16% of their time searching
• 16% of a 40 hour work week is 1.25 hours spent searching
• 20% (spent with unsuccessful searches) of 1.25 hours a week is 15 minutes of inefficient productivity
• At an average salary of $60,000 per year that leads to $375 per person of inefficient productivity
• Now take that $375 per knowledge worker and multiply it by how many knowledge workers you have in an organization and the costs mount quickly
• An organization with 4,500 knowledge workers is looking at a inefficiency cost of $1,687,500 per year.
• Now keep in mind your knowledge workers are you most efficient at search
• Many organizations as a whole are running at 40% to 70% success rate for search

We Know We Have a Costly Problem

This usually is enough to illustrate there is a problem and gap with spending time resolving. The first step is to set a baseline inside your organization. Examine search patterns, look at existing taxonomies (you have them and use them to some degree, yes?) and work to identify gaps, look at solutions like tagging (folksonomy) to validate the taxonomy and identify gaps (which also gives you the terms that will likely close that gap). But get a good understanding of what you have before you take steps. Also understand the easy solutions are never easy without solid understanding.

Evaluating what, if any taxonomy you have is essential. Understand who is driving the taxonomy development and up keep. Look at how to get what people in the organization are seeking in the words (terms) they use intend to find things (this is often far broader than any taxonomy provides).

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.

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.

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.

Getting Info into the Field with Extension

This week I was down in Raleigh, North Carolina to speak at National Extension Technology Conference (NETC) 2008, which is for the people running the web and technology components for what used to be the agricultural extension of state universities, but now includes much more. This was a great conference to connect with people trying to bring education, information, and knowledge services to all communities, including those in rural areas where only have dial-up connectivity to get internet access. The subject matter presented is very familiar to many other conferences I attend and present at, but with a slightly different twist, they focus on ease of use and access to information for everybody and not just the relatively early adopters. The real values of light easy to use interfaces that are clear to understand, well structured, easy to load, and include affordance in the initial design consideration is essential.

I sat in on a few sessions, so to help tie my presentation to the audience, but also listen to interest and problems as they compare to the organizations I normally talk to and work with (mid-size member organizations up to very large global enterprise). I sat in on a MOSS discussion. This discussion about Sharepoint was indiscernible from any other type of organization around getting it to work well, licensing, and really clumsy as well as restrictive sociality. The discussion about the templates for different types of interface (blogs and wikis) were the same as they they do not really do or act like the template names. The group seemed to have less frustration with the wiki template, although admitted it was far less than perfect, it did work to some degree with the blog template was a failure (I normally hear both are less than useful and only resemble the tools in name not use). [This still has me thinking Sharepoint is like the entry drug for social software in organizations, it looks and sounds right and cool, but is lacking the desired kick.]

I also sat down with the project leads and developers of an eXtension wide tool that is really interesting to me. It serves the eXtension community and they are really uncoupling the guts of the web tools to ease greater access to relevant information. This flattening of the structures and new ways of accessing information is already proving beneficial to them, but it also has brought up the potential to improve ease some of the transition for those new to the tools. I was able to provide feedback that should provide a good next step. I am looking forward to see that tool and the feedback in the next three to six months as it has incredible potential to ease information use into the hands that really need it. It will also be a good example for how other organizations can benefit from similar approaches.

Folksonomy Provides 70 Percent More Terms Than Taxonomy

While at the WWW Conference in Banff for the Tagging and Metadata for Social Information Organization Workshop and was chatting with Jennifer Trant about folksonomies validating and identifying gaps in taxonomy. She pointed out that at least 70% of the tags terms people submitted in Steve Museum were not in the taxonomy after cleaning-up the contributions for misspellings and errant terms. The formal paper indicates (linked to in her blog post on the research more steve ... tagger prototype preliminary analysis) the percentage may even be higher, but 70% is a comfortable and conservative number.

Is 70% New Terms from Folksonomy Tagging Normal?

In my discussion with enterprise organizations and other clients that are looking to evaluate their existing tagging services, have been finding 30 percent to nearly 70 percent of the terms used in tagging are not in their taxonomy. One chat with a firm who had just completed updating their taxonomy (second round) for their intranet found the social bookmarking tool on their intranet turned up nearly 45 percent new or unaccounted for terms. This firm knew they were not capturing all possibilities with their taxonomy update, but did not realize their was that large of a gap. In building their taxonomy they had harvested the search terms and had used tools that analyzed all the content on their intranet and offered the terms up. What they found in the folksonomy were common synonyms that were not used in search nor were in their content. They found vernacular, terms that were not official for their organization (sometimes competitors trademarked brand names), emergent terms, and some misunderstandings of what documents were.

In other informal talks these stories are not uncommon. It is not that the taxonomies are poorly done, but vast resources are needed to capture all the variants in traditional ways. A line needs to be drawn somewhere.

Comfort in Not Finding Information

The difference in the taxonomy or other formal categorization structure and what people actually call things (as expressed in bookmarking the item to make it easy to refind the item) is normally above 30 percent. But, what organization is comfortable with that level of inefficiency at the low end? What about 70 percent of an organizations information, documents, and media not being easily found by how people think of it?

I have yet to find any organization, be it enterprise or non-profit that is comfortable with that type of inefficiency on their intranet or internet. The good part is the cost is relatively low for capturing what people actually call things by using a social bookmarking tool or other folksonomy related tool. The analysis and making use of what is found in a folksonomy is the same cost of as building a taxonomy, but a large part of the resource intensive work is done in the folksonomy through data capture. The skills needed to build understanding from a folksonomy will lean a little more on the analytical and quantitative skills side than the traditional taxonomy development. This is due to the volume of information supplied can be orders of magnitude higher than the volume of research using traditional methods.

Life Data Stream

Emily Chang posted about "My Data Stream", which brought to mind the idea of personal planets. Emily is pulling together the streaming data from her digital life that passes through feeds.  Jeremy Keith has written about his life streams and has had a nice interface to Jeremy's Life Stream for some time now.

It was a chat with Jeremy and some others this past summer at the Microlearning conference that I started thinking about playing around with a personal planet, which would use PlanetPlanet, a Python script, to pull all of my life streams together.  It works nicely on my laptop, or did until the December crash.  But, now it could be time to put it out in public.

Personal Planets

Why a personal planet? We have an incredible amount of information that passes before out eyes and that is generated by our simple actions.  Emily did a great job showing the breadth of feeds generated.  This seems a simple thin thread.  What if we could quickly scan that thread and annotate it to make it easier to refind.

Planets are relatively easy to build and it should be easy to share for others to build upon. Personally, I am really surprised there are not thousands of these out there already.  Now to start tinkering a wee bit this week.