NCBI recently got some funding from the Department of the Taoiseach under the Access, Skills and Content initiative to create a wiki. The result is vipipedia. The “vip” prefix stands for “vision impaired person” and the wiki contains mostly “how-to” articles written by and for people with vision impairments. Topics like “detecting colours of clothing” – a very important ability for the sartorially elegant blind man or woman about town!
User centred design
The experience of creating it was a typical example of inclusive, user centred design. First we gathered information about users and their requirements using focus groups – who might use this wiki and what level of experience would they have? At the same time we carried out an analysis of existing wikis and wiki creation tools. To what extent did they support the functionality, accessibility and usability we required? Based on these findings, we chose our tool, built the wiki, user tested it, rebuilt it and are now ready to let it out into the world.
Wiki building tools
It’s pretty easy to build a wiki using tools like Wikispaces or PBwiki. Not only that, but the usability and accessibility of the wikis they produce is pretty good, with some minor niggles. However, we opted to use the MediaWiki software, as used by Wikipedia among others, and host it ourselves. This has the benefit that it is more configurable, so the resulting wiki can be as good or better in terms of functionality, accessibility and ease of use.
So we built our wiki and we made sure it was accessible, then we asked a few people to try it out – Oh dear!
Now I should say at this point that we are accessibility and usability experts and a wiki doesn’t seem that complicated, but listen to some of the comments we got:
Frankly, I was baffled by its complexity.
I couldn’t work out which part would be open to visitors, which to contributors and which to moderators.
The content seems to be just placed at random below the bottom of the first list.
This is important information to know about, but comments are just comments. Why did they find it so complicated? Is it in the nature of a wiki? Or was it to do with our user interface design? The only way to find out was to run user tests. We recruited typical wiki users, invited them into the CFIT user test facility and asked them to read, write and edit a number of articles. And we discovered what was wrong.
What went wrong
Firstly, wikis are different from your average website. Wiki concepts like editing and history and the lack of a site-wide ‘navigation’ structure were rather alien to our users. The tabbed interface, where each tab gives a different ‘view’ of the current article (text, discussion, editing or, history), was not so obvious without the visual cues. Creating or editing articles required users to use a complex markup language or a somewhat quirky editor.
Second, we had adopted a ‘clever’ design where the content came first, followed by the ‘navigation’ and ‘tools’. This was because we knew that the vast majority of users wanted to do only two things – search for articles and read articles. But the ‘upside down’ interface was so different from people’s usual experiences that they simply didn’t get it. It reminded me of when I was at Frontend and we created the original NDA IT Accessibility Guidelines. We built a ‘revolutionary’ user interface which filtered and repackaged the information according to your role and areas of interest. In user tests, nobody could find anything!
There were also problems with the default MediaWiki outputs – search results and history pages have confusing layouts and contain way more information than is necessary. To see what I mean, go to Wikipedia and click on the History tab of any article. Whew!
But thanks to the user testing, we were able to see exactly why all the users’ problems arose, then go away and fix them. The revised wiki is now very usable and accessible.
We’re under no illusion though. Now is where the real work starts. Many a great wiki has been built but fallen into disrepute and disuse. Wikis have to be managed by the community of users. There are many issues to be tackled and many roles involved to ensure the wiki grows and flourishes. So we hope were at the start of something big.
The moral of this story is that you can get away with a problematic design as long as you user test it, discover the problems and why they arise, then use that information to fix them. That’s the essence of inclusive, user centred design.
Mark Magennis (IIA guest blogger)