About | Help | FAQ | Special pages | Preferences | Log in

Printable version | Disclaimers | Privacy policy

Understanding the LearnLive system


The LearnLive system: the 50,000 foot view


The image above shows the basic organizational plan of the LearnLive Learning Management and Content Delivery systems. The users of the system are divided into administrators, who enter the system through an administrative interface, and the participants ("students," "learners," "end users") who enter the system through a completely different interface called a University.

You can think of the system as being like a theater: there is the front entrance to the auditorium, where the audience arrives and prepares to watch the play, and there is a back entrance where the actors and technicians arrive, and prepare the play. The university interface is like the "front of the house" and the administrative area is like the "backstage." However, both interfaces are linked together in the same underlying web application.

To continue this analogy, if there is an equivalent to the "play" being performed, it is the program, which you can see in the middle right of the diagram. Programs are created and prepared by administrators and their allies in the administrative area by uploading various kinds of files and other information-- PowerPoint slide presentations, audio, video, handouts, and so forth. Programs can be launched in the Media Player (like the "stage" itself, if you will) by the participants via clicking on items listed in the university interface.

Kinds of users

Administrators: These users create programs, arrange training sessions, track user completion, sometimes monitor compliance, and perform all the other tasks necessary for a learning management system to function properly. If you are reading this article, it is likely that you are an administrator. Administrators enter the system through the administrative interface located at http://admin.learnlive.com.

Participants: are defined as the consumers of the learning experiences offered through the LearnLive system. This is most basic and ubiquitous kind of user. An individual may wear multiple hats in the system, being an administrator and a participant as well. Participants enter the system through http://university.learnlive.com or, http://university.learnlive.com/nameOfUniversity.

Instructors: These are the individuals listed as the "teachers" for one or more programs; you may also think of them as the "actors" in the play. Instructors may also be participants, and they may also be administrators. If an instructor's other roles includes being an administrator, he or she may enter through the administrative URL; otherwise, he or she may enter through the university URL.

Building Blocks of the System

Version 2.0 of the Learning Management System is constructed of four main kinds of building blocks: the program, the catalog, the university, and the company.

A program is a defined learning experience. A program has a name, a description, and other information that describes the learning experience. A program is made visible to end users by being put into a catalog which appears in a university.

A catalog is a container: think of it as a binder, or a bucket, or a box, containing one or more programs. You can use this handy container to move programs around, store them, and affect what users have access to them. Your end users cannot enroll in a program, however, unless that catalog is inside a university.

A university is best thought of as a place, with its own portal, where catalogs are kept and are available for end users to browse. A university has its own url, and its own visual style or color scheme, and can be configured in a number of different ways to serve the needs of your end users.

A company, in LMS v 2.0, is different than a university. A company is a business unit with a contract for using the LearnLive platform.


As you can see in the illustration above, these blocks build on one another to create your overall LearnLive ecosystem. Gather together some programs, add some metadata (restrictions on who can use the programs), and you have a catalog. Gather one or more catalogs together, add some metadata (commencement and expiration dates), and you have a university. Add one or more universities together with some users, and you now have a company.

All these concepts exist in the original LearnLive LMS system, but in Version 2.0, they are more clearly defined, and also more flexible. To illustrate that, let's look at this comparison.


In our current LearnLive system, we use the terms university and company nearly interchangeably. Each company has only one university. In Version 2.0, we've opened that system up, so that, if you like, your company can run multiple universities. In version 1, this was only possible using child companies. In Version 2.0, we've made it easier.

The difference between a company and a university is this: the company defines which administrators can work on a set of programs and users. The university defines the experience that end users have: what programs they can see, how they see them, and what other features they can use.

The possibilities of multiple universities

For example, perhaps your firm runs training for two very different audiences: professional development programs for your own staff, and seminars for your customers. You don't want your customers to have access to browse your internal training materials, and you don't want your associates accidentally signing up for customer seminars that don't get accredited. So you can easily run two different universities, one tailored for the needs of your staff, and the other for customers, and you can still share programs and users between them easily and seamlessly.

Child companies

A "child" company is one that is an extension of another. A child company does not have a unique business contract with LearnLive, rather, one of its "parent" companies holds that contract and the child is an administrative subset of the master, or parent. Earlier versions of the LearnLive LMS made use of child companies extensively. In this version, child companies are still supported, but may situations that currently can only be addressed by creating child companies will be handled more easily through using multiple universities.

Multiple Catalogs

As mentioned above, one can think of a catalog as a container for programs. Catalogs can host restrictions (what in version 1 are called "permissions") on what users can see them. Let's say you have two groups of professionals: "new hires" and "partners."  The partners don't want to hear about or see the programs for the new hires, and the new hires aren't authorized to use some programs that should only be restricted to partners. In the current system, you would need to attach "permissions" to every single program in your one catalog to show or hide it from those groups as the case may be.

In v 2.0, the ideal scenario would be to create two catalogs: "new hires only" (which is only visible to new hires) and "partners only" (which is only available to partners).  Then, each time you create a program, you can add it to whichever catalog is appropriate, and it automatically becomes visible to only those users. This may not seem to be much of a time saver, but consider this: one day, it is decided that the partners should be able to see all the content being used by the new hires. Now, instead of changing the permissions program-by-program, you only need to change the permission on the catalog-- one place-- a task that can be accomplished in seconds, and the change is made.

To get the most out of working with multiple catalogs, they should be used in tandem with user groups. See Understanding user groups for more information.

Multiple catalogs are also an amazing organizational tool for anyone working with multiple universities. Because I can organize my catalogs to appear in some of my universities but not others, I can easily get content distributed where I need it. In the diagram below, if I choose to put "program 1" into universities Athens and Rome, I can drop it into Catalog B. However, if I want that program to go to universities Rome and Cairo, I can drop it into Catalog C. With only three universities and two catalogs, it may not seem like much time saved, but if you are a content provider sharing programs to dozens of universities, the advantage is immediately clear.


Architecture changes and the transition to Version 2.0

If you are an existing LearnLive user just making the transition to Version 2.0, your data will be transferred into the new architecture for you. When you upgrade to v 2.0, your account will automatically contain exactly one catalog which has already been placed into one university. You can continue using a single catalog and a single university if that suits your needs. If you currently make use of child companies, however, you have some more options available when you upgrade to v 2.0. You may want to speak with your account representative and/or one of our specialists to see which configuration option will best suit your needs in v 2.0, and we can customize the data migration in response to your needs.

Retrieved from "http://help.learnlive.com/index.php/Understanding_the_LearnLive_system"

This page has been accessed 7,138 times. This page was last modified on 18 November 2013, at 13:24.

Main pageLearnLive CaptureLearnLive ConnectLearnLive CompassLearnLive ComplianceLearnLive ContinuumCPE Jurisdiction rulesGlossary
My pages
Log in / create accountMore…