Putting Out Fires, Part 4: Setting eLearning Standards

In part 1 of this series, we discussed 10 questions to ask before youstart to modify someone else’s eLearning project. In part 2, we discussed whatto look for once you open the files. In part 3, we discussed basicdocumentation when you finish the revisions and at the end of every eLearningproject.

In this article, the final one of the series, we’re going to switchgears and talk about eLearning standards. When working on a large project withmultiple team members, it is common to have a set of organizational or projectstandards for eLearning courses. These standards make it easier for the teammembers to pick up each other’s work, based on availability.

Why have standards?

Most courses follow a set of standards, whether they are documented ornot, even those developed by one person. Often the standards are derived fromstakeholder or client comments during development or by following a pattern whiledeveloping several courses.

When someone has to revise another developer’s course, if standards arenot documented, then during revisionsthey will likely be missed. When developing a course, keeping a running list ofthe standards or patterns that you follow can be really helpful to someone elsewho has to modify the course at a later date, even if that person is you. Standardscan be documented in an informal Word document, or even a blog or wiki.

What kind of standards should we have?

There are five types of standards for eLearning development projects.

• Structural
• Verbiage
• Visual and Media
• Technical and publishing
• File management

Structural Standards – Curriculaare usually built using a hierarchical structure and most organizations havetheir own naming conventions for each part of the structure. Some people callthe SCOs a “course,” others combine multiple SCOS or modules and a test to forma course.  Whatever you decide to callthe parts of your courses or curricula, it is helpful to document those namingconventions and the structure of the course. Most developers will look for this structure in the course descriptionand at the beginning of each SCO. So thecourse or lesson overview, which is great for learning purposes, is also helpfulwhen making revisions.

Verbiage Standards – Each professionor body of knowledge has its own set of terms comprised of meaning, spellingand proper usage. When you design aneLearning course, you will discover these terms during the content developmentand revision phases and it is helpful to write a glossary as you go.  You may even want to include the glossary inthe course itself. Each organization has its own standards for describing theirproducts and services, including copyrights and registered trademarks. Ifsomeone outside your organization is asked to modify your course, it is helpfulto be able to provide that person with a list of these terms and their properusage. Some organizations also havewriting standards, such as using active instead of passive voice, capitalizingthe first word in bulleted lists, standard transitional phrases and screendirections, etc. Alternatively, you may have set these writing standards foryourself. Regardless, of who set them, when revising someone else’s work, it ishelpful to have these documented, rather than having to go through the courseto try to discover the pattern.

Visual and Media Standards –Most eLearning courses have photos and other visuals that are processed forquick Internet display, as well as a consistent look and feel throughout thecourse. For these images, you should document the file type, maximum width andlength in pixels, and resolution in dpi (dots per inch). If you crop the imagewith rounded corners, or place a shadow or outline on all the images, youshould specify the proper cut, color and style. Videos are processed in a waythat they play properly in a particular authoring tool, window size, LMS or Webserver. At a minimum, you should specify the file type, tool and settings (codecs)that you used to process the videos. It is also helpful to know the source ofthe images, such as the name of the stock photo provider and the original filenames.

Technical and Publishing Standards – As we mentioned inpart 3, it is helpful to have a publishing guide that documents the tool(s),version(s) and publishing settings that were used to develop the originalcourse. It’s best to document thefeatures you used when developing the course. Consider the following:

• If text-to-speech voices were used, which voiceswere used and where were they obtained? If there are text changes, not knowingwhere to get the voice will result in inconsistent voicing within the course.
• For tools that allow variables, such ArticulateStoryline or Adobe Captivate, it is helpful to have a list of of user variablesthat were created and how they are utilized. These variables provide cluesabout the logic and structure of the course.
• Flow charts or branching charts can be very helpful.They can quickly explain the structure of the course and how navigation works.
• If any scripts were written in the tool’slanguage or in other language, such as Javascript, be sure it’s wellcommented.

File Management Standards –One of the most critical tasks in modifying someone else’s work is finding thelatest version of the source files. Oneof the worst things that can happen is that you make edits to an earlierversion and find that earlier revisions are notin your revised version. To preventthis problem, it is helpful to store all the organization’s source andpublished files in one location that can be accessed by anyone who is workingon them. Often course files are found ona PC. This is dangerous, because we haveseen PCs get reformatted when a person leaves an organization and in theprocess, the editable files are lost. Ifyou use a cloud-based storage product, be aware of how the deletion functionworks in that product. We had a situation where the voiceover companyreformatted the talent’s computer and all the shared VO files this person evercreated for us were deleted in the process. We’ve seen organizations assumethat we can edit the files that are in the LMS, and that is just not the case.

We recommend that you standardize your file naming conventions, filestructure and location, so that anyone who is looking for the files can discernthe latest version of the file. We often find ourselves looking at the lastaccess date listed by the operating system, but sometimes this can bedeceiving. As we mentioned in part 3, we recommend putting the course name ornumber and the date saved in all filenames.

We all follow standards, whether we realize itor not. If we can document the standards that we used in each project, thensomeone who comes after us will be more likely to revise our courses in theintended style.