Your LMS "IS" the "MENU"

About 15 years ago I started working with Learning Management Systems. In that time much has changed and a lot has remained the same.  One thing that has remained the same and is often a point of confusion is that when you have an LMS, the LMS is the menu for your course.

In all these years, I have yet to meet an instructional designer or eLearning developer that realizes that the LMS is the Menu!

What does this mena?

When you design a course, it is usually organized as follows for larger courses:

• Course - this is the course name
• Introduction
• Module 1
• Lesson 1
• Lesson 2
• Lesson ...n
• Module 2
• Lesson 1
• Lesson 2
• Lesson ...n
• Module ...n
• Course Summany
• Assessment

A shorter course may be simpler and have the following:

• Course
• Lesson 1
• Lesson 2
• Lesson ...n
• Assessment (there could be an assessment at the end of each lesson and a Course assessment at the end of the course as well)

In many cases, the Instructional Designer and/or elearning developer creates one HUGE piece with everything in it. Or several pieces all launched by a Main Menu embedded in each lesson. This Main Menu then either branches to the section in the piece or launches a separate piece.

Sounds OK, right?

Well, not really...

The whole purpose of the LMS is to:

1. Organize
2. Launch
3. Track, and
4. Analyze

If you structure a course in the LMS as strictly one launchable unit (SCO), you lose the visibility of what the learners are doing. You also lose the ability to analyze completion and performance.

When designing a course that will reside on an LMS, think of the LMS as the Main Menu of the course. Your LMS could be organized as follows:

• Course (the name of the course you will be taking in the LMS)
• Introduction (a short lesson that introduces the material that follows)
• Module 1 (a divider in the LMS that describes the lessons to follow)
• Lesson 1 (a discreet lesson that covers specific information in this Course/Module)
• Lesson 2 (another discreet lesson that covers specific information in this Course/Module)
• Assessment (either a Course/Module/Lesson assessment)

Each Lesson and Assessment can be launched independently of each other. Dependencies can be set up to ensure proper sequencing of the content for the learner (i.e. Intro must be taken before Module 1 is taken. Module 1 needs to be completed before Module 2 is started, etc).

By launching smaller objects (lessons), you now have the ability to track a learner through the Training process and to ensure performance levels are met.

Launching smaller objects also allows for more efficient course design and "chunkable" learning content versus massive courses and lessons. When was the last time you enjoyed seeing "Page 1 of 545" in a course?  Much more palatable for the learner to take smaller lessons when time permits...

It's very easy to define LMS course structures. Once you get the hang of it, it will make your instructional design process much easier as well. Sure, the LMS is not the prettiest of menus, but it does help an organization "organize" learning in a much more productive and digestible format for the learners.

If you have any questions or comments please feel free to post them here.  Thanks!

Tools, tools, they're only tools!!!

As humans we have an instinctual need to belong. Whether it's a tribe, a religion, a team or any of a thousand others entities we can belong too, we like to belong... And so it is with eLearning development tools (or for that matter any kind of software tools).

As with all things, belonging can be a double-edged sword. When people "adopt" software tools and become zealots for the tools, it's usually harmless. But that zeal for a specific tool can also be blinding.

I've been involved with computers since my first programming class in college back in '72 (that's 1972 when computers were huge and speeds were sloooow).  I've worked as a programmer, systems analyst, instructional designer, director, V.P and business owner. I've seen hundreds of tools come and go both in programming and authoring. Attachments to any tool may be hazardous to your mental well-being!

When RELATE became an eLearning vendor, after years of implementing ERP systems, it was quite a change in terms of the quality of software used to develop courses. Tools were not quite at the "professional" level we were used to, but they were adequate.  In those days we used the following tools:

• Macromedia Authorware
• Aimtech IconAuthor
• Allen Communications Quest
• Asymetrix Toolbook

Any of these tools was more capable and powerful than the tools currently on the market. But they all required more expertise in order to be a proficient developer. Knowledge of programming was also a great plus in those days as these tools had programming or scripting languages as part of their toolset.

Wait, wait, before you start screaming that all the current tools also have the ability to write HTML or Flash or whatever, those are external languages to the authoring tools themselves. Proficiency is now needed across many more tools than was needed before...

Today we have tools that seem more watered down in many ways. They are aimed at instructional designers vs. developers, which would explain why the tools are less technical.  Tools like Adobe Captivate allow extension to be written in Flash in the form of widgets, which usually need programmer intervention to make them work. Tools like Lectora can be enhanced using JavaScript, HTML or other web-based programming standards. Again, programming intervention is required.

Ultimately, a tool is a tool. Getting attached to any tool as the "end all" tool is, in today's rapidly changing economy and marketplace, somewhat suicidal.  Of all the tools I mentioned above, only Toolbook is still around and it's largely unused by many. All of the attachments, praises and good capabilities of those tools meant nothing as the markets, or perceptions of the markets by the vendors, changed.

Tools are just that: tools!

If you were building a house, you would have a large set of tools. Many hammers, screwdrivers, saws, drills, planes, wrenches, etc. The more tools you have, the more you are able to deal with tasks at hand in a flexible manner. Less tools would necessitate finding many workarounds and take much more time.

eLearning development is like buying a house. You need graphics, audio, video, text, animations, and something to somehow tie all of that together. One tool can rarely do all of that though some try. For example, if your project requires some soft-skills training you could do a combination of Trivantis and Adobe Captivate. You may use PowerPoint and Captivate. You might use Articulate and TechSmith Camtasia. The combinations are endless.

Yes, you may be able to do all in one tool, but is that one tool the best one for the job? Often, a tool can do everything but in a mediocre way.

Like a building contractor, having lots of tools in your eLearning arsenal is a good thing.  Development today is much buggier than it was back then and rarely does any one tool fit all the needs possible. Some tools require half of your time finding workarounds or fixing problems within the tool. Other tools do more but badly. And not all tools will be around tomorrow.

Budget permitting, get as many tools as you can for your development efforts. Mix and match them. Use the best tool for the job. And above all,  don't become co-dependent or overly attached to any tool. Remember, they're just tools!