Adding Hot-off-the-Line Freshness to a Wiki

Krispy Kreme doughnuts are such a success that fans camp out overnight for a store opening as if it were the release of a new Star Wars movie. In Creating Customer Evangelists, Ben McConnell and Jackie Huba attribute this success partly to the fact that Krispy Kreme stores feature their stainless-steel assembly line as part of the “experience.” This mystique — this feeling that the shiny Krispy Kreme machines are making something for you right now — makes Krispy Kreme special. The doughnuts are warm because they popped out of that magical machine not yesterday, not a few hours ago, but right this minute.

I think wiki evangelists can learn from this.

Wiki content, by its very nature, is fresh. Contributors add hundreds of edits and scores of new articles per day. Most wikis have special pages that link to the newest edits, but these special pages are buried. Many wiki communities run projects where multiple authors play various roles (researchers, subject matter experts, copy editors, etc.) and assemble articles in a process resembling an assembly line. On an active wiki, you can bet something was authored just minutes ago, like a doughnut Krispy Kreme dropped fresh out of the oven and handed to you while still warm. And yet most wikis don’t make this just-out-of-the-oven freshness obvious.

While a MediaWiki site’s New Pages or Recently Edited Pages section shows the latest edits, driving customers to these articles wouldn’t be effective marketing because most of the articles listed there are stubs. They’re not among the wiki’s better articles. But something I’ve noticed in FamilySearch Wiki is that when an article hits a certain number of edits — say 100 or so — it starts to become pretty engaging.

Sure, sites like Wikipedia have sections for Featured Articles and What’s New, and these are certainly worth creating on any wiki. But wikis need a feeling of every-minute freshness long before their contributor communities hit the critical mass required to maintain Featured Articles or What’s New sections. Newer wikis need a programmatic way of featuring not just new content but new, mature content. Featuring content that has not only received recent edits but that has also received enough edits to make it interesting gives  customers a feeling that there’s a quality article coming off the line each hour or even each minute.

So the question is How can our wiki automagically show a conveyor belt full of well-written articles — a list of articles which are pretty engaging and which have reached that threshold within the last few hours or minutes? Should a wiki have a frame that lists the subject lines and first couple sentences of such articles? Could the frame be called something like “New Edits” or “Recent Writings?” Is there an easy or bot-driven way to include such a pane in a wiki, particularly in a MediaWiki site?

What do you think?

Community authoring: consensus and avoiding re-work

I have a learning to share with those of you who are interested in…

1. best practices regarding community governance and how to run a community writing project efficiently;
2. how the U.S. Census and U.S. Vital Records wiki writing teams on FamilySearch Wiki are doing;
3. an executive decision made yesterday which should help our the U.S. teams avoid unnecessary re-work.

Until yesterday, I didn’t understand why Wikipedia leaders are wary of a straight vote to decide issues. Now I understand why they value consensus significantly higher than majority, and why sometimes it’s even necessary for Jimmy Wales to make a ruling as “Benevolent Dictator” <g>.

According to U.S./Canada research consultants, a lot went well in Sprint 1. They built a meeting area, started standup meetings and post-scrums, started learning scrum through practice, and learned a lot about communicating and working as a team. One thing that consultants felt could be improved, though, was that we need to churn less and execute more. Part of the excessive churning was caused by often reconsidering what information to show in an article and how it should be presented. Should we lay out census links to different sites in a table or in paragraphs? Should we include only one type of link to an Ancestry.com census, or include three links leading to Ancestry’s Library account access, personal account access, and Institution account access?

Wiki teams do most things democratically. So when we have an idea of how to lay out an article, we present it to the team for feedback before replicating our idea on, say, 50 state census pages. The decision to replicate the idea across many pages hinges on a vote. In the beginning of Sprint 1, we were basing decisions on a majority vote. That’s fine when you want to get an initial decision on whether to replicate a new idea across 50 pages. But we learned that once an idea gains initial majority support and is replicated across many pages, it’s time to forget about majority votes and start thinking about consensus.

