GuidedTrack Blog

Here’s what’s new:

• Bold new look behind the scenes of GuidedTrack.
• Much anticipated progress bars.
• Create fancy charts.
• New ways to *randomize.
• New keyword to *repeat yourself over and over.
• Repeat yourself *while certain conditions are met.
• New changes to the *clear keyword.
• In the CSV, see multiple answers a user gives to the same question.

A Bold New GuidedTrack

You may have noticed that GuidedTrack’s editor looks a little snazzed up. Now you can visually see your keywords.

You’re also getting a taste of a new navigational bar on the programs page and on individual program pages.

This navigation bar will continue to change, so be on the lookout for a “Help” tab and quick reference to the GuidedTrack language to be added soon.
 

Progress Bars

Now you can mark your user’s progress. To do so is quite simple, with the *progress keyword.

You control what the progress bar says at all times by simply typing “*progress:” and the percent of the progress that is complete (from 0% to 100%).

When a user presses the back button or jumps to a different part of the program, you’ll have to make sure the progress bars still work as intended. Progress bars are updated on a user’s screen only when they pass a *progress keyword in the program. It may be a good idea to have a *progress keyword on every screen of your program (if you’ve enabled back buttons, so the progress gets updated when the user presses back) as well as just after every *label keyword (so the user’s progress is updated as they jump to new sections of the program.

You can also choose to hide a progress bar at a given moment. The keyword “*progress: hide” will cause your progress bar to disappear until a user trips another one.
 

Charts

Charts provide eye candy for your users. Here’s a sample of how they currently look:

Charts involve 3 main keywords:

1. *chart: You’ll need to type in the *chart keyword and optionally provide a title (e.g. “*chart: My Chart”).

2. *type: You’ll need to define what kind of chart you’d like to plot. For now, we’ll only have “bar“, but we envision adding many other types in the future.

3. *data: You’ll need to provide the data to chart. The data you enter will always be in [square brackets].

Now let’s talk about this square brackets business. Anything in [square brackets] is considered a “collection” and is simply a collection of multiple smaller things. Collections in GuidedTrack are defined as a list of numbers, strings, variables, other collections between square brackets, or a combination of these things. 
 

Basic Way to Add Data

To illustrate a collection and how to use it we’ll start with the most basic way you can add data to your chart.

The above program will display a bar chart that looks like this:

Let’s return to the GuidedTrack code so we can take a look at how collections are used.

The entire data needed for this chart is in one big collection (see the square brackets on the outer edges?). This large collection consists of three smaller collections, one for each of the three important pieces of data we want to plot. Each smaller collection consists of the bar label in “quotes”, a comma, and the data point. Each smaller collection is separated from the next one with a comma. This is the simplest way to add data to your chart.
 

Using Simple Variables with *data

Look how our previous code could change if we instead used a couple variables in our data.

The above program would display the exact same chart as the one we made earlier. Here you can see the data keyword contains two variables, “ellen” and “Bshoe.” You can substitute pieces of your data collection for variables, so long as you defined those variables previously in the program using the *save keyword or >>, like we did above. Note when using variables, you do not need quotes (like how the variable “ellen,” when used after the *data keyword, does not have quotes around it).

For a refresher on variables, check out Introduction to GuidedTrack.
 

Using a Variable of a Collection with *data

We could also use more complex variables in our data. Check out this example now. It produces the exact same chart.

Here you can see that the variable “ellen” is now itself a collection. We can substitute the variable “ellen” (as well as “beyonce” and “kate”) right after our *data keyword to produce the same chart we had before.
 

Using a Variable of a Collection of Collections with *data

One final example:

This again produces the same chart we showed you earlier. Now, after the *data keyword, is a variable that represents a collection of collections. You can see how the variable “Celebrity_Shoes” was defined as a collection of the variables “ellen”, “beyonce”, and “kate”.

Now you’ve seen three ways to use variables with the *data keyword. You can mix and match all different types of variables or non-variables to produce your charts in a way that is most convenient for you.
 

New Ways to *randomize

There are two great new upgrades to the *randomize keyword.
 

Re-randomize *everytime

Ordinarily, the above program will re-display the exact same fish to the user. They’ll never see any fish other than the one they got the first time around.

Once a user activates a *randomize keyword, the program remembers the randomized selection and will re-display it whenever the user passes that same *randomize again (i.e. if they press the back button or return to it via a *goto keyword, they will see the same randomized thing they saw the first time). This makes sense, since a lot of the time you don’t want the user to realize they’re being shown random content.

Now, there’s a way to allow a *randomize keyword to re-randomize *everytime the user passes it.

With the addition of the *everytime keyword, your randomized content will re-randomize. This will pave the way for new fishes for your user to enjoy.
 

Embedded Expressions in *randomize

It’s possible to show your users more than one randomized thing. This program will show the user 3 appetizers at random:

You can now also make the number of randomizations a bit more personal by adding variables or mathematical expressions.

In the above program, the number of appetizers randomly shown will be the same number that the user asked to see.

You can also include mathematical expressions:

The *repeat Keyword

The *repeat keyword provides an easier way generate the same content a set number of times. Let’s take the following example:

In the example above, the user would be allowed to specify how many times they’d like to do the “activity” and consequently see the two pages of the activity: the first containing the text “Take a deep breath in” and a “Next” button and the second containing “And take a deep breath out” and a “Next” button. So, if users entered “2” in the question box, they would be instructed to take a deep breath in and out twice.

The *repeat keyword repeats the content that is indented below it for the given number of times. You can write any number expression after a *repeat keyword to state how many times the indented content should be repeated (e.g. 3, a variable such as “times”, points + 1, etc.).
 

The *while Keyword

The *while keyword is the same as *repeat, except that it allows the author to determine how many times to execute the code dynamically. So, instead of repeating something a specified number of times, it repeats it eternally *while a given condition is being met. Let’s illustrate that with an example:

In the above program, the user will see the text enticing them to guess the narrator’s name. They will also see the question “What’s my name?” If they guess the narrator might be named “Harold” they will see the text “That’s not my name. Try again.” Then, they’ll once more be presented with the question “What’s my name?” They can keep trying new names (Sally, Gilbert, Veronica), but so long as their answer is anything *other than Rumpelstiltskin, they will repeatedly see the text telling them to try again and will repeatedly be asked “What’s my name?” in a debilitating, never-ending cycle.

As soon as the user guesses “Rumpelstiltskin” (with appropriate caps and spelling), they will finally break free from this cycle and will at last be told they won the money.

So how does this work?

The program will execute the code indented beneath *while so long as the variable “answer” is still being defined as the string “wrong”. As an editor, you must create some kind of condition in which the value of that variable could potentially change so the user can continue on with the program.

Remember that with *type: text questions, the user is presented with a box in which to write an answer, but as an editor you can also create customized content for specific answers they could potentially write. We created customized content for the answer “Rumpelstiltskin” as well as anything *other than “Rumpelstiltskin”.

Only if the user writes “Rumpelstiltskin” would the content >>answer = “correct”  be activated by the user. Once that happens, this would change the variable “answer” from “wrong” to “correct”. Only while “answer” is “wrong” would the question repeat.

(Note: instead of re-defining “answer” as “correct” we could have also written “you got it”, “bingo” “183847438”. So long as “answer” was anything other than “wrong”, the cycle of questions would end).

We’ll illustrate another example in the next section on the *clear keyword.
 

Upgrades for the *clear Keyword

Previously, a *clear keyword cleared the screen of maintained text (text that is held constant at the top of the page with the *maintain keyword). Whenever a *clear keyword was used, there was also some sort of page break, and the clear occurred on the new screen. For example, when there was a question preceding the *clear keyword, the question caused a page break and the new screen was cleared of the maintained text. When there was text preceding a *clear keyword, then the *clear keyword also created a button that said “Next.” The button produced a page break and the very next screen was cleared of the maintained text.

Now, the *clear keyword NO LONGER produces a button that says “Next” when preceded by text. Program writers now have to manually create a “Next” button by adding the code: “*button: Next” before any *clear keywords that are preceded by text. This code is not necessary for *clear keywords preceded by questions. In other words, the *clear keyword no longer forces a button to occur.
 

Note: Without the *wait keyword in place in this sample program, the user would not ever see the instructions and image as the clear would occur immediately. The user would only see the question. Similarly, maintained text will be cleared as soon as the user reaches a screen with a *clear keyword (assuming there’s no *wait keyword). In most cases when you need to clear maintained text, you’ll want the *clear keyword to be the first thing on a new screen, by preceding it with a *question or a *button.

Now here’s another example, using the *wait keyword:

The above program is a countdown. The user will see the text “Countdown” with a number beneath it. To start, this number shown will be 10. Then there will be a wait of 1 second and the number shown will appear to change to 9, then another second wait and 9 will change to 8, and so on. The next-to-last thing users will see is the text “Countdown” and the number 1. Then, the screen will *clear and they will see the words “Blast off!”

In the last section, we talked about how the *while keyword works. Here, *while the variable “seconds” is greater than the number 0, the indented content will repeat indefinitely.

We know the content won’t repeat indefinitely though, because the “seconds” variable is slowly decreasing by 1 each time the program passes this line: >>seconds = seconds – 1. And it passes this line exactly 10 times, until “seconds” = 0 and the *while keyword no longer kicks in. That’s when users will see “Blast off!”.

Here’s how the *clear keyword comes into play. Without it, the user’s screen would begin to look something like this:

However, because we’ve added the *clear keyword, the user’s screen will clear each time they get to the *clear keyword section of the *while content. That means, the words “Countdown” as well as the number on display will disappear and will be quickly be replaced by a new “Countdown” and a new number. Usually these clears happen pretty quickly though, so to the user, it will seem as though “Countdown” stays on the screen the entire time and only the numbers change.
 

In the CSV, See Every Answer a User Gives for the Same Question

Suppose that within the same run a user answers the same question multiple times (because of *goto or back buttons, for example). It used to be that we would only export their latest answer in the CSV file. Now we can display all of them within the column for the corresponding question, separating each answer with a |. You might notice some of these |’s next time you’re looking at your downloaded CSV.