Update: The pillows were done by the folks at Throwboy. Which reminds me that I’ve been meaning to order some Birdfeed pillows.
Birdfeed 1.2 was just approved for sale, which means it should be showing up on the App Store and as an update on your iPhone within a few hours. I’m very proud of this release, since it contains a few features that have long been at the top of my Twitter client most wanted list, and one that I hope will play a small part in an exciting new direction for Twitter. Because Neven and I spent a lot of time agonizing over many of the details of this release and trying to make sure we got things right, I wanted to do an in-depth post explaining the new features and some of the thinking that went into their design. Here’s what’s new:
Months ago, when the @twitterapi Twitter account solicited developers’ opinions on which new features they’d like to see in the API, my response was simply “per-tweet geolocation.” As a resident of a dense urban area and frequent traveler, I’ve always been intrigued by the opportunities presented by location-enhanced tweeting (see the Times’ recent article on the subject for a good overview), but disappointed and somewhat annoyed by the lame approximation of it that iPhone clients have foisted on us thus far. The Twitter profile location field, which most clients currently use as a repository for geo information, is, in my mind, intended to be a permanent, human readable description, not a repository for ever-changing metadata. The plague of ugly floating point numbers on Twitter profile pages is a poor replacement for first class Twitter geo support I’ve always dreamed of.
So, naturally, when Twitter announced it was working on a geolocation API, Birdfeed was quick to jump on the bandwagon.
The goals Neven and I had in designing the Birdfeed geo experience were:
One early option we considered was the sticky on/off switch Twitter proposed for geo clients on their API wiki. We found this approach had two problems, though. First, we didn’t like it aesthetically. The standard iPhone switch control is huge and attention-grabbing, and we felt it immediately assumed an importance in the cramped posting interface that would distract infrequent users. Second, in keeping with our goal of emphasizing place names and making it very clear to the user what location was being posted, we wanted the UI to include a reverse geocoded place name (say, “Metropolitan Avenue, Brooklyn, New York”) for the current location. We felt that this text paired with an on/off switch felt a bit odd.
Instead, we thought more in the direction of something like a Mail “subject:” line and implemented an unobtrusive location field at the top of the posting UI. In Birdfeed’s settings, there are three options for location posting: “off,” “manual,” or “automatic.” If location posting is set to “off,” the location field doesn’t even appear in the posting interface. If it’s set to “manual,” it appears, but the user has to tap to add a location to the tweet. If it’s set to “automatic,” the location field appears and automatically starts determining the location when the posting interface opens. In both the “manual” and “automatic” cases, the user can remove a tweet’s set location by tapping the “X” button on the right side of the field.
We maintain our emphasis on place names in the tweet detail view. When viewing a tweet with an attached location, the user sees an extra line with a reverse geocoded place name in the metadata below the tweet text.
Tapping the place name takes the user to a view that shows the tweet’s location on a map.
This is, of course, only the beginning of what could be done with geolocation. I have a lot of ideas about other ways Birdfeed could be made location aware in the future, and I suspect a lot of third parties will have interesting ideas for it as well.
There has been a lot of discussion lately in iPhone circles about whether the Settings app, Apple’s prescribed repository for application preferences, makes sense for third party developers. While for awhile it seemed that devs were going to stick to their guns with the Settings app, and users were going to get accustomed to looking for application preferences there, recently the tide has turned very much in favor of in-app settings.
I had been planning to adopt in-app settings within Birdfeed for awhile, for three reasons:
Birdfeed’s in-app settings are accessed by tapping the blue disclosure button on each row in the accounts list. From each account’s settings view you can change the following settings:
The in-app settings also introduce a “Clear Cache” button, which can be used to delete the local tweet database for each account.
The rest of Birdfeed’s settings (things like “Maximum Tweet Load” and “Display Name”) are still in the Birdfeed section of the settings app. I may eventually migrate those into the app as well—they just weren’t a priority for this release since I didn’t think they’d be the kind of thing people would want to have to set up on a per-account basis.
One of the features I’ve always wanted in a Twitter client is Flickr support. In my opinion, an ecosystem of third party, Twitter-specific image sharing services thrives at least in large part because their authentication scheme (simply using users’ existing Twitter credentials) is easier for third party developers to implement than Flickr’s somewhat involved (but arguably superior), OAuth-like mechanism. I was a Flickr user long before I was a Twitter user, and in a lot of ways using anything other than Flickr for my image sharing has always bothered me.
So, once I took care of most of the basics in Birdfeed, I started work on Flickr support.
Of course adding Flickr support isn’t like simply bolting on “yet another Twitter image sharing service.” In designing the Birdfeed Flickr user experience, I took into account a few unique factors:
With the first factor in mind, I implemented Birdfeed’s in-app setting such that a Flickr account that is added for any Twitter account can be set as the image sharing service for any other Twitter account. This allows an unlimited number of Flickr accounts to be associated with an unlimited number of Twitter accounts. This way users can:
To add a Flickr account in Birdfeed the user navigates to an account’s image sharing setting, and chooses “Add Account” and then “Flickr.” She is then presented with a dialog warning that Birdfeed must exit and open Safari to start the Flickr authentication process.
Some might wonder why Birdfeed doesn’t just open an in-app web view instead of exiting and sending the user to Safari. Well, as it turns out, OAuth advocates consider it bad practice to have the web authentication part of the process happen within an embedded browser. The concern is that this approach gives the user no assurance that they’re actually interacting with the trusted web service since a phishing app developer could be the faking the web authentication UI.
Assuming the user agrees to be sent to Safari, he is then asked by Flickr to approve Birdfeed’s use of his Flickr account, and finally is redirected back to Birdfeed via an “x-birdfeed://” URL. For 1.2, I implemented an extension to the Birdfeed URL scheme that takes the user back to the account settings screen, where the authentication process is completed and the user can actually see the image sharing setting change to “Flickr: username.” This latter detail was important to me, since, as I said, I think iPhone apps that implement OAuth can often be a bit vague about what, if anything, happened.
Once a Flickr account is authorized, it can be used as a replacement for the usual Twitter image sharing services thanks to Flickr’s “flic.kr” short URLs. There is only one difference in the experience: for Flickr (and, incidentally, Posterous) uploads, Birdfeed now presents a photo metadata sheet that allows the user to specify a title, description, and tags for a photo before it is uploaded. As I said, I believe Flickr users think of their photos as a bit less disposable than users of traditional Twitter image sharing services, and therefore I suspect they care more about controlling the associated metadata.
While I’ve always been pleased with how Birdfeed handles mention/DM notifications and unread counts, I recognize it has its drawbacks.
First, there’s the problem of mentions by people you follow. If you’ve already seen someone’s mention of you in your timeline, it’s a little annoying that you have to go all the way to the Mentions view to get rid of that pesky little “1” in the back button. Before Birdfeed launched, it had a setting that specified it should only notify you of new mentions from people you don’t follow. Unfortunately we had to remove this setting at the last minute because, after a long debate over a bug I filed, the Twitter API folks finally decided they could not improve the reliability of the “following” information I was using to implement that feature.
I may eventually put this setting back in (it’s still implemented, just not accessible), but until then, I’ve put in a small fix designed to make the problem less annoying: when the user taps into the detail view for a mention tweet, it will automatically be marked as “read,” and the unread mention count in the back button will be decremented.
The other unread count problem that’s always bothered me a bit is the inability to mark all DMs as read in one tap. Very often the user will have seen all of the DMs in question on their desktop client or the web, so marking them all as read individually seems tedious. The simple solution to this problem is, of course, a “Mark all Read” button, and now Birdfeed’s DM inbox has a toolbar with just such a button.
As with all releases, Birdfeed contains many other small improvements and bug fixes, in addition to these major tentpole features. The most interesting of these is probably the addition of two new third-party services, Tweeteorites and Favstar.fm, to Birdfeed’s user profile view.
Hopefully that is a helpful overview of what’s new in Birdfeed 1.2, as well as a bit of a behind the scenes look at the release. If nothing else, I hope it serves to illustrate that nothing in Birdfeed is arbitrary, and that, as the long suffering Neven can vouch, pretty much everything that goes into the app undergoes an almost excruciating amount of scrutiny. That, of course, doesn’t mean we get everything right, so if you have any feedback, drop us a line!
But much of the joy of using Birdfeed is its use of a design principle called progressive disclosure, an elusive but powerful property whereby an application presents only what is needed as it’s needed, gracefully exposing more features and complexity only when the user seeks them out. In other words, the power is there, but it sticks to doing its job, not getting in your way.
This post by David Adams is one of my favorite reviews of Birdfeed ever. As I said in my reblog of Merlin Mann’s kind words, it absolutely makes my day when people appreciate stuff like this.
For a lesson in keeping an app powerful but super-easy (and Mac-like) to use, look at Birdfeed, Buzz and Neven’s Twitter app for iPhone. I mean really look at Birdfeed. If you weren’t the type to fiddle around, looking for power user bits, you might never realize how much you can do with this easy-to-use app. And if you’re not that type, you probably never need to, right? So they built it that way. Got it? Exactly. Sublime.
In the software business, it’s difficult to market based on subtleties like design, even though it’s what makes software great. People tend to buy apps, particularly on the App Store, based on kitchen sink feature lists and price, not based on user experience. Even worse, in my experience, many users assume that an app whose design maintains simplicity by emphasizing the 80% case at the slight expense of the 20% case actually does less or is somehow less “serious,” even when it has the same fundamental feature set. So it’s always heartening when someone like Merlin recognizes the substantial effort we put into worrying about how Birdfeed feels, not just what it does, and how hard we worked to balance features and simplicity. Thanks for the kind words, Merlin!
Flickr Photo Saved Search
Pro tip alert! Here Friend of Birdfeed Kellan demonstrates a clever use of Birdfeed’s saved searches, combined with its nearby filter, to view nearby Flickr photos that have been posted to Twitter. Brilliant!
As I indicated on Twitter, Birdfeed 1.1 was primarily intended as a bug fix release. In time honored Apple fashion, I worked very hard in the month after Birdfeed’s release to smooth out the rough edges every software developer has to accept to ship a 1.0. Consequently, 1.1 is heavy on Snow Leopard-style “refinements” and light on out-and-out marquee features. Still, I think it sports some very nice improvements, and, more importantly, it lays a strong foundation for some more ambitious plans I’ve already been working on for 1.2.
Here’s what’s new:
Birdfeed 1.1 was approved by Apple yesterday, which means a tour of what’s new is in order. First off, I’d like to talk a bit about what is, to me, one of the most interesting features of 1.1: the new x-birdfeed:// URL scheme.
For most users, the URL scheme will be of interest primarily because of two other features it makes possible: a bookmarklet for posting shortened links from Safari using Birdfeed, and integration between Birdfeed and third-party push notification apps like Boxcar and Tweet Push.
More technically minded users may be interested to know, however, that Birdfeed’s URL scheme goes far beyond what most similar apps offer, and could, in some ways, be thought of as an interapplication API for the app. Here are some examples of things it can do (full documentation forthcoming):
x-birdfeed://timeline
x-birdfeed://timeline?view=mentions
x-birdfeed://messages?account=buzz
x-birdfeed://user?screen_name=buzz
x-birdfeed://status?id=2814526203
x-birdfeed://search?query=buzz%20andersen
x-birdfeed://post?text=Birdfeed%20&url=http%3A%2F%2Fbirdfeedapp.com&account=buzz
Some of the applications of this are obvious: for example, a third-party Twitter push app could use the URL scheme to open Birdfeed in either Messages or Mentions depending on the kind of update. I suspect that there are lots of other interesting uses for it in third party apps and bookmarklets, but I’ll leave that as an exercise to the reader.
Excited to learn this morning that the Birdfeed app icon is featured prominently on the phone screen in a new iPhone TV ad (and right next to another one of our favorite apps, Locavore, no less)! Thanks again, Apple! (via Sophie Teutschler and Dominik Wagner)
It has recently come to our attention that users are seeing crashes after installing Birdfeed on a new phone using an iTunes backup from an old phone. For users experiencing this problem, Birdfeed will start up at the Accounts screen and crash when the user taps an account to log into it.
This problem is rooted in a quirk of the iPhone Keychain we were, sadly, unaware of: a backed-up keychain can only be restored to the iPhone or iPod touch on which it was created (as explained in this Apple Knowledge Base article). Therefore, when a backup of Birdfeed is restored to a new phone, the account list is restored but the accompanying credentials from the Keychain are not. Unfortunately, Birdfeed doesn’t anticipate this situation as well as it should, and the result is this crash.
Fortunately, there’s an easy workaround: simply tap the “Edit” button in the accounts view and then tap the red circular button next to the account name to delete the account. Then just create re-create the account.
We are currently doing a careful examination and redesign of our accounts code as part of the next Birdfeed update, and this problem (and many others) will be addressed as part of the effort. As always, apologies for the inconvenience.
Unfortunately, it appears that for some subset of its victims, the dreaded “Account Amnesia” problem is not entirely solved by Birdfeed 1.0.1. Though we tested our fix on a variety of different permutations of the problem, it appears we may have missed a persistent crash that can occur if your Birdfeed account credentials in the iPhone Keychain are already in a particular inconsistent state. This problem should only affect people with mixed case usernames who are upgrading from Birdfeed 1.0.
Fortunately, there’s a much easier workaround for this problem than for the old one: simply delete your existing account in Birdfeed, and then log in again using only lowercase letters in your name. Once logged in, your account name will still show up in Birdfeed the way it appears on Twitter’s site.
Needless to say, we will be taking a long, careful look at the account management code for the next release. Apologies once again for all of the confusion this issue has caused.
