This post is a review about the syncing process of a number of popular self-tracking devices.
Currently, most wearable trackers require some procedure to sync the device with your smartphone in order to get the data off of them. While it doesn't sound like there would be a huge difference between the Bluetooth syncing of the Fitbit Flex vs the Basis watch, it turns out small technical differences can make huge behavioral differences.
I've been wearing all of the below devices for at least over 3 months, and I've had the Jawbone UP for two years. I don't like to jump to snap conclusions, so I wait until I've lived with a device for an extended period of time before writing about it.
Starting the Sync: To sync the Basis watch, you press the button on the side of the watch to begin syncing. However, this requires that the app is running in the background or the watch won't be able to communicate with the app. In practice, this means you end up launching the app, then pressing the button on the watch.
The Syncing Process: The syncing process takes several minutes. I don't know why it's so slow, but it's definitely the slowest out of the bunch. Afterwards, there is very little information visible in the iPhone app, the website has a better view of the data.
Effort vs Reward: The amount of effort it takes to sync the Basis is far too high given the minimal immediate reward on the phone after a sync is complete.
Starting the Sync: To sync the Fitbit Flex, you simply launch the app on your phone, and it goes and finds the Fitbit and begins downloading data.
The Syncing Process: It takes relatively little time to finish the sync once it's started. The only thing I've had trouble with is getting distracted while it's looking for the Fitbit and then not noticing if the sync is complete or if it errored out before finding the Fitbit.
Effort vs Reward: The amount of effort to sync seems like it should be low, since it only requires launching the app. However, in practice, the cognitive overhead of inspecting the interface to determine whether the sync has started and finished successfully makes the effort relatively high. The reward is also not as great as it could be, since the effects of the sync are not immediately visible. Yes, the screen shows today's stats, and you can page back through previous days, but I often forget when the last time I synced the device was, so I don't know how far back I should keep looking to find the "new" and "interesting" data that I haven't seen before.
Starting the Sync: This is one of the only devices that does not require a manual step to begin syncing. Assuming you have a computer always plugged in at home with the Fitbit base station plugged in, then whenever you are in range of the base station the device will automatically sync with no additional effort on your part. In fact I've also had my Fitbit sync via other people's base stations! I guess it was only using the base station as a radio-to-Internet gateway, just treating the OSX app as a way to pass data through.
The Syncing Process: Because you do not have to manually initiate the sync, you don't even notice the syncing process.
Effort vs Reward: This essentially requires no effort, since as soon as you get home the device syncs. However, this also means Fitbit has less opportunity to reward you. The feedback was limited to push notifications about significant events, like if you broke your goal for the day, you'd get a push notification when the device was done syncing. The result is that there is very little reward, and it's easy to forget about the app completely.
Starting the Sync: To begin syncing, you need to tap the "Menu" icon in the top left corner of the screen. At this point the lower half of the screen changes to show a Shine-sized circle on the screen saying "Place Shine here to sync". The app claims you need to place the device on the iPhone's screen to begin the sync. However there aren't any sensors in the phone that can actually determine whether the device is physically on the screen. So I end up starting the sync by just tapping the center of the circle with my finger.
The Syncing Process: During the whole syncing process the app shows rings emanating from where you are supposed to place the Shine on the screen. However there is no indication of the progress of the sync, and it's not even very clear that anything is happening other than some animated circles.
Effort vs Reward: After the syncing is complete, the app updates its daily activity cards with the recent data. Unfortunately there is no indication of what data is new vs what has already been synced, so you end up swiping back until you see a day you recognize as having already seen before. The bottom half of the screen still shows "Grab Shine and hit the road. Then sync your shine to see how many points you earned" even immediately after syncing, so it's not quite as motivating as it could be.
I was not able to get enough experience with syncing the Pulse to make a fair comparison. The device recently started rebooting whenever a sync begins, and I haven't yet returned it to get a new one.
Starting the Sync: To sync the UP band, you have to take off the endcap, launch the app, and plug in the band to the headphone jack on your phone. The app auto-detects when the band is plugged in and begins syncing right away.
The Syncing Process: Once the sync begins, there is a nice big progress bar on top. It animates quickly, so you're never left wondering if the device got "stuck," and usually finishes within a few seconds assuming you're downloading 1-3 days of data at a time. The sync finishes with a resounding "100%" on the screen, so it's absolutely clear whether the sync completed successfully, even if you look away from the app for a few seconds.
Effort vs Reward: When the sync is complete, the app shows a summary of the data that was just downloaded. This serves as a great way to mentally recap and reflect on my previous day or two of activity without paging through interfaces. It probably sounds like the effort of physically plugging in the device to the phone is high, but the rewards far overcome any inconvenience, and so this ends up being the most satisfying syncing process out of all the devices.
The new Jawbone UP claims to have "continuous syncing" through the phone's Bluetooth LE connection. If that's the case I'll be very interested to see how that ends up feeling in practice!
I was sitting at the back of the API discussion at the Quantified Self Conference this Friday in San Francisco, and realized that there is something wrong with the current way these quantified self devices are built and marketed. I don't want to buy a device and be trapped in the company's ecosystem of apps and be stuck in yet another social network. I want to use these physical devices as inputs to my own data store, and have a completely separate set of companies handle the social and aggregation of data from the data that I own.
In the current model, every device has its own app and its own social network, and most of them have an API. Each device wants you to completely buy into their entire world. This is even more apparent when you see apps like Jawbone UP and Fitbit letting you track things that their devices don't track, like food and water consumption!
This presents a number of questions and challenges with privacy and data ownership. You have to trust that these services are handling your data properly, letting you share with who you want to share it with, etc. If you request that your account is deleted, you have to trust that they delete it.
Many of these APIs are designed only to support displaying data in the corresponding apps, the API is not necessarily designed to be a complete export of your own data. A common problem is when times come back from the API in the user's local time without even including timezone information. Surprisingly, some of these APIs don't return unix timestamps or full ISO 8601 dates. The problem of course is that without the actual timestamp, you can't correlate this data with anything else.
Of course if the company shuts down, you lose all of the data stored in the system. As we've seen before, like with the Zeo sleep tracker shutting down suddenly without giving any notice, this is a big problem. Even the way a company is acquired can make it beneficial to hide the fact the service will be shut down until after the acquisition, so that the value of the company is not affected by negative press about a service shutting down.
A better framework is to separate the device manufacturers from the app builders. Let companies like Jawbone and Fitbit focus on building great hardware, and let other companies build social networks and aggregators of the raw data.
In this model, I would buy or rent a personal server that would collect and house my QS data from all of my devices. This might be a physical device I plug in at home like an Airport Express, or it may be a server I rent from Amazon or Linode, or could even be a service provided by a company dedicated to this purpose. This personal server would be responsible for storing and backing up all of my data. It may or may not actually have a user interface for viewing the data, most importantly it has an API for getting data in and out.
A device manufacturer like Jawbone would build a device that could send data to my personal server. Of course it's not always practical or possible to communicate straight from a wearable device to a server at home (although Bluetooth LE makes this increasingly easier). So in the mean time, it's completely acceptable that a device may require a cloud service operated by the device manufacturer in order to sync and process data. The main difference is that in this model, I'm not treating Jawbone's servers as an API, they are simply a "syncing service" that exists to push data down to my own server. This also simplifies things greatly for Jawbone, since they don't need to worry about building mobile apps or websites, they can focus on building great hardware.
Once I've set up many devices to push data to my personal server, I may want to share some parts of it publicly or with a social network. I may also want to see aggregate graphs of weight data or step counts, or correlate my sleep data with the air quality of my home.
This would all be accomplished by having separate aggregator and separate analysis services. I would selectively grant them access to the data on my personal server using a framework like OAuth 2, where they would be able to pull out the pieces they need.
Creating this "indie web of things" is hopefully not too far of a stretch given the foundations we're laying with the building blocks of the indie web.
You can start by getting your own domain name and backing up your personal data to your own server. Until this new ecosystem exists, you can get a head start by downloading your data from APIs like Jawbone and Fitbit, and storing it on your personal server.
This post details aspects of the IndieWeb community, a community of people who own their data and their online identity. We're currently focusing on this type of architecture for the web, starting with what we've been calling POSSE, publishing content on your own site and syndicating to sites like Twitter and Facebook.
Aaron Parecki is known for having tracked his location at 5 second intervals since 2008, tracking many other types of personal data, such as sleep, weight, heart rate, personal weather and air quality. He is a proponent of data ownership, and uses his domain as his own personal data store and indentiy provider. Parecki founded IndieWebCamp with Tantek Çelik and Amber Case in 2010. Previously he was the co-founder of Geoloqi, a location-based software company acquired by Esri in 2012.
Parecki currently works as the CTO of Esri Portland R&D Center. His personal data collections have been featured in Wired, Fast Company and at conferences around the world. You can follow him on Twitter \@aaronpk or on his own domain, aaronparecki.com/notes