5 Core Insights for Community Platforms Today

Intro:

The last two or three years have been "interesting" in the community platform space as things have been shifting quite a bit with regard to vendors. Most every organization I know is looking at changing their platform as their contract is up for renewal and they are looking around, or their vendor's state has changed. There are also an incredible number of organizations who are looking at getting their first platform up and running. Many are also looking at augmenting what they have or trying to unify what they offer or build a more unified environment.

It is important to remember just as organizations are social human environments that interact at different social scales simultaneously and with differing tasks and needs, the platforms that support them also focus on different segments and scales as well. A rare few handle multiple scales and segments in one platform or product. It is best to start with understanding one's organizations own needs for these then looking for solutions. These are 10,000 foot level views of things.

Understanding Needs and Types of Platform

Just as there are different human social interaction models at different scales in organizations and different engagement types around knowledge and work, there are similar types for platforms and tools. Many platforms were built looking at one segment and optimizing toward that model (often not intentionally, but driven by customer need and expressed pain points).

There are four main types of social platform segments based on their social interaction models. They are not fully mutually exclusive of each other, but overlaps that are solid across with two or more strengths are rare. These types of interaction models are based on what the needs are for the organization.

Collective Social Model

The first of these is collective interaction which is both a collective social model, in that it is people working together to build a whole perspective across their expertise and capabilities. But, it is also collective in the manner of activity in that they are collecting and curating information. Collective social tools are highly valuable for gathering information, but also for seeing the whole of an information space. These are common in competitive analysis, legal environments, M&A, early assessment of a product or process. The focus in the Collective Social Model is around a subject (a social object) where getting full (deep and broad) understanding is what is valued. Filling in gaps and organizing, through curation, is the working model. These spaces and their outputs can be fodder for knowledge bases, libraries for teams and groups, and the foundation for building something upon.

Cooperative Social Model

The Cooperative Social Model is based on social interactions where there is sharing, questions asked with responses, and interacting around what others are sharing and doing. This is the common model many people think of for teams and enterprise social networks, which are drastically different scales with different core needs, but the social interaction models are very similar. The Cooperative Social Model focusses on a subject with others sharing around that subject, but they are also interacting with each other to further understanding and to often build cohesion. A common interaction model can often be thought of as a call-and-response interaction where something is shared into a space (by a person or system notification) and others respond or take action upon it.

Organizations use these models in teams, small and large groups for community of practice or location / specialty interest sharing, community spaces (all inside an organization, as in an enterprise social network), and network model which spans beyond an organizations boundaries to interact with consultants, B2B, customers, clients, etc. Each of these sub-models operates at different scales (more on this in the next section) and each of these sub-models are different because the focus and scale and often aren't all that interchangeable the platforms often only work well with one of these levels well and not across more than one.

Collaboration

Collaboration for the last 20 plus years has often been the blanket for social platforms where people interact with others around work or help each other. But, the older understanding and framing is around bringing different ideas and approaches together into one space where the differences are negotiated and mitigated into one cohesive path forward. The management of the background for what is negotiated and mitigated is an essential component as it capturing the reasoning for the way forward on each point. Most often the path forward isn't the final path forward, and all the work researching the paths not chosen have value when there is the inevitable need to iterate and change course (slightly or drastically). Quite often the greatest value isn't what is captured around what you chose, but in what is captured around what you didn't choose. A decent level of capturing of information and understanding with what wasn't chosen save large amounts of time when iterating or course-correcting. Decent level of capturing background can make a course correction a couple to a few weeks rather than months of going back to the starting point again. There is gold in the capturing what isn't chosen today and why.

Communication

The last of these segments is Communication. Communication platforms not only support people interacting with each other, but supporting an activity stream for services sharing status, insights, and alerts where it is relatively easy to follow and interact with others around it. Traditionally this has been email for people communicating and as the activity stream. But the downsides of email with its lack of ease of onboarding someone to a conversation and its history, or to status is problematic. The modern model of "point and don't attach" many organizations adopted in the past 10 to 12 years for files and objects is much cleaner in social communication channels.

The communication service is often the intersection and jumping off point to other services and platforms. People can interact in the service around a subject, but notification of a conversation in another platform can also surface in the communication channel and respond there or respond back in the other service.

Communications often support teams well and their distinct needs (tasks, status, process & planning, progress, calendar, team fit, shared resources (files, etc.), communication, and decisions) either in the platform or through notifications from services that handle these needs. A good communication platform integrated well, shouldn't be overwhelming and can provide a good view across a team's activity, state, and needs along with the means to initiate responses.

Good communication platforms are invaluable. They are more than chat services and notification activity streams. They should integrate well and provide the means to highlight was is needed for attention across disparate avenues, but also should provide the means to interact in the comms service as well as jump out to another platform easily and support an easy means to be a supportive layer across many endpoints.

Scale(s) of Social Need Areas

As mentioned above, understanding the scale of social segments is desperately needed before assessing a platform. Understanding scale is one element of social platforms that is often overlooked and becomes problematic if the fit isn't there. A service focussed at large scale social interactions for a community or network level social interaction often doesn't handle the smaller scale social needs well.

The smaller level social segments are: Collective, Teams (and sometimes small groups in Cooperative), and Collaboration. Each of these segments work best with groups of 8 to 12 or fewer, but sometimes up to about 25 people at maximum.

Where things sometimes get a little complicated is with groups and the larger scale platforms. Much of the social interaction in larger scale platforms is in groups (large and small), but a good group platform may not work well for community nor network scale interactions. Community (mostly inside an organization or a bounded community of practice) and Network scale capabilities are categorized as such because of their global capabilities. These capabilities are: announcements (which often can be pushed into commutations platforms), identity and authentication models for access and permissions for roles, search, cross-pollination, and ability to integrate with teams for their ability to provide support or get support.

User Experience

An area that doesn't get the focus it should nor the understanding it needs is the user experience. This isn't just the ability to brand and modify the UI with colors and decoration, but the ease of use and fit for the user's mental model.

A big differentiation platform to platform is the user experience / user-centered design. The flows and ease of the use flows for common tasks is essential. The ease of understanding social interactions should fit the users mental model and be clear to the users. Many platforms aren't using current interaction models for common activities, like uploading content. But, also the social interaction design models are essential and for many platforms they have yet to really embrace these understandings and are rather clunky and cumbersome.

