The Making Of A Module

Most adults have participated in an eLearning module at some point—either through a work-mandated training course, as part of a self-paced online curriculum for a certification, or even to pursue personal interests by signing up for free online courses.  We have certain expectations now from these courses, but rarely stop to think about the person/people behind the curtains who are addressing those expectations.  Developing an eLearning module from the ground up during LDT 504 course exposed many of the secrets and struggles of the process.

I would like to note that I found this experience much more difficult than I think I would have if I were not working full-time concurrently (as I am sure many other course participants are as well).  Without having as much time to devote to the material, I found that I was skimming through instructions, skipping past non-essential module blocks, and fast-forwarding through lecture recordings to find essentials.  This ultimately resulted in several unfortunate misunderstandings and mishaps that greatly interfered with the flow of my module’s development.

One of the first obstacles that I encountered while creating this eLearning module came in the planning phase.  I prefer a visual planning style, and if possible, the opportunity to sketch something by hand in my first rough draft.  Usually this will not look like much more than scribbles to anyone else, but it makes sense to me.  However, with the introduction of the Twine wireframe tool, I was scrambling to understand how its new features worked and how to input the large bulk of information required.  I didn’t sketch it out for myself because I had no idea what the tool I was using would end up looking like and relied only on how it was coming together on the screen.  I also felt overwhelmed that I needed to dump so much into each of the pieces I added to the wireframe.  Even with a liberal amount of copy-paste to keep formatting consistent, it still felt tedious and frustrating.  As a person who does not usually plan out every fastidious detail prior to execution of anything, that step was probably the worst for me.

Despite feeling behind and overwhelmed for most of this course, there were some parts that I genuinely enjoyed.  I am a creator at heart, and I have a rudimentary understanding of how coding works (although the only coding language I’ve learned has very limited applications).  This helped me to understand concepts in Articulate 360 like “states”, “variables” and “triggers” quicker.  As I began adding in more of the required slides, I started to feel curious about trying new things with the program.  Some triggers that I spent some time on ended up duplicating a feature that was already part of the interface, such as the play/pause button, so I didn’t keep them.  Others, like disabling the “next” button until a certain trigger, I did keep.  I also felt like if I’d had more time with the program while working on the final part of the project (not during the early stages when I was just trying to keep up), I would have experimented with many more strategies.  To provide an example—when I work with the program Desmos (an online website for creating activities), I can spend hours on tasks like choosing which parts of a screen appear or disappear depending on correct/incorrect answers, buttons that cause hints to appear when pressed, screens that reveal answers to previous work but only after work has been completed, graphs that can judge their own correctness, and so on.  I would have liked to explore to that level of detail with this program and then submit a product that demonstrated those types of strategies.

While I am glad that some of the key resources were provided for the design case, there was still much confusion when I launched the project—namely over the comment that I would “receive an email” which actually referred to a faux email included in the design case notes themselves.  I also spent an inordinate amount of time researching a topic that I was definitely NOT a subject matter expert on.  I assume that these three design cases were prepared because it is easier to grade on a rubric; however, if that is not the driving reason behind the choice, I believe that offering students the option to choose their own topic (but provide a limit to branches in the module) would be a great support.  For example, since I am a math teacher, if I’d been able to develop this module about methods for Polynomial Division, I would have been able to gather the materials much quicker and therefore spend more time developing the module features.  I already have many images and examples, and I can speak confidently about each method.  I would also feel comfortable developing assessment questions that accurately match objectives and are appropriate for the audience. 

        Looking to the future, I know that generative AI will come to play a significant role in the development of eLearning modules.  I foresee human-made programs that employ generative AI where a person inputs key details such as course objectives, audience demographics, module style, assessment style, and module length; then the module is designed to match these characteristics and passed back to the designer for editing in order to ensure that all goals are met.  While this is fascinating from a pragmatic standpoint (yay!  Less work!) I think I am more excited about the prospect of virtual reality or at least augmented reality modules.  Just think—Pokémon Go! meets “Safety in the Workplace Refresher Training”—in my mind I am seeing people using their devices to roam around (in a safe way) and “catch” AR cartoons of workers doing something dangerous.  I just hope that the people who make those eLearning modules don’t make them boring…