LMS design

1. What and why

I have spent the last couple of years on a project to install a new Learning Management System here at Murdoch University in Perth, Western Australia. As you would expect, we spent time looking at existing products, mainly here in Australia but also elsewhere. This was largely to understand what other universities used, but also to get a feel for what a modern LMS can do, and how such systems are constructed.

I've also been part of discussions on LinkedIn about LMS technology, a couple of which have moved to private email conversations. At some point the question always appeared .. "Well, what should an LMS do?".

Here's my answer to that question. Note though, this is my personal opinion, and not that of Murdoch University.

2. What does an LMS do?

There's an occasionally expressed view that an LMS doesn't actually do much at all. If you make a simple web site, you can use that instead, because that's all the LMS is.

For a naive user, that may be all they see, but like the swan, there's a lot going on under the surface. An LMS is the presentation part of a learning environment, so I would agree that it can look like a web site. But everything on the Internet looks that way, doesn't it? Your bank, Gmail, newspapers and Australian government departments. Just because they all look like a series of web pages doesn't mean there's nothing happening, particularly with your bank.

The LMS has to recognise individual students and record their marks. It has to organise material into a set of units (or courses or modules, which ever term works for you), and present it in an orderly fashion. Some of the material might not be seen by the student until they have completed other parts of the unit, so some form of conditional access is needed.

So, here's my view of the functionality that an LMS should provide. Not all products provide all of these features, but there are people who want to write an LMS from scratch, so this list may help. If I've missed anything, email me and let me know - I'll update this page as comment come back.

3. Functionality

3.1 It's a framework

An LMS works best when it handles the presentation layer and leaves other work to external systems and services. But the framework has to make some guarantees and provide some services itself:

3.2 It has a supported API

This goes with the framework comment above. An API is a series of tightly defined software interfaces which allow other software modules to interact with the LMS and with each other. They describe what the data has to look like and what protocols must be supported by both ends of the interface. And the API must remain supported for as long as the LMS itself survives, even with version changes.

This is really important. If the LMS is going to be supported by other software companies or even individuals writing modules to extend it's capabilities, they have to be sure that the interface they use won't disappear at some point. Or even worse, keep the name and change the data or the protocols.

3.3 It needs authentication

Most LMS environments need users to identify themselves, if only to differentiate between staff and students, and that's what authentication achieves. How identification is done is harder, and the LMS must provide at least four options:

  1. Active Directory - this a MicroSoft product which stores information about individuals and allows them to authenticate. The Open Source equivalent is LDAP (Lightweight Directory Access Protocol) which is almsot entirely compatible;
  2. External database - user names and passwords are stored in a database outside the LMS. This option implies that the LMS can be configured to securely connect to this database, hand over the username and password and get back a true or false indication;
  3. Internal - the LMS itself stores usernames and passwords. So, there will need to be web pages to create new accounts, remove unwanted accounts and allow users to change their passwords;
  4. Single Sign-On - here the LMS would recognise that the user has already authenticated against another trusted system, and not ask them to login again.

3.4 It must support roles for users

At least 3 roles need to be recognised:

  1. Staff - a non-student responsible for managing the way students use the online unit. By default they will also create the online "web presence" for the unit;
  2. Student - someone who is using the system to learn;
  3. Administrator - someone who is responsible for managing the LMS as a software environment.

The LMS should also allow new roles to be created to meet the particular needs of the organisation. Perhaps the person who creates the unit is not always the one responsible for running it, and you may choose to create a unit builder role. The default Staff role could be disabled and replaced by a combination of several roles such as unit coordinator, unit builder and teacher.

3.5 Everything should be a plugin module

If the LMS is a framework then the detailed work will be supplied via plugin modules which use the API described above. The advantages of a module include ease of update, reduced complexity of the core system and the convenience of other options available from third party software suppliers. It means, for example, that if your current content management system is being changed, plugging in a new module to interact with the new one is the only change you should need to make.

3.6 It shouldn't store files

This may be a bit contentious. People quite rightly expect a lot from systems that manage data on their behalf, and it's unreasonable to expect the LMS to do an excellent job of both handling an advanced learning environment and also manage potentially thousands of files.

So, the LMS should not store data, that job should be out-sourced to a suitable repository. There are a lot of data management systems around, and the APIs mentioned previously should be sophisticated enough to allow a supplier to write an interface for a new repository. Depending on the architecture of the repository used, this could rely on one or more of a broad selections of mechanisms - WSDL, SOAP, XML, SQL or JSON. Or something proprietary.

The point though, is that the LMS provides a clean interface for a possibly complex software module which will handle communication with the repository. That way the organisation can take advanage of their current preferred content management system knowing that the learning content will fit in there too.

3.7 It must be configurable

Earlier I mentioned that the term for the quantum of learning varies. At Murdoch we use "unit", other Australian universities use "course", and I have been told that in the USA "module" is often used. The LMS needs to allow this terminology to be configured by the organisation simply and easily.

Some information will need to be configured for the entire installation (like "unit" above), and other things on a per-user basis. Technical information will always vary - the name of the organisation, the Internet domain name, base URL, ports and protocols. Each module will also have it's own configuration settings.

3.8 It must be themed

Schools, colleges and universities have their own logo and their own preferred style for web sites. The LMS will need to fit in with this, and having a theme which can be changed without altering any of the underlying software is the only practical solution.

Staff may need more familiarity with web style sheets than they are used to, or the organisation may employ someone to do the work. That's not important. What matters is that the LMS supports this ability through a mix of configuration and CSS files.

3.9 The cloud

This had to be here, didn't it? There are vendors offering cloud-based LMS products and pointing out the advantages of not having to own or manage your own software environment. And there are advantages, but tread carefully, there are also potential pitfalls.

Using a cloud service means that some client data will be stored off-shore, and there may be local legislation covering privacy issues and protection of personal data. For the vendor, it's vitally important that you provide proof that your system is secure, and that you support independent audit capability.

3.10 Reporting

In addition to providing a set of standard reports (number of units, number of students, number of assignment submitted over a period, etc), two other things should be provided.

  1. Easy creation of additional reports;
  2. Easy extraction of raw statistics so that customers can use other systems to process the data in a way that suits them.

3.11 Cost of ownership

Forget this one at your peril! Overall, the LMS must cost less to own and manage than the financial benefit of having it. Itemise your costs and be as honest as you can. If you don't know accurate numbers, estimate but always to try to be a bit on the high side. And don't forget ongoing costs - license fees and additional staff costs for a new system.

Even if you don't provide the detailed figures for your customers, knowing them will help place the LMS in the market. At least, you have to be sure that it has financial benefits over the competition.

3.12 Documentation and help

You will need documentation for the LMS, particularly for the configuration settings mentioned previously. Users who are new to the software will need some help to get acquainted, at least initially.

But, this is an LMS .. so make all of this available as one or more online training units. For the most part, it will be administrators who need to understand configuration options. Staff and students will benefit from training materials suited to their roles. If all of the material isn't provided with the package, it's going to have to be produced locally, and that's not necessarily a bad thing.

4. Summing up

This ended up bigger than I expected, but it has only touched lightly on the requirements. Creating a new LMS is a big project, and there's a lot to consider if it's going to be a success. Above all, always get the architecture and design right and everything else will flow from there.

If you decide to write a new package, drop me an email, I'd be interested to hear how it goes.

5. Contact me

What have I forgotten? Let me know. Email me