A key focus for social platforms is people interacting with people through a platform and often interacting around a shared object. Often the platform gets in the way of these people-to-people interactions. But, many systems don't quite get to enabling clean interconnections and these lead to limitations and confusion, which shouldn't be introduced.

The platform should have a solid UX and social interaction design team working on it full-time and their own leadership who has depth and experience with social interaction design. I've been seeing some platforms that have been allowing the community managers to select and optimize their user experience, which is something that has been a long time coming. The ability to have a simple interface and simple interaction model as a user gets started is essential, but enabling more complicated experience that support more advanced user's needs is something that is really beneficial.

Interconnection and Interoperability

One of the big insights from organizations is that those who have a good percentage using and relying on their social platforms is they have more than one. Often for many organizations at scale there are more than one team tool or platform in use. They may have and community platform for their communities of practice, some different tools and platforms used at the team level, and recently a communication platform all integrated to some degree or another.

Over the last 12 to 20 years one of the big changes has been the capability to interconnect and interoperate different systems and platforms. Many vendors touted their capability to pull information into their system easy from other platforms, but it was rare for them to open their capabilities to others. The last 10 years or so that too has shifted with platforms not only opening their APIs for others to read and use, but also new platforms and new versions of platforms start with APIs and build their platforms out from there.

While there is a lot of proclaiming kumbaya, we all get along, mantras the ability to truly interconnect and interoperate across and between platforms can be much more muddled. Spending time with vendors showing what they can easily share out in APIs and streams, what takes more work, and what is really difficult if not impossible is something worth spending time on. This will pay off when working to connect a communication platform and various team platforms together. It is also worth the time to look at integration enabling services like Zapier and Microsoft's Flow to see what capabilities are out there for services and platforms you may have interest in, but also see what others are doing.

Exit Strategy

Related to open APIs and open data models for interconnection and interoperability is using similar and more when the time comes to move on from a platform. Very few people think about this in the early stages of product selection or at all. The last year or two this subject has been coming up a lot as the landscape for social platforms for organizations change. As people and organizations find value in having social capabilities in the organization they may realize they have changed as an organization and need a different solution, they realize their platform is not a great fit, or their platform or service has changed requiring the need to move to another option.

It is incredibly important to think about how data, conversations, knowledge, history, etc. can be exported out of a system before they purchase the system. There are some organizations that run failover systems for some or all of their core interactions, while others test their archives and exports for continuity exercises should their main platform cease to function or they have a short window to transition.

The ability to have a different platform that can provide continuity of operation, or enable failover through export and / or API backup is a conversation that is needed before purchasing not after.

Often an added benefit of this is these platforms often have better integration, improved capability for advanced analytics (few platforms have analytics that meet mature needs), and solid up-time through redundancy and failover systems.

Summary

These five core areas to consider are far from a full list of areas to focus on, but they are areas that should be on your list for product selection, or your regular product review cycles (every quarter or six months is a good time to take a look around and see what has changed and what your organizations next possibility could be).

Other areas that are highly important include: Security, great customer support, great uptime (for the platform and all of its sub-services), mobile use (including integration into mobile device management environments), accessibility, great admin tools with ease of use (a great test of solid user experience is looking at admin tools and services and how well they are done), failover plans, set integration native in the system (file / document storage is one of the most common), and frequency of product updates (incremental and major).

Team Roles Needed for Social Software Projects

I have a lot of hands-on designing, developing, and managing of social / collaborative platforms since 1996 and regularly advise product makers, vendors, and buyers around right fitting and understanding then working on solving problems they may have. One of the things that was regularly surfacing around 2007 as enterprise social platforms were getting taken seriously. But tool selection and roll out of them was often bumpy at best as there was a lack of the breadth of understanding around many services. This was the case with many vendors, but also really much the case on the customer side of things. When working through discovery of the problems that customers were having, usually in the “One Year Club”, many of the issues correlated to the lack of understanding the breadth of perspectives important to social and collaborative work and environments.

Looking at situations where products were right fits gave insight into what works well. The success factors surfaced where vendors with well rounded products that were correct fits for certain customers [commercial social platforms that understand social interactions at various scales and get their products right for specific users] and roll outs that have rather solid adoption. These all had breadth and depth of understanding. Looking at what helped them be successful it wasn’t one or two things, nor five, it was they had most of 14 different roles with roles in their selection, development, strategy, planning, launch, and running of their offering covered.

If you wanted to have success it became clear that having breadth and depth with these 14 roles would provide a good team that could help work through many, if not all the difficult struggles most social software / services rollouts and programs running face at one point or another. When looking across many of the projects I worked with in the One Year Club category (or colleagues who were working with programs that needed help) most of the efforts didn’t have the 14 roles covered. Most had 2 to 4 roles covered at best.

This gap was glaringly apparent when large parts of a rollout were in the custom build model, much like many organizations were struggling with around Microsoft SharePoint or other build your own solution platforms. Organizations weren’t buying finished products, but a platform that focussed on heavy customization (often with difficulty getting what they hope to do working well). Part was what came out of the box from SharePoint was a bit rough (3rd party solutions like Newsgator/Sitrion were quick ways to get things working well for social and collaboration needs in SharePoint with little hassle). What the teams working on SharePoint were lacking were 10 to 12 roles that they desperately needed for depth of understanding around how humans are social, how things function, ease of use in contexts, and other essential needs.

Moneyball of Social Software Teams

This breaks down the 14 roles at a somewhat high level. At times myself and others have called this the Moneyball system of social software. In baseball, which Moneyball focussed on, they focussed on what made the Oakland Athletics team with a low budget able to compete with large budget teams. Big budget teams focussed on home runs and star pitching along with other simple understandings of analysis. What the Oakland Athletics did was look at what makes a winning team and how to measure things based on outcomes by understanding things more broadly and deeply.

What I ran into was similar, though understanding the roles and needs to have a solid well rounded social software team, so to get solid successful results. Most solutions were rolled out with 2 to 5 roles with depth, but what are the other factors that also have deep value and because they were missing had a less than positive impact? Over the last 6 years or more I’ve shared this list of 14 in workshops and with long engagement clients (but at a deeper level), but also help them cover the ground across a few of them where I have that depth and breadth (from 20 years of experience with social software and formal learning).

One last thing to realize with this list, particularly if you are on the customer side, is you may not have these skills and roles, but your software or service provider cover some you are missing or help narrow the gaps for roles missing.

The 14 Social Software Roles for a Solid Team

IT Development

IT development is usually the one role that social software rollouts have covered. The development portion and getting the code right is often not an issue. This role covers development, integrations, stability, and upgrades / patches.

