Feature Update – *until, *return, *countdown, new icons, and more!

Here’s what’s new:

More super awesome icons!

What’s more fun than a good icon? Pretty much nothing. Except maybe cake. Definitely cake. And beer, and sleeping, and bicycles…

But look – icons!!

Icons were covered earlier, but the list of potential flare you can bedazzle your program with has now expanded.

In addition to the bootstrap icons we mentioned… you can now find way more (675 to be exact!) icons here: http://fontawesome.io/icons/

To add either a glyphicon icon or a font awesome (fa) icon, you type *icon:, followed by the type of icon (glyphicon or fa), followed by a dash and the name provided on the site where you got it from. Like this:

You can add icons to multiple choice or checkbox questions plus navigation options. Enjoy!

Creating Associations

Associations are sort of like neatly-organized collections that allows you to look stuff up fast. If you’re familiar with programming terms, these also go by the names “Hash tables,” “Associative arrays,” “Hash maps,” or “Dictionaries.”

Here’s an example. Let’s say you have a terrible memory, and want to create a GuidedTrack program that can give you the birthday of any of your friends. You set things up so that all you have to do is type in their name, and their birthday pops up on the next screen.

With that scenario, you might use an association to add all the starting data you have. Each entry in an association must include two things:

  1. A “key” (the term associated with each piece of data, in this case the name of your friend)
  2. Its value (such as the friend’s birthday).

If you were a postal enthusiast, the keys of your next association might be thousands of zip codes, and the values might be the names of the town associated with each key/zip code.

The code for associations is a little different, so to start, here’s an association with just one birthday entry in it:

In this example, the name Justin is the key that you’ll use later to find the associated data, which in this case is Justin’s birthday, March 1, 1994.

What’s perhaps most striking here is that you’ll use {curly braces} instead of [square brackets] to create the association. Also, the arrow ( -> ) is used to say something along the lines of “when I input this key, show me this thing right here.”

The final program, once you’ve added more of your friends, might look like this:

Each entry in the association is separated by a comma. You can then type the name of your friend, saving your selection as “friend”, and then, similar to the way you would show a specific position in a collection, you display that friend’s birthday by typing {friendsBirthday[friend]}

You don’t always have to use a variable though to show items in an association. If you had Bieber fever, you could prominently display Justin’s birthday in your program by typing:

While you could accomplish this same feat using collections and the *while keyword, associations make it much easier to look up values associated with other values.

Adding or changing a single item in an association
Once you’ve got a basic association set up, it’s easy to add or modify items.

For example, let’s say you have an association of English words with their Polish translations. If you want to add a new word to this pre-existing association (which you’ve called polish_words), you can simply do the following:

“tea” will be a new key added to the polish_words association, and “herbata” will be its value.

Similarly, if you realized you misspelled something and need to replace the value for a given key, you can overwrite a key in similar fashion:

If “cake” was already in the association, it’s value is replaced by “ciasto.” If it wasn’t in the association, then it’ll be added new.

One more association example, for good measure
If we revisit the earlier example about adding friends’ birthdays to an association, there’s another way we may want to organize lots of info we have about our friends. For example:

In the above example, each friend has their own association, complete with different keys representing crucial details about them. The collection ‘myfriends’ contains all the associations. If you set things up this way, here’s a couple ways you could display data:

The first line accesses the second association in the myFriends collection and displays the value to the key “name,” which is “Mariah.”

The second line would display the key “Perfume” of friend3, which is the sensual “Eau de Gaga,” with its opulent woody-floral intensity.

You could display all your friends’ signature scents, like so:

Help the user *return to their original program

There’s a new keyword that works particularly well when partnered with *navigation and at least one *program keyword, though it could have simpler use cases as well. This would be the *return keyword, which functions like a high-tech *goto. When users pass over the *return keyword, they go to the very end of the current program they’re in, which returns them to wherever they were prior to that.

Here it is in a somewhat simpler form:

(starting program):

(Super Fun Exercise program):

In the above example, users start the program, which then launches into the “Super Fun Exercise” program via the *proram keyword. Once there, they have a choice to “Play” or say “This is lame.” If they choose the latter, they immediately exit the Super Fun Exercise program via *return, and next see the text “Now we’ll do something else!” from the original program. If they instead choose “Play,” they’ll see the line “Let’s get ready to prancercise!” and any lines that follow.

So why use *return when you could instead use a *goto keyword that could direct users to a *label at the end of a program? For one, laziness. You can now accomplish the same feat in one line of code instead of two. But suppose you didn’t actually know which program users were in? And suppose you instead wanted users to be able to exit out of the current program via an option in *navigation. Sounds weird right? Here’s an example to show you what I mean:

​

The *goto keyword does NOT work across programs, so trying to add it beneath this navigation option would be of no use. But no matter which tool users are randomized into, the *return keyword will bring them out of the tool, to the next line in the original program, which reads “Alright, that’s the end!” Of course, it doesn’t have to be the end here, you could allow users to return to the beginning to try a new tool, or your program could just continue going forward.

Note: If one of the tool programs itself includes an additional *program keyword that leads to a program that would carry the user through two or more screens, and the user is in that second program, *return alone isn’t going to cut it. *return only exits the user back one program layer, not several. So keep that in mind if you end up using *return! It can be tricky to use if the user needs to exit out of a program within a program within a program!

Specify that a recurring email should keep being sent *until a certain date

Recurring emails were discussed last time, but since then there’s been a new keyword added to make them even more effective: *until

If you’d like to send users the same email multiple times (every Wednesday, for example), but have a natural stopping point (after one month), *until is the keyword for you.

Here’s how this works using the example from last time.

Let’s say the user will be completing an intervention each day for seven days, and you want to send out a reminder each day to complete the task.

  • You’ll can optionally add the *identifier keyword, (if you may want to cancel the email early later on).
  • You’ll use the *every keyword, to specify how often the email should be sent out.
  • You can use *until to specify that the email should stop after 7 days.

The most an email can be repeated is once a day (not hourly, for example), and users are now given an option to opt out of your recurring email by clicking an automatic opt-out link that will occur at the bottom.

Timers for questions

Want to restrict how much time a user has to answer a certain question before they automatically advance to the next page? Enter *countdown

When you use *countdown, you can set how many .seconds, .minutes, or even .hours a user has to complete your question. The time remaining even displays just above the question like this:

When time is running out, the timer turns red:

The code is pretty simple, here’s an example:

All you really need to use timers is the *countdown keyword specifying how much time the user can have before the page automatically advances.

But in this example, we also used the *save keyword to store the user’s response. We can find out if the user left the question blank by checking the .size of the variable (gets the character length of the response). If the size is 0, then the user didn’t get to type anything in before the question disappeared.