Feature Update – *trigger, scales for *answers, version control, email settings, and more!

Here’s what’s new:

Add a scale to *answers and make questionnaire creation a breeze

Particularly if you’re a researcher, you may have a lengthy questionnaire where the same answer options are repeated over and over (“So true of me”, “So not true of me”). Likewise, the number of points assigned to each answer option may be consistent across questions.

You could copy and paste your scale beneath each question, but that could get tedious. Instead, you can also use *answers with a scale. Here’s an example of how it works:

In the above, “Adventurousness Scale,” several questions use the same “YES!!!” to “eff no” answer options. But here’s how you simplify adding the scale to *answers:

  • First, you define a variable (e.g. “answerScale”) that contains a collection with several smaller collections. Each smaller collection looks like this: [“text of answer option”, point value associated with that answer] (e.g. [“YES!!!”, 4 ]).
  • Second, if you have any other scales for other questions, you may wish to create more variables, such as one that includes a reverse scoring of the typical answer options, if needed (like the “reverseScale” in this example).
  • Third, you add “*answers: yourScaleVariable” beneath each question that relies on that scale.

The points assigned to each answer won’t be visible on the user’s screen, but they will be in the csv of the data. In the csv, you’ll see a column with each full question, and beneath the column will be the point values of all the responses you’ve collected (rather than the typical text-version of the responses). This will make analyzing your data much easier!

Note: the text-version of the user’s answer response will not be saved ANYWHERE! The csv only stores the numeric value of the response, as does the *save keyword. Of course, if you really needed to, later on you could look up the point value in the CSV and check the GuidedTrack code to see what answer it corresponds to.

If you wish to add up a total score, or do other mathematical tricks, you can add a *save keyword plus a unique variable to each question. As mentioned, these variables will save the numeric value of the selected response, rather than the response text. At the end of the program, you can add code like >>totalScore=variable1+variable2+etc. to get a variable of the total score.

Control “who” your emails appear to come from

There’s a new setting that allows you to control the “from” name when you send emails via your GuidedTrack program. This is not the email address your email is from, but rather the name of who it comes from, which many email providers display prominently.

Here’s how to activate it:

From the “Settings” tab, enter what you’d like the “Email display name” to be.

For example, if you made a program about cats that emails the user at some point, you may want the email to be from “Mr. Whisklypuffs.”

Without the display name, your email will appear to be from the name of your program plus some randomly generated letters and numbers.

Later, the “Public name” will be the name of your program as it’s displayed in the iPhone or Android app store (when that soon becomes a thing) and eventually as the title of the tab that your program is running within.

Enable version control

Enabling version control is a great idea for programs that will need live updates while multiple people are taking them (over multiple days). It ensures that the program version people began with will be the version they continue with indefinitely, so that new changes you’ve made don’t accidentally make a muck of their progress.

Here’s the scenario: You have this amazing program that allows people to track the firmness, dexterity, sweat control, and length of their handshakes. You think it’ll greatly help people master the art of a truly impeccable digit delivery. You anticipate that people will use your program over the course of several weeks as their limp noodles firm up.

Here’s the thing, within a couple weeks you have a few hundred palm perfectors, but you’ve thought of a new handshaking aspect you’d like for people to be able to track – the webby-to-webby touch. However, if you just throw in new changes to your program now, it could disrupt the progress of the people currently in the program (perhaps they wouldn’t have important variables from your revised intro quiz, or their current place in the program could have disappeared). That’s where version control comes in.

By going to Versioning from the Settings tab, you can set the version to be “Consistent” for active users as opposed to “Always latest”

As GuidedTrack advances further, there will be an option to safely migrate your existing users to the new version, but for now, this is your best bet to ensure complete smoothness as your program reaches new heights.

Create a JavaScript event using *trigger

*trigger is used to run JavaScript that is sitting within the HTML file that a GuidedTrack program is embedded in. Hence, it enables GuidedTrack programs to effectively do anything JavaScript can do, as long as you put the appropriate JavaScript within the HTML file that the GuidedTrack is embedded in.

This feature is for those who are embedding their programs on other websites, and it’s best for those who have a working knowledge of HTML and JavaScript (or at minimum who feel comfortable enough copying and pasting JavaScript obtained through other sources).

So in other words, be warned that this section gets quite technical!

The *trigger command is used to “trigger” JavaScript code to run on the current page. For example, it could trigger the sending of data to external sources, such as Google Analytics for tracking activity in your program. In it’s simplest form, it looks something like this:

Above, “quizEnd” is the name we chose to give to our triggering event, and on the website that’s embedding our program there will be JavaScript code matching this name that will be actively listening for this event to be called. When the website notices this event, it will grab the JavaScript code from the *send keyword and do with it as you’ve commanded (for example, perhaps sending the accompanying data from your program to an external source that you’ve specified).

The data used with the *send function is always written in the form of an association, with a name or description of the data on the left of the “->” accompanied by its value to the right.

For a simple example of how you might *trigger a Google Analytics event, you could do the following:

There would also be JavaScript on your website that included this along with other JavaScript:
// Include the following on the page that embeds the program inside of a <script>…</script> tag
$(window).on(“finished”, function() {
ga(“send”, “event”, “progress”, “view”, “page”, “end”);
});

Here’s a more complex example of using *trigger with Google Analytics:

And here’s a description of what you’d put in the JavaScript on your website:
// The first parameter to the event handler is the event itself
// The data sent along with the event is the second parameter (data)
$(window).on(“analytics”, function(event, data) {
ga(“send”, “event”, data.category, data.action, data.label, data.value);
});

To get the above example to work, you’d also have to include in the HTML page the JavaScript that Google provides to activate Analytics and the Google Analytics function that’s being used.

Here are a few more ideas of ways to use *trigger, with more detailed versions of the JavaScript code that gets added to the website.

Start the user’s run at a custom *label using URL parameters

You may have a reason for starting some new users further along in your program. Now you can give users a custom link to your program that includes the *label of where they should begin.

For example, let’s say you have a training program that teaches basic and advanced skills in hobbyhorsing, the dramatic trending sport where (mostly) young girls leap over hurdles and gallop around tight corners, all while skillfully controlling a wooden stick attached to a stuffed horse head. You know that some of your users will be of a more advanced skill-level, and therefore, will need to skip the kiddy stuff.

After the beginner lessons in jumps, dressage, and keeping your hobby-horse well-groomed, you’ve added a *label: advancedTechniques just before the extreme stuff begins. To provide professional users a link that will automatically start them there, you’d simply add the following to the end of your URL:

https://www.guidedtrack.com/programs/programID/run#advancedTechniques

Users clicking that link will start at *label: advancedTechniques instead of the beginning.

As another example, let’s say there’s a menu at the beginning of your program and you’d like returning users, those coming to finish the program later on, to begin at *label: mainmenu instead of wherever they may have left off. You can easily share a link to your program that’s something like this:

https://www.guidedtrack.com/programs/programID/run#mainmenu

The *label/URL parameter trick only works for a *label that’s within your starting program (it won’t work for a program that’s linked to within your program using *program).

Hide the user’s points

When you give users points, they appear in the top-right of the screen, but they don’t have to stay there forever. Hiding points is a breeze.

The points are no longer visible to the user, though they haven’t been erased completely. They’ll still display the correct total if you decide to add them on the screen again later.