Content management

Content managers are incredibly helpful not only with content management practices and needs, but could also cover content strategy needs as well (if content strategy isn’t there working with communication specialist helps close this need). Most social environments have professionally created content that are part of their offerings as blogs or other more planned content models. But, content also surfaces out of conversations and cooperative activities in communities and groups. This content can be repurposed as it is or honed for other targeted and / or broad uses. Content managers also often works with document management and taxonomy roles for ease of finding and helping keep content well structured and easily found.

Community management

The community manager is a role that some organizations and services understand the need for to be successful. Others have yet to understand the need for this yet. Having a solid community manager who can help set the tone and culture of the community and groups, as well as help set good skills and practices in place for members of the social offering is a great asset. The community manager is the guide, host, and facilitator, but often has good depth working with difficult situations and turning them into very good outcomes. Good community managers are also adept at seeing needs and gaps in tools and services that need attention. A good community manager can’t fix a tool that isn’t a good fit for an organization, but can help get through that state to one that is a better fit, then help the better fit thrive.

Communication management

Solid communications management folks help with finding solid messages and well created content into a social environment. But, from a social perspective they also should have strength seeing content from users in the social environment that needs attention (as it is positive and needs more exposure, or it is negative and needs a calm way handling of it). Understanding the life cycles of content and workflows around finding, creating, honing, and right fitting content and messages shared from the organization as well as from the users is powerful and helps bring life to the social environment. Setting good content guidelines is another way the communication management role contribute to social environment success.

UX general design

User experience design is essential and has long been overlooked in enterprise until lately, as the focus services being designed for use and ease of use weren’t considered as needed when you could just send people to hours of training. But, with social offerings there are a lot of diverse elements that people are having to work through, besides how to get something done in a platforms or service. Good usable design with regular user research (prior to taking steps, as well as while designing potential options, and honing what is in place) helps take the rough edges off that get in the way of people using as well as understanding what a service does, and can do.

Social interaction design

General UX design isn’t enough with social platforms as there are a lot of interactions with the service and system, which is used to interact with others (which is difficult for many on its own). Understanding the design of social interactions (what is clicked and then what happens after it) so that the tools aren’t getting in the way, but also some of the rough edges of human social interactions are also eased is badly needed. There are broad options for buttons, forms, profiles, reactions, likes, etc. and social interactions designers work to understand what are the best fits for the contexts at hand and what the impacts will likely be with distinct user groups. User testing around social is a little different from general user testing as the situation requires working with a diversity of end points (people) at either end of what is put in place that need to be understood. Testing also needs to include various depth of use and maturity with the service. These help find a good fit in the social interaction design that works well.

Data analyst

