I spent a significant amount of time in 2018 and 19 working with elearning authoring tools like Articulate Storyline and Evolve Authoring. Over a decade of experience in university teaching, motion graphics, and growing experience in web development, made the elearning industry a logical fit for this point in my career.
In this article, I discuss some of the hindrances I found while trying to push the boundaries of the rapid authoring tools we used and the approaches I took to overcome them.
During my time at Pure Learning (R.I.P. 2020), rapid authoring tools like Articulate Storyline and Evolve Authoring made sharing projects possible across a team of non-programmers. These tools abstract away the programming languages and endeavour to provide interfaces that allow anyone on the team to contribute directly into the product without needing to be a programmer (Much like WordPress or Squarespace does for websites, or Animate CC does).
On the other hand, working directly with code instead makes any implementation more flexible. With code, any feature you can imagine and build (within budget and timeframe) becomes possible. The product becomes purpose built to your exact design, rather than, as is often the case with rapid authoring tools, your design being adapted to the range of possibilities a tool allows.
Many in elearning haven’t trained to work with code, and instead, focus on a different skill set and bring different expertise. And yet, elearning work often expects you to wear both hats and authoring tools are designed around you doing so.
In our team at Pure Learning, we all had our specialties, and yet the nature of a small team and company meant that we all needed to work beyond the scope of our roles. If only one person understood a particular task, if they left or got sick, the work would be in jeopardy — this added the need of using software that could be accessible to all more quickly, rather than technologies that, while more versatile, might require years of study.
In addition, clients often request content be made in certain authoring tools — Tools they know or have licenses for. The intention is often that this will allow a client to make edits as their needs change in the future (or when new stakeholders inevitably appear with new opinions), without the need to continually enlist a developer.
Sidenote:
While that’s often the client’s intention, I’d be interested to hear how often clients do end up editing their own files(and how well they manage).
As a coder myself though, I was perpetually frustrated by the inability of the authoring tools to customise interactivity in ways that I knew would communicate concepts more clearly to the end user, or customise the project setup in ways that would make it significantly better for the developers.
As an animator, I was also perpetually frustrated by the limitations to refining or recreating common animation techniques.
Animation and interactivity techniques that I knew where simple to achieve in other programs became impossible or complicated in the tools we were using — Like parenting and intuitive easing in animation, customising device responsiveness, or modularisation of aspects for reuse across a project (to name only some big easily describable things).
I also found myself frustrated by the low expectations of the software in the industry. One example involved a discussion about considering Animate CC as a development alternative for certain jobs, and fielding the question “But does Animate CC do branching” — Branching; A software ability so basic that it never occured to me to point out it was possible.
Sidenote:
The rapid authoring tools I’ve mentioned certainly do branching; This is more an example of how a view of development grown from experience as an Instructional Designer can be different to that grown from a more agnostic entry point to development.
After spending some time researching and creating examples of the possibilities other authoring tools could open up, specifically Animate CC, I demonstrated these examples to the team, who, while impressed by the versatility of the software (they’re younger than me and hadn’t seen it before), had more experience of the industry’s expectations and inertia than I did. From this feedback and the development research (into where Animate CC was lacking re: elearning today), it was clear that moving toward different software was a monumental task that couldn’t be chewed all at once.
Sidenote:
Animate CC was chosen for a number of reasons.1. It was initially designed for animators and is therefore more intuitive for non-coders – while still offering comprehensive coding ability that could be abstracted away through custom functions.
2. It is in the Adobe Creative Cloud, which would lower the barrier of client acceptance – as they will likely already have a license.
3. It is mature and proven. Animate CC used to be Adobe/Macromedia Flash and used within eLearning regularly. It has since moved on from it’s Flash limitations and exports code in standard web technologies like Storyline (but unfortunately that’s not well understood by many).
While my long-term goal remained for the team to be able to use Animate CC as a replacement option for Articulate Storyline (on jobs that were appropriate), this was not a realistic short-(or even mid)-term goal. I did however, see potential to use Animate to augment our existing authoring tools and immediately plug some interactivity and animation holes in our projects.
Lottie Animationsalso provided this potential — As a way to export animations directly from After Effects into high quality vector animations that could be used in HTML authoring tools. These could, I realised, be used in a similar way to improve animation in Evolve Authoring (Storyline too, but this is more complex).
While Animate CC and Lottie, provided a way to improve the assets put into our existing authoring tools, on some Evolve Authoring jobs, there also still existed a need to solve specific problems that required custom coding, and yet, Evolve Authoring didn’t officially support this, and where realistic, I didn’t want any use of custom code to create an over reliance on my own presence and skillset.
Of the varied workarounds to these problems that I experimented with, the most robust solution I found was the use of iframes. Evolve supports embedding iframes into the learning modules much like an image. This meant that for many interactivity or animation needs that Evolve couldn’t create, could be created externally and embedded to sit seamlessly next to all native content — This covered both the ability to embed Animate or Lottie content, as well as (in some instances) integrate with the page and solve gaps that required custom code.
In addition to this, I began building and using a set of modularised code snippets and instructions that could be included in an exported Evolve package by non-coders, and easily turned on and off. This solved many of our custom coding requirements.
Adding custom CSS and JavaScript to a tool that doesn’t encourage or support it is not without significant risks, however, and in addition, Evolve runs directly in the browser, which means it’s regular updates can negatively affect or break any custom solutions we build on top.
As such all these solutions require more detail than I can put in this article, but I will break these approaches down in future articles so that others in elearning can utilise them too.
In many ways, as an industry that sits at the cross section of my experience in motion design, web development, and my experience as a university teacher, elearning is a logical transition point for me. While it’s limitations were frustrating, they also provided interesting opportunities for creating solutions that could thrive at that crossover between coders and non-coders, and I look forward to sharing these solutions with others.
designdebt.club