Procedure Training

Hi Victor,

I've never done anything exactly like that before, but here's how I would approach it:

1. Add a visited state to all the document titles. When the user clicks to download the document, the visited state will be automatically activated.
2. Set the initial state of all the "click to test" buttons to Disabled. Then add a trigger that changes the state to Normal when the state of the associated document button is equal to Visited.
3. Add a trigger to each test button that links that button to the associated quiz.
4. Insert the variable reference for each quiz into a text box in the test result column in the corresponding row.
5. For the status button, you'll need to add a custom Complete or Passed state and a trigger that changes the state of that button to Complete or Passed when the score variable is higher than the passing score. If there's no score requirement, then you'll need to figure out a way to change the button state when the learner finishes the quiz, no matter what the score. For example, using a true/false variable that you place on the last slide of the quiz.

Let me know if you run into any issues or if you have any questions.

Thanks for the reply. I setup the modules almost exactly as you recommended (great minds think alike). It is a fairly complex setup and requires a lot of attention to details for the triggers. Just thought there might be an easier way to design the modules. Best Regards,
Victor E. Madison SR

I'm not aware of a simpler way, but maybe someone in the community will jump in with an idea.

The primary reason for setting up the "lessons" this way is to reduce the flood of training elements on the LMS. There are over 200 separate documents to be reviewed and tested. This method reduces the total "foot print" on the LMS to only 30 modules (with lessons nested within the 30 modules). Best Regards,
Victor E. Madison SR

Hi, Victor,

"Requires a lot of attention to details for the triggers" is an understatement. One thing that helps with that is to follow good naming conventions. For example, make the button names match the names for associated items (e.g., documents, variables, etc.)

In your case, you might use a convention like this for everything associated with DC-ALL.WI.0001:

• WI-1-view for the button to open the document. Note: I'd use the minimal amount of info needed to see which document you're referring.
• WI-1-test for the button to take the test
• WI1resultScore for the variable (Alas. Variables can't include hyphens.)
• WI-1-result-field for where the results shows up
• WI-1-status

Something like that means that you can quickly scan a trigger to ensure all the pieces start with "WI-01," which makes it a little easier to troubleshoot.

I setup a "matrix" table that shows the relationships between all of the items on the scoresheet and with variables. This shows the complexity of the scoresheet. For example, the DOC NUM is the name on the timeline associated with the document title button. When the user clicks on the document title button, the state of the button (DOC NUM) changes to visited. This also opens a link to the document located on a file server. When clicked, this also changes the state of the test button from disabled to normal) to allow the user to take the test. The "states" of all of the buttons then reflect the results of the test. This is a lifesaver when something does no work properly. Wish there was an easier, less complicated, way to do this but this is what I came up with. Best Regards,
Victor E. Madison SR