GuidedTrack Blog

Recent Updates Page 10 Toggle Comment Threads | Keyboard Shortcuts

• 

  Aislinn 5:57 pm on November 12, 2018 Permalink  

  A *service case study: Using Zapier and IFTTT to connect to Google Sheets 

  There are two awesome tools we want to highlight that you can use with *service to connect your GuidedTrack program to the APIs of hundreds of other apps and services – Zapier and IFTTT.

  For example, you could potentially do the following:

  • Save a date in your Google Calendar or Calendly
  • Add to-do items to Trello or Todoist
  • Send important info to Evernote
  • Show an event via Eventbrite
  • Show the weather or photos from NASA
  • . . . and more!

  As outlined here, you can also send GuidedTrack variables to a Google spreadsheet, which would mean your sheet would be populated in real time by users taking your program.

  There are a number of ways this could be useful, for example:

  • Easily see your most important data arrive in real time.
  • Add formulas for to your spreadsheet to do automatic calculations.
  • Efficiently share specific data with others.

  The two services covered are:

  • Zapier: Zapier is a tool that connects multiple apps to each other. The *service keyword will send data to Zapier, which will in turn populate the appropriate columns in a Google spreadsheet. If you want to send data from GuidedTrack to Zapier you will need a Premium account, but currently you can try it for free for 14 days.
  • If This Then That (better known as IFTTT): IFTTT is another service that connects apps with each other. With IFTTT, you can send user data an unlimited number of times, but you are limited to populating only three columns.

  Using Zapier with GuidedTrack (for instance to add a row to a google spreadsheet)

  1. Prepare your spreadsheet

  Go into google spreadsheets (http://spreadsheets.google.com) and create a new google spreadsheet that will be the one you’re adding rows to via GuidedTrack. Fill in the the first row of this spreadsheet with the column names (for example, “Customer’s name”, “Customer’s age”, “Registered on”, “At”):

  

  2. Write your program

  Here you have the sample code to send four variables to Zapier, see how you can use both text and number variables:

  >>name="Peter"
  >>age=34
  >>date="October 15th, 2013"
  >>time="9:33 am"
  
  Sending data to google sheets…
  *service: zapier
  	*path: /
  	*method: post
  	*send: {"Name" -> name, "Age" -> age, "Date"->date, "Time"->time}
  	*success
  		Success!
  		>>result = it
  	*error
  		Failure!
  		>>result = it
  *Response from zapier server*: {result}
  *button: Done!

  3. Create and test a Zap

  1. Create a zapier account at: https://zapier.com.
  2. On the dashboard click Make a Zap!
  3. You will now be asked to select a trigger event to start the Zap. Click on the Webhook icon.
  4. Select Catch Hook on Trigger Event and then click on Continue.
  5. Zapier will give you a Custom Webhook URL. Copy it to your clipboard.
  6. Switch to the tab where you have your GuidedTrack program and go the program Settings. Go to the Service tab and create a New Service. Use the URL on your clipboard and name the service zapier. Leave empty all the other fields and save.
  7. Click preview in GuidedTrack to run the code. If you have configured the service correctly, you will see on the screen that the status of the response from Zapier is Success. This means that GuidedTrack is communicating with Zapier.
  8. Go back to the tab or window where you have Zapier to check that it is receiving the data correctly. Click on Continue and then on Test your trigger. It should display the fields Name, Age, Date and Time populated.
  9. GuidedTrack is communicating properly with Zapier, now you will be configuring what Zapier does with the message received from GuidedTrack. Click Continue and select Google Sheets.
  10. Zapier will ask you to choose an action event. Select Create Spreadsheet Row and Continue.
  11. Connect to your Google account (you may have to grant Zapier access to it if you have not done it before). Then, Continue.
  12. Select the Google drive where the spreadsheet is located, the spreadsheet and the tab (worksheet) where the table you created is. Map the data that Zapier receives to the columns of your target table as shown below and Continue.

  

  13. Click on Test & Continue. The following screen should display a message saying that the test was successful. Go to your spreadsheet and check that a row was created:

  

  14. If everything looks right, go back to Zapier, click on Turn on Zap and you’re done!

  Using IFTTT with GuidedTrack (for instance to add data to a Google spreadsheet)

  Note: when it comes to Google spreadsheets, IFTTT is unfortunately limiting to only adding rows that have no more than 3 columns of data. Use Zapier if you need more than 3 columns.

  Step 1: Create an IFTTT account at https://ifttt.com

  Step 2: Once past the onboard, type “sheets” in the search/filter box, click on the “Services” tab, and click on Google Sheets

  Step 3: Click “Connect” and then set up the connection with your Google Drive / Google Sheets account

  Step 4: Click your username in the upper right and choose “New Applet”

  Step 5: Click on “this” in the “if this than that” and search “webhooks” in the search/filter  then click on it. Then click “Receive a web request”

  Step 6: Give it the event name: guidedtrack_data

  Step 7: Now click on “that” in the “in the “if this than that” and search Google Sheets and click on it. Then click “Add row to spreadsheet”.

  Step 8. Fill in the form to give the spreadsheet a name and choose a path where it will be saved within Google Drive if you like. Leave the “formatted row” unchanged for now. Click “Create action” then click “Finish”.

  Step 9: get your webhook key, which you can find here:

  https://ifttt.com/services/maker_webhooks/settings

  The key is the last part in the URL shown, the last part of:

  https://maker.ifttt.com/use/YOUR_KEY_HERE

  Step 10: Create a new guidedtrack program, so you can test out sending data to your google spreadsheet.

  Step 11: Once you’ve created this GuidedTrack program, go to its editor window, then click “Settings” then click “Services” then click “New Service.”

  Fill in this info:

  Name: ifttt

  URL: https://maker.ifttt.com/trigger/guidedtrack_data/with/key/YOUR_KEY_HERE

  where guidedtrack_data is whatever event name you set before, and YOUR_KEY_HERE here is the key from the ifttt webhook settings page.

  You do not need to enter a username or password.

  Then click “save” to save your service.

  Step 12: Go back to the GuidedTrack code editor, and put in this code:

  Sending data to google sheets…

  >> value1 = 100

  >> value2 = 19

  >> value3 = 24

  *service: ifttt

          *path: /

          *method: post

          *send: {“value1″->”{value1}”, “value2″->”{value2}”, “value3″->”{value3}”}

          *success

                  >> result = it

          *error

                  >> result = it

  *Message from ifttt*: {result}

  *button: Done!

  Try previewing this program a couple of times to send data to your spreadsheet.

  Step 13: Open up google sheets (http://sheets.google.com) and look for a folder IFTTT in your google drive. Go a couple folders deep inside that folder to find your spreadsheet! (unless you edited the path it got saved to, in which case it’ll be located wherever you indicated). If you wish, you can add column headers. You can also remove text you do not need from the GuidedTrack code (such as “Sending data to Google Sheets”).

   
• 

  Aislinn 1:25 pm on July 17, 2018 Permalink  

  Feature Update – *picture with questions, logos with logins, and *switch, removing “Reset everything” from the hamburger menu 

  Here’s what’s new: Use pictures as answer options Add your logos to logins Remove “Reset everything” from the hamburger menu Introducing *switch: when the user’s position is in multiple places at once

  Use pictures as answer options Doing so is simple with the *picture command added to a *question: Your answer options must include text (so you can’t have just a picture), but you can include some answer options that don’t have a *picture keyword at all (e.g. adding a text-only option to the above like “Music is dumb”).

  Add your logo to logins If you require users to login to your program (i.e. create a GuidedTrack account so they can maintain their position in your program from multiple devices), you can add your logo to the sign up/sign in page.  From the “Settings” tab, under “General” you’ll see a spot to add your logo. By adding your public name and an email display name, you’ll also ensure that the sign up confirmation email displays your name as well as your logo.  Special note: Users who are logged into your program are now also automatically given a “Sign out” option from the hamburger menu.

  Remove “Reset everything” from the hamburger menu The “Reset everything” option (previously known as “Run again”) provides users a chance for a clean slate on your program. It ends whatever progress they’ve made and allows them to start from the beginning of your program.  However, if your program is a 10-week course on becoming a professional canine couturier, this option could be detrimental to a young pupil on their 8th week toward success who clicks this by accident and is forced to start anew.  To turn off this otherwise handy option, visit the “Settings” tab, click “Run menu,” and then click “Hide”:

  Introducing *switch: when the user’s position is in multiple places at once The new keyword *switch is for the rare program that keeps track of the user’s position in multiple places at once, allowing them to *switch back and forth, or apps that have multiple distinct sections that you want to be able to switch the user back and forth between easily. For example, let’s again say you have a program that teaches the finery of dog fashion design. There are 10 scintilating lessons, but the user is allowed to take them in any order, and can pause one lesson to switch over to another, then switch back again to finish the earlier lesson up later. In this scenario, you could use the *switch keyword, and your program could look something like the following:  Above, the user might start in the lesson 1 program, but a navigation placed at the top can be clicked to *switch them to an organizing “home” screen, where they can select a different lesson to *switch into. From there, they can *switch into any of the other lessons, or back again into session 1. How switch works: *switch: The name of the program to switch to     *reset (an optional attribute to start off fresh from the top of the program) As soon as the user hits a *switch command, they are immediately transferred to a different section of your program (and any text that might’ve been on the screen prior to the *switch is not shown, so it’s best to have *switch after a *button or page break).  There are two ways to switch: *switch with a *reset keyword indented below: users start at the top of the program, any previous progress is wiped out *switch without a *reset attribute: users resume at their last position within that program – if this is their first time in the program then they start at the top In our example program, when users *switch to the “home” program, the *reset attribute ensures they start off at the top of that program. When they *switch to a lesson though, since there’s no *reset attribute, they’ll start off wherever they were when they last switched out. What switches or changes with *switch? The features below do not persist as a switch is made (so they will disappear from the screen, if present, as a section is left, and reappear if they were previously present on the program being switched into): *progress *maintain *navigation Any points accumulated stay on the screen between switches. Variables can also be shared across sections.  In a program like our example above, we would have to put a *navigation at the top of each lesson that helps users *switch back into the home page, since *navigation is not something that persists between switches. What happens at the end of the program the user switched into? You’ll need to control what should happen when a user reaches the end of a program they’ve switched into. GuidedTrack’s natural response when there’s no further content to display is to assume the run is over, the user’s entire run (i.e., the next time the user opens the program it’ll be as if a “Reset everything” has occured).  For example, at the end of our lesson 1 program, we could include the following to control what should happen next: Once lesson 1 is complete, the user will be directed to the home screen. If we wanted to prevent users from starting lesson 1 over, the variable “lesson1” that’s been added (stored with the value “done”), could be used to remove this lesson from a list of lessons available to complete.  To sum, whenever a section reaches its end, use *switch to bring the user somewhere else.  Why is *switch superior here to *program? Switching around willy-nilly would be hard to pull off with the *program keyword alone. The *program keyword runs one program that yearns to be finished, returning the user back to the program that contained the *program keyword. You cannot create a loop where two programs continuously call each other via *program, as GT would grow wearisome and possibly crash. When a *switch is used, it is not necessary for the user to ever return to the program that called the *switch. Two or more programs could continuously switch back and forth, and GuidedTrack would be completely chill about the whole thing. In short: *program – run a program until it completes, automatically continuing on from here when done. *switch – switch to a program, pausing the current one until *switch is used to come back. Other times *switch would be useful? If your app has a “Home” or “Main Menu” where users can adjust settings, or could potentially get several subprograms deep into alternative content, and you want to quickly *switch them back into the main thing they were doing. If your app has a “Toolbox” or “Homework” that user’s can play around in, and you want to keep track of users’ progress in the various tools. When you’re developing a traditional app that has a persistent navigation bar, where clicking each navigation icon takes you to a different section of the app, you can use *switch to actually do the switching between the sections. Note that you’ll have to create the *navigation again at the start of each section, since navigation does not persist across sections. Any other time you use a *program keyword, but the *program you call may not run to its end.

   
• 

  Aislinn 9:04 pm on February 9, 2018 Permalink  

  Feature Update – *page, *startup, and using Airtable with *service 

  Here’s what’s new: Put a whole lot of questions, and whatever else, all on one *page Add content and/or code that launches at every *startup of your program Use Airtable as a *service in your program

  Put a whole lot of questions, and whatever else, all on one *page You asked for it, and now it’s here! The ability to do something like… You can put heaps of questions all on one page, and the regular things that can go on a page, such as text, headers, images, videos, etc., can be added before, between, or after questions.  This keyword is great for creating user “preference” pages or pairing related quiz questions. Simply add the *page keyword, and indent whatever you want included on that page below. GuidedTrack will automatically insert a page break just before your *page keyword and on the bottom of it if there isn’t one there already (in the form of a “Next” button”). You can also add your own buttons before *page or as the last thing indented beneath page.

  Add content and/or code that launches at every *startup of your program The new feature *startup (an attribute of the new keyword *events) can be handy when you have a program that users may return to more than once. It offers a block of code that will run FIRST each time a user loads your program, irrespective of their position when they last closed the program. *startup is great if: You have a program you’re continuously updating and you need to add the newest variables for users with older runs. You want to *trigger some event whenever someone returns to the program (e.g. using *trigger to send usage data to google analytics) You need to check how long it’s been since the last time the user started the program, and if it’s been a while, bring them to a different place than if they were using the program recently (i.e. using *goto with the *reset attribute, explained below) The below example covers the third use case. To begin, here’s a way you can check how long it’s been since a user was last in your program: Above, we’re first checking if the user has ever activated the variable last_load. If it’s their first time, then the *if is ignored and the variable last_load is activated immediately after. If it’s the user’s second or more time in this program, then they would have the last_load variable, so the *if is triggered and the time_elapsed variable is defined, which lets us know how much time has passed since users last opened the program. Once the content from *startup is complete, the program would then start from the position the user last left off on when they exited their run, even if that position is buried deeply within your program.  With *startup though, you can also change where the returning user will return to. For example, if it’s been a few days since the user opened your program you could make them start it over from the beginning. The *reset option lets us reset the user’s position and place them elsewhere… The *reset option exits the user out of any programs they may have been running (via *program keywords) and then takes them via *goto to a *label of your choosing on your main program page. In this case, *reset will send any users who’ve been out of the program for more than 3 days to the “beginning” label that we’ve put at the start of the program. The *reset attribute ensures users smoothly exit out of any subprograms they may have been in, ensuring your main program has full control.  Within *startup, *goto is only allowed if it has a *reset attribute, because a regular *goto will not exit users out of subprograms they were previously in the middle of, which may cause unexpected behaviors. It’s important to also note that page breaks are not allowed within *startup. This is intentional, as things could quickly become mucky and complex if users were to refresh the screen while within content of a *startup, or if *back buttons were in use.  In the future, the *events keyword will have additional, innovative uses that allow you to detect other important activities of your users. For now, *startup is the only keyword it supports.

  Use Airtable as a *service Airtable is a user-friendly database system that you can use like a spreadsheet as needed. Some reasons it could come in handy: Storing custom information (one row per user) that can be checked by someone else in real time (like looking at a spreadsheet, such as a professor quickly checking which students have finished a test). Storing information that will be shared across users (i.e. multiple users will need access to the same information, such as a dataset from a study). Storing information created by one user that is accessible to another user, like a high score in a game. Storing a list of things that each user gets only one of (which is then deleted from the spreadsheet once a user has gotten one, for instance unique coupon codes). Here we explain how to set it up to use with *service, how to add entries to your database (i.e. spreadsheets) from GuidedTrack, and also how to look up (i.e. check) entries in the spreadsheet. 1. To set up Airtable Go to Airtable.com, create an account, then create a new workspace. You want to avoid using spaces or special characters in the title of your workspace or in any of its tabs (sheets).   2. To integrate a GuidedTrack program with Airtable Go to the Services tab under Settings, and create a new Service as follows: (Click the image for a zoomed-in version).   Note that the URL will be different for you, based on your unique Airtable account. In order to get the proper link, go to your Airtable’s API page (we can’t include the link, since that page is unique to your account, but you can find it pretty easily).   Also note that you need to find your Airtable API key, which you can access from your Airtable account. (It will likely begin with “key” and then have a random string of case-sensitive letters/numbers.) Note than in this part of GuidedTrack, you need to type “Bearer” before your key.   3. To ADD entries to Airtable from a GuidedTrack program Use and modify this code based on your own Airtable tab name, column headings, and GuidedTrack variables:   Note that under *path, you’ll include the name of the sheet/tab in your Aitrable database you want to add to (the example here is called AccessCodes).     In this example, the spreadsheet columns are AccessCode, UserType, GroupName and AdminEmail—as partially shown here:   See how the code above sends two variables that have been defined in the GuidedTrack program, named accessCode and adminEmail. Note however, that for POST requests, any variable in GuidedTrack that isn’t text (e.g., a number, a list) won’t get passed properly to your Airtable spreadsheet, and the entire POST will fail but it won’t give you any error message. The way to fix it is to pass your variables within quotes. For example: Lastly, in our example the variable “posted” was created beneath *success and *error so that you can confirm in the csv of your program whether your attempt to send data to Airtable was met with success or not. You could also let users know the outcome, with something like the following:   4. To CHECK entries in Airtable from a GuidedTrack program Use and modify this code based on your sheet name, the column you wish to check, and the GuidedTrack variable it pairs with: Note that under *path, you’ll include the name of the sheet/table in your Airtable database you want to check (just like with adding entries, in this case “AccessCodes” is the name of the sheet). Then, the filterByFormula code tells Airtable what to look up. In this case, we are looking up all entries that have the field AccessCode (singular unlike the plural sheet name, which is also the first column in the screenshot above) equal to the variable tocheck (which was defined in GuidedTrack). Here’s a super handy tool for creating a URL that gets exactly the data you need.   Airtable retrieves the records in a funky way—it’s a list of a list of a list. So, to give an example, this is how you would extract the other fields: