[Web4lib] Drupal and wikis

[John Fereira]

At 08:13 PM 6/8/2007, Leo Robert Klein wrote:
>Carol McGeehon wrote:
>>I'm interested in the differences between a content management system
>>such as Drupal and a wiki.  I've been asked the question since we are
>>looking at using Drupal for our library web site.  What are the
>>strengths of using Drupal instead of a wiki to develop a library
>>website?  What are the strengths of using a wiki instead of a content
>>management system to develop a library website?
>
>A Wiki is just one way of storing and arranging information.  A Blog 
>is another.
>
>The fact is, it all just goes into a database like any other form of 
>content using a Content Management System.
>
>Drupal can do blogs.   Drupal can kind of do Wikis -- though not 
>that well.  (Drupal's "book" function is Wiki-like.  For an example, 
>see the Drupal Handbook Section: http://drupal.org/handbooks)
>
>I guess where I'm coming from is wondering if a Wiki would really 
>answer the needs of a library website.
>
>I totally have my doubts.  I mean, people go to your site for 
>materials of one kind or another.  They also go for information 
>about news and events.  They might also want ways of communicating 
>with you for more information.  How would the structure of a Wiki 
>serve these people?
>
>I think it'd drive them nuts.
>
>The Wiki only has one trick -- hierarchal arrangement in a very 
>pedestrian way.  It's the new Gopher.
>
>It can be helpful in certain areas (e.g. Research guides).  But very 
>often the presentation of your material, as in choices for a 
>database, require more dynamic treatment.
>
>You might also want an integrated calendar, news items, and some way 
>of dealing with user input as in comments, contact forms, etc.  A 
>system like Drupal can do that out of the box.

So can a wiki.  I use the Atlassian Confluence wiki extensively and 
it has a Calendar plugin, new (blogs), commenting facilities, and can 
pretty much render any kind of content I want.  I have recently been 
using he XMLRPC API to automate content creation in the wiki from 
external applications.   For example, I am working on a large scale 
digitization project and we are dynamically producing "report" pages 
which can include detailed status info for any of the 100,000 books 
identified for the digitization process over the next year.  One of 
the wikis I work with serves as a mailing list archive (it acts as 
just  another address on the list) and archives all of the IM logs 
associated with an open source project I'm involved with.   Both 
Drupal and a decent wiki are extensible such that if a feature isn't 
available out of the box, either someone else has created that 
feature (for example, audio file uploads) and made it available as a 
drop in plugin/module or it's not that difficult to customize a 
plugin to serve a specific purpose.


>Drupal is also highly customizable.  You can design your own content 
>and decide how you want it displayed, arranged, sorted, etc.  It 
>does this through online forms rather than through a lot of 
>coding/scripting.  Of course, you have to figure out the concepts 
>behind the system -- but no pain, no gain.

That, as I see it, is one of the primary differences between Drupal 
(or one of several other content management systems).  A wiki is 
primarily about the collaborative creation of content, presenting a 
low barrier such that anyone with access rights can quickly put 
something up that can be shared and edited by others.  Most wikis pay 
little attention to how that content is presented and may only 
provide a few options for page layout, color schemes, institutional 
branding, etc.   A CMS is much more conducive to being used for an 
departmental or institutional primary web presence.

The other primarily difference found in a good CMS verses a wiki is 
workflow.   For most wikis all content is edited and made available 
in real time.  Most good CMSs have a facility for implementing 
several roles such as "content authors",  "content approvers", and 
"content publishers".   Before content might appear on a final 
production version of the site it might go through several workflow 
steps before it is available to the public.


>Personally I can't imagine developing any site these days that 
>doesn't take after some kind of content management system.  I've 
>been working with Drupal since '04 and got it to do most of what 
>I've wanted without getting too wrapped up in the code underneath.

That's an important feature if one wants to avoid the code 
underneath.  However, someone with extensive programming experience 
I'm not afraid to get under the hood if necessary to produce content 
exactly how I want it.



John Fereira
jaf30 at cornell.edu
Ithaca, NY