Data analysts are essential to help understand benchmarks prior to starting down the path with social offerings, but also are needed to dig into the data to see how people are and aren’t using the services. Many platforms have decent data analysis, but it only scratches the surface and much better analysis is needed; particularly in larger solutions, more mature use environments, scaling, as well as those that have a diverse user segmentation. Social environments change drastically as they grow and act differently with more diversity as they scale. Data analysts should have good understanding of Social Network Analysis (SNA) / Organizational Network Analysis (ONA as well as many social analytics capabilities for seeing diversity, clustering, social scaling changes, etc. Having a solid data analyst helping with capturing the data that is needed, keeping privacy in mind, and slicing and making sense of the data with clarity has a big impact with what deeply matters in early stages and as use scales and matures.

Change management

Change management is not only essential for preparing organizations and people for a new service and offering, but deeply needed for the changes that come along with using these services. Digital social environments help enable normal networked social patterns that are well covered in Wirearchy as the shifts in ease of connecting in a digitally enabled networked environment can be disruptive. This is mostly in a positive way, but is not always perceived as positive if it is not known the changes may be coming. Helping people understand what the new services do and the needed mental models for working in this way are areas change managers can help with, as well as work with others around legal and compliance issues that need consideration.

Document management

Document management, with a solid understanding of social environments, helps with working through how to archive valuable content and conversations, but also how to ease finding and connecting to systems of record from inside a social offering. This connection needs to work in both directions, one is surfacing documents and resourceswell (within permissions guidelines, compliance, and connecting to the right / latest version), but also working out how to show the document or record is being discussed and used. This use activity around a record can be a valuable indicator that it may be getting updated, or caveats have surfaced that are valuable to all who view and need the record.

Social scientists (ethnographer, urban planner, sociologist, etc.)

The social scientists are often overlooked, but should be one of the first roles included. Social scientist, particularly those who have graduate school level of work, see social environments differently than most who don’t have that background (this may be a personal bias, but talking with others with similar background the “how was this essential understanding not seen” is a common phrase in reviewing social offerings). Social environments are under constant change and morph as (sub-)cultures intersect and social environments scale. The questions asked by social scientists, along with framings with models around how humans interact, while watching for conflict and the patterns that surface in constant change and are not seen are nothing less than essential. One of the common downfalls with social platforms is around they often don’t allow people to be social like humans are social. There is no better way to keep an eye out for that to mitigate for it, but also understand how humans are social at various scales than having social scientists involved.

Taxonomist/folksonomist

Taxonomies are essential for easily grouping information, conversations, and content and for helping people find relevant and related matter. But, language and mental models for what things are called and are related to are often far more diverse and emergent than taxonomies allow for, so embracing folksonomy is also essential for social environments. Having a taxonomist involved will help set categories and information structures in place that will enable the capability for solid finding and refinding. If that taxonomist also embraces folksonomies (and the service has the foundation for it) the ability to have emergent taxonomies that take less work to keep up to date than traditional taxonomies can happen. Also embracing folksonomy helps new ideas and mental models (these emerge through new members, training, cultural shifts, etc.) be included in the ease of finding and grouping of findable and refindable information.

Knowledge management

Knowledge managers seem to be in and out of fashion in organizations these days, but no matter what the rest of an organization believes having solid knowledge management as part of the social software team is essential. Early social platforms were around 20 years ago were being built on understandings for how knowledge is created and honed, as well as changes over time. The social platforms had issues, but the foundations in knowledge management are solid. The knowledge manager provide understanding in what the services need to capture knowledge and resurface it when needed. But, in social platforms the “who” around knowledge is helpful as well. Often there is more than one person with expertise who has honed a different dimension of a full understanding, so it isn’t just one answer that is sought and one expert, but likely a few or many.

Search specialist

With all of the conversation, content, information, and knowledge created, shared, and pointed to it doesn’t matter much if it can’t be found. Part of it getting found is helped by content managers and taxonomists / folksonomists, but search needs to be solid as well. Most platforms have search built in to their offerings, but evaluating if that search will suffice at various scales will need a search specialist. But, search in platforms is also often tied to other search systems and how those integrate to find, hold onto, and surface information, content, and resources takes solid search specialists to get right. A lot of information and resources inside an organization is difficult to find (not by intent, but it is trapped in systems that aren’t searched easily nor integrated well) and social environments often point to these resources and frame what is there, which enables that content and resource surface in searches. Your whole organizations gets smarter and has more available resources if the social environment and search is well matched.

Legal

Legal resources are often not thought of until it is late in the process. Working with lawyers to help understand compliance, privacy, security, and risks in general from a legal perspective. Working with a lawyer who can help understand not to just say this can’t be done, but how to meet compliance and other needs and still have a great service is an amazing benefit and one that saves budget and time down the road helping meet needs and provide a solid offering.

How to Fill These Roles

Yes, 14 roles isn’t something that is easy to fill. But, this doesn’t need to be 14 different people. By knowing what to look for a lot of roles can be found and covered by one individual. Knowing what you need, often at a little deeper level than the high level outlined here, and how it fits in to the team can help shape a team of 5 or 6 people, or who can move in and out of the team at various times to help provide the breadth and depth needed.

Also, many of these roles can be and are covered by vendors who are doing things well. As walked through in The One Social Way or Not to Doing Social Really Well in Enterprise user research and other skills are being covered on the product side. Understanding from vendors how they test with users (what types of users - domain, roles, skills, etc.), how they understand social models and social scaling, build taxonomies or enable co-existing folksonomy for emergent taxonomy, enable search and integrate with existing search, have open models for data analysis, etc. can help see what roles are still needed.

Many of these roles (even if they are covered on the vendor side) are really good to have in the evaluation and selection process as well, so having these roles in a review and strategy team up front is a really good idea as well.

These roles also can be filled by integrators. This is rather rare these days, with the exception of a few small boutiques who have approached their offerings for integration and consulting by filling gaps they regularly saw as well. Many integrators are strong on the technical side and today often have good general UX people, change managers, and search integrators, but other roles with more depth around social science and social interaction design is not a focus most have had nor have considered.

Between vendors, good integrators, consultants, strategists, and in-house resources and hires it shouldn’t be that difficult to get the 14 roles covered in one way or another now that you know to look for them.

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.

Shift Happened - Part 4: The One Social Way (Or not) to Doing Social Really Well in Enterprise

Having been at the heart of social and collaboration since 1996 (no, I’m not kidding) it is interesting to see how large organizations that are doing social well (>80% employees are active) actually are doing it.

The interesting thing is most of these organizations are not using just one service or platform. They are using two or three, often with some additional small solutions for niche situations (niche for them). They are also not planning on migrating to one solution (most tried and it didn’t go 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) that comprise reality require embracing that reality with more than one approach.

No organization started out to do this, it just happened. This begins with IT often wanting just one solution that works for everybody, as that makes their job more manageable (often they select something from a vendor they already work with). Often what IT provides for the organization doesn’t work well enough for sections of the organization (often large portions of the organization), as it didn’t meet their needs nor mental models. Over the last 5 to 8 years getting a good social / collaboration solution needed relatively little effort for a division or group as it often runs in the cloud (meaning it doesn’t need IT) and could fit on a credit card for the team or a division’s PO so it is small enough to fly under the radar, so getting a right fit solution 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 until recently 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 from the different parties.

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. While it is a pain the most difficult piece is not porting the data, interactions, and differing privacy models. It is not retraining people (if heavy retraining is needed the selection made may really be the right selection), 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, but no vendor remotely close to delivering on that yet.

Most of the well used social and collaboration platform vendors have understood they really need to understand their users well. They did user testing and mapped their products to their user’s mental models and needs. But, the thing is their users are not universal (they are a subset of the whole) but 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 SharePoint as it is honed (and really not well) for tech centered folks or needs to be heavily optimized, but there are extremely few organizations with the depth of roles needed to modify SharePoint to get it to be easily usable widely in an organization. Jive works really well for knowledge workers (and even information workers). The innovation and leading edge teams and groups (it doesn’t scale up yet and works best with smaller groups) are often using Slack (there is no chance in hell you can remove Slack and they are likely the best minds and change makers in an 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, functional areas 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 is decent, but not great usage is doing great in parts of the organization, but untouched in others; 2) There are 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 system. Be fine with that reality. But, realize you can likely reduce the number of systems.

Now, the harder goal, is getting products integrated, 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 following a tech schematic that most integrators use as their blueprint.

The first step is to bring in people who understand the differences in the social platforms, beyond what the checkboxes say and vendors 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 services more than a decade.

Likely this person (or people) will be from outside the organization. It is rare such a person will be inside, so getting them access to the services will be required - as many organizations have rules against outsiders having access to platforms but it is needed for research to get honest insight and feedback 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 (if the right versions each are in place) 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 representing those not using it (also refine the understanding of who IS using it, as you don’t really want to mess with success of employees along the way).

Mapping the gaps where people are not using the tools, as well as why not, will start as a guide. In this mapping and research 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 they are used 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 organizations that have 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 (or what they rarely if ever use) 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 and vetted they 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 systems work into, out of, and around. Understanding the multiple 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.

It is important to keep organizational external boundary crossing in mind. Working with clients, consultants, and other valuable external resources in a closed system is really helpful. Having few services that are used with outside resources is a good thing from the perspective of keeping external parties confusion to a minimum. A services for document haring (like Box) along with a community and / or collaboration space is a good fit and keeps confusion to a minimum.

While There Is No One Way There Can Be Fewer

Many organizations hope to get to just one platform, but getting to a few that are optimized for large portions of the organization and their needs are going to be really helpful. This gets the advantages of productivity gains and efficiency that can come form services honed from solid user testing from vendors that match the people working in the tools (there will always be more user experience optimization needed, but it will be much less).

---

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

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

Donna, Designed for Use, Closes

The impending closing of Donna has bumped a couple of thoughts to blog to the front of the queue.

First off, Donna is an iOS calendaring app that focusses on one’s agenda for that day and upcoming days with a targetted focus on the transportation timing and how that impacts your day. If your life has children that need transporting between activities or work that is out and about bouncing to meetings or work sites Donna is utterly indespensable. Donna puts a focus on the getting between places, so calculates the travel time to let you know when you really should leave, as it monitors traffic and weather conditions. The app offers four different modes of transportation and the related times for those: Driving, public transit, biking, and walking.

One of the best parts of Donna, which many other applications also do, is it reads your native calendar on iOS and augments it. It isn’t a separate calendar to lose things in if you forget. Content you may modify to help plan in Donna, like search to find the exact location for a meeting, is added to the calendar object and can be used in other calendar apps. I will focus a bit more on this in the following section on “Small Apps Loosely Joined”.

Not only will Donna give you a warning when it is approching time to leave, but it can send those you are meeting with notification that you are on your way and / or you are running late. Donna also monitors the weather and can advise on transportation changes should you be walking or biking. One other really helpful element is having the option to use Uber, if you are in a city that has it (Donna knows) and the event is that day (this was incredibly helpful this week).

One of the wonderful things is the evening of the day prior Donna provides a notification of how many meetings you have the next day, but if you don’t have any in your calendar(s) it tells you to enjoy your day, which is a wonderful little touch.

Designing for Use

The thing that stands out with Donna is not just its really good interaction design and really well designed information structures for easy to scan appointments, but it is designed to solve a pain point. Most specifically it is designed for use. The design is focussed on solving a problem and to be an easy to use solution for that problem, which is: I have meetings and activities in my day that take me out and around and sorting out the timing so I can optimize my day for my interests (get more time by driving, more health and environmentally focusse using bike or walking, etc.). Letting others knwo when you are late or on your way is really helpful and directly tied to the mobility of getting to meetings and activities. Having an app that pulls all the needed information around that task set is fantastic.

Donna isn’t designed to be a full replacement for a calendar, but is there to augment it and the use needs around the activities of getting between places.

Donna also understands what is needed as well as not needed. Allowing for modifying settings for alerts and notifications is really helpful. Understanding when alarms are not going to be helpful, understanding helpful user preferences when you are running late (auto send notes, how far ahead, or not to send at all automatically). Donna was built with the idea of a really helpful human assistant who looks after your schedule and is a step ahead of you. This framing of use and a helpful model really shines through in the app.

Small Apps Loosely Joined

Donna and many other calendar apps that are on mobile devices are not aimed at fully augmenting your native calendar service, but to integrate and augment that service. The model that is increasingly familiar is along the idea of small apps loosely joined model. This model puts a focus on using standard data structures, common object types, and a central app or service as a hub to provide a foundation for other apps and services to use the core object and augment it, often with data that fits the model type, and exends use.

With Donna the object is a standard calendar entry that has day, time, timezone, location, who are meeting with, notes, etc. But, the app can improve the data in the object, such as location. But, most of the apps not only improve the information within itself, but improve the core data so all other apps that use that object as well. The apps are often offering agency to do a task, or set of tasks, around the object. Donna puts the use focus on the use needs for getting there and communicating with others around that activity.

With calendaring, many using Mac or iOS opt for Fantastical to imput new calendar items as its native language parsing into a calendar data structure is incredibly good. Some people really like the interface from Fantastical and use it to view their day and upcoming events. There are an incredible amount of viewing your calendar / schedule options out there. Another smart agent for the calendar is Tempo app, which works to aggregate everything around a calendar item and pull it into easy reach (very much in the Come to Me Web model). Tempo pulls all the contact information for all participants in a meeting, all related email, all related files, weather, etc. all within easy reach as part of its view of the calendar entry. Tempo is as indespensable as Donna is for me personally (and I heavily rely on Fantastical for easy input, on my mobile I talk the calendar entry info into Fantastical and let it do its thing).

Who is Living the Small Apps Loosely Joined Life?

So who is working this way? Not so surprisingly, if one has been paying attention to how people actually are using devices and services, the user survey’s the past year or so have been asking about using more than one app for task types (calendaring, notes, reminders, text, etc.) and finding that 60% to upper 70% of those surveyed are using multiple apps for task types. Those surveyed have often been well outside of the geek and nerd camps that have worked this way for years, but regular folks who are not deeply adept technically. The focus on apps that do a task or set of tasks insanely well and easily trump a large app that does many things somewhat well. That one size fits all and category winner thinking has been dead for quite a while and is far from helpful model for thinking about much of anything.

The last few years, either in conferasions or listening to them, with people talking about their apps and how they do things on the devices (often mobile and tablet) it is increasingly common to hear, “I use a few apps to do…” what follows is calendaring, text documents, notes, mapping, driving directions, reminders, etc. and two or more apps stated and the specific tasks and user flow they have for each app. These were often non-geeks, but having surveys targeted at mainstream users and their habits and use patterns really brought home how mainstream this actually is.

Good Bye Donna

As Harry McCracken pointed out in Yahoo to Donna Users: We’re Dispensing With Your Indispensable App Donna has become indispensable for me. The great folks at Incredible Labs (that includes bud Kevin Cheng) did a fantastic job with Donna. Keeping Donna going was likely going to be a struggle as the computing to suss out location and needs as well as the and licensing the transportation times they used was not going to live a long time as an ongoing free app. The competition with other apps starting to incorporate similar time for transit models (yet clearly not designed from a perspective of use, but as a feature to add) likely was going to make things tougher as well as Apple adding transporation times and notifications based on that in Mac’s Mavericks version (adding it to desktop OS and not the mobile OS really was an odd move that is very un-Apple as it was not designed from a use in mind perspective).

It has been a while that I have been worried about the long run for Donna. A chat with Kevin about running a start-up in this space somewhat gave legs to that concern. Many start-ups have an exit in mind from the start and with any luck and perseverence it is a positive exit (not just shutting it and going bankrupt). I am really happy for Kevin and the other Incredible Labs folks as they got a positive exit for them and I wish them well at Yahoo (for all that are making that transition). Incredible proved they could nail a service that is designed for use, which leads to it becoming a really valueable part of people’s lives. Thank your for bringing us Donna as an agent to greatly improve our lives.

Responsive Design is Part of the Question not the Answer

Today’s New York Times redesign has lit up Twitter and other services with many saying “… but, it isn’t responsive”. I quickly recalibrated who knows mobile design / development and who is still learning. Responsive design has become the mantra the zombies repeat for mobile. Responsive is one of the five options for mobile and most often the end product doesn’t end up with responsive as the best answer, it is the intermediary stage answer if needed.

I am going to start with looking at understanding mobile and the user, then look at how we got to responvie design, then look at the New York Times (which, I think is the most important piece of this whole piece).

Understanding Mobile and the User

The history of mobile and designing and developing for it goes back far beyond the iPhone and Android. It predates the years of smart phones that came before this current iteration, and gets it starts about the Post-WAP age (it actually starts with WAP, but it was so bloody limited and poor most skipped it). Early mobile started with the PALM generation of devices and building web pages that worked on the go (often through AvantGo or similar) or network connected apps. The design and thinking process, as far as which to use route to go started with understanding a few things (I framed these in 2003 in presentations, workshops, and client work as Model of Attraction Receptors, which I realized never blogged so can’t point to it but will have that shortly as an active link): The user and their use (the intellectual, perceptual, and physical receptors) and the whole of the device system (mechanical receptor).

The user’s basic need is they want the content or tool/service capability on their mobile device. Since the early 2000s more than 60 percent of us in the, often referred to as, first world have had these devices on us to use content we find out where we need it (in the world) either in a Come to Me Web manner, or finding and creating the information out in the world. (For many today the laptop / desktop is now their secondary device not their primary).

The essentials for the user are have the information or service in the mobile device and work. The “working” is where the thinking comes in for options as the question of network connectivity, volume and velocity of change of the content or service changes, how often with the user interact and how long, and is this the primary service or is a just to get one through until they get to their desktop (and are you really really sure about this last one). These are the rudimentary questions to understand some of the use to start making the decisions about options. The largest issue in the set of questions relates to the reality about the network and capabilities of the device as both capabilities are assumed better than reality. Networks are far more limited that assumed and devices on the whole are not as robust nor consistent as hinted at.

The mobile user is most often looking for something that is quick, easy to load, and really easy to use.

The options we have before us on mobile are: Native app, web app, web app wrapped in native app, mobile site (often using media query), and responsive.

The questions and thinking needed to work though which option fits the need best are quite a few and usually best worked through by people who have designed and built through all of the options, and (most importantly as always) been responsible and had to fix the end results. These people questioning not only working with those wanting mobile site or service, but also the users. The decision trees and understanding which route to go can be learned, but takes a workshop of a day or two not a blog post.

How Did We Get to Responsive?

So, with these five options how is it responsive got to the front of the line, even when you walk through all the questions and would rarely end up with responsive as a viable answer?

The simple answer is content management systems suck. In 2009 / 2010 many organizations realized they were late to the game and their site use had relatively high mobile use and their users were complaining about how poor the site was on mobile. (This actually hit much earlier and work on solutions has been long brewing going back to early 2000s as to how to resolve this.) Mobile finally had tipped into the territory of something organizations needed to deal with.

In 2010 Ethan Marcotte shared his Responsive Web Design as a way forward to get mobile web up and running, somewhat as a hack to CMS that couldn’t support other options. Ethan is also one of the many who with Jeremy Keith and others of us from the (now shuttered) Web Standards Project (WaSP) focussed on web design from a progressive enhancement model. Responsive design is intended to be a progressive enhancement approach, it is one of a few “mobile first” design approaches.

A large chunk of Responsive design as it is today isn’t practiced from a progressive enhancement approach and there is a ton of bloat up front, which is very counter to mobile needs. Responsive design filled a gap and serious need. As Ethan points out Responsive is one approach and other business cases will lead to other solutions.

Responsive Design for Content Management Systems that Suck

Part of the need and fit for Responsive web design is due to content management systems that suck. Why do they suck? There are many, but with mobile in particular there are two issues: 1) Content is not stored in a manner that is far enough separated from the presentation of it; 2) The CMS adds incredible cruft into the page that there is page bloat.

