RD3: Behavior Modification
One of the meanings of the word behavior is “the way in which a natural phenomenon or a machine works or functions.”
This definition means that a particular action will result in a particular response. Every software has a specific behavior that is defined by code. Depending on the complexity of a piece of software, you may be able to modify the behavior of a program.
For example, if you want to read up on the fuselage of aircraft, you can go to Wikipedia using the following address: https://en.wikipedia.org/wiki/Fuselage
If you want to read it French, then simply replace en.wikipedia.org with fr.wikipedia. By doing so, you have modified the behavior of the web site – it delivers the same article, but using the French language.
Behavior Modifications Require Changes to Specific Parameters
The behavior of the Wikipedia page was modified by switching the input, specifically by changing two characters in the web address. In this example, the web address is the parameter that was modified.
Complex software applications usually allow the user to select the desired parameters the program will use when it is running. For example, a lot of phone apps allow you to specify the use of facial recognition instead of logging in every time you want to use the application.
Modifying Parameters Allows for More Efficient Customization of Online Training Courses
Over the years, we’ve learned that the needs of our customers are very diverse – what works for one training organization does not suit the needs of another. This creates a distribution problem – how do you allow each customer to get what they want without having to create a different version of the course?
For example, training organizations in the US typically need courses in imperial (gallons and feet), whereas customers in Europe would need the courses in metric (liters and meters).
The brute force method to solve this problem would be to create the course in metric, copy it, and then modify the copy to turn it into an imperial system. But this is quite a bit of work that involves a significant amount of duplication of effort.
One way to solve this problem is to make use of a parameter that the user can modify. These are called settings, and our RD3 platform enables our customer to modify these settings to suit their needs.
Avsoft develops courses using both imperial and metric, so the system also allows the customer to select which standard to use:
Additional Useful Parameters in RD3
We have some customers that want to force the students to listen to the entire audio clip of each screen, whereas others want their students to have more freedom. RD3 has a setting for that as well:
There’s also another parameter called the “idle time limit.” This is a neat little feature that is designed to keep the student “honest.” Some students don’t really want to take the course, so they download a software that will automatically perform a click on a specific part of the screen. These users launch a module and walk away while this “clicker” program clicks on the next button, giving the appearance that they are studying when in fact they’re not.
The problem for these users is that we’ve built in traps through the module – the student is asked to click on one or more parts of the screen. Since the “clicker” program only clicks on the next button, the expected interaction doesn’t occur and the program is stuck. After the specified period of time (default is 10 minutes), the module closes, gives the student an incomplete, and reports to the LMS that the module timed out.
This process results in some hilarious tech support requests along the lines of the program is “stuck on screen X,” or the module keeps closing. Our response is to go look at the LMS activity log, and we reply to the tech support requests with the conclusions. For good measure, we copy in the director of training on the email. You’d be amazed at how rapidly this type of tech support disappears from a specific organization!
RD3 also has a setting that modifies how the module interacts with the LMS. For example, some customers prefer to give an incomplete instead of a failed status.
RD3 settings also allow the customer to modify the delivery of questions at the end of each module.
RD3’s Robust Behavior Modification Functionality Allows for Greater Course Customization
Overall, we have 24 variables that a customer can change, resulting in 1,333,735,776,850,280,000,000,000,000,000,000 permutations! This allows each customer to get exactly what they want, and we don’t have to create a special copy based on the specific needs of a particular customer.