GuidedTrack Blog

Updates from Aislinn Toggle Comment Threads | Keyboard Shortcuts

• 

  Aislinn 2:07 pm on May 30, 2014 Permalink  

  Feature Update – checkbox questions, *maintain update 

  Here’s what’s new: Adding checkbox questions. Changes to the *maintain keyword. An overview of the new GuidedTrack website.

  Checkbox Questions Now you can ask your users checkbox-style questions. Simply write and indent “*type: checkbox” beneath your *question to allow your users to select as many responses as they wish. As we’ve done in our example, you can still use the *save keyword with checkbox questions. When saved answers are recalled, all of the answers the user selected in the question will be displayed. For example, if a user selected “dog” and “cat” in our example, then they would see “dog, cat” in the following: Using the *save keyword with checkbox questions is especially useful if you’d like to provide follow-up questions or text to users who select specific responses. Since points are the only content you can indent beneath checkbox responses, the *save keyword will help you add more advanced follow-up. Customizing responses for specific items in collections Answers to checkbox questions are stored in what’s called a “collection.” You may recall that collections are also used for chart data. Let’s return to the pet checkbox question. If a user selected “Dog,” “Cat,” and “Hamster/other small furry thing” then the collection of their answers would be stored as this in GuidedTrack language: [“Dog”, “Cat”, “Hamster/other small furry thing”] Because we’ve also used the *save keyword, this collection will be saved by the variable/codename “pets.” Later, if you wish to target only cat people with follow-up questions, you would use the following code to test whether the “Cat” answer is “in” their “pets” collection: Note: Capitalization is important. We couldn’t write “cat” here because our exact answer option read “Cat”

  Changes to the *maintain Keyword Just like the *clear keyword, the *maintain keyword will no longer provide a mandatory page break. A *maintain keyword provides text that is held constant at the top of the page. Previously, whenever a *maintain keyword was used, there was also some sort of page break, and the maintained text occurred on the new screen. For example, when there was a question preceding the *maintain keyword, the question caused a page break and the new screen contained the maintained text. When there was text preceding a *maintain keyword, then the *maintain keyword also created a button that said “Next.” The button produced a page break and the very next screen contained the maintained text. Now, the *maintain 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 *maintain keywords that are preceded by text. This code is not necessary for *maintain keywords preceded by questions. In other words, the *maintain keyword no longer forces a button to occur (neither does the *clear keyword).

  The New GuidedTrack Website GuidedTrack’s editor keeps getting snazzier. New quick reference toolbar A new toolbar on the left-hand side of the Edit page gives you handy reminders of how to use GuidedTrack keywords. More ways to share your program Now you can grab the share link, get a link for your website, or get a code to directly embed your program on the web. Click the “Share” button to see all the options. Better onboarding for new users New users can now get familiar with GuidedTrack fast. New account holders are walked through a brief tour of GuidedTrack and are given sample programs to start with in their program list. If you know anyone who might be interested in GuidedTrack for their own projects, now may be a great time to invite them on board. In addition, you can try out our new tour yourself by clicking the “Tour” button at any time from the top of the screen.

   
• 

  Aislinn 2:17 pm on March 24, 2014 Permalink  

  Feature Update – *progress, *chart, *repeat, and more! 

  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.   This change was made to allow for exciting new elements in GuidedTrack. You are now able to *clear the entire screen of anything on it, not just maintained text! For example, you can have a program like this:   In this sample program, once the timer is up the instructions and the image is cleared from the screen and the user only sees the question, “Where was the cow?” With this new change, the user does not have to click any “Next” buttons in order to see the question.   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.

   
• 

  Aislinn 2:40 pm on January 30, 2014 Permalink  

  Feature Update – *audio, *quit, and better CSVs! 

  Here’s what’s new: Add mp3 and ogg audio files using the *audio keyword. End your program with the *quit keyword. Add text *before and *after your question box. See a chart showing answers to a question. Learn where a user stopped their run by checking out a new “Position” column in your CSV (comma separated values data file). Also in the CSV, check out the end values of all variables used during each run.

  Add Audio Files Now you can add mp3 or ogg audio files directly into your programs. Hint: there are some great ogg freebies on Wikimedia Commons. Add an audio file Here’s the default way to add a file. Users will see an image like the one above and can click a play button to get your audio started. Play your audio file automatically To have your audio file play automatically without the users needing to hit a play button, simply add *start: yes beneath the file. It will start on its own. Hide your audio file You might not want your users to see an audio image like the one we showed you above. Simply type *hide: yes to hide your file. The setting shown below will cause the audio file to start playing immediately in the background.

  Use the *quit Keyword Allow the program to end wherever and whenever you like. When inserting the *quit keyword, users won’t be able to see any line of text or keyword that may follow it. The *quit keyword may be especially useful in multiple choice options, where one option causes the program to end and the other allows it to continue.

  Add text *before and *after a question box Now you can add text immediately before and immediately after the box in which users can write an answer to a question. It looks like this: These keywords are easy to add. They also work with any other question add-ons. So, if you’d like users to enter a number, but want to provide a dollar sign for them, simply enter something like the following: Similarly, to enter a % sign try the following:

  See a chart showing answers to a question When viewing all answers given for a question, you’ll now be able to see a bar chart of how that question has been answered by your users. Here’s a sample of what it looks like. As you can see, five people answered that there favorite color was “fuzzy wuzzy brown,” which was about 45% of the total answers. Here’s how to find the charts. Go to the Data screen of your program. Click the Questions tab. Select a question of interest to you. Marvel at the chart. Voila! You can see a fancy pants graph (soon to be fancier) showing you the percentage and number of times an answer was given. Tip: You can also access this by clicking “Answers” for any user’s run and selecting a question of interest from there. This chart will show for all types of questions, including multiple choice, text, and paragraph. However, if there are more than 15 unique answers (which may be especially likely in a text or paragraph question) then the chart will not appear, (at least, not yet).

  See the Last Place of a Run in the “Position” Column of a CSV You’ll now be able to tell how far along a user has gotten in their run by looking at the CSV file. Check out the column “Position.” It will show a unique code (aka “node”) that represents the text or keyword that was at the top of the last visited screen. Tech jargon: Nodes are unique identifiers, made up of a 7-character string of numbers and letters. Each line of text, keyword, question and answer pair, etc. will have a unique node.

  See the Final Value of Variables in the CSV Your program may use variables with the save keyword, the set keyword, or with the option to save variables using >>. The value of these variables may be different for different runs or at different points in a run. You’ll be able to see the final value of a variable in the CSV of your data. In our example above, you can see that 2 variables were part of our program, “Name” and “Likes_Sugar.” Here’s a peak at the program that produced these variables: The variable “Name” was created using the *save keyword.  In our case, we asked users their name and saved their response by typing *save: Name. Variables saved using the >> function will look similar in a CSV. The variable “Likes_Sugar” was created using a *set keyword. When a *set is triggered during a run it will produce the value “TRUE” in the CSV. As you can see, in 3 of the 4 runs users set off the variable “Likes_Sugar” by selecting “Yes” when asked if they like sugar.