Tuesday 25 August 2009

How to make your social software succeed

A colleague recently pointed me at Microsoft's Community Clips. It is a community-driven website where users share training videos about Microsoft Office. Why, he wondered, would anyone want to freely document Microsoft's profit-making software?

I was intrigued, so I had a poke around. It didn't look like a vibrant healthy community to me. The most popular featured videos had all been added over a year ago and there was nothing at all within the last 30 days. I then played a few clips. Each video started with a banner "Attention! The Soapbox service will be discontinued as of 31st August 2009!".

No surprise then that Community Clips has the aura of a ghost town. Soapbox launched in 2006 as Microsoft's equivalent to YouTube, and it powered Community Clips. On July 21 2009, MS announced the demise of Soapbox, and on 31st August it will vanish.

A sad story, but despite many such examples I'm sure that collaborative, social Web 2.0 services are here to stay. I expect the audience for this blog will agree with me, but many people within HE remain unconvinced by Web 2.0. If asked I point them at Facebook. Some thought (still think?) it is a passing fad. The hype may have peaked, but at Bristol our student IT survey 2009 shows that more students are using it than in 2007.

Ah, they say, but we did that once. Our organisation tried a project with this social software thing, and it flopped. So it's all a bit pointless isn't it? Well no. Most social software experiments don't work out. I've launched one or two of them myself (so long ResNet Chat!). Suw Charman-Anderson has a great piece explaining why most social software doesn't work out, why this is the normal state of affairs, and not necessarily a problem.

For every success like Facebook, Flickr or Youtube there are another dozen similar ventures that flopped. Why do some fail and others succeed? If you can understand why then you have the best chance of stopping your service becoming another Soapbox.

This fell into place for me through reading Here Comes Everybody by Clay Shirkey. Two examples Clay gives are Linux and Wikipedia, and he draws out three rules for social software: the plausible promise, the effective tool, and the acceptable bargain.

Linux and Wikipedia were both announced to a relevant mailing list of like-minded people who might well contribute. They were intruigued by what the project offered, it gave them a plausible promise - something they wanted, but wasn't too ambitious.

Here is Linus' original Linux announcement from 1991:
I'm doing a (free) operating system (just a hobby, won't be big and
professional like gnu) for 386(486) AT clones. This has been brewing
since april, and is starting to get ready. I'd like any feedback on
things people like/dislike in minix, as my OS resembles it somewhat
(same physical layout of the file-system (due to practical reasons)
among other things).

I've currently ported bash(1.08) and gcc(1.40), and things seem to work.
This implies that I'll get something practical within a few months, and
I'd like to know what features most people would want. Any suggestions
are welcome, but I won't promise I'll implement them :-)
Linus says "this is just a hobby"! People liked this approach. If it had been a big commercial project people wouldn't have been attracted to join. I give you my labour for free and you exploit it, giving nothing back isn't an acceptable bargain. Group of hobbyists together, sharing under a free software licence, is.

Wikipedia illustrates another point - make it as easy as possible to get started and to use it. This is completely crucial - even a low barrier is too high. Anybody can edit wikipedia, you don't even need to sign up for an account. You must provide effective tools - lightweight, simple, that encourage, not discourage collaboration.

Inspired by Clay Shirkey and others, here are my suggestions for successful social software within a university:
  1. Seed your site with useful, relevant content, so it isn't starting from a blank slate. Content you can't get anywhere else is great if you can manage it. This helps make it obvious why the service is useful.
  2. Announce it simultaneously to a large, relevant group. Promise something useful but not undeliverable.
  3. Make your tool extremely easy and effective to use, so your users can get results quickly.
  4. Use single sign on with an ID most people will already have. Your University ID is great, or perhaps something else from a huge common provider like Microsoft or Google. Use no sign in process at all if you can possibly manage it.
  5. Don't make it too official/corporate/commercial - people need to share ownership of the tool. They won't contribute if they feel they are being exploited and there is nothing in it for them. Students may trust the Students Union more than the university. Consider getting the support of your union and putting the service out under their branding.
  6. Nurture your first few users. The founders of Flickr commented personally on the photos of their first few thousand photographers, to make sure they'd come back.
  7. Build your social software on top of a larger network, in order to benefit from the larger network's beneficial network effects.
