Wiki Usability — 2

I was asked to help update a private wiki knowledge base. The owner was using MediaWiki.

Preferred solutions were free/libre software.

First we looked at the LibreOffice Writer extension to support MediaWiki. While great in theory the extension falls short in several ways. One is the source content is always maintained in *.odt. The final output is copied and pasted into MediaWiki. That means there is the potential to directly edit the wiki without first updating the source. I will guarantee the results, which will be two versions soon out of sync. Second, while the extension supports creating new content, there is no way to open existing wiki markup. LibreOffice supports opening remote links, but the entire page is opened rather than just the specific content markup. Third, there is no direct interface. That means a clunky work flow of updating content, saving the *.odt, copying or exporting as markup, opening the wiki editor, pasting the text, saving the session, and then viewing the result.

Next on the list was the long promised MediaWiki VisualEditor. I am not MediaWiki guru and do not play one on TV. Reading the VisualEditor installation instructions made my eyes glaze and my head hurt. The tool is still classified as a beta. That means not ready for prime time and production use, especially with non technical users.

Looking at other text editor extensions for MediaWiki revealed most are no longer maintained or come with their own set off complications and unclean markup results.

We looked at stepping away from the entire wiki paradigm. Just use LibreOffice Writer as a nice WYSIWYG editor. Then use the operating system file management as a means to accessing knowledge base articles. Doable but clunky. Some kind of portal accessing that information is needed. This is a cornerstone of a knowledge base: a straightforward portal to the information.

WordPress is used in this business. Therefore we looked at various themes to support a wiki like look and feel. Testing made us feel like we were inserting a size 10 foot into a size 8 shoe.

Returning to the simple file management model, we looked at ownCloud as a portal. Recent developments support LibreOffice Online. The approach proved clunky.

We looked at document management systems. A slick idea but overkill for a tiny business.

We looked at other wikis and narrowed the list to those that supported visual editors that hide markup. We further reduced the list to those that supported flat files. The idea that everything needs to be stored in a database just needs to die.

DokuWiki looked nice and is popular among the geek culture. Yet none of the editors are maintained in a healthy manner.

We ended up choosing FosWiki, which uses the TinyMCE editor. Yet FosWiki is a classic wiki. That is, designed by geeks and intended to be used and maintained by geeks. The FosWiki folks are up front at their web site with listing expected skills of anybody using FosWiki. Basically they expect system administrator skills.

Wikis have outlived their usefulness. Time for something for normal people.

Posted: April 22, 2016 Category: Usability Tagged: General

Next: Free/Libre Software Usability

Previous: Wiki Usability — 1