So why does majority rule bow to consensus after a stylistic idea is implemented? Because the opinion of the majority changes constantly. Projects gain new authors over time. In our census project team’s case, new research consultants began to be freed up from other assignments, making them available to work on the wiki. So in this case, an idea to include three types of links for Ancestry.com censuses based on the different accounts a patron might be using won majority approval initially, and was implemented over 50 pages dealing with census records in various states. But as the project team gained members, the majority shifted the other way. The majority opinion now was to include only one Ancestry.com link for each census, and have that link lead to another page where links to the three kinds of Ancestry.com accounts would reside.

If approved, this new decision would force us to redo all the 50 state pages we’d done on the census, as well as forcing us to create 50 new pages with the various Ancestry.com links. We’d done this kind of back-and-forth revising on two other issues during the sprint, and it was killing our forward progress. It seemed like every time the project gained another one or two contributors,  the majority opinion on some style/layout issue would change, and we’d end up reworking a lot of articles. This waffling and constant re-working of articles was bad for morale and performance, so something had to change.

That’s when it hit me: Wikipedians have expressed reservations about straight votes and majority rule. And although I don’t remember them really saying <why> straight votes and majority rule don’t always work, experience was teaching us the “why.” If all a community needs to force a stylistic change over many pages is for the majority opinion to turn, all one needs to do is to bring in more contributors to change the vote. Thus the majority opinion on a hot issue will change back and forth many times as new contributors (voters) engage the project. One possible solution might be to demand that only one vote takes place on each issue, or to require that an issue can have only one vote per year. However, limiting the frequency of votes on an issue can stifle essential changes that have incredibly broad support.

That’s where consensus comes in. Once initial majority has been reached on the style/layout/information of a large body of articles, it’s time to discontinue rulings based on majority and start requiring rulings based on consensus. After we’ve written the first draft of 50 state articles, a 5% shift in majority opinion should no longer compel us to change all those articles. That is inefficient – it forces change too frequently. After a collection of 50 similar pages has been written, if the community wants to change how the articles are presented, they need to reach not just a majority, but a consensus. A consensus shows much stronger support for change, and will tend to prevent rework except in cases where change is essential.

So what percentage of the vote is needed for a consensus? Wikipedians say it varies according to the issue. But what we’re trying in U.S./Canada is a 70%/30% split. If we’ve written 50 state census pages a certain way and someone wants to change the style, they need 70% of the voters to agree with them before the change will be made. Hopefully this will quell a lot of unnecessary re-work of articles while allowing changes that are essential and truly supported by the bulk of the community.

Converting Consumers to Contributors (C cubed)

Today Sunir Shah, founder of Meatballwiki, tweeted that “Realizing a truth makes us *want* to act even if we don’t. Users are most prone to discovery just before they take action.”

If users are most prone to discovery just before they take action, they take action right after discovery. (Um, sure, Mike. Duh. So what?) It follows, then, that if community builders want to convert their site’s reader/consumers into contributors, their best shot is to do it at the very moment when the user sees the value of the site. So how can community builders know when that moment is occurring in the user’s mind?

Thousands of people register on FamilySearch Wiki without ever contributing content. There’s no good reason for this — registration doesn’t open doors to greater functionality — but there it is. It seems an easy thing to assume that registered users should be more easily converted to contribute content than, say, unregistered users.

There’s a mantra in marketing that it takes less energy to retain a current customer than to win a new one. And Web 2.0 mavens like Ben McConnell of Creating Customer Evangelists say that going the extra mile to dazzle customers is what converts them to evangelize a product.

Sunir mentioned that one way to know when the customer understands the value of the site is when he “starts taking actions that fit the mental model.” The only such action our customers do that our system reports to us is registration.

….So why don’t we dazzle them at the moment they register?

I don’t mean we should try to dazzle them with some automated message from the system. The idea an automated message would dazzle anyone is laughable. But human interaction? That’s different. I can’t think of a Website that has ever tried to engage me with human interaction at the moment I registered. That would knock my socks off. Is there any better way to show users they’re valuable? Is there any better moment to get their first impressions of a site, see which parts of the value proposition they are catching, and discover and walk them through the barriers that would otherwise prevent them from contributing? Using this method a high percentage of newly-registered users could be converted to contributors in a matter of minutes.

