In part 1 of this series, we discussed 10 questions to ask before you start to modify someone else’s eLearning project. In part 2, we discussed what to look for once you open the files. In part 3, we discussed basic documentation when you finish the revisions and at the end of every eLearning project.
In this article, the final one of the series, we’re going to switch gears and talk about eLearning standards. When working on a large project with multiple team members, it is common to have a set of organizational or project standards for eLearning courses. These standards make it easier for the team members to pick up each other’s work, based on availability.
Why have standards?
Most courses follow a set of standards, whether they are documented or not, even those developed by one person. Often the standards are derived from stakeholder or client comments during development or by following a pattern while developing several courses.
When someone has to revise another developer’s course, if standards are not documented, then during revisions they will likely be missed. When developing a course, keeping a running list of the standards or patterns that you follow can be really helpful to someone else who has to modify the course at a later date, even if that person is you. Standards can 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.
- Visual and Media
- Technical and publishing
- File management
Structural Standards – Curricula are usually built using a hierarchical structure and most organizations have their own naming conventions for each part of the structure. Some people call the SCOs a “course,” others combine multiple SCOS or modules and a test to form a course. Whatever you decide to call the parts of your courses or curricula, it is helpful to document those naming conventions and the structure of the course. Most developers will look for this structure in the course description and at the beginning of each SCO. So the course or lesson overview, which is great for learning purposes, is also helpful when making revisions.
Verbiage Standards – Each profession or body of knowledge has its own set of terms comprised of meaning, spelling and proper usage. When you design an eLearning course, you will discover these terms during the content development and revision phases and it is helpful to write a glossary as you go. You may even want to include the glossary in the course itself. Each organization has its own standards for describing their products and services, including copyrights and registered trademarks. If someone outside your organization is asked to modify your course, it is helpful to be able to provide that person with a list of these terms and their proper usage. Some organizations also have writing standards, such as using active instead of passive voice, capitalizing the first word in bulleted lists, standard transitional phrases and screen directions, etc. Alternatively, you may have set these writing standards for yourself. Regardless, of who set them, when revising someone else’s work, it is helpful to have these documented, rather than having to go through the course to try to discover the pattern.
Visual and Media Standards – Most eLearning courses have photos and other visuals that are processed for quick Internet display, as well as a consistent look and feel throughout the course. For these images, you should document the file type, maximum width and length in pixels, and resolution in dpi (dots per inch). If you crop the image with rounded corners, or place a shadow or outline on all the images, you should specify the proper cut, color and style. Videos are processed in a way that they play properly in a particular authoring tool, window size, LMS or Web server. 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 of the images, such as the name of the stock photo provider and the original file names.
Technical and Publishing Standards – As we mentioned in part 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 original course. It’s best to document the features you used when developing the course. Consider the following:
- If text-to-speech voices were used, which voices were used and where were they obtained? If there are text changes, not knowing where to get the voice will result in inconsistent voicing within the course.
- For tools that allow variables, such Articulate Storyline or Adobe Captivate, it is helpful to have a list of of user variables that were created and how they are utilized. These variables provide clues about 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.
File Management Standards – One of the most critical tasks in modifying someone else’s work is finding the latest version of the source files. One of the worst things that can happen is that you make edits to an earlier version and find that earlier revisions are not in your revised version. To prevent this problem, it is helpful to store all the organization’s source and published files in one location that can be accessed by anyone who is working on them. Often course files are found on a PC. This is dangerous, because we have seen PCs get reformatted when a person leaves an organization and in the process, the editable files are lost. If you use a cloud-based storage product, be aware of how the deletion function works in that product. We had a situation where the voiceover company reformatted the talent’s computer and all the shared VO files this person ever created for us were deleted in the process. We’ve seen organizations assume that 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, file structure and location, so that anyone who is looking for the files can discern the latest version of the file. We often find ourselves looking at the last access date listed by the operating system, but sometimes this can be deceiving. As we mentioned in part 3, we recommend putting the course name or number and the date saved in all filenames.
We all follow standards, whether we realize it or not. If we can document the standards that we used in each project, then someone who comes after us will be more likely to revise our courses in the intended style.