User Centered Design and Responsive Design

As Ethan points out in his Responsive Web Design article:

That’s not to say there isn’t a business case for separate sites geared toward specific devices; for example, if the user goals for your mobile site are more limited in scope than its desktop equivalent, then serving different content to each might be the best approach.

The business case should follow the user needs. In the last few years if you spend a lot of time watching how people use their mobile and tablets (how we use them our selves isn’t that helpful other than as a base to watch the insane variety of different use patterns others have and the interaction models other’s use when they are out or even in meetings - something I started doing in the 90s when I got a Palm Pilot as I watched others to see what I was missing, which was an extension to always watching others interact with the world around them to learn for myself (moving a lot as a kid provides this potential)). How people use mobile and tablet has expanded greatly in the past four to five years. The expectations (often users are completely unaware of their expectations as it becomes as natural as breathing for many) for each device and the actual use vary quite a bit. This expansive shift makes honing in to device classes needed.

The last year or so I have been hearing many doing mobile and tablet design for years have been moving away from broad (one-site for all and Responsive) offerings with Responsive to targeted offerings for mobile, tablet, and desktop and using hints of responsive within those classes of offering. The user research finds the needs are different enough across the classes that full Responsive became unwieldy very quickly.

Users Live Across the Patforms

One of the realities of use is it is very common for multi-modal use of sites (mobile, tablet, and desktop) and the need for content to be there. One of the very important user context to always consider is spacial memory. People remember where on a page they saw something. This is really important for news sites as people will see the an article that doesn’t have much interest, but later in the day they find themselves needing that article and often their memory of where it was on a page (Business page on far right column, etc.) is how they know to get to the article (one of the reasons news publications for year have offered a “print view” of their offerings). With most Responsive design this ability to switch between these presentation modes is not there.