Obviously, this method of conversion is labor intensive. It doesn’t scale. However, given the reports that the lion’s share of Wikipedia edits are made by a core of a few hundred authors, a method of converting consumers to contributors doesn’t necessarily have to scale very much. In our case, it would amount to less than ten thousand chats or phone calls a year. To an organization like ours that has a sizeable call center, that’s not such a big deal. And there’s no reason we’d have to contact every new registrant — consistency in user experience is wildly important when you’re giving something to customers, but when you’re trying to help them give to you, there’s less need for consistency.

What would the call or chat sound like?

1. Thank the customer for registering.
2. Ask the customer whether she registered in order to contribute information.
3. If the customer would like to contribute or isn’t sure if she has enough expertise to do so, help her contribute something simple.
4. Ask the customer about the projects she’s working on that relate to the purpose of the site. Guide her to information on the site that will help her do a project.
5. If the site fails to produce the content the customer wants, guide the customer in creating a request (wiki stub or forum query) for that content.
6. Thank the customer and terminate the call.
7. Monitor the forum thread or wiki stub. If the requested content doesn’t appear within 24 hours, gather it, post it, and notify the customer that it’s there.

You just created a customer evangelist.

Leveraging a Wiki for Research Advice

Folks who hear about the new family history research advice wiki at wiki.familysearch.org want to know two things. First, What is a wiki? And second, How will the wiki deliver more of the genealogical research advice I need?

What is a wiki?

Wiki. A short, sweet, strange word whose form matches its meaning — a Web site you can edit without being a programmer. A site where average people like you and me can write things to help other people. A place where we can share information and even collaborate on articles that make us each look smarter than we are alone. A paradise for people who seek information. A wiki community can deliver and revise more research advice information for more users in more languages.

Challenges in the traditional approach

To see the potential of FamilySearch Wiki, it helps to explore the challenges an organization faces in offering free research advice worldwide when they try to do it the traditional way.

The Semantic Web

Our wiki scrum team is now testing Semantic MediaWiki, a tool that will improve the wiki’s search and browse experience by bringing further tagging (and resulting meaning) to our articles. To understand the power of such a tool, one must understand the concept of the Semantic Web. One of the simplest descriptions I’ve found is Chris Gledhill’s “The Semantic Web — A Muggle’s View.” Below are a few quotes that explain the Semantic Web in a clean metaphor:

“The web is like a vast library in which the books are completely randomly arranged, each book has a predefined space on the shelf but there is absolutely no categorisation. Search engines such as Google act as librarians to help us find the resources we want, but in a most bizarre way. A web search engine is like some sort of autistic genius with an immense memory and perfect recall of the words in each book but absolutely no idea what they mean.”

“So instead of being able to ask Google to direct us to the section on advanced bungee jumping techniques or DIY space exploration, we have to think of some words that are likely to appear in the books we want and then wade through all of the irrelevant rubbish that happens to contain the same words in the hope of finding something useful.”

Having explained how the primitive Web works, Gledhill goes on to explain the Semantic Web:

“In information science… an ontology is a formal (and rigorous) description of all of the entities, relationships and rules within a particular domain of knowledge. The magical bit happens when you have created an ontology in a particular field. It then becomes possible for computer software to make logical inferences from real world information to ‘discover’ new facts which have not been explicitly encoded.”

Gledhill ends by predicting which fields will likely embrace the work it takes to create the semantic context that will allow their information to be more useful and findable. The Semantic Web, he says, “will be welcomed in any commercial field where the economic advantages of standardisation outweigh the benefits of confusing the opposition, punter [beginner user] or regulator.”

A trickle here; a perfect storm on my Twitter page!

Recently someone mentioned that she wishes I posted more often here. Me too.

But until that happens, if you want to learn vicariously from the Web 2.0 books I’m reading, see my Twitter page at http://twitter.com/MTRitchey. When I read a Web 2.0 book, I mark it up quite a bit. Then each workday, I transfer my book notes to Twitter. When something strikes me as extra profound or as needing some synthesis into learnings and action items, I transfer it from Twitter to this site and start expanding.

Prioritization of New Feature Requests

My community team has had a problem lately trying to convince the product manager that certain features proposed to enhance communication and community should be placed earlier in the development schedule. But in defining the term “groundswell,” Li and Bernoff give a simple litmus test that may show which proposed features to prioritize. “The groundswell” they say, “is a social trend in which people use technologies to get the things they need from each other, rather than from traditional institutions like corporations” (Groundswell, 9). Whenever our scrum team prioritizes new feature requests to see which ones we’ll develop first, we need to ask ourselves of each feature “How helpful will this feature be in helping users get what they want from each other?”

