Mon, May 28, 2007
WikiClock: The Next Killer Wiki App #
Got back from Montreal and RoCoCo 2007 last Friday with a pile of notes and a case of the flu, which pretty much killed my productivity this weekend. Fortunately, spring conference season for me is over, and I'm boycotting all summer conferences with the possible exception of WikiMania in Taipei this August, which means I've got plenty of time to digest and regurgitate. As usual, it'll come in bits and pieces, starting with this post. (MAV)
RoCoCo pretty much kicked butt. Much props go to EvanProdromou, AnneGoldenberg, AntoineBeaupre, and the entire Montreal Wiki community for pulling off such a great event. Lots of participants traveled to attend, including several Europeans, which made the experience much richer. This included representatives from every PHP-based Wiki (TimStarling of MediaWiki, AndreasGohr of DokuWiki, ReiniUrban of PhpWiki, PatrickMichaud of PmWiki, and MarcLaporte of TikiWiki), which was awesome. I was happy to see old friends from afar and from not-so-far, and I met several great new folks. WikiOhana is a wonderful thing. (MAW)
The best session was Evan's, "Wiki And...," which he nefariously scheduled at the same time as my Wiki Interoperability session so I couldn't attend. That didn't prevent me from learning about his incredibly brilliant idea: WikiClock, made possible by GordonMcCreight's most excellent service, pageoftext.com. (MAX)
What is WikiClock? It's a clock on a Wiki that tells you the current time in GMT. How does it know the current time? Someone edits the time. Who edits it? Whoever feels so motivated. (MAY)
WikiClock is a great example of a totally ludicrous application of a Wiki. The point of Evan's session is that Wiki-enthusiasm can lead to overly narrow thinking. Wikis are great, but they're not the end-all-and-be-all of collaborative tools. There are a whole slew of good tools out there. Use the right one for the right job. (MAZ)
The story doesn't end there, however. What makes WikiClock all the more ridiculous is that people are actually using it. You heard me right. The buzz from Evan's session started propagating pretty quickly. If you check WikiClock right now, chances are the time is correct. And if it's not, well, correct it! (MB0)
WikiClock is that rare breed of joke, where you laugh, then you stop and think, "You know, it's really not that bad of an idea." Next thing you know, it's no longer a joke. I know of only one other joke like it: Parrot, the virtual machine for dynamic languages that started off as an April Fool's joke. (MB1)
/tech/wiki | Posted at 11:22pm
Tue, Feb 13, 2007
Visualizing Wiki Life Cycles #
On the first day of WikiSym in Denmark last August, I spotted AlexSchroeder before the workshop began and went over to say hello. Pleasantries naturally evolved into a discussion about PurpleNumbers. (Yes, I've got problems.) Alex suggested that unique node identifiers were more trouble than they were worth, because in practice, nodes that you wanted to link to were static. Me being me, my response was, "Let's look at the numbers." Alex being Alex, he went off and did the measurements right away for CommunityWiki, and he did some followup measurements based on further discussions after the conference. (LSP)
As it turned out, the numbers didn't tell us anything useful, but our discussions firmly implanted some ideas in my head about Wiki decay rates -- the time it takes for information in a Wiki page to stop being useful. (LSQ)
I had toyed with this concept before. A few years ago, I came up with the idea of changing the background color of a page to correspond to the age of the page. A stale page would be yellowed; an active page would be bright white. I had originally envisioned the color to be based on number of edits. However, I realized this past week that I was mixing up my metaphors. There have been a few studies indicating a strong correlation between frequent edits and content quality, so it makes sense to indicate edit frequencies ambiently. However, just because content has not been edited recently does not mean the information itself is stale. You need to account for how often the page is accessed as well. (LSR)
(At the Wikithon last week, KirstenJones implemented the page coloring idea. She came up with a metric that combined edits and accesses, which she will hopefully document on the Wiki soon! It's cool, and it should be easy to deploy and study. IngyDotNet suggested that the page should become moldy, a suggestion I fully endorse.) (LSS)
This past Sunday, I had brunch with the SocialText BloomingtonBoys. Naturally, pleasantries evolved into Matthew and me continuing along our WikiAnalytics track, this time with help from ShawnDevlin and MattLiggett. We broke Wiki behavior into a number of different archetypes, then brainstormed ways to visually represent the behavior of each of these types. We came up with this: (LST)
The x-axis represents time. The blue line is accesses; the green line is edits. Edits are normalized (edits per view) so that, under normal circumstances, the green line will always be below the blue (because users will usually access a page before editing it). The exception is when software is interacting with the Wiki more than people. The whole graph should consist of a representative time-slice in that Wiki's lifespan. (LSV)
The red line indicates the median "death" rate of Wiki pages. After much haggling, we decided that the way to measure page death was to determine the amount of time it takes for a page to reach some zero-level of accesses. We'll need to look at actual data to see what the baseline should be and whether this is a useful measurement. (LSW)
The red line helps distinguish between archetypes that may have the same access/edit ratio and curve. For example, on the upper left, you see idealized Wiki behavior. Number of edits are close to number of accesses, both of which are relatively constant across the entire Wiki over time. Because it's a healthy Wiki, you've got a healthy page death rate. (LSX)
On the upper right, you see a Wiki that is used for process support. A good example of this is a Wiki used to support a software development process. At the beginning of the process, people might be capturing user stories and requirements. Later in the process, they might be capturing bugs. Once a cycle is complete, those pages rapidly become stale as the team creates new pages to support a new cycle. The death line in this case is much shorter than it is for the idealized Wiki. (LSY)
Again, one use of the Wiki isn't better than the other. They're both good in that they're both augmenting human processes. The purpose of the visualization is to help identify the archetypes so that you can adjust your facilitation practices and tools to best support these behaviors. (LSZ)
This is all theory at this point. We need to crunch on some real data. I'd love to see others take these ideas and run with them as well. (LT0)
/tech/wiki | Posted at 3:24pm
Wiki Analytics at the Wikithon #
I got to put on my hacker hat for a day (a very rare occurrence for me these days) last Wednesday at the Wikithon. After trolling around for ideas, I decided to work on WikiAnalytics with MatthewOConnor. We ended up dominating the competition and winning the contest for best hack. (So what if there were only two teams eligible for two prizes?) (LRI)
Our driving question was: How can we measure the health of a Wiki? I don't think there is one best way to use a Wiki, but there might only be three or four. If we can start teasing out patterns of Wiki usage, we can better understand how people collaborate with Wikis, which will help us better facilitate Wiki communities and improve Wiki software. Our goal was to tease out the patterns. (LRK)
We used data from 266 public SocialText workspaces and SocialText's internal corporate workspace. You can read the details of our brainstorming and work on the SocialText STOSS Wiki. Our approach was to simplify our tasks so that we could have something to show at the end of the day. It was decidedly practical, but it also reflected a deeper philosophy about WikiAnalytics. Start simple and evolve. You can learn interesting things from even simple measurements. (LRL)
Results (LRM)
We chose to focus on two types of analysis: page name and graph (link) analysis. I hacked on the former; Matthew on the latter. (LRN)
Frequent followers of this blog have heard me say it before: LinkAsYouThink is what makes Wikis powerful. The better your page names, the more interlinked your repository will be as you LinkAsYouThink. In order to see if I could measure "good" page names, I looked at three things: (LRO)
The hypotheses are straightforward. Shorter names are better. Names with fewer tokens (words) are better. Names without non-alphanumeric characters are better. (This last hypothesis is complicated by internationalization.) (LRS)
You can read the results of my analysis. The workspaces on the index page are ordered largest to smallest. The top two workspaces are full of spam and can be safely ignored. The numbers on the index page are buggy; click through to the individual pages to see the correct numbers. (LRT)
Matthew studied the graph characteristics of the Wikis, specifically: (LRU)
- Number of links (forward and back) versus number of pages (LRV)
- Number of islands (clusters of pages that are strongly connected to each other) and their sizes (number of pages on an island) (LRW)
Islands of one are orphan pages (not linked to anywhere) and are undesirable. Large islands are better (or at least more interesting) than small ones. (LRX)
You can view Matthew's results on his site. (LRY)
Analysis (LRZ)
To give you an idea of what the stats mean, let's look at four Wikis: (LS0)
- stoss (SocialText Open Source Software) (LS1)
- speakers (Speakers Wiki) (LS2)
- st-rest-docs (SocialText REST API Wiki) (LS3)
- ivrwiki (Interactive Voice Response -- Angel.com) (LS4)
The mean number of characters and number of tokens for page names on each Wiki were: (LS5)
- 21.3 / 3.1 (stoss) (LS6)
- 18.6 / 2.4 (speakers) (LS7)
- 17.4 / 1.7 (st-rest-docs) (LS8)
- 39.3 / 6.7 (ivrwiki) (LS9)
On the surface, the two Wikis in the middle -- stoss and speakers -- seem to have hit the sweet spot for page names: between two to three words per name. Since stoss is meant to be a collaborative workspace for a larger community, this seems to be a healthy number. The speakers Wiki is a repository of potential speakers. Since the majority of pages consists of people's names, the numbers (two, sometimes three words in a page name) make sense. (LSA)
The remaining two Wikis diverge enough from this minute data set that we can infer some different patterns of usage. st-rest-docs documents SocialText's REST API, so there are a lot of one word page names representing method names. Even though the average number of tokens is smaller, the average name length is comparable to the two Wikis in the middle. This also makes sense, given that the methods in a REST API are actually URI paths, which can get somewhat long. (LSB)
On the surface, ivrwiki seems to exhibit the classic signs of a newbie dumping ground, with page names that are too long to be useful. However, if you dig deeper, you can see that that's not the case. The standard deviation of number of tokens is quite large (4.2), indicating a flat distribution curve. In other words, while there are a lot of long names, there are also a lot of short names. If you dig even further, you'll see that the community is using the Wiki as a question repository, and questions naturally have lots of words. Additionally, there seems to be a lot of more traditionally "Wiki-like" behavior on that Wiki. (LSC)
This was no accident. The reason I'm showcasing ivrwiki is that Matthew identified it as an "interesting" Wiki from his graph analysis. Look at the numbers. There are three sizes of islands: 19 of one page, one of 16 pages, and one of 353 pages! That's one big island! It indicates a fairly tight set of linkages across the majority of the pages on a Wiki. Dig a bit deeper, and you can see the hub of the cluster: the Knowledge Base Index page. It links to every page in the knowledge base, and every page in the knowledge base links back to this page. (LSD)
The st-rest-docs Wiki exhibits similar behavior -- one big island of 81 pages. This makes sense, given that this Wiki represents documentation, which is structured in a similar way to the ivrwiki knowledge base. (LSE)
The stoss Wiki is the most Wiki-like of the four when you dig into the graph analysis. There are five sizes of islands, the largest containing 10 pages. The distribution is fairly regular -- based on my guess of what "regular" should be, at least. To really get a sense of what "regular" should be, we'll need to identify several Wikis that we consider to be "Wiki-like," and examine those numbers. (LSF)
Finally, look at the numbers for the speaker Wiki. The numbers are in reverse of the other Wikis. There is basically no clustering; all of the pages consist of islands in and of themselves. At first glance, this is surprising. You would expect it to look somewhat like ivrwiki and st-rest-docs. The reason for the lack of clustering is that this Wiki relies on SocialText's tagging interface for navigation. Tags could be treated as a type of link, but we don't treat them that way in our analysis. (LSG)
Thoughts (LSH)
As with any simplified analysis, there are always caveats. A lot of them are specific to the Wiki implementation. For example, several people at SocialText use the stoss Wiki as a blog, which creates long page names and thus skews the statistics. Other Wikis may be similar to the speakers Wiki in that they use tags as navigational links. (LSI)
There's an open question as to whether or not to consider a Wiki a directed graph or not. We chose the former, but you can make a good argument that the SocialText Wiki acts as a non-directed graph, or at least a bidirectional one, because BackLinks are displayed on the page itself. The same holds true with any other Wiki depending on the navigational context. If I start at the home page and start navigating around, I can often use the browser back button to go back, or at worst, I can click on "BackLinks" to figure out the context. (LSJ)
I'm not sure the page name analysis is that interesting by itself. I think it gets very interesting when applied to the specific islands on a Wiki. People may be using a Wiki in a number of different ways, as demonstrated by the ivrwiki. Analysis on each individual cluster will potentially surface the different kinds of behaviors on a Wiki, which is more appropriate than trying to slap on a single archetype if one does not exist. (LSK)
Finally, what level of clustering is healthy? In systems theory, networks that are either too tightly clustered or too lightly clustered are problematic. With enough analysis, we may be able to speculate on the right number for Wikis. (LSL)
Matthew and I will release our code at some point, and we'll hopefully have some time to follow up on it as well. Specifically, I'd like to examine a lot of other Wikis, starting with the ones that BlueOxenAssociates hosts. (LSM)
There were a lot of other hacks at the Wikithon that were cool. My favorites were IngyDotNet's Social Zork (which was not only hilarious, but is actually potentially useful) and ShawnDevlin's Word Cloud, which I hope to use on other Wikis. ChristineHerron wrote a good summary of the day's festivities. (LSN)
/tech/wiki | Posted at 12:42pm
Sun, Nov 05, 2006
Why the French Hate Wikis #
At WikiSym last August, WardCunningham showed some regional trends comparing Google searches for "wiki" and "blog." Overall, searches for "blog" (in red) steadily outpace searches for "wiki" (in blue), although the rate of growth is about the same for both. (LH4)
Ward pointed out that the phenomenon is reversed in Germany: (LH6)
The same is true in Japan, except the difference is even more pronounced: (LH8)
At WikiWednesday this past week, PeterThoeny said that he had shown similar trends for a recent Wiki talk, and that he also showed the trends in France: (LHA)
Whoa, Nellie! Apparently, the French don't care much for Wikis. It was a shock for me to see this, as I know several stellar French members of the Wiki community and even more French-speaking members. Any thoughts as to why this might be the case? (LHC)
/tech/wiki | Posted at 1:15pm
Kirsten Jones on Perlcast #
SocialText's KirstenJones talks about Socialtext Open and its REST API on this week's Perlcast. It's a good interview, and the last question reminded me of a funny exchange at WikiWednesday this past week: (LH0)
Kirsten: PHP is for girls. (LH1)
EvanProdromou: Hey, Michele would object to that! (LH2)
Kirsten: That's because she's a woman. PHP is for girls, Perl is for women. (LH3)
/tech/wiki | Posted at 12:59pm
Wed, Nov 01, 2006
Wikipedia Virgin No More #
Yesterday, ErikMoeller asked me to look at the Wikipedia entry on Intellipedia. Curious as to the timing of the request, I checked my feeds, and sure enough, a few articles on Intellipedia had cropped up. (LGQ)
I figured the best people to review the accuracy of the article were those involved, so I passed Erik's request along to them. However, in reviewing the article myself, I noticed that somebody had linked to my picture of the Intellipedia shovel, along with a short description. The description was slightly off, so I decided to fix it. In doing so, I lost my Wikipedia virginity. (LGR)
If you want to be technical about it, I wasn't a real Wikipedia virgin. I've vandalized the site anonymously on more than one occasion. That's right, vandalized. It was a cool trick I picked up from RossMayfield as a way to demonstrate in front of a live audience that yes, anyone really can edit Wikipedia, and more importantly, that Wikipedia is self-healing. I don't do it anymore, because the bots have gotten smarter, thus eliminating one of the main points of the demonstration. (LGS)
The first time I told this story to Wikipedians was when I was introducing myself at the Hacking Days Wiki developers summit at WikiMania 2005. I said, "I've never edited Wikipedia, but I have vandalized it on more than one occasions." I thought it was pretty funny, but no one laughed. It could have been that people had a hard time picking up on the irony in English, but I think people just didn't think it was funny. So for all of you Wikipedians hearing this story for the first time, blame Ross. (LGT)
I nearly edited Wikipedia for real in 2004, when I was finishing up my research on OpenSource adoption in Brazil. In my original draft, I told some great stories about the rise of grassroot communities in Brazil, and to my horror, the editors cut them out. I decided to insert them into Wikipedia, but I never got around to it. Maybe I'll revisit this, especially now that Lula is back in the news. (LGU)
I've spoken at both WikiManias, and I've talked to many folks about Wikipedia, so I've always felt a little guilty about not having actually edited it. Then at this year's WikiMania, I learned that WardCunningham hasn't edited it yet either. (It's captured on this recording.) That helped, but now the guilt is gone for good. (LGV)
How does it feel to have finally edited it? To be honest, it's no different than editing any other Wiki. Personally, I find that really cool. It's further confirmation that as big as Wikipedia has become, at its core, it's still just a Wiki. It reminds of the original exchange between JimboWales and WardCunningham on Ward's Wiki about Wikipedia: (LGW)
My question, to this esteemed Wiki community, is this: Do you think that a Wiki could successfully generate a useful encyclopedia? -- JimboWales (LGX)
Yes, but in the end it wouldn't be an encyclopedia. It would be a wiki. -- WardCunningham (LGY)
Of course, my assessment isn't quite fair, either. I haven't experienced a Wikipedia edit war first-hand or a negotiation over NeutralPointOfView?. More things to look forward to! (LGZ)
/tech/wiki | Posted at 10:40am
