We’d all like to be more productive, but it’s far easier to stick with a daily habit like reading for at least five minutes than, say, training to run a marathon sometime in the next year. I’ve personally found these types of small, repetitive goals really easy to gamify, and if your brain is anything like mine, a few strategic dopamine deployments can really go a long way. Drinking eight glasses of water a day isn’t hard to begin with, but it’s certainly a lot easier if you’re constantly being reminded about it. And if you’re made aware that you’re actually at risk of breaking a 15 day streak, you’re even more likely to get off the couch for a refill. Obviously these streaks don’t really matter, but brains work in mysterious ways. Or at least mine does.
It’s really easy to go overboard here. In a perfect world, I’d of course like to read about current events and practice the guitar every day, but the quickest way to make sure you don’t drink those eight glasses of water is to lump them alongside a bunch of other goals that you weren’t realistically going to hit anyway. Take something like hitting a daily stand goal1; I can usually accomplish this without really thinking much about it, and on the days when I don’t, I’m usually only an hour or two short. But since missing a day isn’t particularly crucial, there’s no compelling reason for me to explicitly check how I’m doing. Going from pull (“Let me proactively see how many hours I’ve stood for today”) to push (“Hey, you need three more hours or you’re going to lose your 20 day streak”) provides enough of an impetus to do the task that was easy to begin with as long as you didn’t forget.
Like weather or to-do list applications, there are a lot of different habit trackers, which shouldn’t be surprising given that everyone responds to subtly different types of motivation. Most are pretty similar, however. Before diving in too deep, let’s take a look at a couple that aren’t really full-featured habit trackers, but interesting entries nonetheless.
Sessions and Activity++
Sessions is unique amongst the applications listed here, as it’s entirely built around setting timers for habits. If your goal is to read for five minutes each day, it’ll kick off a timer and increase your streak once it’s completed. It’s very nicely designed, and there are certainly plenty of cases in which timers are useful when performing daily habits2, but it’s not flexible enough to be a general purpose streak tracker.
Activity++ has a narrow focus; it tracks streaks and provides gorgeous visualizations for the three metrics highlighted by Apple’s Activity app – Move (active calories burned), Stand (hours in which you’ve stood and moved for at least a minute), and Exercise (minutes of “brisk activity”) – and does so automatically by integrating with HealthKit. Given the small feature set, Activity++ is a very nice application, but it frustratingly doesn’t notify you if you’re at risk of breaking a streak. There is an Apple Watch complication, but it oddly doesn’t include any streak data. I’d like to see a simple Today widget with streak information added as well.
Next, a group of apps that I found to all be pretty comparable to one another.
Habit List, Momentum, and Strides
These are all nice, and all pretty standard as far as streak tracking goes. They each provide a bevy of flexibility options (multiple times per day or week, every 2-3 days, only on Tuesdays, etc.), so depending on your needs, the specific configuration that one provides might be reason alone to use it. Habit List has my favorite design of the bunch, but Momentum has a Today widget which may give it a slight edge. I don’t personally need a desktop component, but if you do, Momentum has a Mac app and iCloud sync, while Strides (my least favorite of the three) is also available on the web.
With a few slight tweaks, either Habit List or Momentum could be sufficient, but they’re each missing at least one of the two features that I’ve since come to rely on from…
Productive and Streaks
Productive is similar to the apps outlined above, feature-wise, and sports an incredibly custom UI that I really enjoy using. But the ingenious difference is that it lets you specify when in the day you plan to perform each of your habits: in the morning/afternoon/evening, or anytime. It also let’s you indicate which specific hours your morning, afternoon, and evening are comprised of3.
Why? If you only perform a certain habit (e.g. flossing) at night, there’s no need for your homescreen to show a badge all day indicating that you haven’t done it yet. I’m pretty conservative about app icon badges – I think important ones should be noticeable and jarring, which means not letting unimportant ones dilute their prominence. Productive lets me do exactly this, which makes up for the fact that it doesn’t offer a Today widget or a Watch complication.
The easiest habits to track are the ones that get automatically tracked for you. While Streaks allows you to enter custom habits as well, it’s main draw is a wide variety of built-in presets for automatically tracking based on your HealthKit data: sleeping, drinking water, weighing yourself, exercising, etc. For this reason alone, tracking your health-based habits with Streaks is a no brainer. It even has a Today widget, a Watch complication, and really nice custom Watch notifications.
The biggest problem with Streaks is that it supports a maximum of only six habits. This, combined with the aforementioned smarter badging solution that Productive employs, has me using both in conjunction with one another: Streaks for habits that can be automatically tracked via HealthKit, and Productive for everything else. And it’s working really well for me.
I don’t realistically expect Productive to add HealthKit support, or Streaks to drop its habit limit and ape Productive’s badging implementation, but if one or the other did, I’d happily consolidate.
Productivity is all about finding a system that works for you, and importantly, not trying to do too much. In my case, the combination of reminders and streak tracking helps keep me motivated and prevents me from forgetting, making it easy to keep up with simple habits that I know would otherwise lapse. As our smartphones and watches learn more and more about ourselves, the opportunities to employ systems4 that help us be better versions of ourselves is only going to increase.
There’s been a lot of talk these past couple of years about how good Apple is or isn’t getting with regards to developing web services. When referring to Apple’s services acumen, I think people generally mean the speed, consistency, and reliability of offerings like iMessage, iCloud, Apple Music, and the App Store(s).
I’d argue that these characteristics, while necessary, are not sufficient for a web service to truly be “great.” To make a great service, the proprietor must truly understand and buy into one of the web’s core tenets: interoperability. This is only becoming more important as time goes on.
We shouldn’t think of the “web” as only what renders inside a web browser. The web is HTTP, and the open Internet.
I really like the sentiment here, but I worry about whether or not Apple sees it this way. HTTP, a universal protocol that allows clients to talk to servers in ways that wouldn’t be possible if everyone used a different (perhaps proprietary) transport mechanism, is only as good as the number of clients that are actually allowed to communicate with your server using it.
CloudKit web services is one of Apple’s more recent service endeavors, and the fact that it can be openly communicated with over HTTP is reason for optimism. But let’s take a look at Apple Music. Unlike most other streaming music services, Apple Music doesn’t have a public HTTP API, meaning a third-party like Last.fm can’t easily integrate with it; there simply isn’t a way for the Last.fm servers to connect with Apple’s the way that they can and do integrate with Spotify. iOS 9.3 did add client-side Apple Music APIs, but these aren’t nearly as useful as an HTTP API would be. Nobody’s servers run on iOS.
Apple Music works with Sonos speakers, but it doesn’t work with the Amazon Echo. And no one outside of a Cupertino business development meeting will have the ability to make it work with the next great Internet connected speaker or smart home device. I buy the argument that the new web is “HTTP and the open Internet,” but in this case, Apple might as well be using something proprietary instead of HTTP. The lack of openness means they aren’t actually allowing their service to be a part of this new web1.
Apple now claims that being a services company is important to them. If they’re able to address the latency and reliability issues that their services have historically been plagued with, they may have succeeded at exactly what they set out to improve. But I still personally won’t consider them a good services company until they take tangible steps towards making their APIs far more open than they have been to date. These types of companies understand that they alone cannot build all of the interactions their users would find useful (nor would targeted, limited partnerships suffice). They earn the adoration of their developer community by empowering them to create the next big app or feature, standing on the shoulders of giants rather than sitting in their pocket.
In addition, I’d love to see this same mentality adopted by third-party client-side application developers, not merely Apple. In 2013, Brent Simmonsastutely opined that when his customers asked him for “sync,” they were usually really asking for multiple versions of an application. Users of his Vesper app for iPhone wanted an iPad version and/or a Mac version; the fact that an HTTP API running on a server would facilitate these new versions was an implementation detail, not what anyone was explicitly asking for.
While I think he was right in 2013, I’m not positive that this same logic holds today. For the apps and services that I rely on the most, I increasingly do care about how the back-end can be communicated with. Products like IFTTT, the Echo and Google Home will only proliferate this mentality to more and more non-technical consumers. They may not know about REST or HTTP, but they’ll wonder why their Echo can hail an Uber but not a car from a different car service. Interoperability will become more of a selling point as the Internet-of-Things becomes more of an actual thing.
Their answer to products like IFTTT and the Echo is Mail Drop, a service that turns emails that into OmniFocus actions. While I’m heartened that they clearly care about interoperability and plan to continue making Mail Drop more advanced, I’m flummoxed as to why they wouldn’t give us a service based on HTTP rather than email3.
Closed systems have enabled Apple (and members of their developer programs) to deliver many of the user experiences we know and love, but past performance does not equal future success. While embracing interoperability might require a philosophical shift away from what has worked to date, I worry that the alternative is Apple continuing to stretch themselves thinner and thinner as software continues to eat the world and hardware continues to become smaller, cheaper, and more ubiquitous.
The Echo, programmable Dash buttons, and now a Siri “API”4, are only the beginning. As the number of Internet-connected devices that we use increases, so does the importance of third-party developers being able to integrate these devices and services without their proprietors having the foresight or granting us specific permission to do so.
Enabling this is what being good at web services means to me.
To me, one of most glaring indications that Apple Music isn’t a “service-first” product is the fact that there isn’t a shared “Next Up” queue that persists across all of your devices. If I’ve started playing an album on my Mac, I should be able to walk out the door and pick up right where I left off on my phone. Rdio did a masterful job of this (even letting you choose to either transfer playback to your phone or simply use it as a remote for your computer), and I really miss it. ↩
Incidentally, Brent also works on OmniFocus now. ↩
It’s only a matter of time until I build my own server that simply turns incoming HTTP requests into outgoing emails to Omni, but this isn’t ideal. My proxy server will have to return a 200 OK for every request, regardless of if an action was successfully created on Omni’s server or not, for example. ↩
Don’t even get me started about how much of a mistake I think it is that Siri integration is entirely client-side as opposed to server-side. Farhad Manjoo (Can Apple Think Outside the Device?) and M.G. Siegler (Siri in Chains) perfectly dissect this decision in their respective pieces. ↩
At Tumblr, we were beyond thrilled when iOS 8 provided the ability for us to create an extension that could integrate with the OS at a deeper level than our application did. In practice, we ran into a handful of limitations. For a non-trivial part of my final year there, I worked on a library called XExtensionItem, intended to address a couple of these shortcomings.
As I approached a 1.0, iOS 9 was released, obviating the primary issue that prompted me to build XExtensionItem in the first place. It still would have proven useful, but the diminished utility didn’t seem to justify much more development effort (or any subsequent evangelization). I effectively gave up on it and it hasn’t been touched since.
This isn’t a sob story, however. Third-party libraries are usually built because we’re lacking an adequate first-party solution to a problem, and in most cases, the best thing for the broader community is for a first-party solution to eventually materialize. The percentage of iOS developers who would’ve ever heard about my library – let alone actually integrated it – pales in comparison to how many have benefited from the fix that Apple ended up adding in iOS 9. Most almost certainly don’t even realize it.
I remember feeling bad for my friend Jared Sinclair after he put so much work into OvershareKit, only for Apple to go ahead and release the very Extensions APIs that we had been clamoring for at Tumblr. But in hindsight, I don’t think he would have wanted me to. OvershareKit wasn’t built because he expected it to bring him fame or fortune; he was simply trying to provide a solution to a problem that he knew he wasn’t the only one facing. While he may have preferred many aspects of OvershareKit to Apple’s built-in UIActivityViewController, he knew that no solution he could deliver was better than the problem simply going away.
So while I don’t actually care that something I put a lot of time into didn’t amount to anything in the end, it felt weird that I never ended up talking about it. Hence my talking about it now.