Updates from Aislinn Toggle Comment Threads | Keyboard Shortcuts

  • Aislinn 10:54 am on January 10, 2017 Permalink  

    Feature Update – *until, *return, *countdown, new icons, and more! 

    Here’s what’s new:

    More super awesome icons!

    What’s more fun than a good icon? Pretty much nothing. Except maybe cake. Definitely cake. And beer, and sleeping, and bicycles…

    But look – icons!!

    Icons were covered earlier, but the list of potential flare you can bedazzle your program with has now expanded.

    In addition to the bootstrap icons we mentioned… you can now find way more (675 to be exact!) icons here: http://fontawesome.io/icons/

    To add either a glyphicon icon or a font awesome (fa) icon, you type *icon:, followed by the type of icon (glyphicon or fa), followed by a dash and the name provided on the site where you got it from. Like this:

    You can add icons to multiple choice or checkbox questions plus navigation options. Enjoy!

    Creating Associations

    Associations are sort of like neatly-organized collections that allows you to look stuff up fast. If you’re familiar with programming terms, these also go by the names “Hash tables,” “Associative arrays,” “Hash maps,” or “Dictionaries.”

    Here’s an example. Let’s say you have a terrible memory, and want to create a GuidedTrack program that can give you the birthday of any of your friends. You set things up so that all you have to do is type in their name, and their birthday pops up on the next screen.

    With that scenario, you might use an association to add all the starting data you have. Each entry in an association must include two things:

    1. A “key” (the term associated with each piece of data, in this case the name of your friend)
    2. Its value (such as the friend’s birthday).

    If you were a postal enthusiast, the keys of your next association might be thousands of zip codes, and the values might be the names of the town associated with each key/zip code.

    The code for associations is a little different, so to start, here’s an association with just one birthday entry in it:

    In this example, the name Justin is the key that you’ll use later to find the associated data, which in this case is Justin’s birthday, March 1, 1994.

    What’s perhaps most striking here is that you’ll use {curly braces} instead of [square brackets] to create the association. Also, the arrow ( -> ) is used to say something along the lines of “when I input this key, show me this thing right here.”

    The final program, once you’ve added more of your friends, might look like this:

    Each entry in the association is separated by a comma. You can then type the name of your friend, saving your selection as “friend”, and then, similar to the way you would show a specific position in a collection, you display that friend’s birthday by typing {friendsBirthday[friend]}

    You don’t always have to use a variable though to show items in an association. If you had Bieber fever, you could prominently display Justin’s birthday in your program by typing:

    While you could accomplish this same feat using collections and the *while keyword, associations make it much easier to look up values associated with other values.

    Adding or changing a single item in an association
    Once you’ve got a basic association set up, it’s easy to add or modify items.

    For example, let’s say you have an association of English words with their Polish translations. If you want to add a new word to this pre-existing association (which you’ve called polish_words), you can simply do the following:

    “tea” will be a new key added to the polish_words association, and “herbata” will be its value.

    Similarly, if you realized you misspelled something and need to replace the value for a given key, you can overwrite a key in similar fashion:

    If “cake” was already in the association, it’s value is replaced by “ciasto.” If it wasn’t in the association, then it’ll be added new.

    One more association example, for good measure
    If we revisit the earlier example about adding friends’ birthdays to an association, there’s another way we may want to organize lots of info we have about our friends. For example:

    In the above example, each friend has their own association, complete with different keys representing crucial details about them. The collection ‘myfriends’ contains all the associations. If you set things up this way, here’s a couple ways you could display data:

    The first line accesses the second association in the myFriends collection and displays the value to the key “name,” which is “Mariah.”

    The second line would display the key “Perfume” of friend3, which is the sensual “Eau de Gaga,” with its opulent woody-floral intensity.

    You could display all your friends’ signature scents, like so:

    Help the user *return to their original program

    There’s a new keyword that works particularly well when partnered with *navigation and at least one *program keyword, though it could have simpler use cases as well. This would be the *return keyword, which functions like a high-tech *goto. When users pass over the *return keyword, they go to the very end of the current program they’re in, which returns them to wherever they were prior to that.

    Here it is in a somewhat simpler form:

    (starting program):

    (Super Fun Exercise program):

    In the above example, users start the program, which then launches into the “Super Fun Exercise” program via the *proram keyword. Once there, they have a choice to “Play” or say “This is lame.” If they choose the latter, they immediately exit the Super Fun Exercise program via *return, and next see the text “Now we’ll do something else!” from the original program. If they instead choose “Play,” they’ll see the line “Let’s get ready to prancercise!” and any lines that follow.

    So why use *return when you could instead use a *goto keyword that could direct users to a *label at the end of a program? For one, laziness. You can now accomplish the same feat in one line of code instead of two. But suppose you didn’t actually know which program users were in? And suppose you instead wanted users to be able to exit out of the current program via an option in *navigation. Sounds weird right? Here’s an example to show you what I mean:

    The *goto keyword does NOT work across programs, so trying to add it beneath this navigation option would be of no use. But no matter which tool users are randomized into, the *return keyword will bring them out of the tool, to the next line in the original program, which reads “Alright, that’s the end!” Of course, it doesn’t have to be the end here, you could allow users to return to the beginning to try a new tool, or your program could just continue going forward.

    Note: If one of the tool programs itself includes an additional *program keyword that leads to a program that would carry the user through two or more screens, and the user is in that second program, *return alone isn’t going to cut it. *return only exits the user back one program layer, not several. So keep that in mind if you end up using *return! It can be tricky to use if the user needs to exit out of a program within a program within a program!

    Specify that a recurring email should keep being sent *until a certain date

    Recurring emails were discussed last time, but since then there’s been a new keyword added to make them even more effective: *until

    If you’d like to send users the same email multiple times (every Wednesday, for example), but have a natural stopping point (after one month), *until is the keyword for you.

    Here’s how this works using the example from last time.

    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 can optionally add the *identifier keyword, (if you may want to cancel the email early later on).
    • You’ll use the *every keyword, to specify how often the email should be sent out.
    • You can use *until to specify that the email should stop after 7 days.

    The most an email can be repeated is once a day (not hourly, for example), and users are now given an option to opt out of your recurring email by clicking an automatic opt-out link that will occur at the bottom.

    Timers for questions

    Want to restrict how much time a user has to answer a certain question before they automatically advance to the next page? Enter *countdown

    When you use *countdown, you can set how many .seconds, .minutes, or even .hours a user has to complete your question. The time remaining even displays just above the question like this:

    When time is running out, the timer turns red:

    The code is pretty simple, here’s an example:

    All you really need to use timers is the *countdown keyword specifying how much time the user can have before the page automatically advances.

    But in this example, we also used the *save keyword to store the user’s response. We can find out if the user left the question blank by checking the .size of the variable (gets the character length of the response). If the size is 0, then the user didn’t get to type anything in before the question disappeared.

     
  • 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:

    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:

    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:

     

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel