Social Software Comparison

Although I don't agree entirely with the chart, this is still a useful way to introduce and compare social software tools. From vanderwal.

25 point web usability checklist

Even the best social media site or wizz-bang collective intelligence Web 2.0 application has to adhere to some basic website usability principles. Here are 25 website usability points to inspect your site against. Very useful!

A few examples:

Section III. Navigation

Once people generally know who you are and what you do, they need clear paths to the content that interests them. Information architecture is a huge topic, but these points cover some of the basics.
12. Main Navigation Is Easily Identifiable
Almost every site on the web has had a main menu since the first browsers came on the market. Make your main navigation easy to find, read, and use. If you have two or more navigation areas, make it clear why they're different.
13. Navigation Labels Are Clear & Concise
Don't say "Communicate Online With Our Team" when "Contact Us" will do just fine. Your main navigation should be short, to the point, and easy for mere mortals to grasp.

Customer Experimentation vs. Customer Research

Cover of What Would Google Do?

Here's another piece to reinforce customer experimentation (doing stuff live with customers) versus customer research (doing focus groups, surveys, etc). This is from Jeff Jarvis in his book What Would Google Do?

Google vice president Marissa Mayer has said that Google is constantly trying to anticipate and interpret our desires so it can predict what we are going to do--our intent. It does that by watching our every move. When her team wonders whether a page should be this color or that, they don't make the decision themselves, nor do they hold a focus group. They put both colors on the web in an A/B test that measures which yields better usage. "We'll be able to scientifically and mathematically provide which one users seem to be responding to better," Mayer told students at Stanford, demonstrating an engineer's faith in numbers".

Iteration versus perfection

I frequently find in my job that I'm the proponent for lots of  iteration and learning. Gifford Pinchot terms this "early learning beats better planning". By comparison, many folks I work with emphasize getting it right the first time.

While I have nothing wrong with getting it right the first time (if you know what right is, if you have some way to test it, if it doesn't delay you in getting something out), the problem with it as an approach is that practicioners don't emphasize closed-loop learning and improvement the way that a "launch and learn" practioner would. So if it isn't right the first time for whatever reason, you don't have the processes set up and in place to monitor that, learn from it, and respond rapidly.

I came across an interesting anecdote (via Chanpory Rith, via Trent) from Art and Fear on early learning verus better planning:

The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality.

His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot—albeit a perfect one—to get an “A”.

Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work—and learning from their mistakes—the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

Kathy Sierra on humanness: conversational vs. formal writing in products and help

OK, so I had previously found a summary of Kathy Sierra's 2007 SXSW talk, and was excited to see that she spoke about ensuring the humanness of our help documents, FAQ, and other support stuff.

But after a little more digging, I found some great stuff that she wrote earlier that includes primary research citations. (This is the kind of stuff that's good to have when you have to defend these ideas inside a big corporation.)

In 2005 Kathy wrote Conversational writing kicks formal writing's ass. Some highlights from that include:

A study from the Journal of Educational Psychology, issue 93 (from 2000), looked at the difference in effectiveness between formal vs. informal style in learning. In their studies, the researchers (Roxana Moreno and Richard Mayer) looked at computer-based education on botany and lightning formation and "compared versions in which the words were in formal style with versions in which the words were in conversational style."
Their conclusion was:
"In five out of five studies, students who learned with personalized text performed better on subsequent transfer tests than students who learned with formal text. Overall, participants in the personalized group produced between 20 to 46 percent more solutions to transfer problems than the formal group."
They mention other related, complimentary studies including:
"... people read a story differently and remember different elements when the author writes in the first person (from the "I/we" point of view) than when the author writes in the third person (he, she, it, or they). (Graesser, Bowers, Olde, and Pomeroy, 1999). Research summarized by Reeves and Nass (1996) shows that, under the right circumstances, people "treat computers like real people."
So one of the theories on why speaking directly to the user is more effective than a more formal lecture tone is that the user's brain thinks it's in a conversation, and therefore has to pay more attention to hold up its end! Sure, your brain intellectually knows it isn't having a face-to-face conversation, but at some level, your brain wakes up when its being talked with as opposed to talked at. And the word "you" can sometimes make all the difference.

And then in 2007 she wrote Your user's brain wants a conversation. An excerpt from that post:

Which would you prefer to listen to--a dry formal lecture or a stimulating dinner party conversation?
Which would you prefer to read--a formal academic text book or an engaging novel?
When I pose this question to authors or instructors, I usually hear, "You think the obvious answer is the dinner party and the novel, but it isn't that simple."
Followed by, "It all depends on the context. I'd much rather hear a dry formal lecture on something I'm deeply interested in than listen to inane dinner party conversation about Ashlee's lip-syncing blunder."
But here's what's weird--your brain wants to pay more attention to the party conversation than the formal lecture regardless of your personal interest in the topic.
Because it's a conversation.
And when your brain thinks it's part of a conversation, it thinks it has to pay attention... to hold up its end. You've felt this, of course. How many times have you sat in a lecture you really needed and wanted to pay attention to, but still found it hard to stay focused? Or how about the book you can't seem to stay awake for... finding yourself reading the same paragraph over and over because you keep tuning out--despite your best effort to stay with it?
But here's the coolest (and for me, the most fascinating) part of all this:
When you lecture or write using conversational language, your user's brain thinks it's in a REAL conversation!

This is some very cool stuff! Anyone have any success stories to share in making the change to conversational language in technical support content?

Next Generation Wiki: Using Collective Intelligence to Reduce the Wiki Maintenance Workload (updated 4/6/09)

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

Notes from Ward Cunningham on the Design Principles of Wiki, April 2009 CHIFOO talk

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”.

I also want to note that Ward’s own notes on the design principles of wiki are available, as are his presentation slides.

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 25^th 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.

	Agile	Wiki	Open source
Correction	Risk	Knowledge	Property
Barrier	Plan	Privledge	License
Team	Location	Attention (people contribute for the attention that it gets.)	Merit (team is pulled together across the internet because of mutual respect and trust)
Serves	Customer	Reader	Developer

-          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.