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.
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.
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:
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.
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:
At least 3 roles need to be recognised:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.