In the technical support documentation space I’ve been recommending wikis as a way to enhance collaboration on support documentation as an alternative model to the traditional approach of having a small cadre of technical writers and experts using a traditional content management tool to publish documents to the way.

While I’m an advocate of opening up the wiki to customer input, there are levels of collaboration that may make it easier for companies to get their feet wet without going so far as to open it up to customer input. The wiki could be used, for example, to allow input from other employees across the company, from R&D engineers to call support agents.
However, whenever I propose this, the established parties usually say “Why don’t we just fix the content management process we have?” or “If all we want to do is collaborate inside the company, we can use the content management tools we have for that.”
Wikis aren’t just another content management tool however. Wikis embody design principles that encourage contributions. When Digg was first implemented, the earliest versions had a two-step process to submit a digg vote. Kevin Rose, founder of Digg, spoke about the impact that moving from a two-step to one-step process had on the site:

There was a huge shift in activity on Digg when we made the move to the one-click digg in November 2005. Once we added Ajax, activity went through the roof on [the number of] diggs. It was just insane. Just the ease of the “one-click and you’re done” made all the difference in the world. Once the users grasped that the content is syndicated to friends, friends’ activities then went through the roof. These small incremental steps in feature additions drove the growth.

The more direct and lightweight the process is for contributing, the greater the number of contributors. And it’s not just pure volume of contributors: a simple contribution at first can then lead a user from passive recipient to enthused contributor. The editors at Wikipedia that devote much of their lives to upholding the quality of Wikipedia all started their involvement with a single, simple contribution at some point in time.

Wikis are perhaps the purest embodiment of the design principles of directness and lightweight processes. Every page has an edit button, so contributions are never more than a click away. The act of adding a few words to a document t is rarely more than clicking edit, inserting those words, and then clicking save.
Contrast that with a typical content management system: As a user who is browsing support documents on the web, and then spots an error in a document, if I’ve already used the content management system before, I have to then:
  1. find/launch the content management system
  2. login
  3. navigate to the document I was already viewing, usually by an obscure mechanism that isn’t the URL of the public document
  4. choose to edit the document
  5. make the edit
  6. save the document
  7. probably go through an edit review process relying then on other people to review the edit
  8. wait for notification that the edit is published
  9. check that the web document reflects the change
If I haven’t used the content management system, I would need to:
  1. Find out how the content is managed, probably by emailing peers until I get an answer
  2. Find out how to apply for a login
  3. Justify my need/right to modify the content (usually a lengthy process)
  4. Find out how to use the system
The two choices differ so significantly in effort involved, that the result is not just a quantitative difference in the number of contributions, but a qualitative one as well: true collaboration among a large group of contributors is unlikely using a traditional content management tool, because only those whose primary job it is to manage content are likely to invest the effort to use it.
By comparison, wiki makes it clear that editing is possible, puts the edit tool only a click away, and removes the step of having to renavigate to the content to be edited. While these steps may seem small, like we saw with the Digg example, small reductions in effort correspond to large increases in contributions.
Side note: I’m currently reading Designing Web Interfaces: Principles and Patterns for Rich Interactions, which inspired some of these thoughts.

When a large company rolls out social media capabilities on their website, they frequently worry about negative posts. A large company represents to many, a large target. Even the best companies with excellent customer service will have the occasional frustrated, angry customer.

How to deal with this? If the company moderates posts, and filters out anything negative, they will lose trust with their customers. If the company does nothing, and lets negative posts pile up, they could dominate the online community and discussions even if they are not truly representative of most people’s experiences.
It’s not so much whether a post is negative or postive, but whether it is constructive or destructive. A constructive post might point out a flaw in a product, but lead to a discussion about how to improve the product or work around the flaw. A destructive post might point out a flaw in a product and then proceed to personally attack the employees of the company.
Luckily, communities can police themselves. Using comment moderation features, users of online communities and websites can rate comments up or down, or report them for violation of community guidelines (such as inappropriate language).
When the right tools are in place, the constructive members of the community (who generally represent the majority) will tend to vote down destructive contributions. The company who sponsors the community or social media aspects of the site won’t need to be involved in moderation, and so they won’t be perceived as trying to control the conversation.
Pete Hwang, Experience Designer-Strategist at Hewlett-Packard, recently brought to my attention an excellent Wired magazine article by Clive Thompson on “how to open your website to comments without inviting the flood of toxic and inappropriate comments & flamewars that often arise”.

The world’s top discussion moderators have developed successful tools for keeping online miscreants from disrupting conversation. All are rooted in one psychological insight: If you simply ban trolls—kicking them off your board—you nurture their curdled sense of being an oppressed truth-speaker. Instead, the moderators rely on making the comments less prominent.

Pete’s favorite approach to disarming those destructive comments:

Here’s another hack: selective invisibility. It was invented byDisqus, a company whose discussion software handles the threads at 90,000 blogs worldwide (including mine). In this paradigm, if a comment gets a lot of negative ratings, it goes invisible. No one can see it—except, crucially, the person who posted it. “So the troll just thinks that everyone has learned to ignore him, and he gets discouraged and goes away,” chuckles Disqus cofounder Daniel Ha

(It turns out that selective invisibility is a technique that actually dates to Bulletin Board Systems (BBBs) back in the early 1980s.)

