Feature Update – *expandable lists, save users’ progress, *goto and *points update, and more

Here’s what’s new:

GuidedTrack’s makeover

You may have noticed some new changes to GuidedTrack, particularly when you click on one of your programs.

Easier way to edit, preview, and save your program.

You can easily toggle between editing your code and seeing a preview of how your program looks.You can also more easily save your program as you make your edits.

New navigation menu

You still have all the same options, plus a couple new ones.

  • “Share” gives you the share link to your program, plus the embed code to add your program to a personal website.
  • “Data” allows you to view and download a csv of who’s taken your program and their responses.
  • “Settings” is where you can add collaborators to your program, make its access restricted or more open, and decide whether to force your users to login or not.
  • “More” allows you to run your program as a user would see it, duplicate it, or delete it.

Create an *expandable *list

Do you have optional content that you want hidden or shown based on the user’s whim? An FAQ, “learn more” section, list of definitions, help menu, or any other large block of content? If so, that’s no problem with *list: expandable. Users can open and close each item in your expandable list, which saves you from inundating them with a huge word wall or cute panda overload. 

Here’s how an expandable list looks when all its items are closed:

And here’s how it looks when something is open:

The code is pretty simple. Type “*list: expandable” and indent the names of each piece of content (for example, “Upside down panda”), and then indent whatever content you want to show up when users click that item. Here’s the code from our example:

Certain keywords cannot be included under expandable lists:

  • *button
  • *experiment
  • *goto
  • *label
  • *maintain
  • *navigation
  • *question
  • *program
  • *progress
  • … and other keywords that cause a page break, or affect the program on the whole

Text, images, and links are fair game! Audio, videos, and charts do not work under expandable lists yet, but support for them is coming soon.

Allow users to save their progress from any computer or browser

This new feature is especially handy for programs that’ll take users multiple days to complete.

Adjust the settings to make the login screen appear in the beginning

You can set it up so that each and every time a user opens the run link to your program, they are encouraged (or required) to sign into GuidedTrack (if they are not already signed in).

Once they sign in, they will be transported to the very last screen they visited in your program (even if they are accessing your program from a different computer or browser). If they have never taken your program before (or they fully completed their run last time), then they will start from the beginning of your program.

There are some caveats in which the login feature may be faulty if you make changes to a screen the user is on, so do be sure to see the “Important note” below before implementing this feature.

You can control whether or not users should login to your program from the “Settings” tab. To get there, click on a program from your “Programs” screen, then click “Settings.”

From there, you’ll see an option called “Login settings,” with three options:

Required: Great if your program is highly complex, and users will need to take it in multiple sittings, and/or if the same users will be taking a bundle of your programs and you need to track them.
Optional: Nice if your program might take a while to finish and you’d like users to have the option of completing it in multiple sittings across devices, or if the program can be taken multiple times and you want to give users an option to store their past answers.
None: Best if your program is short and simple.

Of course, you may not always want the login screen to appear just in the beginning of the program. You may also want it to appear toward the end.

Add a login screen in the middle or end of the program

This option is especially useful if you’ve given users the option to login in the beginning of your program, they turned you down, and now you either want to give them a second chance or demand that they login.

To do that, you can throw a *login keyword into your program wherever you’d like. This keyword has been around for a while and full details can be found here.

The basic syntax looks like this:

You can change required to say “no” to make it optional, or just nix the whole “required” line altogether to make the login optional.

If users decide to log into your program, then their progress will be saved. However, you should also make sure that the settings are set (as described above) so that a login screen pops up whenever users start your program. That way, they’re immediately given an option to login and pick right back up from where they left off (the *login keyword on its own without the settings set to ask for a login at the beginning, doesn’t effectively help the user return to their saved progress).

Using the *goto keyword (described below) can also give you more options for introducing a login-required program.

Important note: It’s risky to make changes to your program once you already have users who are actively taking it. Though improvements to this are in the works, currently if you make edits to a screen that one of your users has paused their progress on, when they return to the program they may need to start again from the beginning. This is because GuidedTrack is both trying to load the new changes and return the user to the position they were last on, which is problematic if their position has been deleted. Look for better solutions in the future, and for now, minimize changes to your program, consider instructing users to go to a safe spot in the program before exiting (such as a screen they can get to via the *navigation menu that will never be updated), and consider adding code in the beginning of the program that can help users resume their spot quickly if they were bounced to the beginning.

Use *goto to direct your users to a new website

The *goto keyword typically allows you to direct users to any other part of your program (with the help of the *label keyword), but now, you can use *goto to automatically send your users away from your program and onward to a new website.

Why would you want to do this?

  • At the end of your program, automatically send your users to your personal website.
  • Create a tool that first understands your user’s needs, then automatically sends them to a website that can help them.
  • Send your users to other GuidedTrack programs (i.e. other run links). For instance, create a teaser program that describes the features of a much larger program (e.g. one that will take multiple weeks to complete). When the teaser ends and users decide they definitely want to try the rest, use *goto to send them to a new program URL that requires them to sign in before they can view more.
  • Whatever else you can imagine!

The code for this is pretty simple. For example:

Users won’t actually see the text in the example above (it’ll only flash on the screen briefly). Instead, they will automatically be taken to the GuidedTrack website (in the same tab/window, not in a new tab/window). Note: whenever a *goto keyword sends users to a new website, their current run in your program ends.

Use the *points keyword anywhere

You can award *points that will add up on your users screen if they get certain quiz questions correct… but you can also add points just because you want to show your users some love.

For example…

Of course, you can still use *points beneath correct multiple choice answer options in questions, and the below code would also work too, if you want to do a bit of extra typing:

The *points keyword also works with special types of points (points that don’t get visibly added on the corner of the screen, but are saved nonetheless).

“1” = 1

This change will be more exciting for people who have ever used URL parameters to provide custom reports or other programs with preloaded variables.

In the past, particularly with URL parameters, GuidedTrack would sometimes interpret a numeric variable as if it were a “string” or a text-based variable. Numeric variables are usually written as x=1, while string variables have quotes, like x=”yes” or x=”1″.

Now GuidedTrack can correctly interpret a line like this:

In this example, users would see the “Yay!” because GuidedTrack now knows to recognize the “1” as a number and not text.