On Converting Flash to HTML

I received a question from Bob (no, really), who wrote:

I have a question about the newest version of Flash and its HTML publishing option using CreateJS. What do you think of that approach going forward?

I started to write an email response but figured I should probably post it here.

I haven’t been paying much attention to Flash, so I don’t know what the ‘HTML export’ is capable of these days. In general, I’m very wary of converting Flash-based projects to HTML. When Adobe Captivate first released a “publish to HTML5” feature, all it did was convert the SWF animation to a video file, losing all interactivity along the way.

The limitations of the browsers and the HTML5 spec mean you can’t expect a fully 1:1 conversion from Flash to HTML, regardless of libraries like CreateJS. Some of the features found in Flash are still not quite supported in browsers, or might not work quite the way you’d expect. For example, CSS transitions, CSS gradients, and SVG/Canvas support vary widely from browser to browser (though it’s getting better, and there are workarounds aka “polyfills”). Streaming video, which is a breeze in Flash, is not part of the HTML5 Video spec (yet) and is unsupported in browsers. Video and audio codec support is inconsistent. In some cases, devices add new limitations — last time I checked, iOS devices wouldn’t autoplay audio or video in Safari. ‘Play’ couldn’t be scripted, it required the user to press a button.

Publishing to HTML (with the aid of JavaScript libraries like CreateJS) is definitely the way of the future, but I would flip the workflow: use a tool that’s “HTML first”. For my workflow, I always start in HTML then only fall back to Flash if I absolutely have to. I hand-code, but if you want to stick to a WYSIWYG editor, maybe try some of the Adobe Edge products, or go with a third-party product such as Tumult Hype.

If you continue to use Flash as an HTML development tool, temper expectations and test widely, as some things might not work the way you expect when converted to HTML.

And regardless of whether you publish to Flash or HTML, always test the accessibility of your project. Just because it’s HTML doesn’t mean it’s accessible; HTML by nature is more accessible than Flash, but libraries like CreateJS add a lot of complexity to the page, which can easily impact accessibility.

Advertisements

SOAP for SCORM

At DevLearn 2010, Ben Clark and I presented a session named SOAP for SCORM on behalf of LETSI. The topic was the LETSI Run-Time Web Service (RTWS), a proposed modification of SCORM to use SOAP for communication rather than the current JavaScript model. I presented the first half of the session, covering the basic “what” and “why” ideas while Ben covered the technical “how” details in the second half.

This blog post is my attempt at documenting my portion of the session. Bear in mind that there was a lot of Q&A from the audience, and much of the session was ad-libbed. The descriptive text presented below may not exactly match was what in the session, but the gist is there.

If you’re interested in the nitty-gritty technical details, check out the Developer’s Guide on the LETSI website.

The Presentation

SOAP for SCORM: Linking Training Apps to Your LMS with LETSI's Run-time Web Service (RTWS)

 

Learning Education Training Systems Interoperability

Some quick background information on the LETSI organization.

LETSI stands for “Learning Education Training Systems Interoperability”.

LETSI believes in pushing training systems forward through agile, iterative software development. Make things quickly, get feedback, and make changes. In our current Internet age, we don’t have the time to take years developing a spec. Make something that works, then turn it into a spec.

LETSI believes in engagement with standards bodies and vendors throughout the process. If a new technology is to become mainstream, it’s vital to get vendors in on the action. Make them stakeholders and get them involved in the project at an early stage.

Unlike some standards bodies, LETSI is transparent and open — there are no strings attached. Membership is not limited to corporations or agencies. Want to have a say in the future of training technology? Join LETSI and you could be on the conference call next week.

 

What is the RTWS? An alternative to JavaScript

Simply stated, LETSI’s Run-time Web Service (RTWS) is a replacement for the SCORM JavaScript API. There are some other features that go beyond SCORM 2004, but the bulk of the RTWS is focused on replacing the JavaScript communication system with a SOAP system.

 