Recently Waggener-Edstrom, the PR firm, released Twendz, a tool for analyzing Twitter posts for topics. It’s a pretty great tool, and they are making it freely available.
I used it recently to search for “photosmart”, a Hewlett-Packard printer brand. You can see that results of that search.
From this search, I get a sentiment ratio (percentage of positive versus negative posts) for “photosmart”, as well as a subtopic sentiment analysis for the top five subtopics. A word cloud also lets me see other common words used. In many cases, the twitter posts also include a link to a blog post with a lengthier description of the problem/question/topic.
Now there’s no excuse for not monitoring your company and products on Twitter.

Jared Spool
Gourmet Experiences on a Fast Food Budget
Key Insights:
1. Mastery of tricks and techniques across your team are key to great designs. Having a big toolbox and mastery of the tools is the most important factor for great design.
2. Methodology and dogma are unimportant to great design. In fact, focus on these takes valuable attention away from what maters.
3. Rewarding people for failure encourages learning. Throw a big party with champagne and caviar. Spend three minutes making fun of the failure and twenty minutes explaining the lessons learned from the failure.
  • A hamburger and a hotdog cost the same whether you do it on a fast food budget or design it to be a gourmet burger.
  • This begs that question, what’s makes something gourmet?
  • And how can we apply it to web design?
  • You take them apart, and see what gets you there
  • Meticulous Preparation
  • How Do The Best Teams Create Great Designs?
    • The teams with bad design didn’t have different goals than the teams with great stuff. They all have the objective to make great stuff.
    • There is a spectrum… in the middle of this spectrum there is a Process
      • Tricks
      • Techniques
      • Process
      • Methodology
      • Dogma
    • Process: Some teams say “we don’t have a process”, but that’s not true. Any team that eventually produces something has some sort of process. They just aren’t paying attention to the process. (Like a cook who says she doesn’t have a recipe for making something. There is a recipe, it’s just not explicit/conscious.)
      • This is fine when things are going well, but not good when things are not going well.
    • Process: To the right on this spectrum there is Methodology.
    • Dogma: And beyond Methodology is Dogma (unquestioned faiuther independent of any supporting evidence.) Lots of things we do become dogma: “It has to be Web 2.0”, “it has to have social media”.
      • They had a theory, that those organizations with great experiences had some sort of dogma that they adhered to.
    • But on the other side of Process there is Techniques.
      • Many great recipes have a roux. (flour and oil over low heat.) By itself, it tastes terrible, but it makes many recipes great. The roux is useful in many instances. If you can do it well, then you can make the recipe well. It’s a technique. You have to be good at it, and to get good you have practice and maybe a little coaching.
    • All the way at the left end is Tricks. Tricks aren’t always “right”, but they are effective. It’s easier to use the wrong tool to get the job done, than it is to go get the right tool.
    • The Best Teams
      • Don’t have a methodology or dogma
        • The struggling teams often tried following a methodology without success
      • Focus on increasing the techniques and tricks for each team member
        • They were constantly exploring new tricks and techniques for their toolbox
        • Struggling teams have limited techniques and tricks.
    • University websites…
      • Every department maintains it’s own websites. Each college, admissions, etc. So there is a different look and feel for each part. How do you resolve that?
      • The standard answer is to use templates.
        • But there is no evidence that templates result in quality design.
        • It is an attempt at a methodology, and in some cases becomes dogma.
        • Each page has it’s own purpose. The business school is different than the admissions which is different from the school of nursing.
        • There only people who care if the pages look the same are the people who have responsibility for the university website.
          • Students don’t care if a page looks different.
      • Instead, focus on tricks and techniques.
    • The Three Core UX Attributes For Great Experience Design
      • Started with 150 different variables, studied hundrends of teams, only three attributes really matter.
        • Vision
        • Feedback
        • Culture
      • The Three Questions
        • Vision: Can everyone on the team describe the experience of using your design five years from now?
          • Vision turns out to be absolute key to success. It’s a stake on the horizon with a flag. If we can clearly see the flag, then we can instantly look and see if any baby step we take will take us closer or further from the flag. And everyone can see it.
          • A really good vision is stuck in the sand, but we can move it. Then we just move towards the new location.
        • Feedback: “In the last six weeks, have you spent more than two hours watching someone use either your design or a competitor’s design?
          • The organizations where people spend significant time watching people use the design create significantly better designs.
          • It needs to be everyone on the team.
          • No longer do you have opinion wars, because now you actual experiences.
        • Culture: “In the last six weeks, have you rewarded a team member for a creating a major design failure?”
          • When we have a design failure, we learn something.
          • All the really important lessons in life come from failures.
          • Good judgment comes from experience, and experience comes from bad judgment calls.
          • At Intuit they reward people. They throw a big party with champagne and caviar. The CEO makes a speech. They spend 3 minutes making fun of the people, and 20 minutes talking about the lessons learned.
          • Organizations that are risk averse make crap.
      • Five Second Page Tests
        • A simple technique
        • Can be done in less than 10 minutes
        • Can use page mock-ups or real site
        • Example: Buying a Notebook Computer
          • You’re ready to buy a new notebook computer
          • You consider a computer a big purchase
          • How much technical support will you get if you experience problems?
          • CDW: Technical support
            • New Customers
            • Existing Customers
            • Create Login
            • Rated: 2
          • CDW: Customer Support
            • Chat Support
            • E-account
            • Rated: 3
          • Crutchfield: Technical Support
            • Free technical support
            • 30 day return policy
            • Rated: 5
        • Designers often intend pages to have a single purpose
        • We use this technique when users complain that pages are too cluttered or confusing
        • Identifies if pages quickly communicate their purpose
      • Paper Prototype Testing
        • Design is in flux
          • Team needs to try ideas to get feedback quickly
        • Team can participate in study
          • They are at a point where they can make changes
        • Good resource: Paper Prototyping (book)
    • Quality Ingredients
      • In and Out: Sells burgers, shakes, and fries.
        • There is a secret menu. But they are all burgers, shakes, and fries.
        • They have a machine that slices the potatoes into fries just seconds before cutting them.
        • They have a butcher on site. The meat is freshly prepared.
      • Inuit Inuksuk: Arrangements of rocks to show that someone had been this way before. Lets the solitary hunter traveling alone for weeks or months to know that they are not alone.
        • The Amazon Product Review is like an inuksuk: it lets someone know whether people have been this way before. Not all Amazon reviews are technical in nature, many of them at an inuksuk: just to let you know that other people bought and liked this camera.
        • This is also what having testimonials about.
        • Colleges are now experimenting with having students blog about their college experiences.
          • Colleges even have content for the parents: an inuksuk for the parent.
    • Creative Approach
      • At MIT, students submit CSS designs. They choose 365 a year, and the MIT homepage changes every day. The content is the same, it just moves around.
    • Cooking Up Gourmet Experiences
      • It’s not about the money you spend, or dogma or methodology.
      • You need to focus on developing great tricks and techniques across your team.
        • Don’t let methodologies and dogma boy you down.
      • Look for opportunities for creative approaches.
    • Website:
      • Newsletter: UIEtips (free weekly newsletter)
    • Blog:

This was one of the better presentations at WebVisions. I felt like it had some pretty concrete actions to take.
Best takeaway: By putting myself out there for feedback on my company, the many benefits include gaining more followers, learning what my customers want, being able to engage in a discussion. I gain more by listening than by talking.
Making Whuffie
Tara Hunt
  • Dunbar number: 120-150 – the number of people we can really know at any point in time
    • Will: based on tribes and communities
    • As a result of the internet / we b 2.0 / facebook+myspace+blogs the dunbar number is raising
    • This doesn’t leave room for the one way messages of corporations / advertising
  • Some companies greeted enthusiastically, some companies are barfed upon
  • Cory Doctorow / BoingBoing
    • DOWN and OUT in the Magic Kingdom by Cory Doctorow
    • In the science fiction future of Cory, instead of money, there is something that he called whuffie
    • Roughly equivalent to social capital: reputation, access to resources, favors added up (reprocity), followers, levels of trust
    • High whuffie score = good reputation
    • You can buy stuff with your whuffie
    • But… not really fictional or futuristic. It’s here and now.
    • It’s how we decide to friend people on Facebook (based on looking at existing friend relationships)
    • To raise your whuffie, you need to establish relationships and credibility
  • 5 ways to raise your whuffie
    • 1. Turning the bullhorn around: instead of just speaking, listen
      • (Will: I wonder what would happen if I solicited input on HP printers and HP website)
      • The silence will smack down your whuffie
      • 8 ways to turn the bullhorn around
        • 1. Get advice from experts, but design for the needs of the novice
        • 2. Respond to ALL feedback, even when you have to say “no thanks”
        • 3. Don’t take negative feedback personally: people want a better experience, they want to keep using your product/website, they are taking the time to give you feedback to make things better
        • 4. Give people credit:
          • mention contributions in blog posts, tweets, or videos.
          • Name a product or feature after the contributor (or let them name it)
          • Send journalists their way
          • Send a gift certificate or special coupon code
          • Schwag and schtuff
          • Upgrade their account
          • Give the contributor more responsibility
        • 5. Point out and explain changes as you make them
        • 6. Make small, continuous improvements
        • 7. Go out to find your feedback
          • Use Google Alerts, Radiant6, or similar tools to seek feedback
        • 8. Ignore the haters (“Don’t feed the trolls”)
    • 2. Become part of the community you serve
      • Figure out who it is you serve
        • What problem are you solving? For whom?
      • Join the community… not for market resource, not to sell them something… to learn what makes them happen. And why they would give a damn.
    • 3. Create truly amazing customer experiences
      • Create love, joy, and laughter.
      • We can design for them.
      • Automagic: a user experience so seamless that it feels like magic just occurred.
        • Tag: “Automagically share your baby’s memories”
        • GrowthGRam, StoryGram, FoodGram, WordGram
        • Automagicness starts with sign: can signin with Twitter account or Facebook connect.
        • You can sync up with your social network accounts
        • And then pick people in those accounts who should receive notifications
        • Estimates dates from EXIF data, and combines with child’s age to guess:
          • First father’s day
          • First solid food
          • Etc.
      • Quicken for iPhone
        • Automagic spending update
        • Automagic account update
        • Automagic ATM finder
      • Tripit
        • “The best way to organize and share your travel plans”
        • You forward your confirmation email, from any airline or travel service, and Tripit creates a uniform itinerary, accessible via web, print, or iPhone.
      • 4. Throwing sheep: fun, lightweight activities that encourage participation, but don’t really do much else.
        • FB: poking, “I like this”, twitter: nudging, virtual gifting, kudos.
        • Makes it an easy way for people to participate, get comfortable
        • Example: Dopplr:
          • Personal velocity meter (silly and fun – people were twittering about it)
          • Carbon footprint
      • 5. lighten up: the ability to inject fun into the most serious & professional interactions
        • Examples:
          • funny 404 page errors
    • 4. embrace the chaos
      • The fear mongers: legal, public relations/corporate communications, IT
      • Understand the need for security… but need to balance it with the need for openness… because that is what people are demanding. We are in a new era of building trust
      • Benefits of embracing the chaos
        • You’ll be better prepared for the unexpected
        • You’ll join in the conversation that is already happening and be welcomed for this move
        • It will bring the opportunity for collaboration
        • It will make your ideas stronger that way
      • In the old days, you had one chance to get the message just right
      • Today, you have multiple conversations and iterations to build that message with your customers and audience
    • Whuffie is part of the gift economy. You don’t hoard it, you give it away.
      • What can you give away that won’t leave you broke?
    • #5: embrace your higher purpose
      • Do well by doing good: in the core of what you are doing, you are giving back.
        • Example: Stonyfield Farms: makes good yogurt, but does good things for the world by doing it. Sustainable production, organic.
        • Craiglist
      • Think customer-centrically
        • Take off your marketing hat, your finance hat, and step into your customers hat. What can you do for them?
        • Look at the “not customer-centric” slide on slideshare
        • Customer-centric is:
          • You send customers to other websites
          • You measure how many people refer their friends to you as success
          • When budgets get tightened, you tighten operational costs (not design, customer support, etc.)
          • Your only customer service policy is to do right by the customer
          • Your customers are doing things with your product you never dreamed and are posting videos.
          • Influencers are adding you as friends on social networks
          • You work with your competitors towards better customer experiences for all
      • Making new things accessible to people:
          • Blogger (enabled amateur journalists)
          • YouTube (enabled amateur videographers/actors)
          • Flickr (enabled amateur photographers)
      • Pay It Forward Mission Card
  • If you combine all of these five whuffie factors, you will become whuffie rich
  • Leads to better word of mouth, repeat sales, customer loyalty
  • Which leads to increase sales and profits
  • Discussion…
    • Q: How to staff up to participate in this?
      • A: It’s everybody’s job. At zappos, everyone is empowered to be social. It’s not one person’s job, not one department’s job. It doesn’t mean spending five hours on twitter, it means being ambient.
      • The big companies spend a hell of a lot of time internally focused. They spend so much time in meeting talking about stuff that doesn’t matter instead of going to barcamps, tweetups, or webvisions conferences.
    • Q: You can’t have a top down mandate to achieve something like the Southwest airlines safety rap. So how do you achieve it?
      • A: You can’t mandate it. You have to cultivate the culture. That takes time, it requires hiring the right amount of people, and it takes time to apply across the board.