I'll expand on this - especially on how you can pick the winners and avoid the losers amongst third-party services - in a subsequent post.

Wednesday 5 August 2009

A domain driven design for the University Web

I wasn't at IWMW2009 last week, but I've been reviewing the conference thanks to a colleagues writeup and slideshare. The highlight for me was How the BBC makes websites (also in a more accessible text version BBC Radio Labs - how we make websites).

In the words of Michael Smethurst, "there's very little original thinking in here. For those familiar with the concept of one web, the importance of persistent URIs, REST, Domain Driven Design and Linked Open Data it'll probably be old news."

Michael is being modest. Personally I was familiar with some but not all of those. Even the most basic concept - having a single, unchangeable URI for an item - is rarely implemented. Bringing them all together makes the BBC Programmes site a powerful demonstration of how to do the web properly. More importantly it is a pleasure to use.

We are currently rethinking the University's web strategy and CMS requirements. To do this step back and think not about the web but about the activities the university undertakes.

What do universities do? They teach and they research. I'll use real-world data in two examples to show what I mean.

First teaching. Here's a course hierarchy:
(this would be clearer as a table or diagram but I'm limited by the tools in this blog)
  • Course Family: LLB Law
  • LLB Courses: LLB Law (UCAS course code M100), LLB Law with Study Abroad, LLB Law with Chemistry, LLB Law and French, LLB Law & German
  • year started the course: 95, 96, 97, 98, etc
  • Programmes of Study: 1st year, 2nd year, 3rd year
  • Year One Units: Law of Contract (Unit Code LAWD10008), Law of Tort, Law and State, Constitutional Rights, Criminal Law, Law of Property
  • Law of Contract Lectures: lectures 1 though 6
  • Lecture 1: introduction to contract law
The URI for that lecture would be http://www.bristol.ac.uk/courses/law/m100/1999/year1/lawd10008/lecture1

Every level in the hierarchy has a web page with a permanent URI. So every course family, course, year, unit, and lecture has a webpage with a single, permanent URI. Ideally we would have a recording of the lecture but as a minimum each lecture must have a presence, at least a placeholder.

Now look at research. Think about web pages for each of the following (again real world examples)

Department of Computer Science
Computer Science Research Groups: Computer Vision, Cryptography, HARE, Intelligent Systems, Interaction & Graphics
Research Group: Cryptography
Cryptography Staff: Elisabeth Oswald, Dan Page, Nigel Smart, Bogdan Warinschi
Person: Dan Page
Dan Page: list of all publications
Publication: Manuel Barbosa, Andrew Moss, Dan Page, Constructive and Destructive Use of Compilers in Elliptic Curve Cryptography . Journal of Cryptology, 22(2), pp. 259?281. April 2009

URIs for the above would be

http://www.bristol.ac.uk/compsci
http://www.bristol.ac.uk/compsci/groups
http://www.bristol.ac.uk/groups/cryptography
http://www.bristol.ac.uk/groups/cryptography/people
http://www.bristol.ac.uk/people/dan_page
http://www.bristol.ac.uk/publications/dan_page
http://www.bristol.ac.uk/publications/2009/constructive-and-destructive-use-of-compliers

So every department, research group, person, and published paper has a webpage with a single, permanent URL. Even if the paper itself isn't available electronically it must still have a presence.

Note that in this case the urls do not follow a strict hierarchy as they did in the teaching context. Why? Hierarchies change. Right now the faculty of engineering is merging its departments into larger schools. The URIs for the research groups, people and papers should not change. Our internal organisational structure is completely unimportant in the web context. Breaking a web link pushes us lower in search engines, hides our research and damages our reputation. It should be avoided at all costs!

Each webpage should be about an obvious, real-world thing. If it isn't about an obvious thing, split the page up into smaller pages, until the subject of the page is now clearly one thing. Then give each thing a single URI, and make sure it never changes.

Simple really. Now how do we do it?