SCORM API: A JavaScript object in a web browser window

The current SCORM architecture requires that courses be launched in a frameset or pop-up window.

 

Course pop-up window communicates with LMS browser window via JavaScript

The course frameset/window contains a JavaScript-based API that communicates with the parent frame/window (the LMS website).

 

LMS browser window communicates with LMS server/database via JavaScript and server-side scripting

The LMS website typically performs data gets/sets on a database using a combination of ajax (xmlhttprequest) and server-side scripting (PHP, ASP, Java, etc.).

 

LETSI Run-time Web Service: A direct connection between the course and the LMS via SOAP (XML)

The LETSI RTWS changes the architecture to eliminate the middleman (the LMS website), allowing the course to directly communicate with the LMS backend using SOAP. (SOAP can be loosely described as XML sent via HTTP requests.)

 

What does this mean? (and why should I care?)

 

No more dependence on Web browsers

Replacing the JavaScript API with a SOAP system means the course no longer needs to be launched from the LMS. If the course is no longer required to be launched from an LMS, the web browser itself becomes optional, enabling the course to be launched from a variety of environments, including mobile apps, desktop apps, hybrid Web/desktop apps such as Fluid, Prism and Adobe Air, and other software solutions such as virtual worlds and serious games. This effectively makes SCORM’s CMI data model available to almost every software/web-based training solution.

No dependence on the web browser also means the course content can be hosted anywhere, and is no longer required to be stored in the LMS system.

Note: In some prototypes, the course must be launched from the LMS for the first attempt. This is due to registration requirements that are still being ironed out.

 

Better security

The JavaScript API has long been the weakest link in terms of security; it’s easy to hack and can’t be encrypted. Replacing the JavaScript API with SOAP (XML served via HTTP/HTTPS) enables courses to use discreet, secure communication via HTTP POSTs, similar to banks and other sensitive systems. RTWS courses will be protected via a combination of a shared key (a hash stored in both the LMS and the course’s code), user name, user ID, and a secure password incorporating SHA-1 encryption.

IMPORTANT: Since the shared key and the password are contained in the course’s code, the course will only be secure if the developer keeps it secure. For example, using JavaScript to handle your SOAP calls will make your data viewable to the client. If you keep all of the SOAP work behind the scenes using server-side code, your course will be much more secure.

 

Better accessibility

The accessibility benefits of the LETSI RTWS are debatable, but here are some of my personal beliefs about how the RTWS can make a course more accessible:

1. Since the RTWS discards the SCORM JavaScript API, a web-based course can be built to run without without a single line of JavaScript (traditional form POSTS and server-side code can process the SOAP requests). I’m not saying JavaScript is bad, but it’s a fair assumption that in most cases pages that don’t require JavaScript are more compatible with alternative browsing devices.

Also, as a developer, I know first-hand that when JavaScript is *required* for a course, many developers feel they’ve been given carte blanche to go hog-wild with JavaScript; for example, they might use it for interactive widgets that require a mouse (not keyboard accessible) and dynamically update/generate page content using ajax (difficult for screen readers and braille displays). These situations are problematic for people who use assistive technology; by eliminating SCORM’s JavaScript requirement, we can force developers to take a closer look at why and how they’re using JavaScript, hopefully leading to a more accessible course.

2. No reliance on web browsers means a course can be built in a desktop app or other environment that may (or may not) be more accessible than a web site or Flash movie. Of course, this is completely up to the developer, but the possibilities are there if the developer chooses to go down that path.

 

Less restrictive development environment

Under the LETSI RTWS, courses no longer need to be uploaded to the LMS and can be stored on ANY web server. There are several useful byproducts of this:

1. Course manifests no longer need to list every course asset. (Manifests are still required because they contain core data about the course, including the shared secret.)

2. If you’re a course vendor, you can maintain control of all of your course materials and simply provide a link and manifest to clients. No more ZIPs!

