Someone recently posted a blog entry ranting about the use of the term “best practices” in our industry. I understand the frustration with thoughtless pronouncements about best practices, especially coming from people who may not know any better; it will often sound a lot like how mom used to say “eat this, it’s good for you” without really knowing whether it’s true. However, there is a big difference between best practices in terms of learning theory — something that’s difficult to quantify/prove — and technology.

A friend of mine, upon completing his MA in psychology, joked that his degree is the only one you can get where you can’t prove a thing that you’re taught. Learning theory is a form of psychology, and as such, you are guaranteed to run into a gazillion different opinions on how learning occurs: behaviorism, constructivism, cognitivism, yadda yadda yadda. Likewise, you will hear many opinions on what development models to follow (ADDIE vs agile vs something-or-other), evaluation methodology, and perhaps edge-case debates such as centralized learning structures versus de-centralized learning structures (social media peeps, I’m looking at you).

I guarantee these conversations will involve lots of name-dropping and liberal use of the term “best practice.” In these situations, I agree that there is no single answer to ANY of these issues, and context will be king.

Most technical issues, on the other hand, most certainly DO have best practices, and for good reason.

For starters, accessibility is a best practice. Why? Well, because it’s the right thing to do. No one should be denied an opportunity to learn simply because their ears or eyes or arms don’t work like yours do. Establishing a baseline level of accessibility is fairly easy to do, regardless of the size of your budget or your time constraints. For example:

  • For the hearing impaired: Text transcriptions and/or closed captioning for videos and Flash animations are as easy to set up as ever. Free/cheap video players like the Flash video component, the JW Player, and Flowplayer all support multiple captioning standards and make it easy to add captioning to a video. Rapid e-learning development tools such as Articulate Presenter and Adobe Captivate allow you to add captions or notes to your SWFs. (Side note: the text transcriptions for TED talks are an excellent example of what can be accomplished with just a little extra effort.)
  • For the visually impaired: If the content of your course is provided in a text format such as HTML, screen readers can read the text to the end user. What does this require of you? Well, if you use standard HTML, not much… just a little extra care in your layout and alternate text. If you embed an image, video, or animation, provide fallback text that describes the image or what happens in the video/animation. SWFObject (a free system for embedding SWF files in HTML documents) makes this easy to do.
    Similarly, Adobe has been working hard to make Flash Player and Adobe Reader more accessible to major screen readers. What do you have to configure to make it work? Nothing so far.
  • For those who can’t use a computer mouse: Thanks to initiatives like WAI-ARIA and companies like Adobe who are actively building keyboard support into their products, many script-based interactions (such as course navigation, quiz questions, and other activities) can be scripted to work without a mouse. Alternate input devices are often mapped to the keyboard input; if your course can be completed using a keyboard, you’re golden.
  • For the color blind: Accessibility can often be improved simply by adding text labels to color-coded objects and not relying on color alone.

I could go on for a while, but the point is that accessibility is definitely a best practice. It isn’t hard, and it certainly isn’t expensive to make a course accessible. It’s also the law if you receive any Federal funding.

There are definitely other technical best practices for e-learning:

  • SCORM: Technically not a standard but rather a collection of standards, SCORM is a best practice because it ensures your course will work on pretty much every major LMS (if you don’t like SCORM, AICC is equally valid). How can I say with confidence that SCORM is a best practice? Because in the bad old days before SCORM, developers had to spend weeks re-coding courses to work with each LMS’s proprietary code base. Once SCORM was widely adopted, the issue largely went away. No one wants to go back to the bad old days.
  • Valid HTML and CSS: If you write HTML and CSS, ensuring they validate means you know your pages will work in every major browser. We learned this lesson in the Netscape/Internet Explorer wars. Best practices on the web are still evolving; for example, sometimes it’s ok to write CSS that won’t validate if you know the repercussions and your code fails gracefully in older browsers. The best practice is simply that your pages work in most, if not all, browsers.
  • Don’t use proprietary code: See above. If your course uses ActiveX, which is only supported in Internet Explorer, your course won’t work in any other browsers. Almost anything implemented with ActiveX can be implemented using other non-proprietary methods. Again, the best practice is to ensure your pages work in most, if not all, browsers.
  • Follow sensible coding conventions: Well-written code that follows documented — and very well-reasoned — code conventions means your code will likely contain less errors, will be easier to update if the need arises, and will be more future-proof, avoiding expensive bugs like the Y2K bug, which could have been prevented with a bit of foresight. A great example of this type of code convention is Douglas Crockford’s JavaScript: The Good Parts.

There are definitely times when people throw around the phrase “best practice” and are simply talking out of their butts. “Never use yellow.” “Never use clip art.” “Never hire a penguin.” “Never let the learner do X.” “Always make the user do Y.” “Always use ___ format.” “Always use ___ pedagogy.”

Whatever.

Just remember that best practices DO exist, but not in every circumstance.

Similar Posts

4 Comments

  1. Great post Philip. I have been following your blog for quite a while now, it has been very helpful for my work and I finally decided to add my 2 cents.

    Accessibilty is a best practice for web development in general. But when it comes to e-learning, Even if I code everything using standards with accessibility in mind (mostly for visually impared learners), in my opinion, it is an overkill. Here are a few reasons:

    – Most LMS say they are 508 compliant, and most of the time, on the coding side it is, but in most cases, learners have problems navigating through the site with a screen reader. So I can pass hours developping a SCORM compliant accessible course, with all the alternative contents, and when the user loads the course, if he can get there, it loads in a SCORM player. This player usually contains multiples framesets around the content, wich cause problems with most screen readers.
    – Some users with disabilities don’t use javascript, if that is the case nothing works.
    – I develop language training courses, and a screen reader really is not the best thing to learn a second language.
    – You have to level down the technology you use and activity types (i.e: drag and drops, map interactions…) that are not accessible. In the end, you end up loosing the quality in the over all product and learning experience because you are trying to built a “ne size fits all solution” when in many cases, it would be better to either hire a personal tutor for a learner with disabilities or provide them with alternate contents such as brail or digital text books.

    The best solution i found so far to please everyone is to build one accessible version of the course, and another version with more interactivity instead of trying to fit everything in the same course. However, this doesn’t fix accessibility issues inside the LMS, will the learner be able to find the course, register and lauch it? That’s a whole other story.

    It would be great to have an LMS with an alternative accessible version. When a user logs into this accessible portal, it would only show accessible courses in the content repository. So far, I haven’t seen an LMS that offers this. Do you know if this kind of functionnality exists in an LMS?

  2. I’m writing a blog this week about justification for using or not using video in e-learning, and ran across your excellent post.

    Marc, that’s been exactly our experience at GCPLearning. All the engaging interactive elements we designed and took time to develop to reinforce learning were impossible to replicate in any kind of 508-compliant courseware. So we created a second set of the same titles. We replaced drag-and-drop and other mouse-intensive exercises with simpler multi-choice text-based knowledge checks, re-did screens that referred to “the thing to the left of that other thing,” and then double- and triple checked everything with several screen readers and had several friends with various disabilities check everything out and sign off that it was accessible.

    In the end, however, we only have control over our content and not over the LMSs that our clients use – and many that claim to be 508-compliant are still a chore to navigate!

  3. Let’s not forget the “learning” part of e-learning. There’s just too much basic stuff that seem to get overlooked when we’re bending over backwards to meet technical standards. What about “context” “storylines” “relevance” instructionally sound objectives.”

  4. Hi:

    Yesterday, I found your site and, by today, I’m one of your biggest fans!

    I’ve read a lot of useful things here, congratulations for this great job you’re doing!

    Greetings from México.

Comments are closed.