Feature Update – *experiment and *navigation

Here’s what’s new:

The *experiment keyword, for smarter randomizations

The *randomize keyword is great. It let’s you randomly assign participants into different groups, but because it’s totally random, you could end up with groups of different sizes.

The new *experiment keyword operates just like *randomize, except it keeps groups balanced. So if you have groups A, B, and C, the first participant to take your study could randomly be assigned any one of those, let’s say they get assigned group B. The second participant could only be assigned A or C, since B was just taken. If they get assigned C, then the third participant will be in group A. The fourth participant once again has an equal chance of being assigned any one of the three groups. This ensures that the difference in the size of the groups is never more than 1.

Unlike *randomize, it doesn’t make sense for *experiment to choose more than one group. So, instead of using the inline text to specify how many things to randomize (e.g. *randomize: 3, *randomize: all), *experiment uses it to name the experiment so that the CSV is much easier to read. We also allowed *group to have the same capacity, so you can now have code that looks like this:

So when should you use experiment over randomize? In most cases, when you’re running an actual experiment (where you want to see how a change in one thing in the program effects some other thing) you should use *experiment. When you merely want things to be random (but you’re not conducting an experiment) *randomize is probably the right choice.

Add *navigation to the top of your program

Let’s say you were bored one day so you wrote a GuidedTrack program entirely about squids. You can now use the *navigation keyword to provide permanent links at the top of your program that will allow users to jump to different sections of your work.

With navigation, your programs can be a lot more like full-fledged apps. Maybe you want to use *navigation to help users access different programs of a comprehensive tool you’ve made, or revise their settings in your well-being program. There’s a lot you can do with navigation and adding it is easy. Here’s an example of how the squid code might look:

The program above begins with the navigation keyword, which will be visible immediately when the user starts the program. Each of the four navigation items are indented beneath the navigation keyword. Indented beneath each option is the content users would immediately see if they clicked on that option.

Once users are done viewing content from a navigation option, they return to the place they were at before they clicked the navigation.

Navigation content can include all other GuidedTrack keywords, not just text. For example, you can add icons to your navigation program, which could look like this:

You can even use the *goto keyword to redirect users to other parts of your regular program, as this example does.

In this program, the navigation options don’t appear until the user clicks the “Begin” button and the navigation is activated. Once the user clicks “Begin,” the program called “Stache Styles” will also immediately start. Users can go through this program regularly and then begin the next programs in sequence. At any point, the users can also click one of the navigation options to easily review content they may have already seen or to jump ahead to new content that come later in the sequence.

If at any point you want to hide the navigation, you can do so by typing *navigation: hide

An update to *icon

Do you remember when we told you that multiple choice and checkbox questions can now get new pieces of flare? No? Good. Because the code for this changed a touch when we upgraded to a new version of Bootstrap.

To add an icon to an answer choice, find the icon you like from this NEW link: https://getbootstrap.com/docs/3.3/components/#glyphicons

Then, indent the keyword *icon beneath the answer option and type in the full name of the icon. Below is an example:

Displaying a user’s paragraph answers retains line breaks.

There are times when you may want to save a user’s answer to a paragraph type question (using the *save keyword or *tags, for example) and display it back to them. Now, if users create line breaks in their answers by hitting the enter keyword (while typing out a list of their favorite foods, for example), when they see their answer displayed back to them, the line breaks will be preserved exactly as they had them (previously, it would have looked like a mucky, cluttered mess).

Here’s an example of how preserving line breaks might look: