Your Source for Learning
Technology, Strategy, and News
ARTICLES       RSS feed RSS feed


email print

The State of Authoring Tools: Where We've Been, Where We're Going

by Joe Ganci

July 28, 2015


by Joe Ganci

July 28, 2015

“Are you happy with the state of tools today or do you find yourself wishing you could do more? eLearning is going to be different for accountants and for surgeons. That means the interactions you build should be different. If you ask yourself, ‘What will my tool allow me to do for this audience and this content?’ then you’re asking the wrong question. The real question should be, ‘What is the best approach to have this audience learn and so what interactions should I build?’”

I just hit my five-year anniversary since I started writing monthly reviews of authoring tools for Learning Solutions Magazine. I have appreciated you readers and your feedback very much. During this time, I’ve seen some patterns emerging, both good and not so good, and it’s time for us to step back, take a breath, and discuss what has happened, what is occurring now, and what the future may bring. Not all of this will be pretty, but bear with me to the end. After that, I hope that you will put your thoughts in the comments section below.

Where it started

Many don’t know that eLearning tools have been around for quite some time. In fact, the National Science Foundation funded two authoring tools way back in the 1960s. The first was Plato in 1960 and the second was TICCIT in 1967 (Figure 1). I entered the eLearning world in 1983, while in college, and used TICCIT to create a large Italian course for the university, a project that spanned three years. By that time, both Plato and TICCIT were in full swing and they both had already spawned quite a few other authoring tools.

Figure 1:
The first two authoring tools arrived 50 years ago

Remember that the personal computer revolution started in the late 1970s and of course, over time, PCs have become extraordinarily more powerful. That means that the early authoring tools did not run on personal computers. Rather, they required at least a minicomputer in an air-conditioned computer lab with washing-machine-sized free-standing hard drives that contained a tiny fraction of the memory that your cell phone does now. Learners needed to use dumb terminals, meaning that all of them were attached to the minicomputer back in the lab and that all the power was coming from the minicomputer. Some specialized terminals, such as PLATO terminals, actually connected to mainframes.

The tools we used were not simple: they required some programming talent. Hence, eLearning, which was called computer-based training (CBT) or computer-based education (CBE) at the time, meant that we had teams of instructional designers (IDs), those folks who understood learning theory and principles and knew how to design lessons that learners could experience on a computer, and programmers, also called developers, who would take the storyboards created by the instructional designers, at first typically drawn by hand on paper and later in Word or PowerPoint, and program them on the computer. I found it interesting that instructional designers tended to be more creative, while the programmers tended to be more logical. The two disciplines, when combined well, would result in excellent eLearning.

Yes, that’s right. Even back in the 1970s and 1980s, there was some really good eLearning being created. There were also problems, of course. Instructional designers (nonprogrammers) could not always understand why developers would balk at an interaction they designed. Developers (non-instructional designers) could not always see the importance of the design they were given and would try to change interactions to something simpler for them to program. Arguments ensued, blood was shed, feuds began, wars started.

What happened next

As personal computers became more powerful, eLearning could be created at one’s own desk. I started to notice a pattern at that point and spoke of it in a keynote speech I gave in 2000, both in the United States and in the Netherlands. I called it Two Steps Forward, One Step Back and I described the phenomenon that was occurring wherein each time we leapt ahead with our technology, we had to make some sacrifices as well, at least at first.

For instance, we were happy when we could stop using floppy disks to store our eLearning because we were given voluminous five-megabyte hard drives in our computers. Imagine, five million bytes! That was great, only we found that in those days before ubiquitous networks it became difficult to move our files from one computer to another. Those were the days when you could often see me take my huge desktop computer and big CRT monitor, with keyboard, mouse, and cables, home from the office some Friday nights so I could continue working over the weekend (Figure 2).

Figure 2:
eLearning, circa 1986: PC and laser disc player

