Tag Archives: notifications

Twitter streaming API and Micro.blog

The writing has been on the wall for years. Now that Twitter plans to move ahead with deprecating APIs that apps like Twitterrific and Tweetbot use, it’s even more clear that there’s no overlap between Twitter’s priorities for the API and what traditional clients need.

When I wrote about Icro, the first third-party app for Micro.blog, I said that I always want to encourage other developers building for Micro.blog. It’s worth exploring how these Twitter API changes compare to Micro.blog and how we can improve.

The streaming API is a big part of this. Twitter apps currently use the streaming API to deliver tweets in real-time without polling, or to notice when someone is @-mentioned so that a push notification can be delivered. Losing this API is especially frustrating because it means developers need to rewrite a bunch of code only to make their apps a little worse instead of better.

Micro.blog doesn’t actually have a streaming API yet. Micro.blog supports multiple APIs, but no persistent connection. The new app Icro doesn’t have push notifications, although the official Micro.blog app does. For a brand new app like Icro, it would be a lot for the developer to also run a server just to do push notifications.

As I think about how we solve this, I remember a discussion in the Twitter developer community when the iPhone first got push notifications. It was an open question: should Twitter third-party developers run their own servers for push notifications, or should Twitter itself deliver push notifications on behalf of third-party apps? Obviously third-party developers have had to run their own servers.

I think a goal for us with Micro.blog should be that third-party developers get access to the same basic tools that we use to build our own apps. Rate-limits should be the same for an app like Icro as they are for the official Micro.blog app, for example.

With that in mind, I’ve mentioned before that I’d like to offer a push notification service for developers. iOS and Android developers could upload their push notification credentials from Apple and Google. Micro.blog would store them and deliver push notifications directly to third-party apps.

This has a few pretty big advantages:

  • Third-party developers won’t need to run their own servers. This levels the playing field so that any Micro.blog app, no matter how small, can offer basic features like notifications.
  • Push notifications are more capable now than at their introduction in 2009. They can be used not just for an alert message but for silently sending data to an app in the background, such as when new posts have been added to someone’s timeline.
  • It’s more efficient. Instead of keeping persistent connections open to Micro.blog servers, Apple and Google handle the persistent connections between devices and the cloud. Micro.blog can simply forward @-mentions to the clients that have requested them via Apple and Google infrastructure.

This is a little bit of extra work for Micro.blog, but Micro.blog is already doing similar processing when a reply comes through. For every reply to a blog post, Micro.blog checks if there is a Webmention endpoint so that it can forward that reply to an external site, such as one hosted on WordPress. Opening up push notifications feels like a natural extension to that.

Some developers might not be comfortable outsourcing this to Micro.blog. That’s fine. In particular I’d like to hear any concerns over security or features where this approach would be too limited. (To be clear, we’d offer this for free. Our business is blog hosting.)

Back to the Twitter news. John Gruber summed it up this way:

Twitter isn’t explicitly saying that they’re shutting down third-party clients, but I don’t know that it’s feasible for them to exist if they don’t have access to these APIs. It’s like breaking up with someone by being a jerk to them rather than telling them you’re breaking up.

That’s a great analogy. Micro.blog is barely a year old, so there is plenty still to do, and there are parts of the API that aren’t as mature yet as they will be. But I think we’re transparent about what we’re trying to do and how we can support developers. We’re not going to be jerks about it.

I’m really excited by what I’m seeing from the community. Icro is in the App Store. Slate is another iPhone app currently in beta. Dialog for Android is in the Google Play Store as a public beta. And then there are all the apps following IndieWeb standards that are compatible with Micro.blog.

WWDC is only a couple weeks away. We’ll have a Micro.blog meetup on Tuesday (June 5th) at lunch. I’d love to talk to developers at the meetup or anytime that week in San Jose to get feedback on how we should handle streaming and notifications.

Slow transitions in watchOS

Much has been made of the Apple Watch not being fast enough. It’s too slow for full iPhone-like apps, of course, but that doesn’t bother me because I think the watch is pretty great at its core features. But I’ve noticed that it’s slow even for some of the simple stuff, and I don’t think this can be blamed on hardware alone.

Take notifications, for example. There are several distinct steps to notifications after you receive one:

  • Tapping a notification.
  • Waiting for it to load, which is an animated transition.
  • Optionally scrolling to the bottom to read it all.
  • Actually tapping Dismiss to get rid of it.

There’s a tiny lag between all of these. I frequently can’t scroll right away, as if it’s not responsive until the animation completes. The Dismiss button also doesn’t seem to be enabled immediately, requiring a 2nd tap before it “clicks”.

I bet these are solvable with a software update. Shorter animated transitions or pre-loading notification text might go a long way to improve the experience.

Apple Watch still pretty great

Stephen Hackett posted an Apple Watch follow-up recently. He has mostly stopped wearing it:

“The Apple Watch can do a lot of neat things, and I miss its fitness tracking, but so much of it just doesn’t fit my lifestyle anymore. It’s not super useful for work, apps are still miserably slow and at times, its an additional distraction.”

The Apple Watch is a very personal device. It’s okay that it’s not for everyone. There’s no network effect; the watch isn’t better or worse if other people don’t use it. And it’s even okay if most of the apps are too slow to bother with. Fitness tracking, notifications, the time — for me, those 3 simple features are enough.

Casey Liss also writes that notifications have been one of the most important features, letting him keep his iPhone ringer off:

“The Apple Watch has allowed my iPhone to transition from being a personal device to being a private one. That’s a really profound change. More so than I expected.”

Once every couple of months, I leave the house in a hurry and forget to put my Apple Watch on. I survive without it, of course, but I do miss it. After not wearing a watch for most of my life, it’s weird now if I don’t have the Apple Watch with me. I expect to use it for years to come.

Prompt for push notifications

David Smith says to not bother the user with alerts on first launch:

“I have just sorted through the App Store and settled on trying out your app. I open it up and you immediately ask if you can send me Push Notifications? I have no context about what these are going to be used for or why they might be useful to me.”

I agree. For Sunlit, we only prompt to enable push notifications after you’ve chosen to enable sharing for a story. While it might be useful to have push notifications for everyone, by waiting until we really need it, most users are never bothered with the alert. And it forced us to focus on specific and valuable uses of notifications, such as sending a push notification when someone subscribes to your shared story.