In update 4, I gave an overview of some of the modules available for PostNuke, the open-source content management system; modules which could, perhaps, have some educational utility. In this update I want to consider the affordances and constraints of integrating larger components or services into the content management system; those with VLE-like features of their own. Keep in mind that PostNuke is merely my 'base camp' from which I explore and that I'm not necessarily advocating this as the solution. If you want to know more read on! From one perspective PostNuke can be viewed as a content management system. From another it could be viewed as a weblog engine. From yet another it can be viewed as a portal solution. Now the component model that I feel most comfortable with is the one in which a component (module in PostNuke) does one thing very well and doesn't attempt to be a multifunction 'swiss-army knife'. In my view, the asynchronous discussion (PNphpBB2) and Journal modules in PostNuke fit my perspective exactly. I could also add chat and quiz modules. These are modules and not just passive links to functions because the PostNuke infrastructure is aware of their presence … once a user has logged in to the PostNuke environment they are not required to re-authenticate.
Now some clever people have also made it possible to integrate other VLE-like systems into PostNuke, e.g. ATutor, and Moodle. For example, adding a small integration module to PostNuke (pnMoodle) makes it possible to login to a PostNuke site. A click on the pnMoodle item on the PostNuke menu fires up Moodle and using the user's PostNuke login automatically authenticates said user on Moodle. Readers should appreciate that this is a trivial procedure, technically. This is a good thing, right? … Or is it?
Let's get what I consider poor about Moodle out of the way first. I think the standard Moodle interface is dated and is unlikely to become a design classic. A trawl through Moodle sites would suggest the effort to change the default is just too great and so one Moodle site begins to look just like another. On the positive site I admire the conceptual clarity behind the pedagogical framework on which it is based. I think the concept and implementation of an extensible library of 'Activity Modules' is brilliant. So what's the problem? … Surely the user just needs to login to PostNuke click on pnMoodle and off they go!
The problem as I see it is illustrated below (there's a high resolution alternative image).
Here is a high resolution image of the above. (N.B takes longer to display).
The screenshot shows our test PostNuke environment with an embedded Moodle session. Hopefully, although the default screenshot above lacks a little resolution there is enough detail left to illustrate the points that I'm now going to make.
First, I accept that I could have opened Moodle in a separate window but I wanted to illustrate a point which can be obscured by separate windows. We end up with an interface 'Russian Doll' in much the same way that embedding the Adobe PDF Reader in a web page adds another interface layer for the user to adjust to and navigate. Second, PostNuke has similar interface controls to Moodle, but yet these configure entirely different systems. In PostNuke individual modules can have an administrative interface but are always part of the host system. Third, although the single login to PostNuke will be welcomed by users that's as far as the integration goes. In other words apart from the login Moodle and PostNuke are functionally independent and not really integrated at all. Those taking a PostNuke as portal perspective may argue that this is a lot better than most systems and that at least one burden has been taken off the user. I have some, but not total, sympathy with this view.
The question here is how big should a functional component be? As we've seen, it feels appropriate somehow that discussions, journals, chat etc are components, but the issue as I see it is that everyone wants to keep developing systems, the design of which invariably make it too difficult (or impossible) for functional components and resources to be accessed within that system without having to navigate the host system interface. The result is that no matter how much I may like the concept of Activity Modules in Moodle I've got to have the whole interface and administrative caboodle of Moodle or nothing at all. One result is that whilst I may very well have email, online discussion, and chat facilities in my PostNuke driven environment but when I connect to Moodle et al I get them all again! If I'm lucky I may be able to turn some of these replicated functions off, but only if the developer of the other system makes this possible. I may be doing Moodle an injustice here since they may very well have plans to make available functional components … if so let me know.
For Moodle, we could substitute Blackboard, WebCT etc and the result would be the same. In my recent article about ATutor, however, I did highlight how their Export feature did at least allow for manual extraction of content at any level … but we also need to be thinking in terms of export of functionality.
As a past CETIS article has pointed out there is a debate underway as to whether we actually require monolithic VLEs or whether the focus should now become the development of portals with loose-coupled functional components. Now this sound very good until we discover that functional components are being considered at the VLE level! In other words we end up with the institutional or departmental portal passing through to another portal (the VLE). Here are the ingredients for a usability nightmare. It appears like a device for maintaining the status quo.
Instead of just focusing on content reusability and repurposing we would do well to also be thinking about functional reusability and repurposing. For the commercially oriented this should not kill the market indeed it should expand it. Vendors or advocates of monolithic systems are likely to be less supportive but is this necessarily a bad thing?