Tac Anderson recently wrote that one of the keys to increasing blog readership is to post 3 times a day or more. So how does one find the time for this level of participation? Tac has a few good tips on reducing the time involved. But thinking about it made me remember a a blog entry I wrote in 2007 in respond to the question of “How does a dad with three preschool age kids and a full-time job find the time to post?” I think these ideas apply not only to blogging, but also to any form of social media participation, whether it is Twitter, discussion forums, or anything else. The trick is is that social media shouldn’t be another extra hour or two on your day, but it should in some way replace or complement activities you are already doing.

After a friend recently posted about trying to find the time to blog, I got to thinking: How do I find the time to blog?

After some thinking, I came up with a few principles. In some ways, I’m the worst person to give advice, because my frequency of posting is terrible compared to any decent blogger. On the other hand, I’m the father of 3 children under the age of 4 (doing attachment parenting no less) and I work full time, so if I can find the time to post, then anyone can.

First, make sure that you know why you’re blogging. If you don’t know, the issue may not be a lack of time, but a lack of clarity or motivation. Rebecca Blood’s articles and references on blogging and book, The Weblog Handbook, are useful if you are just finding your voice. Once you know why you’re blogging, the following tips may help you find the time to actually get those blog posts going.

  1. Repurpose: If you are an information worker of any kind or a student, you’re probably already doing research, generating reports, analyzing information. If you can find a way to take your initial work and repurpose it for use in two places, then you can generate content for your blog with only a little additional work. Be aware that depending on your employment contract, work policy, and employment laws, there could be all sorts of issues about who owns your work, the confidentiality of your work, and a slew of other issues. On the other hand, judging from recent Wired magazine articles, many companies are now opening up and encouraging transparency in all its forms, including blogging. Research this ahead of time so that you’re doing the correct legal and ethical thing.
  2. Substitute: You probably already bookmark websites, send emails about interesting articles or thoughts to friends and you may even write the occasional letter or holiday newsletter to family and friends. All of these are material that could be published on your blog. When you publish your bookmarks on your blog, not only do you benefit, but so do your readers. Blog instead of bookmarking, blog instead of emailing, blog instead of writing a letter, blog instead of publishing.
  3. Get creative: Take the creativity advice of Gifford Pinchot III, and always keep index cards or a quarto on you. The time when you have a creative idea to post is most likely not when you are in front of a computer. So grab that handy pen and paper, outline your post, and it’ll be quick and easy to post when you next sit in front of a computer.
  4. Scratch an itch: My own blog originated from my desire to keep track of books that I had read. As I borrowed more books to read (instead of buying), I found it difficult to keep track of books and authors I liked. That make it difficult to decide what books to read next. I could have simply kept a lot on my computer, but how much more fun to share it with everyone. Now using my blog helps me do something I already wanted to do, and that’s true even if no one ever reads it. The epilogue to MIT’s open source book has an interesting discussion of the open source principle applied to writing:
    “While every writer will tell you they write for themselves, this is more a statement of principle than an actual description of process—a piece of writing, whether a textbook or a novel, needs an audience to succeed. A programmer who claims to writes code for him or herself, on the other hand, is often telling the literal truth: “This tool is for me to use. Additional users are nice, but not necessary.”

    If you can manage to write and simultaneously create value for yourself through your writing, then you have a double motivation to write.

  5. Eliminate barriers: If posting on your blog requires you to jump over a dozen hurdles, you won’t do it. Eliminate barriers, and you’ll find that even five minutes can be enough to start an interesting post. Use simple blog software with a WYSIWYG editor so you aren’t spending time messing with HTML. Keep a browser window open to your blog editor at all times, so it is always easy to get to. Start a post, even if you won’t have time to finish it now, and keep the edit window open. You’ll come back to it later when you do have time.
  6. Have modest expectations: I’m sure I could have made this a “top ten” list, but seven items came easily, and still fulfilled the purpose of the post.
  7. Set a goal: E set the goal of posting at least once a week, and while she may have missed one week somewhere in there, for the last two months, her blog has had plenty of fresh, interesting articles. Way to go!

