I was following my feeds in SharpReader this morning when I came across this post by D’Arcy Norman at the University of Calgary: Tikiwiki as a “secure” wiki? D’Arcy is exploring the use of a locked-down TikiWiki installation to achieve an environment where the data is more secure. Philosophical arguments of the true nature of a wiki aside, this is something that we have been wrestling with at Plymouth State since last April.
After analyzing a number of wiki solutions, we chose TikiWiki primarily because one of the requirements of our project group was that whatever solution we chose had to be PHP-based (which at the time ruled out MediaWiki which stated it was PERL-based) and allow us to ensure that the information that is presented to the campus remains accurate, or “trusted,” in content and that, as required, its availability could be limited to certain specific or targeted audiences.
In deploying TikiWiki as our campus knowledge base we found that we needed to develop access and structure hierarchies.
The access hierarchy was necessary for two reasons:
- We have a number of sub-groups that needed an information repository that was not open to the general public, specifically our HelpDesk who need access to internal processes and procedures that are restriced based on access and/or privilege. As well, some of the information we have is available to our campus consitituents but not to the general public (such as WebCT tutorials that were paid for . Other information is primarily for the internal use of the staff at our HelpDesk and is not available for general consumption (We accomplished this by locking down branches of the tree and restricting it to certain user groups, such as the relatively small group (less than 50 students and staff) that are members of ITS. We are still working out some of the rough spots – specifically how to scale this to larger groups, i.e. all of our faculty, all of our students, just our graduate students.
- We needed a way to empower and distribute content delivery but still maintain editorial oversight to ensure the quality of the articles posted. As such we used the admin feature to develop the roles of contributor, editor/moderator and administrator. The contributor has permissions to add and edit articles, the editor/moderator can rearrange the structure of the articles while the administrator has access to the application itself.
The structure became necessary because we encountered some frustrations with the means by which the app searches its articles. It appears that in order to maximize searchability, the common search terms needed to be embedded within the title of the article. This slowed us down because it meant that we needed to spend more time focusing on the structure of the knowledge base rather than developing the content. As such, we are still waiting to deploy this to our campus as the replacement for the Help Tab in our Luminis portal myPlymouth. We are hoping that this will occur within the next week.
We are not using the wiki as it was originally designed, yet I don’t feel that its value to us has been minimized. Althought I would love to run a side by side experiment where I could compare the trustworthiness and usability of an open wiki v. a closed wiki. But then again that would require time.