GuidedTrack Blog

Recent Updates Page 13 Toggle Comment Threads | Keyboard Shortcuts

• 

  Aislinn 3:48 pm on February 2, 2016 Permalink  

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

  Here’s what’s new: GuidedTrack’s recent makeover Make a *list with content that users can expand and close New setting allows users to save their progress from any computer or browser Use *goto to direct your users to a new website Use the *points keyword anywhere, not just under questions “1” = 1

  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.

   
• 

  Aislinn 12:01 pm on November 13, 2015 Permalink  

  Feature Update – use a collection variable to show *answers to a question, CSS *classes part 2 

  Here’s what’s new: Use a collection variable to show the *answers to questions Use *classes to add custom CSS from the *settings keyword Tip: you can add symbols to GuidedTrack programs

  Use a collection of your *answers beneath a question Consider this scenario – You’re lazy and want to type as little as possible in your program. You have to ask your users 10 yes/no/maybe questions in a row. Rather than type the answers each time, you use *answers, like this: In the above example, users will see each of these multiple choice questions along with the answer options of “yes,” “no,” and “maybe.” Here’s a second scenario – you have a program that allows users to create their “Bucket List,” all the things they want to do before they die. It’s totes amazeballs. You know that some unimaginative users will come up with two goals though and the over-achievers will have hundreds. At the end of the program, you want to show users their entire bucket list and ask them to select the one thing they’ll do first. That’s where *answers will come in. Here’s an example: In this program, the *while keyword allows the user to add as many things to their bucket list as they want, until they leave the box blank. Each of their ideas is added to a collection called “bucketList.” When they finish, they see a question that asks for the goal they want to achieve first, and they see a multiple choice list of all their bucket list ideas. The *answer keyword works for multiple choice, checkbox, and slider questions.

  Add custom css beneath *settings Earlier we told you about how CSS smarties can add custom *classes beneath individual elements of GuidedTrack. Now you can do something similar with *settings. So, for example, if you wanted to right-align all the text in your program, you could write your code like this:

  Add symbols to GuidedTrack program Did you know that a lot of symbols are compatible with GuidedTrack? The symbols from this list of miscellaneous symbols on Wikipedia all work wonderfully. Simply copy and paste the one you want into your program. You might delight in dotting your program with little snow people, or find it useful to add checkmarks to multiple choice options after people complete a section of your program. You can even use the frowny face to show your disappointment in your users. Of course, you can also add an *icon to multiple choice and checkbox options as well.

   
• 

  Aislinn 4:21 pm on September 17, 2015 Permalink  

  Feature Update – *shuffle answer options, add *default text, and create CSS *classes 

  With *shuffle, you can more easily randomize the answer options in a multiple choice, checkbox, or slider question. *default allows you start any question type with a pre-populated answer. The especially computer-savvy can also add custom CSS using *classes.

  *shuffle the answer options presented in a question Provide *default answers to questions Use *classes to add custom CSS to individual elements Downloading your data just got way faster

  *shuffle the answer options in a question Did you know that people select the first option in a multiple choice question more often than any other brilliant answer you could have given them? Is it out of laziness? Subconscious beliefs that the first option is best? Reckless captivation of the heart? We don’t know.  What we do know, is that you can now remedy this problem by randomizing your answer options so that your results aren’t skewed by position bias.  It’s rather easy: In the above example, users will either see the sneeze option first or the latter possibility.  Just indent a *shuffle beneath any multiple choice, checkbox, or slider question (numeric values excepted) that you’d like to randomize.  Note though, that *shuffle is probably not useful for answer options that lie on a continuum (e.g. cold, cool, warm, hot). Shuffle these only if you want to annoy your users.

  Provide *default answers to questions Giving users a little boost in answering a question, or allowing them to revise a previous answer, is now possible with *default. You use *default when you want to pre-populate a question text box with an answer. Or, when you want other question types to have pre-selected answers.   Text and paragraph questions When a text box is clicked by your users, your default text won’t disappear (it’s not hint text), but rather your users can submit the answer as-is immediately by clicking submit or edit the text before submitting. Here’s how the code might look: And here’s how the above code would look to the user:   Checkbox questions To use default with a checkbox question, just add all the options you want selected to a collection. Here’s how the above code would look:   Multiple choice questions To give a default answer to a multiple choice question, just write the exact text to the one answer you want preselected. For example: Here’s how this would look:   Variables You can also use variables with *default, like so:

  Add custom css with *classes CSS smarties can have hoards of new fun with GuidedTrack by adding custom *classes beneath individual elements of GuidedTrack. For example, if you’re embedding a GuidedTrack program and want just the *header on the first screen of your program to match those of your website, you can define some classes on your website and then do something like… By indenting *classes under just about any individual elements (buttons, questions, headers, even text), and adding the CSS code, you can snazzify your program so that specific elements look just the way you want them. The classes you create will appear in the HTML that GuidedTrack generates. Then, you can include rules for these classes inside the CSS of your website. Of course if you want to change all the buttons, headers, etc., you can always override all of GuidedTrack’s CSS on your website. But, if you want just one button to be rebelliously unique, or a specific set of GuidedTrack elements, *classes has got you covered.

  Downloading data just got faster Thanks to some handy work of our developers, you can download the csv of your data at even quicker speeds!