I have heard users and content owners talk about this problem for a few years, but it was a train from NY to DC where I saw the deep frustration this causes. A gentleman in front of me was working and had started out in Boston and needed to link to an article he saw on the Boston Globe site that he was reading on his laptop in the morning in Boston. He tried finding the article on his mobile device, which triggered anger as there wasn’t a way to get to the full front page on the Globe’s responsive site, he needed to fire up his laptop. The whole train car started helping him, mostly saying go to the “M dot” (m.bostonglobe.com) site and find the link to the full desktop version. The inability to get to the full site stumped the train (they were mostly New Yorker’s who read papers with mobile version and desktop versions, like the New York Times). Soon the whole car was angry.

The ability to jump to a full desktop site in Responsive is technically really easy, but it is an interaction and design messy festival with state and user desire and intent, which is far cleaner to deal with when there are distinct mobile and desktop versions, as a minimum. This issue is also how many started moving beyond Responsive as they saw their user needs move well beyond was was going to be straight forward with Responsive.

Never has a customer said they want Responsive, they want mobile and/or tablet usable formats that meet their needs. Responsive has been a design middle step to get to providing mobile options relatively quickly, but over time (often not much time) that moves beyond what makes sense. The need to design for user needs goes back to the old mobile foundation of thinking first about all the actual user needs and all the options properly.

