Permalink Friday, March 22, 2002
The following was originally posted to David Carter-Tod's Serious Instructional Technology (required reading incidentally) but as it might be generically useful I thought I'd reproduce it here. Comments are welcome, use the link beneath this article.

Here's a little bit more detail about what we've done to develop our Virtual Learning Environment (VLE) using Manila. It may not be relevant to most but it'll outline the thought processes we went through that lead to our decision to use Manila rather than WebCT, our corporate system.

Our course is split into around 50 modules. Each is discreet in that it stands alone as far as content is concerned but overall each module is part of a single programme. Students progress through all modules to fulfil the requirements of the programme.

For me the decision of one Manila site per module was easy. Different module leaders and lead teachers equate to MEs and CEs in Manila. Functionally separate content could be kept separate on the web. As an aside, manila's a fairly lousy collaborative environment once sites get beyond a fairly small number of pages. Don't believe me? Try editing a site with >300 stories and 30 editors when the only story list you have is alphabetized by story title.

So each module team has their own Manila site.

A big breakthrough for us was exploiting browser cookies to devise a shared membership scheme that didn't use Manila's built-in authentication but rather an external membership database. Our users also authenticate against a regular HTTP realm in WebSTAR for all the static content serving. The single log-in authenticates against the realm and sets a browser cookie for shared Manila access.

Once in a module's manila site here's what you'll find. Metadata is supplied using both John's excellent plug-in to give Dublin Core metadata but also our own subject-based metadata that we use for interoperability with other VLEs in other institutions (e.g. See We write our own metadata into a message's table in Manila.

A new project we've developed and are taking further is versioning where the message table is archived every time a story is edited. The editor can restore old versions of a story a la Zope. This is being taken further by being able to version other site content such as templates, navigation, etc.

Much of our teaching & learning content is stored/delivered outside of Manila. So that everything links together I've set up some simple XML-RPCs to link Manila data with external data via subject-based metadata. For example, all learning objects in our system that share the subject content metadata 'myocardial infarction' are linked. This allows us to generate a content-based portal view of our curriculum whereby all related resources are pulled together. By good fortune (or was it good design) the metadata schema we've adopted is shared by other institutions and library-type information services so we're able to interop with these too. None of these other institutions use Manila yet the integration is seamless (e.g. See the example cited above).

The built-in Manila discussion groups and the commentIt plug-in provide valuable pieces of the student aspect of our VLE.

In my opinion it is possible to set up a suite of linked Manila sites that do not necessarily exclude your interop with commercial VLEs though the latter are often less flexible than Manila.

There's a growing user-base of Manila-based VLE developers and a number of new tools such as access control (time release and cohort-based) extend Manila's built-in functionality further.

Our budget? Two Frontier licenses and a lot of my time. Plus the invaluable support of UserLand in developing Manila plus the active developer network.

Training is our big issue as we have to go up against our corporate University MIS team that are offering WebCT as an institutional solution. This is a political battle only as pedagogically there's little contest. The pedagogical neutrality of Manila is a distinct advantage of the constrained commercial systems. Their days are numbered as interoperability renders them obsolete.