3. Since the course materials remain on your server and are not required to run on the LMS server, you’re free to use server-side code (previously a taboo in SCORM).

 

What’s the catch?

 

Requires more work

Despite their often negative reputations, LMSs provide a key service for your SCORM course: a SCORM API with error-checking (including error/debug messages) and behind-the-scenes handling of the CMI data model for you. The RTWS is not currently equipped to provide detailed error messages regarding the use of the CMI data model; if you choose to use the LETSI RTWS in place of the SCORM API, you will no longer have the benefit of the SCORM API’s error messages.

In the RTWS each ‘set’ request is an XML document created by your course and submitted to the server via HTTP. Since your course is creating and submitting the XML, it must use its own logic to determine if there are any errors, such as malformed XML or misuses of the CMI data model. For example, if your course accidentally tries to set a read-only field such as learner_name, you will not receive any error messages. It is up to your course to ensure the specifications of the CMI data model are being followed.

(Hopefully in the near future there will be 3rd-party libraries or frameworks that will provide this logic for you so you won’t have to write your own.)

Also, your course must be using a technology that supports SOAP.

 

Only supports single-SCO courses

The RTWS currently only supports single-SCO courses, and does not support SCORM 2004’s Sequencing and Navigation rules.

On a related note, since the content is being abstracted from the LMS, the LMS’s SCORM “player” will not be available to the RTWS course.

 

http://letsi.org/rtws

You can read more about the RTWS at http://letsi.org/rtws

Reminder: LETSI membership is open to the public. If you’d like help shape the RTWS (or other LETSI projects), join us!

Additional notes and tidbits not covered in my portion of the presentation

  • I briefly demonstrated a prototype I created for Flash-based courses. My prototype uses a modified version of my pipwerks SCORM ActionScript wrapper, allowing developers to simply swap out the pipwerks SCORM class file with a new pipwerks LETSI RTWS class file and still have their course behave as it did with SCORM 2004. This prototype is not available to the public yet, but when I’ve worked out the bugs I will be sure to post a blog entry about it. Stay tuned!
  • The LETSI RTWS is based on the SCORM 2004 (4th Edition) spec and uses the same CMI data model.
  • Because the RTWS uses a new launch approach, support for querying the course’s attempt history has been added to the data model (see GetAttempt and GetAttemptList in the RTWS documentation).
  • Unlike SCORM, a Get request in the RTWS returns the entire data set in an XML file. It’s up to the course to parse the XML and extract the value for a particular CMI element. I’ve whipped up a document mapping the CMI elements to their XML equivalents.
  • A Set request can be partial (set a single or small group of elements) or complete (set the entire data model).
  • SCORM’s Initialize() and Terminate() methods are not currently used in the RTWS.
  • Rustici Software (scorm.com), Booz Allen Hamilton, and Meridian are all creating LMS prototypes that support the RTWS.
  • Rustici Software hopes to fold support for the RTWS into its SCORM Cloud service once the RTWS is ready for prime-time.
  • The ADL (owners of SCORM) are not involved with the RTWS, but they are aware of its existence and are monitoring the situation. In a separate action, the ADL is requesting input on the future of SCORM via Project Tin Can. It is LETSI’s hope that the RTWS, when ready, will be folded into the ADL’s plans for SCORM and that the two will co-exist peacefully.

Make your Captivate movies more accessible

Adobe has a short but useful article detailing how to make your Adobe Captivate movies more accessible.

These are pretty simple (borderline “no-brainer”) steps a Captivate author can easily implement:

  • Add a description to an Adobe Captivate movie
  • Add a description to an individual slide
  • Limit quiz questions to multiple choice, true and false, and Likert scale (short answer and matching question types are not accessible).
  • If you use audio in your project, use Captivate’s closed captioning feature.
  • Ensure the “508 compliance” option is checked when publishing the project (this option is enabled by default). The “508 compliance” feature automatically makes Captivate ‘click areas’ keyboard-accessible.

