Forum Discussion
Calling all Software Simulationists
There are several options here and depending on the stakeholder's requirement I will do one of these.
Option 1. I will build a storyline project on one function. Make sure it works, test and have the stakeholder review and approve. This can now be used as a standalone project. Quick and can be used as a review by learners when needed.
Option 2. Use the above project as a scene and import these slides into a bigger project. I keep it as standalone for changes as needed down the road.
Option 3. Take all my standalone projects and put them in a learning path on the LMS.
A lot depends on your stakeholder's and what they want. In reading your post, I think option 2 will work the best.
Good luck.
When I've done something like this (and on a large scale as you've described) in the past, I've broken the software functions into scenes for ease of management and maintenance. It certainly makes it easier to make a menu structure where you/learners can jump to the functions/tutorials that are most pertinent to the situation at hand, i.e. you can link them sequentially, have a menu where learners can jump to the function (scene) of most interest, or a combination of these.
Typically I'd capture the Show Me/Try Me into a 'capture' project and then transfer the sequence into the 'live' project. This was useful in my workflow for a couple of reasons:
- I could make sure the sequence was complete without any 'oops' in it (or at least make manual tweeks) before risking any corruption or large-scale slide deletions in the live project. Sometimes it was handy to use this staging post to delete early steps from the sequence that were showing learners stuff that was super-obvious or was a repeat of a step that had been shown in other sequences/software features. In these circumstances I could just insert a standard slide that said 'Enter the demographic data as you would when doing X, Y, Z before completing function Y.' (more eloquently and aesthetically pleasing - but you get what I mean) This saves learners' time and sanity by not covering non-necessary or well known stuff to get to the good bits.
- To help keep things fresh for learners, I'd often do a Show Me AND and Try Me sequence of slides (for the same sequence/software feature) into the 'capture' project and mix and match the slides, maybe using the Show Me frames for the simple, early parts of the sequence and inserting some Try Me frames for some of the more key parts of the sequence. E.g., the learner would passively watch some of the sequence, but then have to interact with (try) the simulated software steps to move the sequence along with some judiciously inserted instructions. I found this was often better than all Watching or all Trying, i.e., Watching everything could be boring, or having the learner ALWAYS enter mundane data into some rudimentary fields was just a pain to them getting to the meatier bits of the simulation.
As a final 'on my soapbox' comment on these kinds of projects, I believe it's always good to include WHEN AND WHY learners might user the sequence/function about to be learned. Many of these kinds of projects that I've seen go to great lengths to demonstrate that, for example, a person's name should be entered into a name field (well, duh!) but there's no context as to when and why a learner might use this function or what the implications of using it (or not) within the system are. For example, have you ever Googled how to do something in Windows and you get all kinds of tutorials on how to use the function but you can't find the @#$%! function in Windows to be able to start doing it yourself! Just my two cents' worth.
Good luck!
PeteB
Thanks Pete. I appreciate the depth you've gone into here. Cheers.
Steve, I do a lot of software simulation. Unlike most people, I don't use Articulates screen capture. I prefer the way Adobe Captivate captured a slide for every click. Articulate saves short videos and a lot of automatic layers that are not to my preference. So, import an image for every click. I always user workflow scenarios to teach the topic which are in separate scenes. The separate scenes for topics makes it easy to set up the table of contents to allow users to jump to a specific workflow. The separate scenes are all in one big continuous workflow.
To Pete's point, you often don't want a whole section to be a Show Me or Try Me. I always use a Release of Responsibility approach. If something is brand new, the user has helpful boxes so they know exactly where to click. The second topic will build on the first. Only new content will have red boxes. If the user clicks in the wrong spot a hint layer displays. Keep in mind the second scene is doing something new, but there is some overlaying content. I want the user to immediately practice what they learned for a different example and build on it. It forces the learner to stay engaged throughout. It may be a bit more tedious recording my simulation separately, but the end product makes it worth it because the end product acts exactly like the software I'm simulating (except for red boxes and hints if a mistake is made).
Thanks Stephanie. You're not the only one as we use Captivate for the captures. But we may move to SL for that too. Certainly doing the captures in separate SL files before bringing them into what will be the player shell as a separate scene makes sense.
Not sure how easy it is to replace the content. One assumes the Scene stays even with all the slides removed, if deleting old capture and updating with a new one.
Yeah, I mix and match sometimes within the same capture, depending on the situation - some clickables, some carried out with inserted mouse interactions.
The organisation I am in want everything short as possible - probably like everywhere these days - so it's a tightrope on the deliverables.
