Software and Technical E-Learning Module Examples

Feb 16, 2015

I have recently taken on a new client.  The bulk of the work will be e-learning modules on new software implementations.  I would like suggestions on how to NOT just do screen shots over and over.  Maybe I should be asking, when doing new software implementation via e-learning, what are some best practices to follow?  What are the common pitfalls? 

Also, should all of the different software implementations have the same pattern as developed in the first one - help the learner due to familiarity of the presentation of new information?

 

6 Replies
Michael Hinze

Instead of doing screenshots over and over, you could opt for screen recordings that show a How-To procedure, e.g. how to create a new inventory item in a ERP system. Besides demos, you could also create TryIt simulations that allow learners to practice the various software functions. See some info here: https://community.articulate.com/series/4/articles/recording-screencasts If you do want to make screenshots more interesting, see this recent eLearning challenge here for examples: https://community.articulate.com/articles/interactive-screenshots-online-training#comments 

Simon Blair

I love Michael's recommendations, but I have a cautionary tale,  well... two actually, but the moral is the same.

I had two recent projects in which we used one or both of those approaches.

In the first project, they changed the system. We had to record new video and replace steps in the Try It scenarios.
In the second project, they changed the process. We had to (you guessed it) change the steps in the try it scenarios. We also had to replace a video, but instead of recording a new video I did a series of timed screenshots to simulate he appearance of a video.

The moral of the story is: consider how much re-work will be created if the content changes (even a little). 

Cary Glenn

Change at the last minute is common in the software development industry. This causes headache for many people. What happens is that the company wants to get the program out by a certain time (often to coincide with tradeshows). A schedule is drawn up and the programmers and developers get going. They are allotted a certain amount of time. It then heads off to Quality Testing and Assurance, QA stays up all day and night for days trying to find all the bugs and problems. It goes back and forth between development and QA until it is done (or as close to done as it is going to get). Meanwhile marketing is trying to get images for their campaigns. The technical writer tries to get as much stuff written up and writes up the help files. Once the final build is released the technical writer often has to re-write almost everything they have done. The changes from early versions to the final release can be quite dramatic. My ex-girlfriend was as Technical Writer, on more than one occasion she would work a 30-hour shift. 

Michael's advice is great. Just be prepared to be flexible and make changes at the last minute.

This discussion is closed. You can start a new discussion or contact Articulate Support.