Update (4/12/2007): Here are several other resources about finding or making the time to blog:

Research from Stanford School of Business Professor Itamar Simonson and coauthor Chezy Ofir at Hebrew University in Jerusalem, points out that telling customers they will be surveyed, or asking them about their expectations ahead of time creates significantly more negative feedback. A quote from the article:

The researchers found that people who expect to evaluate are decidedly more negative. They also discovered that merely asking people to state their expectations before they receive a service made people morenegative—even though their predispositions may have been quite positive. For example, people who are asked if they think they will like a movie before seeing it will be statistically more negative than people who were never asked that question.
Simonson and Ofir studied the responses of customers who had called for service at a major computer hardware and software company. The researchers divided the customers into four groups. Participants in the first group were told a technician would service their problems and that they would subsequently be asked about the service, such as whether the tech was on time, whether the employee was polite, and whether he or she solved the problem. A second group was not told there would be an evaluation, but the customers were asked to state their expectations, such as how long they thought it would take for a tech to arrive. A third group was told both: to state their expectations and to expect a survey. Members of a control group knew nothing but were later polled.
The result: People who expected to evaluate were significantly more negative than members of the control group. The same was true of the group asked to state their expectations ahead of time. Interestingly, the group that was the most dissatisfied was the one that was asked their expectations and also warned about a survey.

This has serious implications for customer satisfaction surveys, but also for product research groups. Showing product prototypes to customers in a research setting is a context in which participants will frequently both be asked about their expectations and expect a survey. The effect can be research that “finds” problems that aren’t really problems:

The researchers warn that while marketers must stay on top of customer desires and complaints, they must also be aware of the effects the mere expectation of filling out a survey can have on how customers view their experience. “It may not be realistic,” says Simonson. “They may be chronically more negative, pointing out problems that are not problems to the average consumer,” he says. “You want people who are representative of the marketplace.”

This suggests that if you have any opportunity for analysis that doesn’t rely on surveys, but instead relies on behavior, the results are likely to be more accurate. Social media buzz, word of mouth, and collective intelligence applications based on behavior may all be more accurate than survey responses.

As I mentioned in my last blog post, I recently had the privilege of seeing and talking with Ward Cunningham, inventor of the wiki. In 1995 he built the first wiki as a tool for collaboration with other software developers and created the Portland Pattern Repository.
Virtually everyone is familiar with wiki at this point. It’s the web you can edit. Wiki reached its maximum reach with the creation of Wikipedia. For a wiki to work well, it is essential that there is a motivated critical mass of participants maintaining the wiki. For Ward’s original Portland Pattern Repository wiki, the motivation for users was to advance the way software was developed. For Wikipedia contributors, the motivation is to build a comprehensive encyclopedia of knowledge. Both of these goals are important to their relative population of users. Wikipedia contributors for example, may spend dozens of hours per week in unpaid work to make Wikipedia a better encyclopedia.
Why is a motivated critical mass of contributors so important? Some of the key contributions a wiki needs to thrive :

  • the contribution of original material
  • improving or correcting material
  • building linkages between topics in the wiki
  • various forms of wiki gardening that include:
    • ensuring topics conform to good style
    • correcting mistakes
    • building and improving trailheads and maintaining trails
    • filling in critical missing gaps
    • removing spam and user errors (such as when a user accidentally deletes content from a post)
    • and monitoring changes to spot when any of the of the above gardening is needed

