A client is interested in using a wiki for internal documentation. After a brief discussion, they installed TikiWiki via SimpleScripts, a nice little service supported by their web hosting company. We were asked to figure out the permissions model and create an area, accessible only to their employees, to house the documentation.
I took a look at TikiWiki’s web-site and was immediately concerned. They have a laundry list of features provided by the software, mostly well outside of the functionality of a wiki: blogs, fora, newsletters, polls, news, bug tracker, etc. In my experience, programs that attempt to do so many things rarely do any of them well. Nonetheless, I dove into the documentation and tried to figure out how to meet the client’s needs.
The first problem was to figure out why an account assigned to the “Admins” group wasn’t seeing the complete navigation menu on the left. It turns out that you have to assign the menu to one or more groups. I assigned it to the Admins group, and voilà, the menu appears. However, when I went back to see if I could assign it to more than one group, the screen provided no indication of the current assignment. That made it difficult to manage things.
Leaving that aside, I moved on to the main goal of figuring out the permissions structure so that I could create a private area available only to employees. First, I reviewed the documentation. Unfortunately, the documentation suffers from a number of issues. One, it is dated. I saw warnings in a number of places that pages needed badly to be updated. Some screen shots were very clearly from earlier versions and didn’t resemble at all what I was seeing in the installation. Two, there are numerous references to differences in versions 1.8, 1.9, etc. The software is currently on version 4. Why are those references still there? If you want to maintain documentation for multiple versions, then please fork it. Don’t make users suffer through all sorts of notes about a release that is several major versions out of date. MySQL does a nice job of this, providing forks for various versions.
Another frustration with the documentation (and the software’s UI) was that some of it was clearly written by people who are not native English speakers and has not been edited by someone who is. While I appreciate that people are giving their time to the project and wouldn’t dissuade anyone from doing so, it’s rather difficult to puzzle out some of the alien idioms or poorly worded translations that inevitably creep in when one is working in a foreign tongue. These can greatly confuse and slow comprehension.
Finally, the documentation, like much open source documentation, has a lot of information on “what”, but little on “how” or “why”. Some pages went to great lengths to discuss theory (e.g. of the permissions structure), but didn’t mention how to implement that theory or why and when to use certain features.
I got as much out of the documentation as I could, and then dove in. I created an employee group, added a couple of accounts to the group, and set the default permissions. So far, so good. The interface lacked helpful hints in many cases (and those that existed were sometimes overly terse or suffered from the translation problems mentioned above), but I was able to figure it out. Then I tried to create a category. According to the documentation, a category is to objects (generic term for wiki pages, blog posts, etc.) as a group is to users. That is, it allows one to group objects and assign default permissions to them. This allows one to avoid having to set permissions on every single page in a private area. Instead, just add the page to the private category. This is when everything ground to a halt. I created it and then tried to set its default permissions. I checked off the boxes for the permissions I wanted. After clicking save, an incomprehensible warning about overriding global permissions appeared. None of the checkboxes that I had checked were still checked. It looked as though my settings weren’t saved, and the only clue was an error that meant nothing. I tried again, just in case I had missed something, but no luck.
What next? Continue to spelunk the fora and documentation? Use Google to find answers? I’m sure that with enough effort I could use this software to accomplish my client’s goals. However, I’d already burned over two hours of time and had only solved one problem. I’m not going to burn any more. Instead, I’m dumping TikiWiki for something else. After talking to the client, I’m going to switch to a program that does one thing and does it well.
) but the user can decide if any feature detail shortcomings are compensated for by the benefits of the all-in-one design. Of course the bottom line is getting the best tool for the job.