I haven’t tested how well the accessibility features work, but it’s nice to know that Adobe has made a genuine effort to make Captivate (and Flash) SWFs more accessible. Matter-of-fact, Adobe has quite an impressive “accessibility” section on its website, providing guidance for making almost any Adobe-published media file (SWF, PDF, HTML, etc.) more accessible.

Read the Adobe Captivate article here.

Why don’t more e-learning developers use standards?

Question: Why don’t more e-learning developers use standards?

I don’t know for sure, but I have a number of guesses. Here’s a quick list off the top of my head:

  • Lack of knowledge about standards
  • Confusing or obtuse documentation
  • Competing standards
  • Misconceptions about cost effectiveness
  • Difficulty / Lack of support in development tools

This is a sort of stream-of-consciousness post, so I’m sure I’m missing a few things. Feel free to add your two cents.

Lack of knowledge about standards

It’s my opinion that a large number of e-learning developers are non-technical, or are mid-level techies who came into the field from other areas. Not having a background in web development, many of these developers probably don’t know that using tables for layout purposes is a faux-pas, or realize the power of well-written CSS. Many of these developers probably rely on their e-learning development tools to handle that stuff for them.

And for those who know all about web standards, e-learning standards are a whole ‘nother beast. Being a master with CSS doesn’t mean you’ll easily grasp the depths of SCORM’s murky sequencing features. Which leads us to…

Confusing or obtuse documentation

I like SCORM. I also hate SCORM. Such is life.

There are a number of proposed standards for e-learning courseware, with SCORM and AICC probably leading the way. However, AICC is considered out of date, and SCORM is considered difficult to use. As with many proposed standards, I believe SCORM’s steep learning curve lies largely in the really hard-to-read documentation and unclear examples.

My apologies to those who wrote the documentation — I do think it’s very thorough — but for someone who isn’t familiar with SCORM, trying to get a handle on it by reading those documents is a very frustrating experience. I think Claude Ostyn’s Cooking Up a SCORM and Eye of the SCORM documents were the most reader-friendly SCORM documents available, but with his unfortunate and untimely passing, they probably won’t be updated.

Competing standards

SCORM isn’t the only standard out there. As some of you may recall from my previous post, the IMS Global Learning Consortium (among others) has created a number of proposed standards for the world to use, including the IMS manifest (which accompanies every SCORM course), the Question and Test Interoperability specification, and most recently, the ultra-secretive Common Cartridge proposal.

Having tried my hand at using these IMS standards, lemme tell ya, they are not easy or fun to use. Big disincentive from the start. (The IMS takes inconvenience one step further by making it difficult to even figure out exactly what their standards are.)

The IMS is working on the Common Cartridge Alliance. According to some, it’s a SCORM killer that will revolutionize e-learning courseware.

However, SCORM is much more established, and has been adopted by every major LMS vendor. Assuming the Common Cartridge is as good as promised (and the specification ever becomes publicly available), it will force developers to choose sides.

Backing off of e-learning standards for a minute, what about other competing standards? There are no shortage of standards to choose from: HTML 4 versus XHTML 1.0 (and soon HTML 5 versus XHTML 2.0); Internet Explorer (and its proprietary ActiveX controls) versus Firefox/Safari/Opera/et al, Adobe Flash versus the new kid on the block Microsoft Silverlight, etc.

Making sound choices involves homework on the issues. Oftentimes, I think people make their choice based on ease of use (“does my WYSIWYG editor support it?”) or cost. This is a fair point; after all, we can only do what our budgets allow, right? Well…

Misconceptions about cost effectiveness

One of the biggest arguments against standards and best practices is the amount of time it takes to get up and running with standards.