We also had great big laser disc players that gave us beautiful full-screen video in our learning, but then the digital video files QuickTime and AVI meant we could do away with those expensive disc players. However, in those early days we were lucky if the digital videos could be larger than a postage stamp.

This progress will continue into the foreseeable future. Most recently, we have seen it in being able to deliver our learning to mobile devices. Two steps forward means that we now can let learners access their learning almost anywhere at any time. One step back, though, because we have to deal with smaller screens.

Tools started to change

Tool vendors saw an opportunity to make their tools simpler to use and started to promote them as being so easy to use that an instructional designer could use them. Developers were no longer needed. Many of these tools were add-ins to PowerPoint, which made sense as by 1991 a lot of storyboarding was already being done in PowerPoint. How cool was it that suddenly, from within PowerPoint itself, you could generate eLearning without having to take that second, expensive step to have a programmer make it work? Only in this case many instructional designers found themselves overwhelmed nonetheless and eLearning lessons started becoming more and more just warmed-over PowerPoint files. Many of those tools disappeared quickly, others stuck around.

When dedicated instructional designers started realizing that they were not putting out the best work, they would work with programmers still, at least to do the “hard parts” of the learning, and those programmers often used Macromedia (later Adobe) Flash to create those parts.

Of course, some tools were still powerful enough to use to create great eLearning (based on an ID’s design). One very popular tool was Macromedia Authorware, the brainchild of Dr. Michael Allen, who wanted to develop a visual version of Plato. (Figure 3) It became the most popular eLearning tool in history, topping the charts from 1988 until 2005 when Adobe shelved the product after it merged with Macromedia. There are still people using it today, 10 years after it stopped being updated, because nothing like it has emerged. Why? Authorware had become a tool that instructional designers could use to lay out their design and do a lot of the initial work, which they did by dragging icons onto a flow line. Authorware also had its own programming language (and later JavaScript) that would allow programmers to create very efficient and powerful interactions. When Authorware folks got together, they would identify as either icon-draggers or code-heads—but by and large they were able to work well together.

Figure 3:
Macromedia Authorware

What is occurring now

Remember that initially the tools were meant for programmers, and later on tool vendors simplified them to make them easy enough for instructional designers to use. When that happened, eLearning standards took a dive. We started seeing many more page-turners and PowerPoint lessons with quizzes attached to the end of those lessons. We started seeing eLearning get a bad reputation. Many of us found ourselves hesitant to tell strangers what we did for a living for fear that they would punch us because of the eLearning they had to endure in their companies.

In the last 10 years, we have seen tool vendors change their tools again, not just to meet changes in technology, such as the need to deliver to mobile devices and the impending death of the Flash web player, but also because many have decided to change the audience for their tools once again. While at one time the tools were meant for programmers and later for instructional designers, now tool vendors sought to convince organizations that they could save a lot of money in a different way.

Let me illustrate this by telling you about a recent meeting with a vendor who wanted to introduce me to their new authoring tool. As I sat in their offices, I said, “Before you start the demo, please know that I truly hope that you are not going to say that it’s a tool so easy to use that any subject-matter expert can use it to create great learning.” The person hesitated, took his hand off the mouse, and said, “In fact, that’s what I was going to say.” What followed was a very good discussion about how they wanted to disrupt the market and offer something truly useful and I am now helping them with my suggestions and guidance as to what features they need to include.

So, yes, this is what is happening now. Very often we hear vendors say that we no longer need instructional designers because the tools are so easy to use that Harry the Engineer can create the engineering course himself, or Susan the Physicist can build that physics lesson herself. The bean-counters in those organizations buying those tools are psyched at all the money they can save by not hiring or contracting instructional designers (and of course programmers) to fill their learning needs. They don’t know, of course, that the resulting lessons are often at the very least anemic and at the worst nothing more than boring text and images punctuated with a Jeopardy game and quizzes. Learners end up expecting their eLearning to be onerous and are resigned to getting through it as quickly as possible and in some cases cheating if they can.

So what can be done?

We are seeing a backlash against bad eLearning emerging as people start to realize what has happened. One problem that has held us back is that most of the work we do is performed under nondisclosure, meant to be seen only by a specific audience within an organization. As such, the general public has not seen some of the best eLearning.

But there is hope. As an example, The eLearning Guild holds an event at all their major conferences where attendees can demonstrate their best eLearning examples and everyone votes on the ones that they find most engaging in different categories. Yes, sometimes visuals sway votes more than great coding, but almost everyone recognizes great eLearning interactions when they see them. This leads them to want to improve their own eLearning. The Guild goes so far as to show the winners online, as they will again in August, and each winner demonstrates his or her sample. This allows anyone with access to see great examples that can help improve their own expectations of what good eLearning is all about. If you haven’t seen these, check out the recordings.

There is also hope that some tool vendors are starting to see the wisdom in providing back-end programming capabilities to their tools, so that once again, as in the days of Authorware, subject-matter experts can use the tools to a level, instructional designers can use them at deeper levels, and developers can get down to the deepest levels to make the learning the best possible.

Tool vendors that are successful today do try to balance power and ease-of-use and not just make their tools extremely easy to use. However, no tool today allows for the power that we used to have and that many of us sorely miss. When we use the tools of today, we anguish over the slowness and the inefficiency by which we have to create lessons. The irony is that, in many cases, this slowness means that it is taking longer to create much of the learning today than it did at one time, so organizations are actually paying more. A good programmer can quickly make lessons that work well but that also are easy to maintain and update in the future. However, in many cases those without programming skills are doing the best they can to create lessons that usually have to be thrown out when major updates are needed, leading to even more money being spent.