What if you want a wiki but lack a sufficiently large, sufficiently motivated group of contributors?This is a problem I’ve been thinking about for some time. Derek Powazek says that what we need to do is “smallify the task“. In part that can be done by breaking down big tasks into smaller tasks. It can also be achieved by finding way to eliminate some of the bigger tasks.
In that case, could the gap between the minimum critical mass and motivation needed and whatever actual user population you might have, be at least partially mitigated by some kind of automation or collective intelligence? In other words, could some of the work normally done through the explicit contributions of a small group of committed users be instead done through implicit feedback and machine intelligence? Below I’ve captured my thinking in this space.
Let’s start by assuming that, at a minimum, raw contributions would still have to come from people, as would corrections to the material. But what we could simplify building linkages, improving trailheads in maintaining trails, spotting and removing bad mistakes or spam?
Automating linkages
Wiki topics are frequently characterized by many hyperlinks between the topics. In fact, the rich hyperlinking between topics is very much a part of what makes wiki is so effective. However chasing down all the right links between topics can add to the effort of writing a topic in the first place, or maintaining the wiki over time.
There is a technique that can be used to create a list of suggested topics that are related in some way to the topic a user is currently viewing. This technique relies on observing the behavior of previous users to determine what topics those users viewed, and in what order. For example, even if there isn’t a rich set of hyperlinks, a small subset of users will be motivated enough by their need for information to seek out other topics. They might do this by using search, the recent changes page on a wiki, or by navigating a convoluted set of hyperlinks to get to an ultimately useful destination.
The analysis then consists of using the clickstream data of these visitors to determine, for any given page A, what other pages also seem useful, considering for example, the amount of time spent on each page, and the order in which they were visited. For example, if I view the clickstream data, I may see a number of users who visit topic A, then go on to visit some intermediate topics very briefly, and then spends a significant amount of time reading topics D and G. I may then conclude that for other visitors who read topic A, they may also be interested in topics D and G.
We would need to user interface of the wiki to support presenting a list of recommended topics. Then when any visitor views the topic A page, the wiki can present recommended links for topics D and G. This makes it more likely that subsequent users are able to find related topics without going through search, recent changes, or long navigation paths. The net effect is pretty similar to the effect achieved in good wiki gardening when topics are appropriately hyperlinked together. But since this technique can be automated, it becomes possible to increase the usefulness of the wiki, while decreasing the effort needed to maintain it.
Automating Trailheads
A similar technique can be used to create and improve trailheads. The term trailhead as used for wikis comes from the trailheads associated with hiking trails. Typically there may be a large, interlinked network of hiking trails. A hiking trailhead is a place to enter the network of hiking trails. In a hiking trailhead there is frequently has a map indicating what trails exist and how they connect. A wiki trailhead performs a similar role. For someone coming to the wiki from the greater Internet, the wiki trailhead helps them orient themselves to the organization of information on the wiki and decide where and how to start reading through the wiki based on their interests.
Increasingly, people get to destination websites from search engines such as Google. While Google is frankly amazing at matching search terms to useful webpages, it can sometimes drop you into the middle of the website experience. That is, while the destination page may be the one with the content that most closely matches the search term, there may be very useful and relevant information on other pages that are related to the current page. And it may not be obvious how to navigation to those other pages. This is very similar to the related topic analysis I described above.
However in this context, we have additional information that can be used to better predict what other pages or topics the user will be interested in. When Google, or another search engine, sends a visitor to our site, the referral field will tell us the URL that the user came from. For search engines, this referrer URL will include the search term the user was searching for. This means that when we do click stream analysis and analyze how users visit the pages on our site, we can determine not just that readers of topic A are likely to be interested in topics D and G, but that if a reader of topic A comes to our site from a search engine having searched for a given term S, that then they are most likely to be interested in topic G, but not D. This adds a level of refinement to our basic predictive algorithm and create a better experience for users who come to our website from search engines.
Automating Weeding
We can also borrow a technique from sites such as Engadget, Gizmodo, and Slashdot to make spotting and removing bad content or spam much easier. The comments on Engadget and Gizmodo can be rated by viewers with +, -, or !. The plus means the comment is good, the minus means the comment is bad, and the exclamation point means the reader wants to “report the comment”, such as for bad language or spam. Many other sites utilize similar techniques for comments, and discussion threads. Highly rated comments either float to the top, or get represented in bold, or otherwise stand out. Low rated comments float to the bottom, get grayed out, or otherwise are diminished in importance. Reported comments may vanish from the site entirely. All of this happens with no manual intervention. Instead, it relies on minimal input from many users.
A similar technique could be used on a wiki. If we allow users to rate a topic, or even sections within a topic, with a plus, minus, or to report it, then we can again apply some automated analysis to determine what to do. Topics that are “reported” by a certain percentage of viewers should relatively quickly go away (with repeated occurences by the same contributor ultimately resulting in banning the contributor altogether). Topics that are rated down by a certain percentage of viewers should diminish in importance-which could be indicated by: the way the topic is displayed (perhaps with grayed out text), eliminating incoming links to the topic, or removing the topic entirely. Or perhaps, if there is another similar topic that is highly rated, perhaps the highly rated topic replaces the lowly rated topic.
Automating Good Style
Another area that gardeners of a wiki spent considerable time on is ensuring that pages conform to good style. Good style may vary by wiki and by group of collaborators, but essentially it is the conventions that ensure a certain degree of uniformity, usefulness, and accessibility of the information contained in wiki topics. It varies by group because different groups have different goals: Wikipedia’s contributors are historians, and they seek to document things from a neutral point of view. The Portland Pattern Repository’s contributors were software developers who were activists for a software development methodology, and they sought discorse and understanding.
A form of template, or gentle guidance, could help ensure that pages conform to good style without manual intervention. For example, a wiki that contains troubleshooting information might guide the user contributing a new topic towards organizing their information as a problem statement, and then series of solutions steps. Subsequent contributors for the topic might be guided to add comments on a section, add solutions to a problem, or qualify a solution step with the particular set of problem conditions.
The trick would be to balance this guidance with the necessary freedom to ensure that users are not too constricted in their options. Systems that are too constricted would likely suffer from several problems. One problem is that the site would not appear alive in the way that wikis frequently appear alive. (By comparison, Sharepoint sites are highly constricted in what information can be place where, and they never display the sense of liveness that a wiki does.) Another problem is that contributors may feel stifled by the restrictions placed on them and choose either not to contribute at all, or not to contribute with their full creativity and passion. I can’t quite envision exactly how this guidance would work, but if it could be figured out, it would go a long way to further reducing the maintenance workload of the wiki.
In summary, what I’m trying to envision is a next-generation wiki that combines the editable webpage aspect of any other wiki, with collective intelligence heuristics that build upon the implicit feedback of many users to replace much of the heavy lifting required in the maintenance of most wikis. This will be useful anytime the intended users of a given wiki are not likely to have a critical mass of motivated contributors. It will not substitute for having no contributors, and it will not work in the case of the wiki with very few users (such as a wiki used by a single workgroup inside a closed environment). But it may help those groups that are on the borderline of having a critical mass of contributors, and have a sufficient mass of readers.
I’m very interested in hearing reactions to this concept, and of learning of any efforts in this direction with wikis currently.
*Note: This post was updated 4/9/2009 in response to feedback. It is largely the same content with some additional clarifications. — Will Hertling

