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.