Requirements

Introduction

openLCMS cannot be another course management system. Instead, it needs to provide an ecosystem in which specialized projects and functionality can thrive and be shared among partners. To that end, it will provide shared basic services:

  • Authentication and authorization
  • Group management (course units, etc)
  • Interface to administrative systems at different institutions (abstracting away particular implementations)
  • Management of content resources and associated services (storage, versioning, replication, access rights, etc.)
  • Framework for user interface including accessibility, internationalization, and responsive design
  • Grades management (storage, bookkeeping)
  • Analytics and recommender services
  • Sequencing and navigation tools
  • XML parser framework for active documents

Open-Source and Free

openLCMS will be open-source software. All newly written software and utilized libraries and services need to have compatible licenses. The resulting package will be shared for free, so a wide range of collaborators from around the World can join the consortium without unnecessary financial burdens (except cost-of-ownership).

We also believe that open-source technology will contribute to the sustainability of the system, as utilized libraries, packages, and infrastructure components remain accessible and, if necessary, maintainable without the dependence on vendors.

Instructor Time and Effort

Making learning materials available as OERs, as well as using OERs, cannot entail additional training, education, adoption of world-views, or work for instructors beyond simple choices regarding the scope of sharing. Efforts that require instructors to upload or download resources are almost certainly limited in growth potential, since instructors already have plenty enough work and will not be willing to deal with “yet another thing.” Instead, the system needs to become a way to save time and effort; OERs need to be a native and intuitive component of the overall system, with no “last mile” (see Sect. 1.1.1) to cross in either direction.

Data Security

The system needs to fulfill the requirements of European, US and Swiss legislation. This is in apparent contradiction to two other expectations:

Life-long Learning Users should be able to carry their data and materials from institution to institution.

Dynamic Metadata As already briefly discussed in Sect. 1.1.1 (page 7), the system needs to learn more about the entrusted content materials from its usage.

The necessary infrastructure to overcome these challenges needs to be part of the system design from the start, and it will be discussed in more detail in Chapter 5 (page 28). Key will be the user’s ownership of his or her own data, and the ability to grant and remove institutions’ access to personal data on a granular level.

Scalability

openLCMS needs to scale with number of users, number of content resources, number of membership institutions, amount of incorporated functionality, and last-but-not-least, workload. Educational systems can experience large peaks of workload due to homework deadlines and examinations. It will essential that additional hardware resources can be easily and quickly added to the network, and that bottlenecks due to storage and transaction management are minimized. 

An important feature of openLCMS will be that session-management is largely client-side, and that the majority of system services are stateless. This feature also increases perceived responsiveness of the system, as users will experience almost immediate reactions to their actions — particularly in examination situations this avoids stress and user-driven reloads that can drive systems into tailspin scenarios. While this paradigm is developing into the industry-standard, there are still competing frameworks to chose from, e.g., AngularJS

Another important feature will be content and functionality replication, so providers of much-in-demand OERs will not be stuck with serving them to all users. Content replication had already been a defining feature of the model system LON-CAPA.

Modularity

The main concept behind openLCMS’s modularity (and extensibility) will be classes of services (Chapter 4 on page 25), in which functionality can be encapsulated and added in a secure way. These may include external services, virtual machines, and containers, which register themselves in the system. Particularly containers can be shipped and replicated between installations to deploy securely encapsulated functionality.

Communication with services will be accomplished using stateless protocols, including web-services with RESTful APIs and OAuth2, as well as industry-standard LTI. Documents and data will be exchanged using open formats, namely XML for textual documents and JSON for structured data exchange. While this approach may come at a performance-cost (compared to traditional software APIs), the advantages in security, transparency, maintainability, and flexibility appear to outweigh it.

No Single Point of Failure

The system is distributed as a network of servers with different functions, similar to the LON-CAPA system:

Access Servers frontline machines that directly host user sessions

Library Servers database backend servers, which store user and course data

Special Service Servers machines that provide special services such as analytics or recommendation functionality

Responsive/Adaptive Design

openLCMS will need to run on a wide range of devices, including those not yet available. Of particular interest are mobile devices, as learners (and even some educators) expect to be able to work anytime, anywhere. Building Apps would be one approach (and certainly possible due to the usage of web services), but increased usage of responsive design will decrease the need for maintaining and supporting several interfaces by following a one-web philosophy.

