GuidedTrack Blog

Updates from Aislinn Toggle Comment Threads | Keyboard Shortcuts

• 

  Aislinn 5:05 pm on April 12, 2016 Permalink  

  Feature Update – new chart options! *color, *type: line, *ticks, multiple axes, and more 

  Here’s what’s new: Pretty chart colors Line graphs Add ticks to customize the graph axes Multiple *data keywords on one chart Multiple chart types and chart axes

  Pretty chart colors We’ll start with the easy stuff. Splash up your graphical displays with some color. To start, you can find your favorite color from this website: http://colours.neilorangepeel.com Copy down the rgb code. For example, if you’re a fan of peachpuff, the code you want looks like this: rgb(255,218,185) When you’ve got your fav, you simply add it to your chart’s *data using the *color keyword, like so: In this example, we’re only using one color, not six. We’ll get to adding multiple colors in a bit. If you want boring colors like solid “blue” or everyday “red”, then you don’t need the rgb. You can just type *color: blue. This will work for many of the basic colors, and a few of the more creatively named. If you like the color you have, but it’s a little too intense, you can add *opacity to make it somewhat see-through, like this: Opacity should be a number ranging from 0 (totally see through) to 1 (totally solid). Here’s how peachpuff looks with different levels of opacity: If you have a custom color you want to use, go for it. The *color keyword will work with any rgb, not just the ones listed on the website above.

  Line graphs Let’s say I want to chart how my millions of dollars have grown over time (cause I’m saving for a yacht big enough to hold my helicopter). I can use a line chart like this: The code for this is pretty simple. You add data similarly as you would in a scatter plot, indicating the x and y points. You also do *type: line Here’s the example:

  Add *ticks – i.e., customize the look and position of the intervals on the axes Charts with money are fun, but they’re hard to read without $ signs. Maybe I also only want to show intervals of $10,000,000, instead of $5,000,000. And maybe I want to call that $10 mil. instead of using all those annoying 0’s. Let’s try this: Much better! Here’s how to do that: It’s the same line graph as the one in the earlier example, but this time I’ve added something called “*ticks” indented beneath the *yaxis keyword. The *ticks keyword let’s me specify [the numerical value of where I want the tick to go, “the label I want to give that tick”] In the case of *ticks, the value comes first and the label comes second. With bar graphs, the reverse is true (bar label, then value). We didn’t do this to try to confuse you, but here’s a tip: in each case try to put the most important info first. Whereas both the bar label and value are required, the label on *ticks is optional information. You could also just have something like *ticks: [2, 4, 6, 8, 10], which would display just the even numbers and label them for you automatically. By the way, I decided not to buy a yacht for my helicopter after all. Instead, I decided to learn the principals of Effective Altruism and give my money to highly efficient charities and save lives. Go me! My new goal is to chart my quarterly distributions to charity. Instead of having an x-axis with years, I instead want them to say “Quarter 1”, etc… like this: The code is very similar as the earlier code, except now I’ve also included *ticks for the *xaxis: You’ll also notice that for the first *yaxis tick I used “” as the label, which means the label is just blank. This can sometimes be helpful for making your chart look a little smoother. Don’t forget you can also use *min and *max beneath your *xaxis and *yaxis to help smooth things out. For example, the x-axis is looking a little crowded. If we set our *min at .9 and our *max at 4.1, they’ll be a little more room. Here’s the code with the new *min and *max added:

  Multiple *data keywords for multiple customizations Now let’s return to colors. Remember my chart at the beginning? With all the super awesome colors? The key to this snazziness is using multiple *data keywords. Each *data keyword gets its very own *color keyword. If you just indent *color: yourcolorhere beneath the *chart keyword, that color is going to apply to the entire chart. If you want to be more specific, then you’ve got to be more specific with your indents. Check out the below code and see what I mean: Instead of lumping all my data points into one *data keyword, I split them up, so that I could then apply a unique *color attribute to each *data point. The outcome to the above code will look like this: If you want mostly light blue bars, with just one vibrant orange, then you do this: The lightblue becomes the default color for all the bars, because it’s indented beneath the *chart keyword, but the color for the fourth bar is overridden with an orange color.

  Multiple types of charts on one chart – and multiple axes on one chart Let’s say you want a line graph AND a bar graph on one chart, cause you’re a chart maniac. For example, you’re a farmer charting how many pounds of kale you sold and how much money you brought in. You want your final chart to look like this: To start, you have two different types of charts. You’ll need to add multiple data keywords, one for each type of chart. In our code above, we’ve used the numeric values of the summer months (6 for June, 7 for July, 8 for August). We’ve also indented the *type keyword beneath each data keyword to specify how to display the data. We’re showing the pounds sold as our bar graph data and the income made as the line graph data. This code results in a pretty ugly chart though: More work is needed! The number of pounds sold ranges from 32-44, while dollars earned ranges from $320-$396. Each data type will need its own *yaxis for good chart chemistry. We can have multiple y-axes and/or multiple x-axes. We just have to be sure to give each a name, and then link their name beneath the data they serve. We also have to tell the program where to *position each axis: on the left, right, top, or bottom, like so: In this code, we’ve now indented *yaxis: pounds beneath the bar graph data, because that’s the data it’s attributed to. “pounds” is just the name we made up, you can call your axes anything. We’ve also indented *yaxis: dollars beneath our line graph data. Next, if you have multiple axes, you should specify their *position. In this case, we want the pounds’ *yaxis to be on the left side of the chart and the dollars’ *yaxis to be on the right side of the chart. You always indent the specifications of an axis beneath a *yaxis or *xaxis that is indented beneath the *chart keyword, not beneath a *data keyword. Axes are attributes of the entire chart, and multiple *data keywords can share the same *yaxis or *xaxis information. That’s why, when you want to provide details about the axes (such as their *ticks, *position, *min, or *max), you include this info beneath the *chart keyword more broadly. In other words, this is bad: Okay, now our chart looks like this: Getting better! But still not great… Let’s change the *ticks on the y-axes so they’re more clear… This is the same code as before, except now we’ve specified how we want the labels to read. The easiest way to add *ticks to a chart with multiple axes is to first look at where the ticks naturally fall (in our earlier chart you can see there are lines on the 10, 20, 30, 40, and 50 marks on the left axis). Once we know where the lines naturally fall, we can work with these existing lines to give them better labels. “10” becomes “10 lbs”, “20” becomes “20 lbs”, and so on. If you don’t like where the lines naturally fall, you can try first adding *min and *max values to the dominant axis. The lines will only appear for one axis, not both. For the second axis, you just have to add labels wherever you’d like them to appear. In this case, we wanted the labels to increase by $25, starting with $300. We added code for the *ticks at the 300 mark, which would read “$300”, another at the 325 mark, to read “$325”, and so on. Now our chart looks like this: That’s pretty good! New *ticks for our *xaxis and some colors would improve things though. Plus, it’s hard to see the lines through the bars, so we should add some *opacity. If we set the *min for the *yaxis: dollars to 275, that would also align the dollar values with the lines corresponding to the pounds, which would look swell!… This final code generates the image we started this section with. For a reminder, it looked like this: With our code, we didn’t need to specify a name for the *xaxis, because there’s only one. If we wanted to though, we could add more. One at the top too. We could even add multiple x-axes at the bottom! We could have 6 y-axes and 7 x-axes just because we were feeling crazy!

   
• 

  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.