GuidedTrack Blog

Recent Updates Page 12 Toggle Comment Threads | Keyboard Shortcuts

• 

  Aislinn 9:49 am on August 24, 2016 Permalink  

  Feature Update – *date/*time questions, schedule *when emails go out, more! 

  Here’s what’s new: Create a date/time question Save the current date/time Add or substract time Schedule an email for the future Cancel a scheduled email Schedule a recurring email Get the size of a variable Hide or show the “run again” menu

  Question that asks for a date and time When you want to ask your users questions about dates, times, or both, you can use the calendar question.  By default, adding *type: calendar beneath a question will produce both a date and time feature: If you’d rather just ask a time (and not a date): Or a date, but not a time: You just set your preference by adding *date: yes or *time: yes. Or, if you’d rather, you can add just a date question by adding *time: no, or add a time question by adding *date: no. As long as you communicate what you do want with a “yes” or don’t want with a “no,” you’ll be all set. You can use other question-related keywords with this question type as well, such as *tip, *save, and even *default.

  Save the current date and time Sometimes you need to know the exact moment a user answered a question or reached a certain point in the program. Whatever the reason, you can now store the current date/time like this: Just make a new variable and call it whatever you want (e.g. “thisMoment” or “time1”), and then set it to equal calendar::now.  If you want to store just the current time, or just the current date, you can do the following, respectively: You can display these variables to the user just as you would any other variable, with {curly_brackets}. The date+time, time, and date, display like this in GuidedTrack, respectively:

  Add and subtract time What if you want to communicate with users about not only the current date/time, but dates in the past or future? For example, if you want to remind the user to do something two weeks from now, you’ll need to know what date that is.  You can create a new variable that takes the current time and add or subtract from it, like so: In this example, you just come up with a name for your variable (e.g. “two_weeks_from_now”), and then equal that to be calendar::now (which gets the current date and time) + 2.weeks (which adds two weeks).  You could instead add 3.days, or 5000.seconds, as long as you add a period in between the number and the time unit. Here are all the time units you can manipulate: .seconds .minutes .hours .days .weeks .months .years You can similarly add or subtract units like seconds/minutes/hours from calendar::time (the current time), or days, weeks, etc., from calendar::date (the current date, without the current time). You can also add or subtract from something other than the present. For example, let’s say your user will be working on a new habit for 21 days, starting on a day of their choosing, and you want them to mark their calendar when the 21 days is up.  You could do something like this: In this example, you’re not looking to add or subtract from calendar::now (the present time), you’re adding or subtracting from a different calendar-based variable (“habit_start”).

  Schedule an email for the future You now know how to get the current date/time, and how to project into the future. Now you’re ready to synthesize this information to schedule future emails. You can schedule emails using calendar::now or using a variable. For example: All you need to add to your email is the *when keyword and the time the email should go out. Then, simply add this email code somewhere in the program where the user is sure to pass over. For example, if you want the user to complete a followup quiz, you could add the followup email reminder at the very end of the original quiz. That way, the user will pass over the code once they’ve completed the quiz and the server will store the email and its contents to be delivered to your user in the allotted time. However, if the user quits the original quiz halfway through, they’ll never reach the end (or the code with the email for the followup quiz) and will never be invited to your second quiz.

  Cancel a scheduled email Let’s say you have an awesome program, but 60% of people drop out halfway through and you want to know why. You’d like to send a followup email to these people to see what the hell’s the matter with them. You can create a scheduled email halfway through your program, and then cancel it at the end of the program so that those who finish never get it. Here’s what I mean: In the example above, once users get halfway through this program, an email will be scheduled for the future. However, at the end of the program, this email gets cancelled. For users who drop-out early though and never reach the end, the email doesn’t get cancelled, it goes scheduled as planned. The key to using this feature is to add the *identifier keyword to your emails, along with a unique name. When you need to cancel the email, you just type the *identifier name along with a *cancel keyword. You can schedule and then cancel all kinds of emails, including things like: The user states they want you to remind them to complete some task, but then they change their mind. You’ve scheduled a reminder to return to the program in the future, but the user remembers to return on their own and now no longer needs the reminder. You’re sending a recurring reminder (see below) and now need to cancel it.

  Schedule a recurring email Let’s say the user will be completing an intervention each day for seven days, and you want to send out a reminder each day to complete the task. You’ll need to use the *identifier keyword, so you can be sure to cancel the email later. You’ll also use the *every keyword, to specify how often the email should be sent out. The most an email can be repeated is once a day (not hourly, for example), and users will very soon be given an option to opt out of your recurring email by clicking an automatic opt-out link that will occur at the bottom. The future holds more enticing special effects, like a keyword to specify when a recurring email should end. But for now, using the *while or *repeat keyword with *email, along with a couple clever hacks (a variable of a date that increases by one day each iteration of the while/repeat), is the best way to cancel such a recurring email.  It’s also nice to give the user an option to opt-out of recurring programs from within the program itself. For example, you could have a settings menu with an option to control email frequency. You would then rely on the *cancel keyword as described above to cancel the existing recurring email, and then perhaps re-create it with the user’s new, preferred frequency. It’s also good to not be a creepy sketchball, and ASK the user first before sending any kind of email, especially recurring ones!

  Get the size of a variable You may be familiar with using .size to find out how many entries are in a collection variable (for example, in a collection of >>pets=[“cat”, “dog”, “monkey”], pets.size would equal 3). You can now also use .size to learn things about text-based variables, like: Did your users write too little in the question you asked?  Or, Did they use too many characters? For example, Sort of relatedly, you can also find the exact letter in any position of a variable. For example, In the code above, you can find out a person’s initials by getting the first character of their first and last names.

  Hide or show the “run again” menu In the top-right of a user’s view of your program there’s a little menu that allows the user to run the program again from scratch: It’s a pretty considerate option to allow. Users can retake your program over and over. But what if you don’t want to provide this option? Like, what if your program is crazy huge and restarting would be disastrous for the user? Or you have an experiment, and you don’t want the user to take it a second time? You can turn off this menu by adding this code: Now that menu in the top-right disappears like magic.

   
• 

  Aislinn 12:17 pm on May 3, 2016 Permalink  

  Feature Update – *multiple answers, *confirm answers, *trendline 

  Here’s what’s new: Users can give *multiple answers to a single question Have users *confirm their answer choice before continuing Scatter graph *trendline is now off by default

  Allow users to list *multiple answers to one question Some questions have more than one answer. For example: When asking users a question that requires list-like responses (e.g. asking them to list their favorite things, their brainstormed ideas, or their bank account numbers – no, don’t do that one), it’s easiest to use the new *multiple keyword. Just add it beneath a regular text box question, like so: When users see the question, they’ll be able to add multiple responses, edit any of the responses on their screen, and delete responses, as the little icons in the example imply.

  *confirm users’ multiple choice selection before they continue on If you have a long series of multiple choice questions, it can be easy for users to get sloppy – misclicking an answer here or there.  You can help users out by adding *back buttons to your program so they can correct a mistake, and you can also have them *confirm their selection. With the new *confirm keyword, users select a multiple choice option and it stays highlighted on their screen. Then, they click ‘Next.’ This 2-step process should reduce mistakes. To use *confirm, simply enter it beneath a multiple choice question:

  Scatter graph update – the *trendline is off by default In days past, when you added a scatter graph, a trendline would appear automatically, showing whether your data trends upward, downward, or just flat.  Now that trendline is off by default. To add a trendline manually, use *trendline, like this: Trendlines look something like this:

   
• 

  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!