The New York Times and Mobile

This started with the New York Times and its redesign. The New York Times has long had a mobile version of their site that is mobile specific. They have a CMS that makes it relatively straight forward to work their content not only into mobile site, but many other options. The New York Times has continually had some great folks who think across platforms that users are using and designing for needs there. The New York Times also has long running experiments that try many different things, like their Skipper Interface.

I bring up the Times not only because of how users actual use what they offer. I know a few Times digital folks and know many who have been part of the digital Times team of the years and even lead it.

The New York Times rough usage patterns for mobile split to roughly even thirds across mobile web (their mobile.nytimes.com) site, their mobile native apps, and full desktop use of the site on mobile devices. Another interesting piece is people bounce from one mode of reading and interacting to another (so read mobile web and shift to desktop or to mobile app) during their session (tracked with user login I assume). [These are from conversations with some current “not on the record” mentions and others at conferences who worked in that group have talked about roughly current use metrics third hand. I had them only roughly confirmed with a “that sounds about right”, but haven’t followed up with going through the New York Times press office to get official quotes.)

What is really interesting is there is no one dominant pattern for mobile users of the New York Times (this also applies to many other services who actually do user pattern research). Not only is there no dominant pattern, but users bounce between the different offerings. I have many times heard readers of the Times telling other readers they will find an article they are looking for in one interface but prefer to read it in another. Different interfaces of the different offerings resonate with people differently (the truth in “there is no one way proves true yet again”) and user patterns for discovery and use/consumption vary too.

Where Does This Leave Us?

One thing that has long been true is the New York Times understands mobile (has the data to influence design - not sure that is how it is used, so just guessing) really well. Also proving many who think they do shouting “Responsive” likely have a long way to go get to that understanding.

We are left, just like we were in the early 2000s, needing to understand mobile broadly and deeply as well as understanding how people actually are using mobile. We need to understand how to work through the questions needed to get to the needed solution for mobile and mobile use (as well as tablets, which need slightly different focus). When you walk through the questions and do the research likely Responsive is not the solution that best fits. It still could be a decent option as an in between step, but the essential first step is to learn the options and how to think through them.

Resonance in Sound and Design

Resonance:

• The quality in a sound of being deep, full, and reverberating: the resonance of his voice.

• The ability to evoke or suggest images, memories, and emotions: the concepts lose their emotional resonance.

Listening to the lovely and haunting Dead Already from the American Beauty soundtrack by Thomas Newman in high quality recording (lossless) and a compressed version (at 256 kbps) the beauty that is lost is in the resonance of the marimba / vibraphone and other instruments that make up the core of the musical experience. The this isn’t the white space between characters in print, but a grey space. It is beyond what is struck and to place a note in time and space, but what resonates out beyond that initial placement or use.

The last few years I have been reripping much of my musical collection as my main headphones improved, which are my main listening experience. The sound and experience is drastically different and exposes the gaps and the details that are missing in other listening environments. This combined with listening to music that is well produced and exposes and lets the musicianship and craft shine.

Resonance in Design

Thinking of resonance from an interaction design view is quite enlightening. The work of creation of usable interactions is good, but it is the first strike and it is not just white space that follows, but resonance of striking that interaction. This struck me a few years back when the iPhone came out (or one of its subsequent iterations) when I realized my Nokia E61i was faster at rendering pages and actions than iPhone, but what the iPhone did really well was manage and design the resonance after the person using the service clicked something. After striking for an action Nokia left white space and a void, but Apple crafted the grey space of resonance. Nokia would surface the result much more quickly, but with Apple that lag in the delay was not as perceivable unless you were watching the clock. Apple filled the empty space with fade-out, fade-in, activity notifications (windmill bars), which display for just a small amount of time usually. Much like the resonance of a marimba the sound and resonance can not last forever, nor very long, but it is enough to evoke beauty through filling the void.

The one or three second lag between clicking to trigger an action was painfully noticeable on a Nokia, but rather imperceivable on Apple devices. A longer delay is perceivable and painful no matter the interface and relies on engineering to resolve those issues. But, it is that resonance and understanding the design and crafting of it is what can separate a good experience from one that is more rough for the people who desire to use it and could find it of value in their life.

Everynow

We are living in a time where there are not only many concurrent realities existing at once, but our understanding of “Now” is perhaps broader and more broken than most any time since the Middle Ages started sprouting into the Renaissance. This is nowhere more prevalent in our understanding of the future, particularly the near future. Future technologies and future living have been part of reality in and around us for decades. But the time gap between the few edge cases who are living with what most consider future technology and life to when it hits mainstream is ever increasing.

The Future is Here…

This stretch of living with future technologies as a regular part of our lives and those who are not there yet, or even living a generation of reality behind all while living in the same culture is something I’ve called the everynow. Everynow started about 2004 as a tongue-in-cheek riff on Adam Greenfield’s everyware term use. Everynow is the breadth reality in William Gibson’s “The future is already here - it’s just not evenly distributed” statement from 2003, which is an idea many have discussed for years prior, but with out such nice phrasing.

Breadth of Adoption Reality

It seems the everynow is about 20 years in breadth.

For years it seemed it was about 10 to 12 years and it was nice to see it in Steven Berlin Johnson’s wonderful book “Where Good Ideas Come From”, he talks about the reality of ideas taking about 10 years from inception to getting them into relatively broad public use. When you think of internet based email in the 90s and the use of corporate email internally and out through internet gateways to better connect freely and more unencumbered, it took about 5 years for email to get to roughly 99% inside the organization (many organizations were much closer to that 10 year mark). But, in the last couple years in particular that 10 years.

Internet of Things

This past week with Tom Coates’ Twitter account for his house, @houseofcoates getting some mainstream media press the difference from what Tom is doing (and thinking and playing with for a very long time) rather echoes things like MisterHouse which started in the late 1990s using X10 devices and services and internet enabling them using Perl. The demo site for MisterHouse allowed those on the web to see the live status of lights, messaging, home music service, and things like window shade open status, but also for quite a while allows any of us to modify them right from the web. Tom’s long interest and work with his House of Coates is the latest iteration and extension of this and his long work on web of data and internet of things. (By the way Tom’s work is quite good and worth tracking down.)

