When we build corporate Wikis and shared knowledge bases, it's tempting to try to neatly arrange every page into a master hierarchy, or tree:
Products
Software
AcmeQuery
Setup
Environments
Deployment
Techniques
Project Setup
Tools
DeploymentWidget
It’s a nice idea, but you will quickly run into one of the following problems:
- Not every article has exactly one place where it should live
- Users might not feel confident to add new knowledge if they can’t find the right place for it to live
- “Designed” hierarchies represent a fixed-in-time purpose in a changing domain
What are the goals for your wiki?
Here are my guesses:
- Easy to contribute to
- Easy to find what you’re looking for
- Comprehensive of your contributors’ combined knowledge
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:
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. 🎷
Summary
My gold standard for super-powered internal wikis is this:
- A wiki is a “big pile of pages”
- Anyone can make a page at any time if they think they know something that other people don’t know
- Try your best to give pages good titles which are searchable
- Try your best to apply relevant tags that you’ve seen around the place, and invent new tags when necessary, on new and existing content
- Add ‘See Also’ links between related pages (perhaps your software can do this automagically)
- Give visitors a “jumping off point” on Home, where they can go quickly to high-quality, highly-connected articles.
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 🌱📃✨
Top comments (0)