Next & Previous

Usable Wikis are Categorical not Hierarchical

When we build corporate Wikis and shared knowledge bases, it is tempting to try to neatly arrange every page into a master hierarchy, or tree:

  Project Setup

It’s a nice idea, but you will quickly run into one of the following problems:

  1. Not every article has exactly one place where it should live
  2. Users might not feel confident to add new knowledge if they can’t find the right place for it to live
  3. “Designed” hierarchies represent a fixed-in-time purpose in a changing domain

What are the goals for your wiki?

Here are my guesses:

How can we acheive these things?

Consider the world’s largest wiki…

Wikipedia. Your corporate wiki will not grow to the size of Wikipedia. But we can learn lessons there about large-scale organisation of information.

When you go on Wikipedia, do you see pages in folders and subfolders? Do you “drill down” to the page you’re looking for? Probably not; it’s driven by Searchability and Categorisation.

Look at this footer from the Wikipedia article for FileMaker, a popular low-code platform:

Footer of a Wikipedia page showing categories and template boxes

The page is in 12 different categories. If the site were a hierarchy, where would you put ‘FileMaker’?

Home -> Technology -> Computing -> Computer Data -> Databases -> Desktop database application development tools ?
Home -> Technology -> Software -> Software by operating system -> Cross-platform software ?

(n.b. these navs aren’t contrived; they’re taken from actual category navigation)

It belongs in both of these places and more.

So, the flexible, usable, discoverable solution for this page is that you can find it using any of the above, or by title, or by page content.

You will end up with pages that could live in two or more places: An analysis of entities that are used by multiple apps or have multiple representations; A supporting tool that you use to do various things; A setup or technique guide that applies to several areas; A glossary that allows cross-team communication; infrastructure stuff; environment stuff; shared features; third-party integrations, etc., etc.

What this means for us

Folksonomy is an idea whereby your “folk” create and organise tags in a grassroots way. It can empower them to create content without fear of miscategorisation, and to own and organise the content as a team.

My personal opinion is that hierarchies set in stone by forerunners and bosses are more likely to inhibit new submissions.

Remember that most wikis allow you to freely move, rename, and recategorise content. It’s digital jazz, man. 🎷


My gold standard for super-powered internal wikis is this:

Next time

Someone once said to me “If you want to write a wiki page, fine, but you’ll be responsible for keeping the (entire) wiki up-to-date!”. I think this misassumption is why said person had never contributed to their wiki.

I’ve got news for you – beautiful and freeing – wikis don’t need to be up-to-date!

But that’s for another time.

Happy tagging 🌱📃✨