Last year the Serious eLearning Manifesto was released (see Based on the work of Michael Allen, Julie Dirksen, Clark Quinn, and Will Thalheimer, it is a set of 22 principles that should guide any eLearning professional to create the best possible work. I was one of the original trustees, and to date over 800 eLearning professionals have signed the pledge. However, it is difficult to hold to the pledge to create the best eLearning possible when you don’t have a tool that gives you the freedom to do so, when you have to compromise your learning design so much that the end result doesn’t work well. I believe that the principles in the Serious eLearning Manifesto are wonderful and it is a great opportunity for tool vendors to improve their tools or create new tools that will help us meet those principles. I suspect that those who do will win over the market.

Are you happy with the state of tools today or do you find yourself wishing you could do more? Remember that the best learning possible takes into account the learner audience, the content to be taught, and the context in which the content is to be taught. That means that eLearning is going to be different for accountants and for surgeons. That means the interactions you build should be different. If you ask yourself, “What will my tool allow me to do for this audience and this content?” then you’re asking the wrong question. The real question should be, “What is the best approach to have this audience learn and so what interactions should I build?” If you look around and realize that your tool can’t handle your needs, find a better one. If you can’t find any tool that can truly deliver your vision of great learning, then urge tool vendors to improve their tools further.

What are your thoughts? I welcome them.

Editor's Note:

This review reflects Joe's view of matters, and is not a Guild position statement. If you see matters differently, please say so in the Comments.

Topics Covered

Appreciate this!

Login or subscribe to comment

Hi, all,

I welcome your comments as I know there are differing views. You know that I write about tools each month and I'm always honest about a tool's strengths and weaknesses, though I don't write about tools that I don't find worthy. That being said, when I say I like a tool today, it is based on its own merits. I base my reviews on what the vendor promotes as to its tool's qualifications and how well it balances the ease of use and power features. I use tools every day and I enjoy the powerful features of many of the tools I use. If I could edit the above article in one way, it would be to indicate that while we are lacking in the powerful scripting abilities of the old tools, new tools certainly do have features that we didn't have at the time. That being said, yes, I do believe that with all the features of tools today that I've yet to find one that helps me push the envelope of what's possible in a way that was as fast as I was able to once. If anyone would like to discuss this with me privately, you can email me at
Joe, nice article (and thanks for the mention of the Manifesto) and big issue. I'd like to put a spin on this statement: "we hear vendors say that we no longer need instructional designers because the tools are so easy to use". This is the problem, to me. The human brain is arguably the most complex thing in the known universe, and yet we don't treat designing for it as the deep science it really is. We are undermining our credibility when we don't represent our expertise as important. And I think our problems with tools won't change until we reset expectations of what it takes to make meaningful learning. Maybe another way to say it is we get the tools we deserve.
Great article Joe! I find that the tools we use for rapid eLearning often become obstacles in the design of effective instruction ( yes we need to keep reminding even instructional designers that eLearning = instruction) and the focus quickly shifts to how do I make this tool work vs what is the design direction I should take for this audience and need. I often wonder whether rapid authoring tools are in large to blame for bad eLearning... the solution might be somewhere between more sophisticated rapid eLearning dev tools or instructional designers developing more advanced dev skills.
Thank you for your comments, Clark and Kazinou!
Great article Joe! I came on the elearning scene quite a bit later just as Authorware was leaving. As a Flash animator (different industry) I leaned to Flash as the main elearning authoring environment. I will also confess I was one of those fanboys defending Flash because of its raw flexibility to develop anything. With the onset of tools specific to the elearning industry, like most, I shifted away from *real* programming because under-the-hood the tool did a lot for me...even today.

I agree with Clark in where the problem lies. It's not about the tool. Never has been. Design starts on paper (figuratively or literally). Design before you Develop. To your point Joe, "What is the best approach to have this audience learn..." is the starting point. Too many IDs start with the tool because of that tool's vendor promises unicorns and rainbows if you buy it. And it is very easy to see side-by-side an elearning project that was *designed* first as opposed to one that was *developed* first and designed along the way.

As for what I'd like to see in tools? More access to the underlying code structure. Whether it be to customize existing elements, or custom program my own widgets I'd like to see some sort of true programming re-emerge. Not everyone is a programmer and even more are not interested in programming. But we has designers and developers need to think "mobile first" and the current stable of tools relies on the vendor's ability to publish an output that's for mobile platforms. Open that up. Let me as a developer choose how to program interactions and behaviors.

Great article! Would love to hear your computer-and-CRT-offie-to-home hauling stories one day!
Thanks, Kevin! I really appreciate it. Anyone want to take an opposing view? Please let us know by including it below.
Joe: a nicely done retrospective, with what I see as the right emphasis: fostering learning, rather than designer pyrotechnics.

I liked that last part so much, the comment I intended here turned into The ooh versus the ah in a post on my blog. -- Dave Ferguson
Hyperlinks in comments don't work? Or do I just not see them?

If they don't work, then the blog post is at, and the title is:

The ooh versus the ah: tools, authoring, and learning
Dave, you're right. Hyperlinks don't work in the comments. Thank you for your comments, and for coming back to type in the URL for your blog!

Bill the Editor
Thank you, Dave! It's great to know there are like-minded folks in the industry, not that I had any doubt about it.
Great article Joe. I had one of those Interactive Video systems on my desk when I was a course author in the late 1980s. (memories)

This is such a huge issue. I constantly talk to people who have been given an authoring tool and told to develop eLearning. They have no ID training, no authoring tool training, no graphic design training, no AV skills. Isn't it strange that the "training" department puts their employees in this position? Then we wonder why people cringe when we say we develop eLearning. Now we have even more work to explain what we do, than we did before "rapid" development tools came out.

I wrote the original article that coined the term "Rapid eLearning," but that term has been hijacked by the tool vendors to mean that a SME uses PowerPoint to develop a course. The original article didn't propose a one-person, SME-driven development process. It was written with a foundation of solid Instructional Design practices.
Hi everybody! I like it:
"It's not about the tool. Never has been. Design starts on paper (figuratively or literally). Design before you Develop."

It means that what we had/have and discuss are just Development not Design Tool.

A good Design Tool is supposed to support what we usually do in mind and on paper, right? An ideal Design Tool should make more: shape our brain/paper-based Design. It can be done only if the Design process is crystal-clarified, unified, formalized, computerized and visualized. That is a strategic Goal.

I am afraid that adding a direct programming function into Development Tool is not a solution, it is rather a step back.

We at iTutorSoft have developed a Design Tool as a part of our Adaptive Learning-Tutoring-Authoring Platform CLARITY. Our Design Tool defines Ontology of Instructional Design, supports any specific Content/Experience representation in a unified Activity framework, which is understood by a run-time Instructional Engine.
A serious Author has option to start from Organizational Activity Analysis, continue with Professional Activity Analysis (revealing Competencies) and finish with Learning Activities blueprints automatically aligned to the above context. The Tool supports Rapid, Serious and any intermediate forms of Design. (It reminds both ADDIE and SAM).

Then Learning Activities blueprints can be passed to Developers for rich interactive multimedia development.

I hope I added some CLARITY into this discussion :-)
One of my biggest disappointments with Captivate 8 is that using the available tools results in a canned feeling with stereotypical actions. I used to love Flash 8 and used tweens a lot to create original animations with variety. Of course, Flash is dying and, besides it had evolved to become a programmers tool. I'm hoping that advanced actions will be my ticket.

