Evolution of an e-Learning Developers Guide

"Soon after we were underway, I felt we needed an e-Learning developer’s guide to preserve some of the decisions we were making. The guide would also serve as a job aid for our inexperienced team members, and perhaps would be a central repository for solutions to authoring challenges as we encountered them. ... This story is as much about the development of a new e-Learning shop as it is about the guide itself, since the guide merely documents the decisions or intentions we adopted."

Our e-Learning development “shop” started operating just over a year ago. We’re small: two full-time course developers and one part-time SME/developer.

I had prior e-Learning development training and experience but the other two had none. We develop courses for internal use, that is, for our organization’s 1,200 employees. We license some third party courses, but for proprietary systems and processes, especially when it is important to convey our corporate culture, we develop courses internally.

This includes compliance-type courses, in which we want to portray situations in our vernacular and environment. I have found over the years, and recent research corroborates this impression, that adult learners just do not see the relevance very readily if they can’t picture themselves in the setting.

Soon after we were underway, I felt we needed an e-Learning developer’s guide to preserve some of the decisions we were making. The guide would also serve as a job aid for our inexperienced team members, and perhaps would be a central repository for solutions to authoring challenges as we encountered them. (I’ll refer to it as simply the “guide” from here on out.)

This story is as much about the development of a new e-Learning shop as it is about the guide itself, since the guide merely documents the decisions or intentions we adopted. We treat it as just that: a guide. We want to experiment and learn, so we don’t treat individual elements as rigid standards. Where do you start with a brand new shop, new authoring system, and inexperienced team? I’ve been down this road twice before, in pre-HTML days. Now with all the latitude offered by hypertext and video, not to mention numerous operating systems and display options, it can be very challenging to develop courseware that is instructionally sound and runs reliably.

So, in addition to our own experimentation, I was also searching for a developer’s guide, something that would give us a starting point from someone else’s experience. I found one on the Web that was public domain, got the author’s permission, and then adapted it for our use. The guide continues to evolve as our operation matures. I hope this article and the one that follows next month will help others select guidelines and make decisions that are germane to their environment.

Our guide is like a lagging indicator on Wall Street: We try something such as a screen layout or a particular way to let the user access reference material, and if we decide it’s a “keeper,” we document it. One caveat as you read this article: we don’t claim these guidelines are necessarily correct for your situation, but at least they provide more of a starting point than a blank sheet of paper!

First steps

The HIPAA training requirement hit about the same time we were planning our entry into online learning. (Editor’s note: HIPAA is the Health Insurance Portability and Accountability Act, a US law governing health industry privacy and security regulatory issues and compliance.) We were fortunate enough to find a snappy and concise off-the-shelf course that was both inexpensive to use and easily customizable. This, combined with our CEO’s gracious form of positive reinforcement (company currency at the company store), led to a very positive user satisfaction rating from employees.

Next, we faced a requirement to deliver several compliance- type courses to our entire employee population. We chose an authoring system, did some panic learning, and ... realized we had many questions. After all, there’s nothing more frightening to a writer or course developer than a blank screen. Where do you start? We had questions such as:

• Where do you put the course title? The screen title?
• Where do you put the navigation buttons? Which navigation buttons do you need?
• How do you convey the size and mental model of the course “package” to the learner? Unlike a book, learners can’t pick it up and thumb through it. It got harder ...
• What is a reasonable course length in terms of student contact time and file size?
• How does a development team standardize some of these things while allowing room for innovation and experimentation?
• How do we make the authoring system do the things you need it to?

... and harder still:

• How do we bring the project in on time?
• How do we meet the business owner’s expectations? What are his or her expectations?

As with other start-ups I’ve been involved in, we began with rather simple course formats: present information using text and simple graphics, and test knowledge with True/False and multiple-choice questions. But, unlike previous efforts where the development teams never fully exploited the power of the authoring system, nor even moved very far up Bloom’s taxonomy, I wanted this team to produce really effective training. So, I adapted the guide to serve three purposes:

• layout and format
• instructional design and strategy
• project management methodology

This article will primarily address the first of those three purposes; next month’s article will address the other two.

One of our first goals was to settle on some initial screen and course layout formats. Our team wanted room to experiment since we’re still relatively new at this, so we agreed to follow a building block approach where we documented certain guidelines as we settled on them. We follow those guidelines unless a project seems to require a different approach.

One of the first things we wrestled with was overall course structure. We settled on the following guidelines. (Again, remember that our guide is a work in progress.)

Overall course structure

