The Future of eLearning in Learning Management Systems

• By Samuel G. Scalise
• 02/03/04

Learning Management Systems have quickly become an integral part of higher education. More and more, they deliver essential functionality instead of just serving as distance learning mediums or places to post the class syllabus. Our growing dependence on proprietary systems, however, is complicating research and development in eLearning tools-the portion of Learning Management Systems that deliver discipline -specific content and assessment. It's a Catch 22. Without source code access to LMS, it is challenging to develop sophisticated eLearning tools we need unless we also build the administrative management portion of the LMS from scratch, a costly and lonely venture.

Gartner recently released a survey showing pedagogical advantage as a main motivator for institutions to implement LMS. As more institutions come to rely on eLearning tools as an integral part of teaching-as the tools become mission critical-so too d'es this mean affordable, reliable systems are called for. Stability often means proprietary systems, much as has been seen in other areas of software development.

Unfortunately for education, this is a double-edged sword. The tradeoff for proprietary reliability is often a fairly closed system, diminishing innovation. Many proprietary products are not amenable to high-level customization of eLearning tools, yet we are only at the beginning of the explosion in eLearning and our instructors and researchers need the ability to experiment in LMS to tap potential in their fields.

According to Gartner, eighty percent of institutions planning to implement an LMS product in the next year will use a proprietary product. Of the researchers in eLearning who are developing low-level tools that need to be incorporated into LMS, very few will find their institutions supporting an open system with access to low-level code. These researchers often need access to the LMS via source code level Application Programming Interfaces, not just by passing higher-level parameters. They may also need to make more significant changes to the LMS source code itself.

Open source Learning Management Systems provide better access to code, and the increasing license cost for proprietary software is awakening institutional interest in them. A good open source LMS must provide quality code-level APIs and easily modifiable source code for researchers developing new e-learning modules. At the same time, it should provide separate broader course management interfaces with such institutional data as course numbers, class rosters, and announcements.

This may complicate the one-size-fits-all LMS direction of the industry because it appears that the future of eLearning tools will need to be heavily customized for the unique pedagogical needs of different disciplines. This means that, across disciplines, a chunk of LMS will be shared while other parts need to be novel and customized to the discipline -a classic indication for a modular design.

For example, one of the most innovative and potentially powerful areas of current eLearning research and development is dynamic delivery of content (DDC). In dynamic delivery, different students receive course material, representations, assignments, or exercises customized for their performance level or unique pedagogical needs. An LMS with DDC can assess how each individual student learns best, and what material they need, producing optimized individual learning experiences for each student from multiple instructors and disciplines -a holy grail of education. Experiments in DDC usually use real-time mathematical and statistical analysis to compare student responses with successful progress of similar students to select appropriate materials and adjust in near real time.

Consider a mathematics class with a student roster including reentry students who haven't practiced math in some time, English language learners, and some advanced students. A dynamic content system such as we in the California State University system are currently working on with UC Berkeley Professor Bernard Gifford can quickly determine that the advanced students don't need to do 100 rudimentary problem sets, and instead provide material at higher level. The English language learners may need to be shown more graphical examples instead of word problems, or have metacognitive prompts available in their first language. Reentry students may be provided with tested review materials in select areas of weakness to refresh their memory. Meanwhile, the instructor can be apprised of students' progress and needs before class begins, and receive statistics for further analysis, perhaps even discovering previously unknown factors in successful learning.

Such a DDC system needs to be compiled at a source code level and access custom presentation tools at very high speeds. To build it outside the LMS may cripple its potential capability, and limit the ability of eLearning tools to assess the knowledge base and adjust accordingly. So the core functionality of DDC needs to be built into the kernel of the code, and shared across fields.

Similarly, a chemistry instructor may want to add the ability to draw precise molecular structures within the DDC, an EECS professor may need to add circuit diagrams, or an architecture student may need CAD capabilities. One central environment with every sophistication of drawing tool for every discipline would likely be both unwieldy and expensive. In this case a DDC-enabled LMS with discipline-specific add-on tools through efficient API access to the kernel code might be the answer-commercial plug-ins or extensions, for instance, that might be purchased on an as-needed basis, either by the students for desktop applications or through institutional site licenses.

Suppose the chemistry instructor has been working in artificial intelligence algorithms and has developed a way to automatically score student renditions of balanced chemical equations within the DDC, allowing students to receive real-time hints and feedback in the area of stoichiometry. Performance demands require tweaking the LMS kernel to experiment with this capability. D'es the instructor (1) build an entire LMS from scratch including all the administration and security tools just to add this functionality, (2) build a small stand alone that d'esn't integrate with the DDC and locks students out of other core functionality, (3) demand that the campus IT group support at least one open system, or (4) give up and abandon these potentially very fruitful attempts at innovation and discovery. Fortunately, some dedicated IT pioneers struggle on.

A proprietary LMS is like a municipal bus. It may get you to where you're going but you can't change the route or the engine. A great open source LMS would provide custom access to a car's engine parts so a race mechanic can optimize internals for performance, and a weekend warrior can fiddle with the carburetor. Then they can drive it where they want to go when they want. There are plenty of eLearning mechanics that are experts in their own fields and can probably tune a car to do new things-if we make it is easy enough for them to tinker.