Topic: Wiki

I’m going to present this post somewhat out of order. Here’s the proposal.

I want to think about moving this blog (or starting another?) to be a blog/wiki hybrid, and at the very least, moving forward I’d like the “discussion” or comment’s link to link to a wiki page rather than a comments thread.

I’ve been thinking about the blog recently. I really enjoy writing posts, and there are days when I rely on writing a blog post to get me thinking and moving in the morning (or afternoon!) and kinds of projects that I don’t think I would be able to work on if it weren’t for having the space to write and the opportunity to have conversations with you all.

I’ve done some work recently to streamline and simplify the publishing process, which does a lot to make me more likely to post on the fly, but I’m not sure that the tone of this site, or the current design, or my own habits would really support a different kind of publishing schedule.

As an aside, I think the technological shift that made blogs possible were “content management systems” and website building tools that made updating a website with new content incredibly simple. While blogging has come to mean many other things and is defined by a number of different features, having the ability to publish on very short notice has a large effect on the way people write blog content.

So here’s the thing about blog comments: I don’t think that they’re used particularly well, and there are some important flaws in so many of the options around. First, the best systems, like the one used on LiveJournal, IntenseDebate, and Disqus (which I use on this site) are all proprietary systems that are depending on an external service to function. The worse systems all have independent authentication methods, often lack proper threading (which most comm enters aren’t terribly good at using anyway,) and it’s very difficult to prevent all these systems from being filled with spam.

What’s more, people don’t really comment that much. At least for most blogs.

• better comment systems, better discussions.
• catering to people who want to write a lot. in comments.
• allowing the conversation to grow from comments, in productive rather than purely discursive ways.

And once you’ve moved comments into a wiki, why not move the rest of the blog as well? My preferred engine, ikiwiki, has support for blog-like content so while there would be some work involved, it wouldn’t be a major hassle to manage. And the worst case scenario is that the old content remains in the old system, which might not be a bad thing in the end.

Anyone out there in reader land have any thoughts on the subject? While I’ll probably make some sort of revision to the way I blog/maintain tychoish.com, any such change is probably a month or two in the future.

I’ve been trying to figure out wikis for a long time. It always strikes me that the wiki is probably the first truly unique (and successful) textual form of the Internet age. And there’s a lot to figure out. The technological innovation of the wiki is actually remarkably straightforward,¹ and while difficult the community building aspects of wikis are straightforward.² The piece of the wiki puzzle that I can’t nail down in a pithy sentence or two is how to organize information effectively on a wiki.

That’s not entirely true.

The issue, is I think that there are a number of different ways to organize content for a wiki, and no one organizational strategy seems to be absolutely perfect, and I’ve never been able to settle on a way of organizing wiki pages that I am truly happy with. The goals of a good wiki “information architecture” (if I may be so bold) are as follows:

• Clarity: It should be immediately clear to the readers and writers of a wiki where a page should be located in the wiki. If there’s hierarchy, it needs to fit your subject area perfectly and require minimal effort to grok. Because you want people to focus on the content rather than the organization, and we don’t tend to focus on organizational systems when they’re clear.
• Simplicity: Wikis have a great number of internal links and can (and are) indexed manually as needed, so as the proprietor of a wiki you probably need to do a lot less “infrastructural work” than you think you need to. Less is probably more in this situation.
• Intuitive: Flowing from the above, wikis ought to strive to be intuitive in their organization. Pages should answer questions that people have, and then provide additional information out from there. One shouldn’t have to dig in a wiki for pages, if there are categories or some sort of hierarchy there pages there shouldn’t be overlap at the tips of various trees.

Strategies that flow from this are:

• In general, write content on a very small number of pages, and expand outward as you have content for those pages (by chopping up existing pages as it makes sense and using this content to spur the creation of new pages.
• Use one style of links/hierarchy (wikish and ciwiki fail at this.) You don’t want people to think: Should this be a camel case link? Should this be a regular one word link? Should this be a multiple word link with dash separated words or underscore separated words? One convention to rule them all.
• Realize that separate hierarchies of content within a single wiki effectively create separate wikis and sites within a single wiki, and that depending on your software, it can be non-intuitive to link between different hierarchies.
• As a result: use as little hierarchy and structure as possible. hierarchy creates possibilities where things can go wrong and where confusion can happen. At some point you’ll probably need infrastructure to help make the navigation among pages more intuitive, but that point is always later than you think it’s going to be.
• Avoid reflexivity. This is probably generalizable to the entire Internet, but in general people aren’t very interested in how things work and the way you’re thinking about your content organization. They’re visiting your wiki to learn something or share some information, not to think through the meta crap with you. Focus on that.
• Have content on all pages, and have relatively few pages which only serve to point visitors at other pages. Your main index page is probably well suited as a traffic intersection without additional content, but in most cases you probably only need a very small number of these pass through pages. In general, make it so your wikis have content everywhere.

… and other helpful suggestions which I have yet to figure out. Any suggestions from wiki maintainers?

• The Contra Purity Test: A couple friends and thought it might be cool to work on a “purity test” for contra dancing/dancers. Mostly for jokes, I said “I’ll make a wiki page,” and then I did. It is, I’d say 70% done.
• Some writing and thinking about TumbleManager, tumblelog engine in response to this post. I’m writing this as a design document/spec sheet because I’m a writer and my brain works like this.
• The Lessons from System Administration is the beginning of an archive of posts that I’ve written recently drawing lessons learned in system administration into other more generally useful contexts.
• Sygn Networking - I’ve done some editing recently on this older project with an attempt to move it forward. Reorganization, cleaning up of text, adding new points in where they make sense. Of particular interest is, I think the data examples of what sygn profiles might look like. I hope this all helps illuminate the project a bit.
• Although this only barely counts: I did some very wiki-like editing to the tubmlelog post, which I think cleaned up the text a bit. I’m, as you’re aware, not a very polished sort of writer. But I think I’m pretty good at cleaning things up after a fashion, and once I have the right distance. Or something. It’s a bit clearer now, at any rate.
• Also not wiki related specifically, but I’ve been doing some rolling revisions on the Cyborg Institute website recently. I don’t want the CI project to die, but I want it to be more realistic, and useful to other people as a platform for some really awesome projects. I think by focusing the site, and pulling out some cruft we’re getting in that direction.

In addition to the above, I wanted to explore the possibility of doing more posts like this occasionally as a way of saying “Hey! I’m working on cool things like the stuff I write about here, but the stuff isn’t getting posted here. Check them out” is that a valuable use of this space? Or would this tedious?

Onward and Upward!

First, an announcement. I’ve started a tychoish.com wiki. I’m calling it, appropriately enough “wikish.” You can see a brief introduction and note about my intentions there.

I’ve written a bunch here about the peculiarities of building communities and practices around “the wiki,” as I think it represents a new paradigm for thinking about collaboration and “the text.” I’m, slowly, working on building a community around the cyborg institute wiki, and that’s an ongoing (and fairly specific) project. I’ve also, in much smaller ways, done things with wikis in a couple of other situations: for some group projects I’ve been involved with, a few things for work, and so forth. Perhaps more relevantly, I also used a wiki--much like this one and the others I am responsible for--as the system I used for storing everything in my brain. From these experiences I’ve come to the following conclusion:

• In any given wiki, most of the “work,” particular at the beginning, is accomplished by a very small number of contributors. Potentially only one contributor.

  Critical mass is a difficult thing to manage or predict, and if you start a wiki and you want it to succeed, you have to be ready to do all of the work of getting it to critical mass, which could take a long time. Fair warning.

• Wikis are incredibly unstructured. It’s easy to impose structure on a new wiki, in cases where structure will actually hinder growth and development rather than promote development. Particularly if the kind of content you hope to develop is wiki like. For personal organization tasks, wikis are often not the right answer, even if they appear to work for a long time.

• Creating a page in a wiki is often better and more effective than writing an email of some length (say, more than 250 words), particularly when more than two people are involved in the correspondence.

• I need another wiki like I need a hole in the head. But, I like that wikish is both public--you all can watch and contribute to what I’m working on--and focused on what I’m working on. The personal wiki, the one that was just for internal use suffered from lack of audience even an imagined audience.

• I think putting the novella that I wrote in late 2007 into a wiki and working on revisions and tweaks in that context makes a great deal of sense, and I think wikish feels like the “right place” to put that work.

So that’s the plan. I’ll probably post from time to time about new things that I’m posting there, and I’m perfectly happy to have you all make pages in wikish as you want. I’ve also decided, that wikish will require OpenIDs as the only means of authentication. Just cause. See you there!