We have a standard course layout. This layout uses the following screen structure with each course and, if applicable, with each module:

• Title screen.
• Introduction or welcome screen. We begin each course with something compelling (e.g., a startling statistic, a powerful quote, or a compelling story) that will create a tension for learning. This screen provides the learner with the “What’s in it for me?”
• Overview screen. This gives the learner a “picture” of the course, including the estimated completion time, the main characteristics of the way the module works, and any unique navigation or resource features. We repeat this screen for any individual modules that differ from the overall course structure if the changes are not self-evident.
• Specific learning objectives or outcomes. These are stated in behavioral terms: What will the learner know or be able to do at the end of this module?
• Content/presentation. - Use second person, active sentences (you ... do ... this) - Use a friendly, conversational tone - Keep the learner oriented with introductory statements, clear transitions, and summary statements as needed - Limit each page to one concept, procedure or item of instruction, and try to do it in the space of one screen (i.e., without scrolling) - Use consistent navigation features throughout
• Course wrap-up. Summarize the content and tie it back to the terminal learning objective.

Notice that the above screen sequence is totally independent of individual screen design, media, or type of interactivity. It serves as our “author contract” with our employees so they know what to expect when commencing a course. We expect to vary it some over time, for variety, but for now, it serves as a standard course structure.

Navigation

An obvious concern when designing courses is navigation. The learner needs to stay oriented and know what is available in the lesson, how to get to it, what the preferred path through the lesson is, and so on. Here are some excerpts from our guidelines pertaining to navigation:

• What should the first screens say to introduce the lesson?
• Should screen titles state course, lesson, module ... what?
• Where should the navigation buttons go?
• How should we situate a multiple-choice question stem, the choices, and the feedback on the screen?
• What size font should we use?
• How do we simulate a software interaction?
• What shall we use for a background?
• How should we highlight a word on the screen with color, bold font, italics, underline?

Learners should spend time mastering the course objectives, not the course navigation. Navigation must be learner-friendly and must comply with the following guidelines:

• Provide learners with the ability to control all navigational activities.
• Provide clear instructions or cues for all required learner activities.
• Use the term “click” for mouse responses and “press” for specific key responses.
• Navigational elements should be formatted as buttons and should include the following functions:
• Forward (or Next)
• Back (or Previous)
• First (or something like “Go to Start”)
• Exit
• Menu
• Glossary (when applicable)
• Tools (when applicable)
• Help (when applicable)


Note: Other navigational buttons may be added as appropriate.

Generally, we place navigational buttons across the bottom of the screen or at the right edge. The only exception is simulations where we may be simulating the actual software. In any case, we are consistent with placement of the navigation buttons throughout a course. Specifically:

• The navigational buttons should be consistent within each course; all buttons and icons should have a consistent and unique appearance.
• Visual cues such as mouse cursor changes and rollover highlights used on all buttons should be consistent.
• All buttons should be labeled with text, or have rollover text that clearly and succinctly describes what the learner needs to do.
• Buttons should “gray out” or disappear when they are inactive.
• All non-button graphics should have design properties distinct from that of buttons.
• Navigation buttons should be displayed in exactly the same position every time they appear in a course or module (down to the precise pixel size and placement).

Finally, we are consistent about access to ancillary content, bookmarks, and menus.

• Learners should have one-click access to Help, Glossary, Resources, Exit.
• Learners should be able to bookmark their progress in a session.
• There should be three or fewer levels of menus (i.e., module, lesson, and topic).
• Menu items should be in sequential or logical order.

Interactivity

The next thing we addressed was one of the most important elements of online learning: interactivity. As of this writing, I am still digesting some very helpful information from The eLearning Guild’s recent online conference on interactivity, held August 10 and 11, 2006. So we will undoubtedly soon update these guidelines! Sidebar 1 below summarizes our definitions of the various levels of interactivity.

 

 

Interactivity at a macro level

For modules with a test at the end, these guidelines apply:

• Require some kind of learner interaction, nonscored, but with feedback, about every four screens.
• Learners should have two chances to answer each question correctly, and then move on after receiving remedial feedback. (The ToolBook “how to” is our guide for specific coding instructions.)
• Put a transition page before end-of-course scored tests that gives the learner the option of reviewing any or all of the material before attempting the test.
• Use a Module Test Summary page to display test results.

For modules with embedded questions that the learner must answer correctly to proceed, we include an appropriate number of questions at the end of each main point or objective.

