So, I meant to get this out during Webstock week, but late is hopefully better than never. Here are some notes & thoughts from Heather Champ and Derek Powazek's workshop 'Designing and Sustaining Creative Communities' (with thanks to Douglas, who has shared his notes with me).
[Any misinterpretations or muck-ups are my own].
Right now, the National Library is more involved in what I'd call communities-within-communities, like our @NLNZ twitter account and taking part in The Commons on Flickr, than occupied in setting up communities ourselves. However, I think it's safe to say that the immediate future will see our involvement in community sites growing.
Before we kick off though, here are two of my favourite articles about community wrangling:
Community: From Little Things, Big Things Grow, by George Oates
Building an online community at Brooklyn Museum: A timeline, by Nicole J. Caruth and Shelley Bernstein
A definition
Web communities happen when people are given tools to use their voice in a public and immediate way, forming intimate relationships over time.
The essential questions to ask yourself- Who is the site for?
- What can they do?
- Why will they want to do it? Without offering benefits for the people who join, why would a vibrant, long-term community grow?
The building blocks of community sitesAside from the contributions from the workshop attendees (an unusually vocal bunch for a Kiwi crowd; I think we're getting braver) this was the most valuable part of the session for me, so I'm going to focus on it here.
The workshop gave me a real appreciation for the hard thinking you need to do before you unleash your site on the world. These are the foundation garments of your community: not sexy, perhaps, but underpinning and holding up everything that's layered on top of them.
1. Privacy policies and Terms of Use/ServiceThe
Twitter privacy policy was recommended as a thorough policy with a good human interface.
Heather and Derek noted that as people are getting more experienced online, they're reading privacy polices and terms of service statements much more closely and
out-cry can follow if people are unhappy with what they see (or, I guess, think they see).
Creating these policies means finding a balance between protecting your assets and respecting the people who are choosing to contribute to your site. You will need to get lawyers involved, you will need to advocate for your users, and you will need to keep revisiting these over time.
You must also make these policies easily available to people who are visiting your site but who are not (yet!) members. People should never have to log in before seeing this kind of information.
In her presentation at the conference Heather expanded on these points -
check out this article for some of the detail.
2. Copyright and ownership10 years ago, people thought that everything that was on the web was "free". Now, people are much more savvy and will read ToS closely to see what you're doing with their content (and remember - this is from photos they upload to comments that they leave) and what others are allowed to do with it.
An ongoing issue is that people will share material that they don't own the copyright to. Have clear take-down policies that make it easy for people to make a complaint and enhance trust on the site. Part of the trust is vetting the requests for take-downs, as this system can be abused.
Another part of the trust is understanding that there can be a difference between what's 'legal' and what's 'right': what you can do and what you should do. Which leads nicely into ...
3. Community GuidelinesWhen a site is small, it's relatively easy to model behaviour. As it gets bigger, this gets harder - and that's where community guidelines can set the tone of the site and act as the human face of Terms of Service and Terms of Use statements.
I've long admired
Flickr's community guidelines, especially the immortal "Don't be creepy". It's pointedly more of a "do" list than a "don't do" list, and it has won the community over, to the point where Flickr members enforce the guidelines themselves. Heather and Derek emphasised that you can't make guidelines that will foresee every possible permutation of behaviour, and that's why it's important to treat these as evolving documents.
4. Abuse GridThis gem by itself made attending the workshop worthwhile for me. Before you launch, sit down and think of all the things you will not tolerate on the site. Now draw these up in a spreadsheet.
-> The first column is the "bad thing".
-> The next column is a detailed description of said "bad thing" that people can use to identify whether the thing they suspect is bad is, indeed, that same bad thing.
-> The final column sets out exactly what site administrators should do when they spot a bad thing. This includes whether warnings are given, what happens to the content, what happens to the account, what changes if it's a repeat violation, whether any external agencies need to be notified of this behaviour.
-> Bear in mind you may need to run this past a lawyer.
An abuse grid has two major benefits. Firstly, it means that if a site has a number of administrators, they're all following the same system of identifying and reacting to badness. Secondly, it prevents you from being forced to make policy on the fly during a crisis.
Design and structureDesign can set the tone and use of the site (it's true! Derek cited all sorts of studies -
check his site for links) so you need set your design to the tasks you're trying to encourage and support. You've got to keep reminding yourself that you're designing a tool, not just web pages.
Barriers to entryDerek noted that there's a strong drive in web design towards inclusiveness, but that communities by their very nature are exclusive (I guess maybe that's the difference between "population" and "community") . The boundaries can be set using design.
We need to think carefully about where we set barriers to entry in all elements of the design, from demanding certain versions of certain browsers be used to the amount of information you ask for during site registration. There's a temptation to set the barrier very low, for the sake of user-friendliness and also to get stuff happening on a site; however, this risks inviting a pretty crappy level of interaction. Set the barrier higher and you're likely to get higher quality contributions, but you might put people off along the way (I had an experience this year where I was asked to hand over my full name, email address and date of birth in order to even see the homepage of a site that I was being encouraged to join.) There's also the fact that community sites evolve: you may set the barrier lower when the site is new and your community managers have more scope to individually interact with new members, setting the tone through human contact; as the site grows and the ability to be this hands-on decreases, the barrier may go higher.
The wisdom of crowd - with a nod to James SurowieckiSurowiecki suggests 4 elements that define wise crowds ...
- Diversity (of people, opinion and input: homogeneous groups often fail)
- Independence (you offer up your own thoughts, and don't feel compelled to agree with the group)
- Decentralisation (there isn't a top-down authority that drives the group)
- Aggregation (where community sites often fail - not enough is done to find commonalities).
... and interface is everything when it comes to encouraging these elements on your community site.
To help yourself out:
Give people small, discrete tasks to make crowd-sourcing workDerek gave the example of the Assignment Zero project that tried to crowd-source articles for an "experiment in pro-am journalism" (
read a full recap here). After a disappointing result, the site's managers realised they had asked too much of the community, and tried a new tack, asking for suggestions for a list of people to interview for the project, and then asking people to carry out the interviews - a task that was more enthusiastically picked up.
Avoiding groupthinkWhen site members put the groups needs and opinions ahead of their own, they stop speaking in their own voices and definitely stop saying or doing anything that might rock the boat. This can cause a site to stultify (and, if you work at NASA, might lead to a shuttle disaster).
Online communities are self-selecting: like tends to attract like. To prevent a site from getting too homogeneous you need to design for a diversity of members; to bring in new members and to support minority opinions.
Design for selfishnessDerek noted that people tend to participate for selfish reasons, but that this can be good in a wisdom of the crowds fashion. For example, people don't create hyperlinks for altruistic reasons, but when aggregated the links support Google's pagerank algorithm. Likewise, people tag in Flickr for 'selfish' reasons, but when aggregated these tags
become a powerful tool.
For this reason, asking yourself "what is the selfish reason for participating in this site" is a key early question in the creation of your site.
Scores create gamesOnce you assign a score to an action or a judgement, you create a game; and once you create a game people will want to play to win, in ways that may be detrimental to the overall health and enjoyability of the site. Design decisions can encourage or discourage gaming behaviour.
Derek used the
Heisenberg uncertainty principle as a metaphor for the challenge of surfacing interesting things happening within the community without unduly influencing behaviour, and suggested design solutions that can be used to prevent this.
Favrd has a very fast decay, which stops the leaderboard from being hijacked.
Online polls reveal tallies only after you've voted;
Threadless witholds voting tallies until the voting period is finished.
Introduce some randomness (Flickr's 'interestingness' algorithm) to prevent gaming.
Allow yourself some curatorial control, and bring back the human element to presenting content (think of the Flickr blog; or conversely, the often disappointing nature of 'most viewed' and 'most shared' lists of articles on newspaper sites).
The Brooklyn Museum's
Click! exhibition (an experiment on crowd-sourcing and crowd-selecting photographs for a show, which both Derek and James Surowiecki consulted on) is a fascinating experiment in
attempting to minimise influence. I really recommend this
series of posts on the project (kicking off wth Surowiecki himself).
If you do use an algorithm, Derek advised testing thoroughly before release and then tweaking as necessary.
Community ManagersAs Heather said in her opening to this section of the workshop: being a community manager is like being a piñata: people will beat you with sticks and you still need to give them candy.
Finding and supporting community managersCommunity manager roles should be separate from customer care. These are the people who set the tone for the site, not the people who help solve problems with uploading or browsers.
Community managers need to have good judgement, to be diplomatic, to have a sense of humour and thick skin. They also need to be active users of your site, meaning that recruiting community managers from existing users is often a sensible move.
When you have more than one community manager, there needs to be consistency in their behaviour. Flickr describes the tone of its community managers as "human, friendly, inclusive, authoritative, transparent, honest, witty, funny and clear". Give your community managers guidelines for behaviour in situations which often crop up (e.g. outages, or changes to the site) so they have something to fall back on.
Taking it offlinePrivate communication is one of the most valuable (and often forgotten) tools at a community manager's disposal. Think about it: if one of your friends was being a dick at a party, you probably wouldn't get him thrown out - you're more likely to have a quiet word with him. Use back-channels to thank people who are helping you out, or to check in with people who are being jerks.
Offer members tools to self-moderateTools for flagging inappropriate or suspect content are common on community sites; tools for reporting problems can help site administrators notice when something is broken (without everyone running to tell the community manager about it).
Tools for managing your interactions with others on a site can also help people define their own experience, and add finer levels of control so that your community guidelines can stay at a more general level. Tools for members to block other members are a good example of this: they allow people to stop other members who they don't like from interacting with them, whilst relieving you from having to negotiate on an individual-by-individual level. You don't need to notify people when they've been blocked (and admittedly, this would be like sending someone an email reading "Hey, guess what? Bob thinks you're a freak and has banned you from contacting him") but do make an explanation available (couched in "it's not you, it's them" terms) if people want to follow up on what's happened.
Reporting problemsMake it easy to report problems and things such as copyright violation. Have consistent footer links throughout the site, and let non-members use these as well.
Heather recommended controlled lists of options for complaints/problems forms, and that you ensure forms are robots nofollow. Include a service level agreement so people have an idea of when their complaint is likely to be acted on.
Bubble up the goodExample content sets a tone far more effectively that terms and conditions statements or community guidelines ever could. Bring good and interesting content to the fore; shine the spotlight on community members (if they're willing!) through mechanisms like the
member interviews on the Flickr blog.
Help forumsMember forums can reduce the workload of answering individual requests, but can also run the risk of getting out of hand as members use these forums as a place to express anger with the site. Make sure it's also the job of someone on the tem to get into the forums regulalrly and help things along (without being all pushy about it).
You can also consider outsourcing this using a site like
Get Satisfaction.
Owning up to your mistakesThere is an expectation of openness and transparency on community sites today. Things will occasionally go wrong on your site, and when they do, it's best to own up, explain, and apologise. If it's a problem that's hanging around for a while, post clear and timely updates.
Managing changeIf you need to make a significant change:
- Announce
- Be clear
- Allow 6-8 weeks for people to get prepared
- Offer an out-option if possible
- Make the change.
Have a strategy for the change: get together and plan out worst-case scenarios and how you'll deal with them (being cognisant that no-one can always second-guess humanity's great inventiveness).
Immediate feedback on changes is likely to be knee-jerk and negative(or perhaps just
par for the course); over the next few weeks more considered responses are likely to filter in. You can give yourself a hand here by identifying influential community members and getting them to trial soon-to-be-released features: this can generate good-will and excellent feedback.
Wrapping upPhew. Writing all this up reminds me how packed the session was with great advice, insight, and awesome contributions from the floor (we were an unusually talky bunch). I haven't even covered off the last two chunks of the day: managing trolls, and the fascinating, difficult-to-describe phenomena that is the merging of the digital and the physical world (think
papercamps,
Arduino, Flickr meet-ups, online mags that are moving into print-on demand,
bridges and
toasters that Twitter ...)
So my apologies that I'm not going to get this all down. I really recommend these other reviews of the workshop, which contain material I'm likely to have missed or glossed over, and different points of view.
Dean Stringer, Waikato University Centre for eLearningJulie Starr, Evolving NewsroomSarah Jones, Lunchbox: software and digital media for learning
