How to run an invisible wiki
February 19th, 2009 by darioBeing pathologically nitpicky about details, I tend to refactor my personal homepage very often. To do this, in the past I used to go through tedious FTP sessions or to hack my changes through the shell.
Since I started to work with wikis I realised how effective a wiki engine can be to invisibly power a website. In this post I’d like to share some tips on how I do this.
As I contribute to the development of the open source wiki engine I refer to in the following examples, this is obviously my software of choice (hint). There is however a range of excellent free software you can use to this aim (provided they have good ACL support and allow you to easily modify the look and feel of the output via CSS, as I’ll show later).
Let me first clear one major confusion about what wiki software is for. One common misunderstanding about wiki engines is that they can only be used to run actual wikis (or web-based collaborative projects such as the Wikipedia). Wiki engines are, on the contrary, simple and flexible tools for maintaining and managing different kinds of non-wiki websites, without bothering with FTP sessions.
The following are common sources of misunderstanding about wikis that typically blur the distinction between a wiki as software and the function of a wiki:
- anyone can edit the content of a wiki;
- wikis look wikish;
Both arguments are false. The truth is that editing privileges in most wiki engines (with some flagrant exception!) can be set on a per-page basis through Access Control Lists. You can then easily restrict read-, comment- or write-ACL for a specific page so that no user other than you, a specific user or more users can access the page.
As to (2), wiki-related features typically include: recent changes links, login links, last edit information, last author information, history/revision links and comments. A simple touch of CSS is sufficient to hide all this information from graphical browsers (not from crawlers and text browsers though, if you want to do this you will have to actually modify the page template!).
For the actual details on how to configure your wiki to enable ACL and hide unnecessary elements from graphical browsers you can read this tutorial.
Here I would just like to suggest three aspects that make wikis a fantastic solution for fast and hassle-free content management:
- they allow you to edit and modify content at the speed of light;
- they allow you to easily embed all sort of contents in a page;
- they allow you to set granular access privileges for specific pages, which is a very powerful solution for collaborative work with colleagues and coauthors;
The screencast below should give you an idea of how easy these three tasks can be made using a wiki.
I hope this is a convincing argument to show the power of an invisible wiki and I look forward to your comments and feedback.
February 19th, 2009 at 7:16 pm
How about using a content-management system?
February 19th, 2009 at 7:25 pm
I am not a big fan of CMS, since they tend to impose too much structure on content. The added value of a wiki, in my opinion, is that it allows you to create new nodes on the fly and to continuously refactor content without any prior assumptions on the right structure. You can still add structure (e.g. using categories) if you wish, but you don’t need to. This is something many people would possibly disagree with.
February 22nd, 2009 at 10:22 am
I was wondering how you get the nice subsections (e.g. tools/latex)? Do you use categories for that? Are the breadcrumbs generated automatically?
February 22nd, 2009 at 3:53 pm
I agree for a simple site they can be excellent. I use them for intranet content management systems where we also have the ability for many users to update pages easily. Instead of complex software imposed rights we just have employees edit only those ares they are responsible for. And it is simply to look back if someone makes a mistake.
Wikis are great tools for maintaining content in house. And while many organizations have realized this, still there is a huge number of organizations that don’t take advantage of wikis in this way. By making it so easy to update information you greatly reduce the amount of information that just never gets updated because it is a hassle to update it.
February 26th, 2009 at 2:23 pm
There’s mail for you, Jo.
March 2nd, 2009 at 9:17 am
[...] recently blogged at AcademicProductivity.com on the benefits of using an invisible wiki to power one’s personal homepage. If this sounds [...]
March 2nd, 2009 at 3:49 pm
I was able to correct my definition of Wiki through here. Thanks!
March 17th, 2009 at 5:35 pm
[...] the same period, I read an interesting blog post on Academic Productivity about using a wiki to invisibly power a (research) homepage by Dario Taraborelli. A wiki seemed to provide a solution to structural flexibility, since it allows [...]
June 12th, 2009 at 10:59 am
[...] people have chosen a wiki for their scientific homepage (Dario posted a tutorial in How to run an invisible wiki). I have considered it myself, although I’m more inclined to use a wordpress blog (post on how to [...]
August 5th, 2009 at 6:03 am
he same period, I read an interesting blog post on Academic Productivity about using a wiki to invisibly power a (research) homepage by Dario Taraborelli. A wiki seemed to provide a solution to structural flexibility, since it allows
December 9th, 2010 at 4:39 pm
[...] dettaglio tecnico per i curiosi. Mi sono ispirato a questa idea e ho usato come motore un wiki “invisibile”, nel senso che il lettore non lo vede ma [...]