I'd also like to point out a couple of open source programs - Synfig and Blender. Both are primarily animation tools but their output can be included in authored courses.
Thanks for the comments, all! I really appreciate it. If you have a tool or know of one that you think I should review and that will put a smile on my face, please contact me!
Excellent article, Joe.

I appreciate Clark Quinn's point and have been a longtime student of cognitive psychology. One of the pitfalls I've seen for many of us IDs is that we design for the tool (as others have mentioned) or for the client writing the checks rather than the learner. It's hard to separate a lot of myth from fact when it comes to understanding how people actually learn and I appreciate Will Thalheimer's efforts in this regard. The biggest challenge I think we face is answering the question, "What is the most effective way to present this content to the learner?" It's only after we've answered that question that the tool of choice becomes relevant. And that's where your expertise comes in very handy, giving us options to choose from.

Keep up the good work. Excellent post.
Thank you, Richard.
This article is great and I totally agree. I'm also very excited about the upcoming DevLearn conference where I'll be showcasing our Conducttr experiential learning platform - intended for instructional designers who want to get under the hood. Now.. you don't need to be a coder to use it but if you like coding then you can take it to another level. We even have an open source mobile web app that you can do whatever you want with while everything backends into our massively scalable experience engine which trackers learner activity allowing you to personalise every experience.
Our origins are in the entertainment business where we started as a tool for building alternate reality games but the past two years we've gained a lot of traction with instructional designers so now we're committing to education and in particular experiential learning.
Incidentally any instructional designers who want to leverage their creation skills can also on-sell their work either as a template or a finished learning experience. This means we can offer a spectrum of functionality from completely off the shelf working learning experiences through to blank page. And we work across platform - SMS, email, social media, web, mobile, wearables etc Any touch point you can imagine as part of your learning experience can we used with Conducttr.
I'm one of the few people (maybe the only one) who has designed and developed courseware for PLATO and TICCIT. TICCIT was interesting, but PLATO supported full interaction and a culture of serious instructional design combined with serious programming flexibility. It eventually detached itself from the mainframe. The ideal, realized only fitfully, was that teachers could actually develop their own instruction. It turned out that few teachers or professors were willing or able to turn themselves into software developers.

I'm now tasked with finding a current development tool for some interactive training and simulation. I've looked around, and the closest I can find are Captivate and Toolbook (with Toolbook not really viable).

So I'm with Joe - I want to find a tool that lets me drop into programming when necessary but still lets the designers work at their level.

- Jessica Weissman
Related Articles