Before the blog took off, before Tumblr became the face of fandom, but around a year after Geocities launched as a platform for Justin Timberlake fan sites, there was The Wiki. We looked upon The Wiki, and we saw its potential as a platform for crowdsourcing knowledge, collaborating, and educating. We saw that it was good. Then Wikipedia was founded at some point, and the rest is history. I love well-maintained wikis to a fault. Wikis have been a large part of my continuing education in web design, random trivia, and the minutiae of video game mechanics for a long time, now. Anyone who learns stuff on the Internet owes a lot, directly or indirectly, to wikis and their less-community-oriented cousin The Knowledge Base. Even though many of the publicly available wiki software options are dated and confusing to operate and organize, they continue to power much of the educational portion of the web. There are more modern options, but most of the ones I’ve found are SAAS platforms for building in-organization private wikis. Ladies and Gentlemen, wikis and knowledge bases need all the love we can give. That’s what this article is about: brainstorming ways to give back to the platforms that have given us so much. I’ve got some general ideas, and some very specific tweaks to the wiki formula that you might consider implementing on your own wikis, should you ever need to build one.

General Front and Back-end Upgrades

Wikipedia still uses a theme that doesn’t have a maximum width on the content area. In fact, I’ve looked at theme options for MediaWiki (the software that runs Wikipedia), and most of them are incredibly dated and not terribly user-friendly. Ditto for DokuWiki (though to be fair, there have been some fairly good themes adapted for it), PhpWiki, and many others. This is at least in part because most of the wiki software still in use is ancient by IT standards. It can be difficult to adapt modern front-end code to old platforms (depending greatly on how they were made). The age of these platforms shows in the back-end, too, as they were clearly designed by software/data engineers, and tend to be harder for anyone else to use. Oh, just about anyone can still learn these systems, but it’s a royal pain. To put it simply, we need new options. We need a whole new generation of (preferably self-hosted) wiki software that combines everything the older projects have learned with everything we now know about usability, UX, and content management. And for the love of all that is holy and good, we need something easier to design and code new themes for. Take Wiki.js, for example. It’s a relatively new project which is definitely on the right track. Now if only there was a PHP version, or at least an easier way to install Wiki.js, I’d be a happy camper. (If you’re a dev working on a new wiki project, please link it below.)

In-Page Search for Long Pages

I know, I know. I’m actually about to recommend adding a JavaScript-dependent feature to a website. But I’ve been on some very, very long wiki pages that really could have used an in-page search function. Yes, most browsers have this sort of thing built in already (and there’s your fallback), but many users don’t know all or even half the features of their browsers. Having an in-page search would be just plain useful for when you need to find a very specific bit of information, and the table of contents isn’t cutting it.

Sortable tables

Depending on what your wiki is about, you may find yourself dealing with tables a lot more than you’re used to. Sometimes, a table really is the best way to showcase a large amount of data. If you’re cataloging, for example, all of the best books in a particular genre on one page, that table is probably going to get really long. So (and it pains me to say this) it’s not unreasonable to spice up your tables with some JavaScript to make getting to the information you want easier. If you can restrict, say, the data visible in your table to specific year, or a specific author, you’re going to save your users a lot of time.

Favorites and Recently-Visited Pages

When I find myself returning often to a wiki or knowledge base (that’s not Wikipedia), I often return to the same pages as before to refresh my memory on the minutiae of one thing or another. For example, I might need to look up a more obscure CSS property a few times before it really sticks in my brain. If you have users doing that, it may be helpful to provide them with a list of recently-visited pages for easy access, or a way to build a list of favorites. If member sign-ups are a thing that you want, you could use these features as something of a selling point, even. You may have noticed that all of the tweaks I’ve listed so far are tied to convenience. Never underestimate the power of convenience.

Final Thoughts

Wikis in general are a smart system. Make a link to a page that doesn’t exist yet, the page is generated automatically, then you go and add stuff to it. It’s an “organic” way of creating content and navigating it, too. Knowledge bases are usually more hierarchical, and that formula works for them. These systems do not, in my mind, need a complete revolution. The theory behind them is sound enough that these systems are still in use despite the inconvenience presented by older (and sometimes incredibly complex) platforms. I’m eager to see what designers and developers could do with wikis and similar platforms while knowing what we know now. We’re accumulating new knowledge all of the time, and with all due respect to blogs, sometimes we just need a good wiki for it.