Interns: Overlooked contributor source

This morning I spent one hour on the bus and a half hour in the office reading sections of two books, trying to learn new paradigms and find something that will help me make my Web 2.0 team’s efforts more scalable. The two books were a couple I’ve been reading lately — William Becker’s How to OD [organizational design] and Live to Tell About It, and David Weinberger’s Small Pieces Loosely Joined: a Unified Theory of the Web. This morning, Small Pieces was just too philosophical for me: Sure, I could take one of the great abstract thoughts I marked in the book and figure out some way to transform it into an epiphany of how I should change my site’s strategy, but boy, the work it would take was just too much. And while Becker’s organizational design book applies directly to a division reorganization in which I am participating as a planner, what it was telling me to do to get other managers aligned and ready for change again felt like an enormous amount of work that nobody really asked me to do. I guess I’m just tired this morning.

Then, clearing my desktop bookshelf of items I rarely read so I could put these books there, I came across an American Library Association journal whose cover read “Shaping the Future with Student Interns.” I’d been grabbing the stack of ALA mags to put them in a closed overhead bin, and ironically, my morning paradigm shift had come from this six-word headline I was about to archive. Student interns. Read: No-cost, temporary employees burning to prove their mettle. We’ve got ‘em in a university nearby that acts like a feeder school to our corporation. I’ve used them before. They were great, and their effectiveness, semester by semester, has grown as the needs of our customers became clearer and our Website matured. And for some silly reason, as I struggled recently to determine ways to get more volunteers writing on our site, I completely overlooked them.

But interns — especially those from our feeder school — really know our content. They use it all the time. They understand how our library’s materials are organized and accessed. They’re young college students, so they understand Web 2.0. Most have a Facebook account; shop on Amazon, Ebay, and Craigslist; and participate in online forums. Many can write well. Each wants an internship whose assignments are measurable so that calculating success, or a grade, will be easy. Many would like to work for our department because they have declared a major (family history) which corresponds with what our department does.

So it’s no big revelation that an intern adds value to our project. The big question is why we don’t have them all the time, why we’re not always trying to get more, and why I didn’t immediately think of them when trying to figure out how to engage more contributors on our Website. And I suppose the reason for all these failures stems from two issues: First, the tour of duty for an unpaid intern is a bit shorter than the duration of a semester. We have them for only about three months, really. And the ones we get are required to work — hours. That’s a lot of turnover, and it takes effort to show an intern the ropes, train them how to use the system, provide follow-up coaching, design a project that’s big enough to keep them busy, and oversee their progress in that project. But judging from the content we’ve gotten from some of our interns, it’s all well worth it if you get the right interns and don’t just accept anybody who applies.

If interns are well worth the time they take to manage, then what’s holding us back from using several interns continually? Organization, really. We have nobody assigned to recruit, train, and direct interns each semester. It feels like a worthwhile assignment to make. Inasmuch as most of this workgroup’s employees are centered around developing a community of contributors around a knowledge domain, it feels like maybe each of them should be in charge of an intern each quarter. Having one person assigned to recruit interns for the whole team feels wrong, somehow — it feels smarter to have each community coordinator select and recruit their own intern so they can get the right person for the job.

The ALA journal’s article about interns yields something important to remember: That interns are there to learn. “The student who only does clerical tasks or low-priority activities during fieldwork may come away with a distorted view of the librarian’s role and reduced interest in remaining in the profession.” In other words, we probably shouldn’t employ interns only to write content. They should become involved with our product development scrums, design portal pages for a knowledge domain, get other sites to link to the content they create, monitor Web analytics for their domain, and survey users on what parts of their designs do and do not work. They could even design and create within their domain the reference-interview system I described in yesterday’s blog entry which helps beginners get the help they need without having to know genealogical lingo or research methodology.

The takeaway from this six-word journal headline that happily took over my morning: My team will have a meeting Monday. We’ll discuss the things each employee is doing that could benefit from an extra set of (intern) hands. If the list is sufficient to keep some interns busy with mind-growing assignments, employees will be assigned to recruit and engage some interns. If it works — if the ROI is indeed worthwhile, recruiting and managing interns will become a regular assignment for employees each quarter.