The chatter around the Internet of Things, which is far from mainstream exposure and partial understanding is nearly 15 years old since its first usage by Kevin Ashton, really took off around 2002 and 2003. Bruce Sterling’s still incredibly valuable framing of the Internet of Things in his Shape of Things book from 2005 added the incredibly helpful concept of Spimes to conversations (actually he seeded this in 2004 in a SIGRAPH presenation, “When Blobjects Rule the Earth”), thinking through, and development many of us had been wading in for a few years.

Information for Use and Reuse on Mobile

Another example is around mobile… When I think about this mobile explosion that has “taken place recently” there is very little that is different from the thousands of handfuls of us living with smartphones in the early 2000s and thinking of the capabilities and potentials and building them and living them, all while the many many thousands of us were swimming in the same pool of live with the billions of others around us. Many of use in the U.S. and Western Europe felt we were deeply behind those living in Japan and Korea and their understanding and living the realities of living a life with mobiles that augmented their reality as the devices and services enhanced their lives lived with the devices in them. As we developed use of our web based information for use on internet connected Palm and other similar devices in the 90s

But, from a consumer and early adopter framing the reality of what is potentially doable in the future and having that in place and in use for some time know then trailing all the way back to those living in prior realities and the frustrations (although they think they are manageable, but not realizing how poorly the tools and services are working for them) is pushing that everynow to a very confounding nearly 20 years.

Broken Decade Precedes It Works Decade

I had long forgotten this Carl Steadman response to Michael Sippy's "Just One Question - What do you want for Christmas", but the response from 1997 is fantastic and frames the 1990s as the broken decade. (I'll wait for you to go read it)

I'm not so sure that Carl's broken decade got better in the first half of the 2000 decade, but it really started to. We are much farther along now. Our consumer world started to improve quite a bit and slowly business systems and services are slowly improving. The initial part of Carl's rant focusses on the number of steps to get something going. Once it is working the steps are still clunky.

Carl gets in a great rant about time and how broken it was in the 90s within technology (calendaring and syncing is still a beast and likely to for a bit longer - you understand the problem sets and pain points if you have ever tried to build syncing). With calendaring and its related activities we now have Tempo, which is freakishly close to the next step scenario I used in many of the Come to Me Web presentations and Personal InfoCloud presentations from 2003 through 2007 (I've been getting requests to represent them as this is what more and more developers and designers are dealing with today and need to have a better foundation to think through them). There was an internal Yahoo presentation (and follow on day of deep discussions and conversations) with a version of the Personal InfoCloud and Come to me Web flow that is nearly identical to the Tempo app video scenario and ones spelled out in Robert Scoble's interview with Tempo CEO, which is utterly awesome that it is getting built out some 10 years later (we had the technology and tools to do this in 2004 and beyond).

Carl's rant gets worn away over time though consumer devices, services, and applications. The refocus on ease of use and particularly the use through mobile, which requires a very different way of thinking and considering things. It thinking through design, the dependancies, and real user needs (all while keeping in mind the attention issues, screen size, networking, and device limitations). The past couple years mobile finally caught on with mainstream users and people doing real work on the mobile and tablets - Box 40% mobile access of files stored there over the last couple years. Many other business vendors have had mobile use rates of their services from mobile over the past two years. When talking to users they opt for mobile solutions over their full enterprise tools as they are much easier to use, which quickly translates into getting more work done. As Bernd Christiansen of Citrix stated in an onstage interview the employee's most productive part of the day is often the walk from their car to the front door of the office working on their mobile devices.

This world is not fully better and fully easy to use from the days of Carl's rant, but it is getting better. We still have quite a ways to go.

Mistaking the Edges for the Norm

One of the best lessons from social quantitative analysis in grad school (public policy) was learning to understand if you are viewing edge cases or the norm (mainstream). Humans have some common traits, but when you start to design or develop any sort of program (be it government services or social software) you start to realize that social at scale has many variations to how humans are social.

When taking that deep understanding we must understand if the trends we are seeing are the edges (or even outliers) or the norm. The common elements that cause the variation (often very large variations) are often driven by culture (as well as sub-cultures) and personality types.

Many of us who were early to blogging and many other social platforms were very much outliers and at or beyond the edges. We built and designed tools and services based on our personality types and traits. When you have 1.5 billion people the internet getting 70 million or even 200 million people that are similar to the edge case traits can be somewhat easy. What is really difficult is that next 90 percent. Keep in mind people use social tools very differently. What has worked for the very early innovators through early adopters is extremely different from the different personality types that will follow.

This gap in understanding that the world is not like us has not become real to many building social tools. But, to some it has hit hard, very hard. Much of the early Web 2.0 theories about social web patterns were looking at the edges and mistaking them for the norm. This was relatively easy to see if you have a background in social analytics and adoption trending through a society at scale.

To get beyond the edges you have to go deep, very much like danah boyd has done with her work. The work danah has done is deeply helpful as it surfaces the difference in understanding across personality types, age ranges, and many cultural influences. She deeply understood the problem that most people on line (youth and adults) were not openly social as was (and sadly still is) the common assumptions of things to come. Privacy and small groups is much more common. Today we see Facebook privacy setting with 70% or more with “Friends Only” or tighter for sharing information ([Pew’s Privacy management on social media sites” report).

Gamification

This understanding the edges and norms differences is also incredibly helpful for things like gamification, which can cause really nice upticks in usage of social services with the innovator and early adopter types (in the Technology Adoption Lifecycle, that is the core of Geoffrey Moore’s Crossing the Chasm framing). But, for the rest of the users it is either non-influencial or is deeply problematic. The mix of benefit and loss is essential to understand. At IA Summit I had quite a few discussions with UX people trying to fix the communities that were damaged by gamification in the long run after a nice initial uptick. It is a tough problem and a real issue to grapple with. This is incredibly noticeable on inside the firewall communities as there is a fixed user base and you can easily see who participated and how over time and the shifts (well, you do need access to the data, which some vendors don’t provide access to).

Today many of the one year to four year old social software deployments in organizations have gone through the edge types and been finding gaps in their services and tools offered as they work to get to the norm types.

The tools must change and adapt to the edges and the norms and the two user sets don’t really work in the same way. We have a lot of seeing, thinking, understanding, and building a better path for the mainstream folks as we bring people along on this fantastic transformation those of us on the edges have been through the last 20 years and more.

Related:

• Cooperation, Coordination, and Competition