Feature Update – *picture with questions, logos with logins, and *switch, removing “Reset everything” from the hamburger menu

Here’s what’s new:

Use pictures as answer options

Doing so is simple with the *picture command added to a *question:

Your answer options must include text (so you can’t have just a picture), but you can include some answer options that don’t have a *picture keyword at all (e.g. adding a text-only option to the above like “Music is dumb”).

Add your logo to logins

If you require users to login to your program (i.e. create a GuidedTrack account so they can maintain their position in your program from multiple devices), you can add your logo to the sign up/sign in page. 

From the “Settings” tab, under “General” you’ll see a spot to add your logo. By adding your public name and an email display name, you’ll also ensure that the sign up confirmation email displays your name as well as your logo. 

Special note: Users who are logged into your program are now also automatically given a “Sign out” option from the hamburger menu.

Remove “Reset everything” from the hamburger menu

The “Reset everything” option (previously known as “Run again”) provides users a chance for a clean slate on your program. It ends whatever progress they’ve made and allows them to start from the beginning of your program. 

However, if your program is a 10-week course on becoming a professional canine couturier, this option could be detrimental to a young pupil on their 8th week toward success who clicks this by accident and is forced to start anew. 

To turn off this otherwise handy option, visit the “Settings” tab, click “Run menu,” and then click “Hide”:

Introducing *switch: when the user’s position is in multiple places at once

The new keyword *switch is for the rare program that keeps track of the user’s position in multiple places at once, allowing them to *switch back and forth, or apps that have multiple distinct sections that you want to be able to switch the user back and forth between easily.

For example, let’s again say you have a program that teaches the finery of dog fashion design. There are 10 scintilating lessons, but the user is allowed to take them in any order, and can pause one lesson to switch over to another, then switch back again to finish the earlier lesson up later.

In this scenario, you could use the *switch keyword, and your program could look something like the following: 

Above, the user might start in the lesson 1 program, but a navigation placed at the top can be clicked to *switch them to an organizing “home” screen, where they can select a different lesson to *switch into. From there, they can *switch into any of the other lessons, or back again into session 1.

How switch works:
*switch: The name of the program to switch to
    *reset (an optional attribute to start off fresh from the top of the program)

As soon as the user hits a *switch command, they are immediately transferred to a different section of your program (and any text that might’ve been on the screen prior to the *switch is not shown, so it’s best to have *switch after a *button or page break). 

There are two ways to switch:

  1. *switch with a *reset keyword indented below: users start at the top of the program, any previous progress is wiped out
  2. *switch without a *reset attribute: users resume at their last position within that program – if this is their first time in the program then they start at the top

In our example program, when users *switch to the “home” program, the *reset attribute ensures they start off at the top of that program. When they *switch to a lesson though, since there’s no *reset attribute, they’ll start off wherever they were when they last switched out.

What switches or changes with *switch?
The features below do not persist as a switch is made (so they will disappear from the screen, if present, as a section is left, and reappear if they were previously present on the program being switched into):

  • *progress
  • *maintain
  • *navigation

Any points accumulated stay on the screen between switches. Variables can also be shared across sections. 

In a program like our example above, we would have to put a *navigation at the top of each lesson that helps users *switch back into the home page, since *navigation is not something that persists between switches.

What happens at the end of the program the user switched into?
You’ll need to control what should happen when a user reaches the end of a program they’ve switched into. GuidedTrack’s natural response when there’s no further content to display is to assume the run is over, the user’s entire run (i.e., the next time the user opens the program it’ll be as if a “Reset everything” has occured). 

For example, at the end of our lesson 1 program, we could include the following to control what should happen next:

Once lesson 1 is complete, the user will be directed to the home screen. If we wanted to prevent users from starting lesson 1 over, the variable “lesson1” that’s been added (stored with the value “done”), could be used to remove this lesson from a list of lessons available to complete. 

To sum, whenever a section reaches its end, use *switch to bring the user somewhere else. 

Why is *switch superior here to *program?
Switching around willy-nilly would be hard to pull off with the *program keyword alone. The *program keyword runs one program that yearns to be finished, returning the user back to the program that contained the *program keyword. You cannot create a loop where two programs continuously call each other via *program, as GT would grow wearisome and possibly crash.

When a *switch is used, it is not necessary for the user to ever return to the program that called the *switch. Two or more programs could continuously switch back and forth, and GuidedTrack would be completely chill about the whole thing.

In short:

  • *program – run a program until it completes, automatically continuing on from here when done.
  • *switch – switch to a program, pausing the current one until *switch is used to come back.

Other times *switch would be useful?

  • If your app has a “Home” or “Main Menu” where users can adjust settings, or could potentially get several subprograms deep into alternative content, and you want to quickly *switch them back into the main thing they were doing.
  • If your app has a “Toolbox” or “Homework” that user’s can play around in, and you want to keep track of users’ progress in the various tools.
  • When you’re developing a traditional app that has a persistent navigation bar, where clicking each navigation icon takes you to a different section of the app, you can use *switch to actually do the switching between the sections. Note that you’ll have to create the *navigation again at the start of each section, since navigation does not persist across sections.
  • Any other time you use a *program keyword, but the *program you call may not run to its end.