I had the great fortune to get to see Ward Cunningham talk about the design principles of wiki, and then afterwards to chat with him informally in the offices of AboutUs.
Ward is a programmer’s programmer. You wouldn’t confuse his presentation with the slick production of some social media marketing guru, but his wisdom shines through. I was a moderately early adopter of wikis (circa 2001), and I’m been consistently amazed by the almost magical way in which they work. It was a real honor to hear Ward speak and get to talk to him.
Though my notes focus primary on the wiki side of things, I want to note Ward’s key role in helping to both define and create the legitimacy of the Agile development methodology. Creating the first wiki, the C2 Portland Pattern Repository, was in support of this community of practitioners and activists who wanted to document and advocate for how software was really developed, rather than how it “ought to be done”.
The presention was sponsored by CHIFOO, the Computer Human Interface Forum of Oregon. Their theme for year is collaboration: putting “us” in user experience
o       #chifoo09 hashtag for anything relevant to chifoo program for 2009.
Here are my notes for the presentation.
          Ward Cunningham
o       Currently CTO at AboutUs
o       Influenced object oriented programming, design patterns
o       Invented first wiki in 1994
          Design Principles of Wiki: How can so little do so much?
          Wrote the first wiki to support the design patterns community. They were a community that had an email list. Within weeks, he knew that he did something good. And within a year, it was obvious that it was a success. He wanted to look back at the success that he had and understand it.
          Big Impact. Small System. Eleven Principles.
o       “200 line program” with amazing impact
          People build elaborate sites with special purpose sharing tools (i.e. a certain company in Redmund), yet those sites are dead. Yet a wiki is evidently alive. How can that be?
o       Eleven Principles
          Wiki Definition:
o       Encarta: 11 words: Server software that allows people to modify web pages.
o       Brittanica: 608 words, only 60 shown without paying
o       Wikipedia: 3126 words
§         Wiki means quick in Hawaiian. WikiWiki means very quick, Ward too a bus in Hawaii.
§         Wikipedia page on Wikipedia gets 500 edits a year, with a lively discussion. It’s clearly “alive”.
§         Page appears in 90 languages.
          Wiki versus Blogs
o       A wiki is a work made by a community. People try to come together to make things fit.
o       The blogosphere is a community made by its works. Each corner of the blogosphere has its own feel.
o       An individual wiki contributor can come and go without changing the identify of the wiki.
o       Wikis vs. blogs on Google search trends: blogs got the early start, but by 2006, wiki searches outpaced blog searches.
          Q: question about wiki in education system
o       A: A key part of teaching kids to write is teaching them that there is value in what they write. What greater evidence of that would be to have them make contributions so well written that they contribute to a wiki?
          History of wiki
o       C2 Wiki in 1994, wiki online March 25th 1995.
o       Wikipedia 2000
o       AboutUs 2008 (finally earning a living remotely associated with wiki)
§         A page for every domain name on the internet. Allows people to express what they are about.
§         The first Wednesday of every month they host a get together called Wiki Wednesday. Starts around 5:30pm. Have a beer with them.
o       C2 Wiki
§         Served off a little PC under his desk, connected to the internet over a 14.4 modem. Designed to be only text.
§         This one site has grown to over 30,000 pages about software programming.
§         The whole agile programming methodology got its start on C2.
§         Like AgileProgramming has over 100 pages specific to some variation of Agile, and 280 pages on variations of programming.
§         This site fueled a discussion about an experiential view of what programming was, rather than an argument about what programming ought to be.
§         People who are busy doing, don’t have time to write a textbook. But they do have time to write a paragraph.
§         Now 3 international conferences on programming based on C2, and 2 international conferences on wiki itself.
o       Agile development corrects dysfunctional behavior resulting from decades of misunderstood risk.
§         People misunderstood risk and attempted to defer programming as long as possible. The correction is that programming needs to start as early as possible.
o       Cool slide showing matrix about Agile, wiki, open source across the top, with correction, barrier, team, serves on the left side. Reproduced below.
This is a comparison of Agile as a movement to wiki as a movement to open source as a movement.
Open source
(people contribute for the attention that it gets.)
(team is pulled together across the internet because of mutual respect and trust)
          How small is wiki?
o       SigWik: 4 lines, 222 chars of Perl
o       RikiWiki: 40 lines of Ruby
o       C2 wiki: ~200 lines of code.
o       It’s the “Hello World” of application servers.
          11 Design Principles