The above guidelines are independent of the kind of interaction that is used. Initially we used True/False and multiple choice questions, but tried to make the experience elegant by not merely repeating rote content, but by using scenario-based design that acknowledged some of the real-world “gray area.” Even without fancy graphics or video, learners have given most of our courses a satisfaction rating of 94% “agree” or “strongly agree” that the learning was relevant, enjoyable, and a good choice for online delivery.

Next, we drilled down to describe more specific aspects of the interaction.

Interactivity at a micro level

We provide opportunities for un-scored practice after teaching each concept or skill. We also ensure that practice opportunities are directly linked to learning outcomes (i.e., we pay attention to the verbs and conditions in terminal and enabling objectives). Here is how we address question construction in our guide:

• These guidelines apply to multiple choice questions:
• Use three to five answer choices.
• Avoid giving cues to the correct answer based on structure of the question itself, e.g.:
• The choice with conditions is often the correct answer.
• The longest choice is often the correct answer.
• Use radio buttons when the learner can make only one selection.
• Use check boxes when the learner can make multiple selections.
• For matching items, use a list with one or two more choices than there are answer spaces.

When we scoured the Internet for sample courses upon which to base our own approach, we found a plethora of ways to deliver feedback. Not all of them were instructionally sound, or even very respectful of the learner, in my opinion. So I opted for a pattern that was built into my first authoring system, TICCIT, which was developed by the Mitre Corporation in the 70’s. (Okay, so I’m dating myself.) Our guide describes it this way:

• Important: Here is the preferred sequence and content of feedback for embedded practice items (i.e., not part of the learner’s final course score). The idea is to give the learner ample practice, along with instructional feedback if they don’t understand.
• For correct answer feedback:
• Use “Correct” or a conversational equivalent when the learner answers correctly, followed by a brief paraphrase of the correct answer and explanation why it’s correct. The idea is to reinforce the correct choice and the rationale. Example: “Right on! The whippersnapple goes on first, then the hummersnoogle.”
• If the correct choice involved a subtle or crucial point, point out the factors that make this the correct choice.
• For incorrect answer feedback:
• First attempt: Feedback on incorrect answers should briefly explain why that choice is incorrect, if feasible. The idea is to instruct gently, even on wrong answer choices without giving away the correct answer. Example: “No, something else goes on first before the hummersnoogle. Please try again.”
• Second attempt: Same as above. Then usually finish with “Let’s go on,” and then explain what the correct answer is and why.

Feedback is an area of e-Learning where art meets science. Good feedback is instructionally sound, it conveys an empathetic tone to the learner, it reinforces correct knowledge or behavior without making the incorrect way more memorable, and, when really well designed, it can be an efficient way to deliver content.

Learner feedback/remediation

We recommend these additional guidelines to feedback for embedded practice exercises:

• The tone of feedback should be supportive and instructive. Check it carefully to avoid any hint of condescension. If you use humor in feedback, use it prudently, and test it with members of the target audience if possible.
• Consider providing the learner with a “hint” if he or she answers incorrectly on the first try.
• Encourage the learner to try again. (Again, we use the ToolBook “how to” for programming instructions.)
• Avoid using pointed phrases such as “You are incorrect,” “That’s wrong,” or, “Of course not.” Even if you think a wrong answer is obvious, be careful not to degrade a learner for choosing it. Here are some gentler ways to say it:
• Incorrect
• No, that’s not it
• Nope
• We disagree
• We encourage visual cues (such as a green “3“ for correct and a red “X” for incorrect. Now let’s move from instructional design to the manifestation of courses on screen.

Media guidelines

This section defines the standard “look and feel” for computer- and Web-based courseware. These guidelines maintain style consistency within the following areas:

• Screen Design
• Text
• Graphics
• Animation
• Audio
• Video

Note: Make decisions involving media — especially the use of graphics, video and sound — for instructional design reasons and not just to be flashy (no pun intended). We will strive to learn what it takes instructionally, and what does not work, based on learner evaluations and the literature. This is not to say we will disregard uses of media that grab and hold the learner’s attention — this is a necessary element of effective instruction.

Screen design

We use the following guidelines for general page design:

• Design for a screen resolution of 800 X 600 pixels. This will prevent any user in the TSS (The Scooter Store) network from having to scroll to see a full screen display.
• Establish a specific location for the presentation of instructions and prompts.
• Provide recurring information in consistent locations.
• Provide generous white space to separate blocks of text.
• Avoid scrolling, to the extent feasible. (Note: Research seems mixed on whether users and learners prefer to scroll down a screen in order to save clicks, or if they would rather have the display “chunked” into only what one screen will display without scrolling. We’re taking the non-scroll approach for now, subject to change as we learn more about our audience’s preferences.)

Text

Use the following guidelines for text layout:

• Present instructional information in a top down, left to right format.
• Limit the amount of text on each page; use a PDF format, or link to an external document to display long text segments.
• Use short lines of 40 to 60 characters (maximum of 60 characters) per line.
• Design text layout in short segments or phrases.
• Use bullets, numbered lists, tables, and charts to break up lengthy sentences.
• If bulleted text wraps to a second line, left-align both lines on the text (not the bullet). In ToolBook this is best done using the Bullet Text Level objects in the Action Objects catalog.
• Do not indent paragraphs.
• Left justify text. Do not right justify. Use the following guidelines for text appearance:
• Use consistent color for text and graphics throughout a course and its modules.
• Generally use Arial or Verdana font. (Although I personally like Comic Sans.)
• Use 14-point for the course title. (A given pointsize font is not the same size in our authoring language as it is in, say, a Word document.)
• Use 10-point bold for subheadings (page titles).
• Use between 10- and 14-point font for instructional text.
• Use Verdana 8-point for instructions within the instructional area of the screen.
• Use Verdana 8-point for learner prompt text at bottom of screen.
• Break up blocks of text to make it easier for the learner to scan the content.
• Underline hyperlinks only; glossary words should be hyperlinks.
• Use bold font to emphasize a word or phrase.
• AVOID USING ALL CAPITAL LETTERS or underlining to emphasize words or phrases (reserve underlining for hyperlinks).
• Use standard Web conventions for hyperlinks (not yet selected, currently being selected, already been accessed).
• Do not use blinking text or repetitive animation.

Graphics

Use the following standards for illustrations and photographs:

• Use the standard color palette prescribed by IT.
• Use colors that accommodate color-blind learners.
• Aside from portraying objects or scenes realistically, use color judiciously for two purposes: - To give the course a certain overall “look and feel” - To highlight or draw attention
• Establish and maintain a convention for the use of color(s) to denote meaning.
• Maintain a constant perspective in a series of 7 visuals, i.e., if showing an overall view of an object prior to zooming in on a particular component, shoot both shots from the same angle.
• Avoid graphics that are trendy, or that may become outdated in a short time.
• All text within the graphic must be readable. If you need to scale down the graphic, then there should be a “click to enlarge” feature.
• Be consistent with all graphics (with the use of borders, effects, and quality).

Animation

We do not use animation in our courses just because we’re not there yet. However, when we do, here are some initial guidelines we intend to follow.

• Allow the user to control the start of the animation.
• Avoid timed effects. (If one or more events are to launch on a page, the learner should trigger the event. Do not time events to launch.)
• Do not use blinking graphics or text.
• Use special effects only when required for emphasis or transition.
• Do not use any special effects that detract from learning.
• Use animation when you need motion to help convey concepts that would otherwise be difficult to describe in words alone.

Audio

We use these guidelines:

• MP3 file format is preferred (optimizes file size and audio quality).
• Use audio judiciously (e.g., to demonstrate interpersonal skills, to demonstrate sounds heard on the job, to engage the learner — such as providing a talking coach).
• Aside from verbatim text intended to correspond with audio for accessibility reasons, text that supplements audio narrative should normally appear as bulleted highlights. Bulleted items may include slight paraphrasing as long as key words are included to help the learner stay oriented.
• Ensure that audio volume levels are consistent throughout the course.
• Provide an audio “Replay” button as a minimum, with a full control panel preferred.
• Use only one voice talent throughout the course. Exception: If needed for role-playing, multiple voice talents may be used, but roles must be consistent.

Video

These are our video selection guidelines for courseware:

Use video to reinforce, clarify, or emphasize a specific behavior or performance objective that you cannot effectively teach using graphics, stills, photographs, or animation. Also use video to add personal interest, e.g., to put emotion into soft-skill or compliance scenarios.

• Do not use continuous video clips (clips more than 15 to 20 seconds in length) because of file size.
• Give the learner some control by offering at least a “Replay” button; consider providing a full control panel.
• Because buffering problems tend to hinder streaming media performance, minimize traditional techniques such as zooming, panning, transitional wipes, dissolves, and fast motion subjects.

Next month

Next month I’ll take more of a “big picture” view by showing how our guide addressed our instructional design and project management methodologies. As a bonus, I’ll describe the instructional design behind the development of the style guide itself — after all, it is a job aid!

 

Comments

Login or subscribe to comment

Related Articles