Accessibility

The interface needs to be compatible to the W3C Web Accessibility Guidelines. Beyond navigation and other mechanics, this includes content essential to STEM learning, e.g., formulas, graphs, and diagrams — openLCMS will natively support rendering of such content.

Internationalized

The system needs to be internationalized throughout (including right-to-left reading direction). To that end, encoding throughout the system should be UTF-8. The system will also need to support multilingual content, where the same source file contains several languages. Switzerland as center-of-development is almost ideal in this respect.

Data-Driven

The system strongly relies on dynamic data, i.e., data gathered during usage. Through Educational Data Mining and Learning Analytics, it provides recommendation to both learners and educators. This is in contrast to static metadata or pre-fabricated learning paths with anticipated “hard-coded” decision points. 

The strategy entails frequent, formative assessment, which is why a robust assessment engine (Chapter 8, page 37) is an essential component of openLCMS. At the same time, this strategy entails careful design of the flow of data, so the privacy of the learners is guaranteed, and it must guard against perceiving learners as “data sources” — the goal is to support learning, not exploit it for ulterior motives.

Quality Control

The majority of the assets in the system will be authored by educators. Most of these educators, who are actively teaching, are unwilling or unable to submit comprehensive curricula, but are willing to add assets to an existing critical mass of applicable assets, and expect return on their investment by being able to immediately use their new assets in the context of the existing ones — this requires rapid publication mechanisms. Thus, early on, a decision was made that there is no formal review mechanism in order to not create bottleneck situations. In traditional library systems, a staff of librarians can address the associated quality control and metadata challenges, however, in an open-source freeware system like openLCMS, other automated mechanisms needed to be implemented:

  • Only bonafide institutions, whose authenticity and integrity have been verified by a board, are admitted as members in the shared asset pool.
  • Authoring access is generally limited to instructors at member institutions, which has the positive side effect of establishing some basic quality control.

Advanced STEM Functionality

openLCMS, being developed in part by a technical university, will offer advanced STEM functionality. This is reflected in the Assessment Engine (described in Chapter 8, starting on page 37), as well as the incorporation of other open-source frameworks such as Jupyter Notebooks (including grader-functionality) and tools such as R, Octave and Maxima.

Content Compatibility

All content needs to be able to “run” on all installations of openLCMS. This is supported by the services strategy, so content can “order” the availability of the functionality needed to run it; “write (content) once, run (serve/render) anywhere” is enabled by a “bring your own” approach to system functionality.

It also includes backward-compatibility of content, so that content once contributed to the system continues to be available (versioning of services); authors will stop investing into systems that do respect the time and effort put into creating resources by deprecating functionality between versions. Naturally, infinite backward compatibility meets its limit by the demise of client-side functionality; client-side Java and Flash are examples of this. Where possible, calls to certain plugins should be abstracted by the provision of XML-tags, which server-side can be translated into the specific calls (more in Chapter 8, starting on page 37).

Content Decontextualization

To foster reusability and remixability, content needs to be free from the context of particular courses. Learning content needs to be decontextualized, which includes two requirements:

  • All navigation should be left to the interface of openLCMS or the CMS into which it is integrated, generated dynamically by tools to assemble the content. This strategy allows reusage and remixability of content at various levels of granularity.
 
  • The content may not (beyond reasonable defaults) determine point values, maximum number of tries, etc. In particular, dates (opening times, deadlines, etc) may not be part of the content. Instead, it needs to make available a list of all adjustable parameters, which the course interface can receive and make available for adjustment. Such parameters should be affecting only particular usage instances, so if the same resource is used multiple times in the same course, it can have different parameters.

Institutional Integration

openLCMS will need to be integrated with existing institutional constructs. This includes Authentication, Authorization, as well as other services. Some of these integrations may be as simple as importing a database, such as in the case for test results, but others may be more complex, as shown in Figure 2.1. Integration will vary with each institution, because each institution may use different services.

 

At least initially, one of the most important institutional integrations will be with existing CMSs via LTI.

Figure 2.1: openLCMS will use different methods to integrate all existing services into the system.
Figure 2.1: openLCMS will use different methods to integrate all existing services into the system.