Listen to Marketing and improve the site? No! Convert consumers to contributors and focus them

In How to Stop Worrying and Start Living, Dale Carnegie quotes Bernard Shaw as saying “If you teach a man anything, he will never learn.” Carnegie, a master teacher, goes on to say “Shaw was right. Learning is an active process. We learn by doing.” That got me to thinking about how I’ve been approaching a lesson on our wiki and forums that I’m going to give at a conference next week. Although the wiki’s bounce rate — the measure of users who visit a page on the site and bounce away to another site without so much as clicking a link or doing a search — is currently at about 40%, the midrange of what Web 2.0 sites usually are, I’ve had a lot of trouble picking out pages that would make my conference students say “Wow, I gotta visit that site!” Basically, I think my problem is that I’ve been listening too much to the marketing and instructional development folks at work who keep saying our wiki isn’t ready for prime time, that it really isn’t useful for beginner genealogists to find useful information.

Maybe they’re missing the point. A Web 2.0 site of a specific field like genealogy, I’m guessing, takes a long time to reach the point where it resonates with beginners. Genealogy is a skill. When people start out, they don’t know the lingo. What’s a probate record? They also don’t know which records will yield the information they desire about their ancestors. And as it turns out, creating the pages that will lead them from what they know (I want to find my ancestor’s parents) to what they need to do (search census, land, vital, and probate records of a specific jurisdiction) takes a long time. To get them from point A to point B you need to conduct a reference interview where you ask them at least three questions: their research objective (ancestor’s parents), the place (where the ancestor grew up), and the time period (when the ancestor lived). Each level of this question-and-answer tree represents a lot of possible answers your system must anticipate in order to guide the customer to the next step. With millions of places (record jurisdictions) in the world, it’s clear that a system that’ll help a beginner will take a lot of work to build. So if we content specialists listen to our marketing and instructional development colleagues and don’t let this site go prime-time until after we build something suitable to beginners, we may literally never get it built.

But as I said, worrying about the beginner segment of our market is missing the point. The point is that Web 2.0 sites’ bounce rate is 30%-50%, and our site is at 40% now. The site also averages above 600 unique visitors a day. Some market segment already finds the site interesting. Our top contributors — who have only been active for 6 months — have over 2,000 edits apiece, so they clearly think the site is worthwhile.

The people who find the site useful are intermediate and advanced genealogists — people who already know the lingo and have some clue what types of records will yield the information they seek. They use the site to find out where to find those records — and the site is positively rich with such information. Intermediate and advanced researchers don’t need millions of “reference interview” pages to guide them from a research objective to a type of record because they already know a few types of records they can use. They just need to know where to find these records, and that’s the thing our wiki does well.

As I’ve thought about what I should teach at this conference full of genealogists next week, I’ve been tempted to spruce up a bunch of pages on the site so I can show them some truly compelling content that they’d crawl through broken glass to access. Really, “spruce up” isn’t the right term. “Overhaul,” “remodel,” or “grow like a mustard seed” is more like it. To make these example pages have the effect I’d want would take enormous amounts of work. I’d work so hard on the content that I wouldn’t have time to prepare the lesson.

But when I reflect upon Carnegie’s words about teaching and doing, I’m reminded that although our site teaches how to edit pages, we haven’t yet really directed contributors in what we’d like them to do. We haven’t sold them on an idea that the site needs a certain flavor of page fleshed out and developed to its full potential, and that we really need them to engage in adding this specific information.

These people at the conference know about our site. We taught them about it during last year’s conference. Some, if not most, are already using it to access information. Most of them haven’t contributed. They think only an expert can contribute because a contribution must be a full-blown article. They don’t consider themselves experts, so they can’t envision themselves adding anything of value to the site. But each one has done some genealogical research, and in so doing, they’ve learned some hard lessons by experience. And if asked to help a friend or relative get started in genealogy, each one would probably convey that hard-won lesson to that relative. So really, all of them know snippets of information that would save someone else some time. Beyond that, they are also capable of performing a whole list of simple but useful enhancements to the site. Some can edit grammar or spelling. Others can create links between related pages. Others can link to archives, libraries, or digitized records already listed in an article. They can add headings to set off paragraphs, or add transitions between paragraphs. They can add pictures of places, or add information about genealogical news and events in their area.

