Wiki Reading Habits

I use a perl script to untangle and format the wiki server logs so that I can get a feeling for how visitors use this resource. Wiki usage, since the beginning, has fallen into three different styles ...

Reference. Some people retrieve a single random page and are gone. I assume they are following a link from elsewhere and have found what they want or don't believe they will find it by browsing further.
Track. Others track RecentChanges and call up two to ten of the pages cited there. These people are regulars who can tell a provocative first post from a dwindling thread from the page name alone.
Browse. Still others take the time to read several dozen pages at a time. The usual style is to link through a few pages, back up, and then link through a few more. Sometimes these visitors are newbies reading the likes of MoreAboutMechanics, other times they are regulars exploring a topic or an author. These are the people most likely to search.

I'm proud that WikiWikiWeb supports these three, quite different reading styles. I also really appreciate the regulars who use their knowledge of the breadth of wiki to tighten-up the writing of some year-old threads buried deep under the tip of the WikiIceberg. Thank you. -- WardCunningham

See WikiMines for a study of WikiWritingHabits. And WikiIceberg for for comments on the "focus" of "consciousness" of Wiki, as seen from RecentChanges.

Ward, I hope the log file doesn't actually identify how many times a day I execute RecentChanges. That'd be embarrassing, I fear. -- RecentChangesJunkie

I'm running a small in-house Wiki-like server here, and some/many of the participants complain that all they can tell from RecentChanges (or our cookie-based UnreadChanges?) is which pages have changed. But they also want to know how those pages have changed. In ThreadMode, of course, it's often obvious, as there's a new-looking comment at the end. But if there have been changes in the middle somewhere instead (or, even more perniciously, as well), they can be hard to find without rereading the whole page. My "well, rereading the whole page might do you good" has fallen on rather deaf ears! *8)

Is there a good solution to this problem that WikiWikiWeb readers use?

I may be persuaded into a technological fix, if I can find some good edit-distance-estimator in Perl: a button (or whatever) that would light up the most recent changes in a different color. Not sure if it's overkill or not; it smells a little glitzy...

-- DavidChess

WikkiTikkiTavi and MeatBall have systems that show you what has changed on a page between any two chosen revisions (if those revisions have not been deleted yet). Very helpful.

-- BayleShanks

You can see the most recent change by hitting "EditText" on the bottom, and then "EditCopy" on that page. (I usually just add "copy=" between the question mark and the page name in the URL.) The "EditCopy" page shows the differences between the previous version and the current version, as reported by the Unix "diff" command.

Unfortunately, you can miss changes if you don't keep up. I think one would need a revision control system on the server, or a history of past page contents on the client to do better. -- JeffGrigg

I feel a UseCase coming on... JeffGrigg finds that he usually wants to know "What changed since I last viewed this page?" Unfortunately, this would require a revision history, and some storage (on the client PC?) to keep track of what version of each page you've read.

Revision history, yes. Tracking read versions? No. I can usually recall when it was that I last looked at a page, to sufficient accuracy for this purpose, anyway.

A faster way to see the differences is to click the last edited date at the bottom of the page.

See MeatBall:CatchUp. Perhaps this sort of thing would be best implemented client-side in a MeatBall:ChangeAggregator

My preferred interface would be change bars a la Word or Frame. A larger font would be okay.

In my experience, this kind of interface creates more confusion than it solves. There are so many RecentChangesJunkies here, that as soon as a page is edited it becomes a candidate for a flurry of changes and comments. I also find that I edit a page, go back to it to see how it looks, and spot an error or typo, which I then correct. Either of these habits would defeat any system based on showing just the changes since the previous version.

My preferred solution would be akin to the one offered by UltimateBulletinBoard? (UBB) where the browser stores a "time last viewed" cookie and the server highlights all changes since that time. Whether this cookie should be per page or per some abstract "reading session" is left as an exercise for the reader. --FrankCarver

Under Ward's second way of viewing the wiki "Track" there are presently at least three useful methods - CategoriesRoadmapsAndSearches - The three are particularly useful when the subject area of the Wiki participant is focused rather than general. Such a person is more likely to have a relatively lower WikiReaderToWriterRatio. Also this type of participant is more likely one who will refactor a page or pages in such a way as to concentrate the essential meaning within wiki and reduce duplication and the remove the less meaningful or spurious content.

I usually browse this Wiki using FindPage as my gateway. I'm surprised that Ward didn't catch on to that usage pattern with his script. Also, this escapes the normal WikiIceberg phenomenon (I found ZenWindow early on, searching for indow [not a typo: I didn't yet know that FindPage was case insensitive]).

Also see: WikiReaderToWriterRatio

You can also ReadWikiAsaDictionary.

CategoryWiki