As technology continues to be included in courseware, people involved in learning experience development may benefit from conceptualizing and talking about learning experience content separately from players.

For example, for older Flash animations, learners needed a SWF player to see the animation content. For HTML5 animations, the learner needs a browser "player" that is HTML5 compatible so it doesn’t rollback to lesser content. Video content requires a video player. Audio content requires an audio player.

So now extend that concept to include the courseware player. SCORM content needs a SCORM player, a full learning management system (LMS) or an app that works like a limited LMS to play the SCORM package per the SCORM manifest.

Why this conceptual pattern helps is that we can think differently about the content versus how it is rendered for the learner in various players.

For example whether you use a commercial authoring tool or an open source tool like Adapt Learning, your eLearning content may be played on a desktop computer with a large screen size and a browser, or a mobile device with a small screen size and a browser. The rendering of the components on a "page" will vary depending on the device screen size. You may already be using responsive design to design for mobile first and large screens second.

That the “page” is no longer the atomic unit of courseware, especially with mobile learning, impacts how we think about and design training. For two dimensional courseware, "pages" are now constructed by combining a wide range of interactive components in any number and mix required. Players now use a scrolling page layout that adjusts to the screen size. Even HTML5 now has articles as children of pages. Add to that components, and you can adjust the layout as needed. The fixed-position "page" drops from our collective prominent mental model to now mostly on PowerPoint slides and print CSS versions of courseware.

The Adapt Learning courseware breakdown structure is a useful model for thinking of chunks of the courseware. It includes:

  • "Pages" (what a page is has changed with varying device screen sizes)

  • Articles

  • Blocks

  • Components

Another example is 3D immersive environments. The content includes 3D models of things and people as well as messages for the learner to explain their mission and provide tips and feedback. The player for the courseware is typically a game engine viewer. The custom-designed user interface (UI) for your learner will benefit from a UI tutorial so they can gain competence in operating your courseware.

A blended component of a desktop simulation, for example, may need a particular type of software installed to run for the instructor. Content needs a player.

Training teams can benefit from encoding courseware content in a format that can be automatically converted into various output types depended on what is needed, using XML or JSON for example. Today many training groups still use proprietary software to encode the courseware content. If the courseware has a long life cycle, can the encoding from LCMS-1 authoring tool be exported and easily updated for LCMS-2 authoring tool? Does this matter to your organization yet? Will it in the next three to five years?

Agile can be used by both the content development teams and the player development teams.


Line By Line

Here a Little, There a Little, Layer by Layer.

Back to Overview