So what these consumers of our site need to know is that they really have what it takes to contribute in simple but valuable ways. They also need a challenge to step forward and volunteer. They need a chance to commit themselves — to put their contact information on a piece of paper that says “Yes, I’ll help. Call me!” They need to feel safe — like they’ll get the help they need to get started. Whether this means I need to visit them at home, have them visit my office, or do a remote session via Adobe Connect where I can walk them through the processes of making simple enhancements to the site, that’s what I need to commit to do for them. If I do my job right, I won’t have to enhance the site before I teach at the conference. If I inspire them, show them they can make a huge impact by doing simple tasks, coach them in person so they can learn by doing, and then recognize their efforts, I’ll have a new team of people contributing targeted, strategic content to the site. I just need to quit wasting time writing site content and listening to Marketing and spend more time converting consumers to contributors and then guiding them in making the improvements consumers need. The takeaway?

1. Show consumers how they can contribute and that it’s easy.
2. Recruit consumers: Get a commitment.
3. Coach consumers 1:1 so they can learn to contribute by doing it.
4. Focus new contributors in providing content consumers want.

A meme’s power to evolutionally weaken a site

Tim O’Reilley’s What is Web 2.0 classifies the term “Web 2.0″ as a meme (pronounced “meem”). It’s worthwhile to know what a meme is because the term smacks of democratization, crowdsourcing, and, at its core, the sort of environment-vs.-genetics, nurture-vs.-nature or choice-vs.-predestination connotations that are core to the Web’s direction. An understanding of the term evokes a warning to the owners of Web 2.0 sites.

According to Dictionary.com, a meme is “a unit of cultural information, such as a cultural practice or idea, that is transmitted verbally or by repeated action from one mind to another.” The term was coined by Richard Dawkins, who used it to define a popularized cultural practice which may supercede biological evolutionary processes of natural selection. A meme can either succeed by being used repetitively by a growing number of users or it can die because people don’t find it particularly useful. In a society, that means a meme which runs counter to natural selection can still succeed. So a cultural practice can actually select and even proliferate a trait that physically weakens the population.

This has implications for the Web itself, and for any Web 2.0 site. A Website evolves in one of three tracks:

1. The site fails to evolve as its users demand and becomes unpopular and irrelevant;
2. The site evolves at every whim of its members and becomes something that serves is popular to its members but that fails to fulfill its sponsors’ original mission.
3. The site evolves in a limited way, serving many user needs but still fulfilling its sponsors’ intended mission.

At face value, the idea that a Web 2.0 site can grow into a monster its creator can’t control seems obvious. But what is less obvious is how to recognize where your own site rests on that slippery slope.

I’m a genealogist, which means I search for my ancestors. A common practice among top genealogists may be helpful in determining where on the slope to popularity-and-mission-loss your site might be. When a genealogist finds records of a person who may be the parent of an ancestor already on his family tree, he steps back and tries to disprove the potential link. Let’s say the genealogist already knows who his grandfather is, and finds records of someone who might be his great grandfather. Rather than just attaching great-grandad to his family tree, he steps back and tries to disprove that this candidate could really be the great grandfather. Did the grandfather and great-grandfather live in the same place, or were their residences distant? Was the great-grandfather candidate the right age to have sired the grandfather? Did the candidate die young in a war or epidemic which predated the birth of the grandfather? Are there other records that provide a definite link between the candidate and the grandfather, and if not, why? Sometimes this discipline — this willingness to say “Why shouldn’t these two people be linked?” — evokes questions which prevent big mistakes in one’s genealogical research.

A similar discipline can apply to the evolution of a Web 2.0 site. It’s easy for site sponsors to just let users evolve the site as they wish. After all, there are more users than sponsors, and the Type-A users are very outspoken, often reaching a level of influence with other users which is higher than that of sponsors. But undisciplined evolution of a site in all directions can bring a chaos that degrades the site’s usefulness. Mobocracy can lead to chaos. So when the user population wants the site to evolve in a certain direction, the wise sponsor might ask himself “What are some reasons why this change would be bad? How might this evolution change or undermine the site’s mission?”