Jeremy Smith's blog

Entry Is Labelled

In Need of Personal Wiki Space

A little earlier, I talked about the possiblity of setting up a meta-wiki service where users could go, initialize a generic wiki area, and then limit/allow access to it based on their specific needs. After some research, I have discovered that this is a common need amongst wiki-ers out there; and the term used to describe this type of service is a wiki farm.

It just so happens that one of the (many) projects I am working on could use such a service. The project's goals are to improve the ways the large email lists are handled... more specifically towards students. We want to be able to better target sub-sets of students (undergrads, sophomores, grad students at Weatherhead, professional students at the Law school, etc.); we want more features embedded into the lists (i.e. leverage the feature set of; we want emailers to the list to be able to use their standard email client; we want security so only approved messages go to the list; and we want it to work easily, smoothily, and expectedly.

The first part is better data. We need better, cleaner, more accurate, and more flexible data from the student systems to better identify the roles of a given student. From there, we can start creating the necessary groupings for these targetted emails; and we can start building out the infrastructure that will enable the rest of what we want to do. But first, the data needs to be taken care of.

So, as with any project, I began fleshing out the details of it on our internal wiki. Unfortunately, only people from ITS can access the internal wiki. This project involves persons from the Registrar, Admissions, and elsewhere (especially when we begin exploring the graduate and professional level students). Those people don't have access to our internal wiki. It would be nice if I could just generate a wiki out of thin air and then grant the dozen or so people on the project access to it.

I've had similar requests from others on campus asking if this was possible.

There are a couple of things upfront you need to think about. And, you may run into upgrade issues depending on how you handle it. And, you want to make sure the feature set of the wiki engine you choose is complete enough but not enormously complex (the simplest thing that could possibly work and work well[1]). And, you want to make sure integration with the other large services (portal, blog, main wiki, email, etc.) are in place.

I'm just saying... it could be useful.

1 I just wanted to make an extra comment on the statement "the simplest thing that could possibly work and work well." I hate, and I mean I loathe, software that once you log in to it, it seems like you are staring at the dashboard of a 747. Too many options. Too many buttons that could be pressed. Too many widgets of marginal functionality cluttering up the area. You can't figure out what to do next. I like software that gets out of my way and helps me do stuff. I don't like software that throws its weight on you challenging you at every move "would you like to enable workflow processing?"; "please target the specific project area that your content is subscribed to"; "your project start date is greater than two weeks in the future, would you like to enable prophesy mode?"; "your document sharing filesystem has global change access available for your primary group's users, would you like to change the permissions?"; etc. Who has time to read 10+ page manuals to just share some basic content with some other people? If it doesn't work as easy as email, I am just going to stick with email; and if I were a betting man (and I am), I would say that I am not the only one.


  1. gravatar

    There is obviously a market. The question is which software to go with. MediaWiki is overkill for such a goal, but exposing users to different wiki syntaxes might be confusing to some.

    The fun part in all of this is integrating the wikis with all of the membership lists that are floating around...

  2. gravatar
    but exposing users to different wiki syntaxes might be confusing to some.

    Mmmm... very true. Heck, I get confused going back and forth between the internal and main campus wikis. The wiki people need to all get together and agree to all user Markdown at the core and extend their wiki syntaxes to tailor to each specific wiki's needs.

  3. gravatar

    If you were using dokuwiki's internal LDAP authentication, it seems like this would be easy. I can easily give people different permissions to different namespaces on the EECS wiki ( It would be nice if I could delegate this authority to a certain person per namespace, but that shouldn't be super complicated.

  4. gravatar

    With the internal wiki, we use dokuwiki. It uses CAS ( for authentication and the LDAP for authorization.

    I am not *terribly* impressed with Dokuwiki. We've gone through Kwiki, Twiki, and Dokuwiki now. Dokuwiki is the better of that bunch; but I am not completely sold on it.

    I'm also leaning towards a DB backed wiki engine for a service like this. Better backups. Can split of the DB tier from the web tier.

    I don't know. It's all up in the air still. Just thinking about it right now.