There is a strong feeling within the team that the Web Services Wiki needs a thorough overhaul.
Having been tasked with looking at how we would restructure our Wiki pages, I identified three problems to be considered.
1) Mass of content
The Wiki has grown organically over several years, with numerous authors adding to it. At the time of writing there have been 14 pages added in the last week alone.
The end result of this is a mass of content that would require substantial time and resources to review fully. The Web Services section – one of 12 that exists within the ‘Webservices’ space in the Wiki’s Space Directory – has more than 2,500 pages.
Some of the content is also several years old, no longer relevant or of debatable accuracy. Culling it would be an entire project in itself.
2) Identifying categories
Being a newcomer to the world of digital, the task I have found most challenging so far is defining content and categories. What seems a logical and useful label can later turn out to be so vague you may as well have called it ‘miscellaneous’.
To structure the range of information found on our Wiki requires much discussion on what exactly the department wants the Wiki to be used for.
3) How do you structure an anti-structure?
The practice of Information Architecture (IA) is all about structure. The classic IA website pattern is the hierarchy, where the relationship between items is one of parent and child.
The problem with the Wiki is that it is a Hypertext structure, which is “almost a an anti-structure”, to quote IA guru Donna Spencer. There is no master structure like in a hierarchy, but instead content is linked together via links.
This suits the Wiki as content is added continually over time, and agreeing a strict structure to rigidly adhere to before the Wiki was first created would have been a lofty goal indeed.
In short, if you impose a structure on the Wiki, does it stop being a Wiki?
In tackling these problems, I did the following:
- Gathered Google Analytics reports on each section covering a year-long period, and looked at the top 20-30 pages of each one as a sample.
- Held meetings with the rest of the Web Services team to discuss what categories would be useful.
- Agreed with the team to hold a card sorting exercise to flesh out a structure that works for our needs.
Once a draft structure is agreed upon, we will implement it and then iterate continually over the next year.
Ultimately whatever is produced at the end of this exercise will be a first iteration. Even if the first draft of the structure ends up being unrecognizable to what we arrive at, the process will be a valuable learning experience for myself and the team.