Implementing the QS Data Spec on iOS

As part of implementing the Quantified Self Data Spec (look here for an introduction), I’ve started implementing it on iOS so that I’m living with it every day. The implementation I’m about to outline leverages the following technologies:

iOSQSOverview

Launch Center Pro

Launch Center Pro is the perfect dashboard for testing (and even long-term running) of custom QS data collection efforts. You can set up multiple 1-touch actions to rapidly log many data points and have it integrate with other apps on your iOS device via URL-schemes if necessary. Notably, this process I’m using passes off to Drafts 4.

While it is possible to save files directly to Dropbox from Launch Center Pro, in order to fully support/implement the QS Data Spec I needed to be able to have a little more dynamic control over the JSON data before it was saved. You will see that my Launch Center Pro actions are missing the required uuid and timestamp  JSON parameters. These will be inserted with Drafts later in the process.

I am going to demonstrate two basic workflow types: single-step (one touch) and multi-step. I’ve set up a emotional logger as the multi-step example, and a bathroom logger as the single-step example. For the bathroom logger, there are actually multiple single-step actions that I’ve grouped in to a folder, to make it more organized. I’m using single-step actions for this since it happens multiple times a day and I wanted to ensure it was as efficient as possible.

Launch Center Pro

Single-step Action (Bathroom log)

This one is very simple. We need to pass a URL-encoded version of the base JSON object for this datatype to Drafts for further processing. Here’s what the QS Data Spec says the JSON object should look like (full schema):

(Note: while the spec is very medical, I labeled things a little more politely in Launch Center Pro. i.e. feces -> BM)

As I mentioned previously, we will add the uuid and timestamp values dynamically within Drafts, so our Launch Center Pro action simply looks like this:

This action is basically saying do the following steps:

  1. Launch Drafts 4
  2. Get ready to run an action
  3. Pass in the URL encoded text for the JSON object
  4. Run the ‘Log QuantifiedSelf Entry’ action
  5. On success, come back to Launch Center Pro

Multi-step Action (Emotional log)

Launch Center Pro - Emotional

The multi-step example follows the identical process as the single-step example except that it prompts the user for a few inputs before sending the JSON object over to Drafts. Here is what the QS Data Spec says the emotional object should look like (full schema):

Our Launch Center Pro action, complete with user prompts to select the values of the three inputs looks like this:

 

Bonus! Medical Log

You get the picture, right? So as a bonus we have the QS Data Spec example for medicine (full schema):

And the corresponding Launch Center Pro action, customized with entries for Ibuprofen and Ranitidine:

Drafts 4

Drafts Action Overview

The quickest way to get this custom action into Drafts is from the Drafts Action Directory. I’ve posted it here.

The Drafts action is pretty straightforward. To contain a JavaScript file and a save to Dropbox action. To keep the files more organized until I can process them at a later date, I’ve told drafts to save the files in a date-based file system hierarchy: Logs/[year]/[month]/[day]/[UUID].json

The JavaScript is fairly simple itself. It basically sets the timestamp and UUID, and then saves the file to Dropbox with the UUID as the filename. It ends up looking more complicated because I had to paste in support-methods for UUID and JSON.

The Beginning of a QS Data Spec

One of the frustrations I’ve had in dabbling with the Quantified Self movement is that there are a plethora of incredible ideas being shared, but no way to combine and replicate them easily. We need a data specification!

Yesterday I began thinking through what this may look like. I wanted it to be simple, flexible, as platform-agnostic as possible, and as extensible as possible. My thoughts quickly started to coagulate around JSON as the format, and a few high-level concepts to build upon.

I created a public Github repo to share my efforts. I welcome (and am sincerely hoping to attract) public comment and participation in drafting this specification. Specifically I’ve already filed an issue requesting comments from anyone who is interested in becoming involved.

While I’m writing up this specification I am testing it out as well; I don’t want it drafted in isolation. I’ve got a simple workflow running on my iPhone which I’ll post about shortly, with full code of course! I’ll also be creating and sharing some scripts to test pulling data from various services and storing it in this format.

How to Get Involved

  1. Head over to Github and read the rather short intro to the QuantifiedSelf Data Spec
  2. Post comments, questions, and suggestions to the issue queue
  3. If you’re really motivated fork the repo, make some updates, and send me a pull request!