When it comes to web standards such as valid XHTML markup and CSS-based layouts (separating content from presentation), I think a small amount of time getting acquainted with the techniques pays big dividends in the long run. When using standards and best practices, you’ll spend less time troubleshooting browser compatibility, less time updating the look and feel (external CSS makes it so much easier!), and less effort making the course work in different mediums (standard web browser versus mobile versus text reader, etc.).

Using standards also ensures your courseware will have a longer shelf life.

It’s too expensive to NOT use standards and best practices.

Difficulty / Lack of support in development tools

A hot topic of late is the quality and capabilities of e-learning development tools. Personally, I don’t use them very much except for special needs, such as making animated screen captures in Captivate and/or Camtasia. I normally stick to standard web development tools such as Dreamweaver and Flash Professional.

However, I totally understand the needs of many others out there who don’t have the time and/or expertise to make courseware from scratch; there’s a reason the e-learning development tool field has really bloomed the last few years, and it won’t slow down anytime soon.

But as I’ve mentioned before, these tools most often do not support web standards or best practices. What’s worse, they often completely ignore standards while making the purchaser/user of the software think they’re getting top-notch, state-of-the-art stuff. It’s false advertising, but it’s also effective marketing. Very effective.

I wish the e-learning tools market would shape up and self-regulate! (Riiiight…) Hey tool developers: Use standards because they matter. Use best practices because they’re best practices for a reason. If you incorporate standards and best practices in this young niche market, you could very well find yourself top-shelf in a matter of months. If you were already top-shelf, you could become uber-elite. Think about it.

So what can we do?

I know I keep espousing standards without really giving enough concrete know-how and direction. Honestly, I’ll be the first to admit I don’t have the answers — but maybe together we can do something about it. I’m proposing we create a community-defined set of simplified e-learning development standards that can be viewed more as ‘rules of thumb’ than law.

For starters, a standard like SCORM is very intimidating because of its intricacies and density. Claude Ostyn’s writings were enlightening if only because the first thing he did was show an extremely simple example of a single-page course. His point was that just because SCORM can be used in-depth doesn’t mean it has to be. We can just use it for what we need and ignore the rest. A great example is SCORM’s page sequencing and navigation system; it’s really tricky to figure out, and requires a really complicated imsmanifest.xml file. If your course only has a few pages, or if you already have a decent navigation system worked out, don’t use SCORM’s navigation features. You can still create a SCORM-conformant course (SCO) that will work with any SCORM-conformant LMS!

Got ideas?

So how about it? I’m going to start writing down simple, easy-to-digest rules of thumb that I hope someone will find useful. I intend to provide examples and/or links with every concept. Will you help me? Maybe together we can get this thing turned around.

Building e-learning courses: Should we use e-learning authoring tools?

This post was triggered by BJ Schone’s question “How do you build e-learning courses?

So, here’s my question: How do you build your e-learning courses? Do you build them from scratch (ex. HTML, JavaScript, etc.)? Do you use an authoring tool for the whole course structure?

This is an interesting question. Personally, I use home-grown solutions, not any particular e-learning authoring tool, though I often use e-learning authoring tools such as Adobe Captivate to create some of my animated content.

However, I think before you can really dispense advice which particular development approach is best, there are a number of factors to consider.

Questions abound

Who’s using the tools?

Development tools are generally used for two things: creating new courses and updating existing courses.

Here are two common scenarios for teams creating new courses:

  1. The team is large, with specialists. I know of some e-learning companies who have specialists for each type of project task, with strict orders to maintain the development boundaries: the instructional designer only works on curriculum development, the writer only writes, the web developer only works on the technological elements, the graphic designer only works on graphic elements, the subject-matter expert only provides insight about the topic and is not involved in any technological development tasks, etc. Apparently this makes it easier to subcontract the work and replace or augment team members where needed.
  2. The team is small, with generalists. In most cases, each person in an e-learning development team wears multiple hats: the instructional designer also does some web and/or graphic design, the subject-matter expert writes large chunks of the curriculum, etc. There often isn’t an experienced web developer on the team, so the team may be forced to learn an off-the-shelf program such as Captivate or Lectora just to get the course out the door. Sometimes, if the team can afford it or is in a time crunch, they may hire a subcontractor to do the technical work.

