On social software consultancy | With Jack Schulze, I've been doing a little consultancy at TimeBank recently on how thinking in social software, adaptive design and associated areas can improve a couple of their projects, and tie into their strategic thinking.
I'm not going to say anything about the projects or the outcome of the seminar day at the moment, just say what social software looks like, deploying in anger, a year in. This is what consulting and teaching non-expects in this area looks like.
Defining sosowa was the source of many posts this time last year. Having to compress it to be useful was a useful process. We're using something like this:
Social software's purpose is dealing with with groups, or interactions between people. This is as opposed to conventional software like Microsoft Word, which although it may have collaborative features ("track changes") isn't primarily social. (Those features could learn a lot from social software however.) The primary constraint of social software is in the design process: Human factors and group dynamics introduce design difficulties that aren't obvious without considering psychology and human nature.
This ties nicely with adaptive design, in that social software encourages you to fulfil latent needs first, then embark on not a development cycle but a dialogue with user concerns in which you listen to their emerging needs and implement them in code -- but you have to give users the ability to stretch the system otherwise you'll never even notice those new needs.
Areas of interest
To design effective social software, you should have some awareness in a number of areas.
So one of the things Jack and I are doing is producing a Primer in these areas to provide an overview but also a bibliography so the TimeBank team can dig deeper themselves. We've spent quite a lot of time running through their projects and these ideas to learn what's appropriate, where they need extra knowledge and so on.
Clay Shirky's essays (these in particular) over 2003 figure pretty big when the areas of concern to social software are summarised. That's not a surprise, they're great essays. But also, looking back, they're the only standalone, well-written essays there are. Outside the context of the early 2003 discussion, most of the weblogs posts just don't make any sense.
So already we're got a way to put the sosowa ideas into practice. I use this example:
We might consider the way, in groups of three or more, how there's always the possibility of two people being disloyal to the gathering, and how to moderate that behaviour. In the physical world, disloyalty is visible because all interactions within the same context are visible to all local group members, and the disloyalty is moderated through politeness and social pressure. There is a different mechanism to exert social pressure in a peer-to-peer small group (of 6 people, say) than a broadcast larger group (a classroom type situation). Contrast this with online small groups and we see misunderstandings by email, people being left off cc lists and so on.
Now that's become a solveable scenario. We need mechanisms in the online software to bring in a similar incentive structure to the offline world.
The single most useful piece of thinking I've been using is Stewart Butterfield's March 2003 post on the devices in social software, mechanisms successful pieces of social software tend to have.
I'll describe each of these, as I see them, critiquing AOL Instant Messanger (just as an exmaple), and then describe how we put them into use.
Clay's essay A Group Is Its Own Worst Enemy provides a great overview of many important concepts here, especially on having a cost to join (which provides the feeling of membership). Incidentally, knowing this is a fantastic rule of thumb: Forums which require a joining step are better that forums that feel like window-shopping. It's a more social design decision on the same level as not putting the reply box at the top (so the user has to read the whole conversation).
Putting this into practice
These seven items act as a tremendously useful framework to critique and comment on social software. We combined them with a further process:
We took a dynamic approach to this. It's very simple-minded design which only gets a person to use the site once, because it's easy to operate or whatever. A more dynamic approach is to consider the consequences, and use mechanisms such as people like sharing to design in the appropriate incentive and moderation feedback loops.
And dynamic's the key. We've attempted to understand user flows, and apply the ideas above to different types of user within the system, using one or two of Matt Jones' UCD tricks (they're handy to use and easy to teach). We've been teaching the technical and other project team members to use these tools and ideas to develop a common vocabulary, and to use social software ideas to make simple social tools more likely to succeed.
(So, for example, we can see that some users aren't going to be comfortable approaching people online - they're educated, highly intelligent folk who aren't good with computers - then we can use mechanisms such as slowly building relationships (making use of presence) and reputation to build an approach with a gradual gradient.)
And then of course it all gets into adaptive design and development processes, and also onto the specific small touches we recommended for the individual projects, but I'll get onto those another time.
I've put many of the social software links we'll be using in the Primer in my links directory.
Of course half-way through gathering these, the Many-to-Many Social Software Reader (and Timeline) launched. Handy, but unfortunately not completely appropriate -- I think they're aimed at providing a history and resource for practitioners, and not a quick way in to pick the most appropriate ideas for people in other fields. The latter is what Jack and I are providing.
Comments always welcome.