When I set out to make Apple Health Report, I knew I wanted more than just myself to be able to use it.
Aside: The real impetus was a new fitness reimbursement program at SEP that I could get reimbursed for working out without having to go to the gym. I wanted all the reporting/math to be done automatically for me. Given that I have fully-onset programmer’s disease (that’s what I call wanting to use code to solve EVERY PROBLEM I have), naturally, I should get to writing code instead of working out.
I toyed with the idea of a dropbox folder, or some kind of slack integration (basically any sort of thing that could catch the file export from the share sheet that shows up when an Apple Health Export is complete (see screenshot).
I never came up with anything, so I just kept coding. Finally, I asked my wife (read: not a programmer)…
Me (Programmer): If you had exported your Apple Health data and then found yourself on this screen (above screenshot), what’s the easiest thing you would think to do to get your data into a program I’m writing.
Sandi (Human): (rolls eyes). Probably email. Everyone has email, right? I definitely don’t want to have to go sign up for something, create an account, and download another app.
Email as the Interface
My first thought was “Yeah, you don’t get it. Let me explain it…” Instead, I bit my tongue, and let it sit a bit. It’s actually pretty genius. In fact, my colleague Matt Swanson wrote about this a few years ago: Email as the Interface.
I’m pretty terrible at making nice looking web-based or mobile user interfaces. This thing doesn’t actually need a user interface other than the interface that let’s the data exchange occur. Email does that perfectly (via attachments). So all I really need to do is accept someone’s email attachment, and then reply back to them with an attachment and some nice copy.
The flow goes something like this:
Mail Processing
Beware: technical details incoming; get ready to nerd out.
There’s a few different ways to interact Apple Health Report through email:
- Ask for help
- Send your data export
- Update your settings
- … more in the future?
The mail processor is an implementation of the Strategy Pattern. It has a list of mail handlers. Each mail handler can determine whether or not they can handle a particular piece of mail. The processor asks each one in turn, choosing the first which returns true, to handle the email.
Here’s what that looks like in code:
Here are a couple examples of mail processors:
You can see the SettingsUpdateMailProcessor will only get invoked when the subject contains the word settings, and when there is an attachment that has xlsx in it. Whereas the HelpMailProcessor is a catch-all. It gets invoked any time an email hasn’t been handled by one of the other handlers.
Wrapping Up
I found that using Email as the UI allowed me to focus on rapidly iterating on the functionality of the system, without having to spend additional time building out new screens or dialogs. The interaction with Apple Health Report is naturally very transactional, which lends itself perfectly for email.
The next time I start a project, I’ll keep in mind that I should pay attention to the natural interaction model of the system I’m building, and tailor the user interaction model to that (e.g. interactive, transactional, etc.).
Build awesome things for fun.
Check out our current openings for your chance to make awesome things with creative, curious people.
You Might Also Like