I think situation #1 lends itself to standard web development tools, whereas situation #2 lends itself to e-learning authoring tools. More on that in a minute.

When you get to updating courses, the question becomes: Who is responsible for maintaining the course? If the course is internal, do your coworkers know how to use the software, too? If the course was for a client, are they expected to purchase the development tools you used, and have enough technical expertise to use them?

Is portability a concern?

The portability of the content is an often-overlooked issue. When I speak of portability, I mean portability in three senses:

  1. Portability as a course from one LMS to another
  2. Portability of the content fragments within a course from one course to another
  3. Portability of the entire course to other file formats or mediums, such as XML, PDF, a database, etc.

What about accessibility?

We should never forget that there are a significant number of people taking our courses who may have special needs, including people who may be deaf, blind, color-blind, have low-vision, or other physical impairments (such as limited ability to use a mouse or keyboard).

Where are you going with this?

Buckle your seatbelts, you may not like this statement: Most e-learning tools do not promote the creation of effective courses, do not promote web standards, and do not promote accessibility; they merely make cookie-cutter course development easier for technically inexperienced course developers.

There, I’ve said it. Please don’t hate me.

Let me take a few moments to explain my thoughts on the subject.

Effective courses

Let me be clear: I am NOT saying that e-learning tools cannot create effective courses. However, I do believe that the templatized nature of most e-learning development tools leads many course developers to favor convenience over effective communication and education.

More time is spent on shoehorning course content into templates, and less time is spent on the instructional design aspects of course-building, where you stop and ask “how can I really engage the audience during the course?” (And by ‘engage’ I don’t mean just adding a simple quiz question.) Personally I don’t find the pre-built interactions in many e-learning tools to be very good. And the few that are good tend to be so overused that they get stale fast.

Since many of the developers using these authoring tools are not experienced web developers, they rarely venture ‘outside the box’ with the tool, and tend to stick to the course options presented by the software. Thus, the course developer’s options are often limited to the tool manufacturer’s instructional design preferences and notions of what constitutes a ‘proper’ course. This may lead to a boring, unimaginative course, or even worse, a course that doesn’t meet the needs of the learner.

My gist is that the tool, with its limitations and hard-coded inclinations, often winds up driving the end product more than the instructional designer. This is not unlike PowerPoint’s relationship with presenters, and how PowerPoint templates have reshaped modern notions of what a good presentation should be.

As I see it, PowerPoint presentations became the standard for two key reasons: they make presentations seem more ‘official’ or ‘professional,’ and entry-level users found the software’s templates to be very easy to use.

PowerPoint is not the answer

“Need to create an online course but don’t know how? Our tool allows you to convert your existing PowerPoint presentations into effective, engaging courses in MINUTES!”

This sounds like a dream come true for non-technical people who need to create an online course fast. But let me ask you a question: how many GOOD PowerPoint presentations have you seen that were created by non-designers? C’mon, be honest… we all know that 90% of PowerPoint’s built-in templates are ugly and hard to read.

More importantly, truly effective PowerPoint presentations are secondary (and complimentary) to a good, dynamic classroom trainer. These presentations are often simple outlines, minimalist in nature, designed to focus the attention on the presenter, not the PowerPoint file.

Simply stated, a PowerPoint presentation is designed to display a linear presentation of bullet points. How does a linear presentation of text (perhaps with a few animations thrown in) have any bearing on effective web-based training? Short answer: it doesn’t.

To expect a trainer’s PowerPoint presentation to be an effective online course without the trainer is preposterous. The trainer’s experience, charisma, presentation skills, and ability to fine-tune the course content to the needs of the individuals in the classroom is paramount.

(An ugly little secret in our industry is that quite a few course developers — and clients — don’t care about the effectiveness of the training nearly as much as they care about being able to say the training has been created and is available to the client. But rest assured: If you’re reading this, you probably aren’t one of them.)

e-learning development tools

I’m not implying that all e-learning tools follow the “let’s import PowerPoint!” model of course building, but you can’t deny how rampant PowerPoint-to-e-learning conversion tools have become in our industry. My belief is that our industry (and others) has a fixation on PowerPoint simply because of its ease of use.

The most popular e-learning tools I’m aware of today are Adobe Captivate, Articulate Presenter, Rapid Intake’s FlashForm, and Lectora. What do these all have in common? They’re geared towards users with little or no development expertise. Yes, they’re geared towards the PowerPoint crowd.

Each of the tools has its strengths, and I’m not telling people not to use them. However, I’d like to point out that each of the tools either creates files in proprietary formats (which requires purchasing their product just to make edits), or outputs courseware that doesn’t adhere to web standards and best practices.

What’s the alternative?

Using standardized web development techniques, including writing valid page markup, maintaining the separation of content from presentation via valid cascading stylesheets, and using unobtrusive JavaScript, will free your course from the shackles of a proprietary e-learning development tool format.

The most persuasive argument for using specialized e-learning development tools has been maintenance — the desire for easy updates and not relying on technical experts to handle the editing.

But I disagree; not being tied to a particular tool or proprietary format means that practically anyone with general web development experience will be able to make edits to your course or even create new courses using your system. Millions of people around the world work with HTML, and hundreds of thousands work with JavaScript. I’m willing to bet that the number of people familiar with proprietary e-learning development tools is much smaller, probably numbering in the thousands. It’s a niche.

Maintaining courses built with web standards means you can hire just about any college student or web designer to come in and make changes. It means YOU can make changes if you learn a little about HTML, or use a standards-supporting WYSIWYG editor such as Adobe Dreamweaver. The key is for your course system to adhere to web standards.

ELearning software that outputs to HTML (such as Lectora and ToolBook) do not output HTML documents that adhere to web standards. Same for many homegrown proprietary formats that have caused grumbles in offices like yours and mine. Not only are these courses harder to update, but they’re more likely to have browser compatibility issues and are less likely to be ‘future proof.’ Adobe Captivate is a good example: The latest Captivate SWFs aren’t even compatible with Flash SWFs created in Flash CS3 (publishing to ActionScript 3).

Using standard web technology means you will have the greatest flexibility possible, including the ability to embed rich media (Flash, Quicktime, etc.) whenever you like. It also means your courses will work in the largest percentage of browsers possible, including mobile devices and game consoles (depending on what type of rich media you embed in your courses).

Until e-learning development tools offer greater content flexibility and create courses that adhere to best practices for web design and accessibility, I heartily recommend using standard web development tools in place of specialized e-learning development tools.

Accessibility

Web sites built for any federally-funded project are required by law to meet a certain standard for accessibility. So why don’t we ever hear anyone talk about accessible online courses? No matter how well you think you may know your audience, don’t ever think it’s reasonable to assume no one with special needs will ever take your course.

Accessibility is imperative for a certain percentage of people. It’s a complete downer for another segment of the population, who think making a web page accessible means making the web page boring and free of any rich media. Perhaps this used to be a fair assessment, but not anymore. Many good people have put in long, hard hours making formats such as Flash SWFs and Adobe PDFs more accessible. Plus many alternative web browsing devices can now parse JavaScript, enabling some JavaScript-heavy sites to maintain a reasonable degree of accessibility (disclaimer: it really depends what you’re trying to do with the JavaScript).

What’s even better is that web standards have finally taken root over the last half-dozen years, enabling manufacturers of alternative web browsers to improve their handling of the modern web page. This means that adhering to web standards will take most of the effort out of making your site accessible! You may need to tweak a few things here and there, or put some extra effort into improving the quality of the accessibility — specialized CSS, a little extra markup, and descriptive text are good starting points — but you will have at least met a basic level of accessibility without even trying. This is way cool.

This is yet another reason why using standard web development tools is a good idea, and using e-learning-specific authoring tools may not be the perfect tools their marketing departments would have you believe.

e-learning authoring tools need an overhaul

I understand that it is simply not reasonable to expect all e-learning developers to learn code and create courses using web standards. In my experience, many self-described “e-learning developers” are either instructional designers who know very little about web development beyond using a WYSIWYG editor like FrontPage, or are web developers who know little about instructional design. “Dabblers” are the norm, and I accept it.

With such a large number of non-technical people in what is largely a technical endeavor, who can blame the non-techies for wanting to use an e-learning authoring tool? They’re cheap, they’re easy, and — most importantly — they get the course out the door. The demand is there and is undeniable. Everyone wants better tools that will make their lives easier, even me.

But we can make these tools better. MUCH better. And these better tools can lead to better courses. That’s what we ALL want, right? Isn’t that why we’re in this business?

Based on what I’ve seen, the e-learning tools industry needs to shape up and provide better solutions for its customers. Here are some suggestions.

Make your tools adhere to web standards and best practices.

Make accessibility easier

When creating courses using your product, why not include tools and gentle guidance that aids the developer in making the course more usable and accessible? For instance, you could prompt users to enter descriptive text for any image imported into the course. You could have a warning appear if the user writes a sentence in all capital letters. You could have a tip appear informing the user that the table they just imported should have a long description, and should only be used for tabular data.

Use better markup and styling techniques

Speaking of tables, the documents created by your tool should never use tables for layout! Adherence to web standards means all page styling (fonts, color schemes, etc.) should be handled by external CSS, not inline styles or deprecated font tags. You should also use JavaScript sparingly, and as unobtrusively as possible. Let the page markup (HTML) and styling (CSS) do as much of the work as possible. Avoid browser-specific code, such as Microsoft’s ActiveX, like the plague.

Allow users to export their content into easily reusable formats

If your tool adheres to web standards, it should be easy to export (most) course content to a reusable format such as XML. Allowing users to export their content to XML in turn allows the user to easily repurpose the content for different media, such as importing it into a print-based document format such as Adobe FrameMaker, using server-based conversion tools to create dynamic on-demand PDFs, or syndicating the content via RSS feeds.

Give the developer more flexibility — and encouragement — to try instructional design approaches your design team may not have thought of.

Many courses are designed to be page-turners with a few interactions scattered around. I’ll admit I’ve created my fair share of these courses. Tool manufacturers often promote their built-in templates as meeting or exceeding well-established instructional design principles. Entry- and mid-level developers in this field may actually believe your marketing spiels, and think that your templates are the holy grail. This may be good for your business, but it certainly isn’t good for the person taking the course.

Why not build more navigation and format flexibility into your tool, encouraging the user to think outside the box? Remind the user that your templates are just starting points and the real power of your tool is the flexibility it provides. Adobe Captivate’s success with its branching feature is a good example of how hungry developers are for alternatives to standard, page-tuner-style linear navigation.

Wrapping this thing up

Getting back to BJ’s original question, I use custom home-grown course solutions. This isn’t for lack of wanting a good all-round e-learning authoring tool; I just think there isn’t one out there that meets my needs yet. And until there is, I feel more confident working with standard HTML, throwing in the occasional Flash or Captivate file. I recommend this approach to others because I think it’s the most browser- and platform-neutral method, and opens up the development environment to any web developer without requiring expertise in a niche (and ultimately limiting) e-learning authoring tool.

What do you think?

Wow, OK, I sure didn’t intend to write this much. As you can see I had a few things I’ve been wanting to get off my chest for a while. If you’ve made it this far, you must be interested in this topic, too, so I ask you to kindly let me know what you think. Am I off-base here or what?