o       Open: Should be a page be found to be incomplete or poorly organized, any reader can edit it as they see fit.
o       Incremental: It must be both possible and useful to cite unwritten pages. (This was pretty revolutionary from an information perspective. Before that, it was considered unreasonable to publish something hyperlinked unless the links went somewhere. So all the information had to be “complete” before it could be published.)
§         Cool story about building hypercard system on Mac that embodied this principle, an early predecessor of wiki.
§         “Being able to point to the empty spot on the table is necessary” for the creativity of design.
o       Organic: The structure of the site is expected to grow and change with the community that uses it. It’s always the right size for the community (co-evolution).
o       Mundane: A small number of conventions provide all necessary formatting.
§         People focus on their ideas and words, rather than the formatting. This was the problem with the folks in Redmund: you could put Word documents in there, and people couldn’t help themselves from using too much functionality.
§         Someone once asked “These wikis are useful, but do they need to be so ugly?” – Ward said yes, because he wanted people to believe they just needed to be literate to contribute, not an artist.
§         Wikipedia has demonstrated that there is a whole lot more markup that is needed for encylopedias, like for doing citations and mathematical formulas. The key is to keep it as simple as possible given what needs to be expressed.
o       Universal Principle: The mechanisms of editing and organization are the same as those of writing so that any writer can is automatically an editor and organizer.
o       Overt: The formatted and printed output will suggest the input required to produce it.
§         This only works if things are very simple. This is lost with Wikipedia.
o       Unified Principle: Page names will be drawn from a flat name space so that no additional context is required to interpret them.
§         Want everyone in the community to be able to use the words in their every day conversations, so the words themselves are useful. No hierarchy, no prefixes, no suffixes. If you have a word on the C2 site, everyone knows what it means.
§         This taught a whole generation of programmers new vocabulary, and over time even unified the vocabulary, so that over time only a single term would refer to a single concept. This is vocabulary construction.
o       Precise Principle: Pages will be titled with sufficient precision to avoid most name clashes, typically by forming noun phrases.
§         To make a link, you have to have two words.
§         Many connections are happy accidents. Where some might see a name clash, others would see a happy accident: a connection between two similar concepts.
o       Tolerant Principle: All input will produce output even when the output is not likely to be that which was desired.
§         I will not output error messages. Instead, the output is shown immediately as a feedback loop.
o       Observable Principles: Activity within the site can be watched and reviewed by any visitor.
§         This came from reading Wabi-Sabi, and also Edwin Schlossberg on interaction excellence.
§         RecentChanges is what gives that visibility. (And this came from the hypercard system.)
o       Convergent Principle: Ambiguity and duplication can be removed by finding and citing similar related content.
§         This is re-factoring.
§         It reflects the emerging evolution of ideas – what is in the system may be ambiguous because what is in peoples heads is ambiguous.
          Wikipedia’s goal is to have neutral point of view – they are historians.
          For C2, they were activists: this is the way the world really works. Their goal is not to be historians, but to evolve the thinking in that space.
          There was a brief discussion of ThreadMode versus DocumentMode – the former is early in the lifecycle of a topic, when its all active discussion, the latter comes when the discussion starts boiling down to the consensus of the group.
          Wiki Nature: wiki as a meme vector
o       People knew what wiki nature was, because it was wiki like.
o       It couldn’t be described, except by experiencing what it was it.
o       The C2 wiki become a destination for understanding wiki
          Three things have to come together to have a winning combination:
o       Methodology: How we will learn? à (Piecemeal growth)
o       Community: People come together to help each other learn it. à (RecentChanges)
o       Technology: some small piece of technology to enable it. à (Hypertext)
          How can so little do so much?
o       Sweet spot of new technology
o       Assemble, guide and transform community
o       Leave room for other’s innovation
          Question: Was the design goal really transforming/manipulating the community or reflecting what the community was doing into the virtual world?
o       A: It wasn’t so much manipulative, it was bringing the disparate parts of the community together to have a discussion. They were proponents of Agile methodology, and the goal was to transform the naysayers, to explain the agile methodology, to try it, to explain how it works and how it addressed risk, it transformed the people who came to the community.
o       Comment: The community transformed itself.
          There was a cool discussion of the theoretical influences, and discussion of the role of metaphors, but I was unfortunately fading by that point.
          Ward had to dispel a notion of computer programmers as anti-social loners. When they were programming, they had a hard time discussing without fighting.
After the presentation, a small group went back to the AboutUs offices, where we continued the conversation over beers. As Hunter S. Thompson wrote in Fear and Loathing, this is where my notes become disjoint and confusing.
I asked about the feasibility of, or current activity in, creating a wiki that is a hybrid: it contains elements of explicit user feedback in the form of content, but depends on collective intelligence algorithms and implicit user feedback (clickstreams, rating of topics) on site organization and navigation. Is this still a wiki? Is it feasible? Does it violate any wiki principles.
Ward generally thought that it was still a wiki. He said that AboutUs was doing some similar things – where they once were asking users to write the content for a specific domain, now they are aggregating some of that. What he described sounded like what Derek Powazek described as “smallifying the task” in his Wisdom of the Crowds talk.
We also discussed how the concept of what a wiki is has changed as the public has become aware of wikis in general, and wikipedia in particular. Earlier, wiki really was the set of design patterns, and each person created their own wiki engine that embodied the design principles but whose implementation was customized to the particular needs of their community. (Hence MediaWiki is different than the C2 wiki, which is different from TWiki, etc.) Over time, the concept of wiki has solidified, so that people think primarily of community contributed encylopedia type knowledge in a MediaWiki environment. This can make it challenging to discuss novel implementations of wiki that embody the design principles but look and feel different than a traditional wiki. 
For Portlanders, there is a monthly Wiki Wednesday meetup at AboutUs on the first Wednesday of every month.