richiety

birdfeed:

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:

Geolocation

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 sorry replacement for first class Twitter geo support I 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:

Make sure the user has complete control over location posting on a tweet-by-tweet basis, and make sure it always clear when a location is being posted and when it isn’t.

Make sure the geo posting feature isn’t annoying to people who don’t care about it, or to people who only use it occasionally (which can be very difficult to do in a constrained space like the posting interface).

Avoid “red dot fever” by emphasizing context-rich, human readable place names over geographic metadata and pins on maps.

Accomplish all of the above without compromising aesthetics.

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 me made location aware in the future, and I suspect a lot of third parties will have interesting ideas for it as well.

In-App, Per-Account Settings

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 getting 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:

The aforementioned usability advantages.

I wanted to be able to offer settings that require somewhat complex logic (for example: account creation for third party services).

I wanted to be able to offer per-account settings, allowing users to, say, have a different photo service for every account.

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:

Location Posting Mode

Image Sharing Service

Image Quality

URL Shortening Service

The in-app settings also introduce a “Clear Cache” button, which can be used to delete the local tweet cache 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.

Flickr

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:

Unlike TwitPic or yFrog accounts, Flickr accounts aren’t implicitly tied to Twitter accounts. It’s possible that a user of multiple Twitter accounts would want to use a particular Flickr account for posting images from all of their Twitter accounts, but equally possible they wouldn’t. It seems likely that a lot of people would want to, say, keep photos taken for their business account out of their personal Flickr photos (or vice-versa). However, it would be nice if someone who did want to use a single Flickr account for everything had the option to.

I’ve often found OAuth-like authentication experiences confusing in iPhone apps—mainly, I think, because they’re not sufficiently explained, it’s often unclear when they’ve worked and what they’ve done, and they disrupt the user’s context.

Users of Flickr are slightly more “precious” about their photos, and are more likely to care about image aesthetics and metadata.

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:

Use the same Flickr account for every Twitter account.

Use a different Flickr account for every Twitter account.

Use Flickr for some Twitter accounts and yFrog, TwitPic, or Posterous for others.

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. 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 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.

“Mark as Read” Improvements

While I’ve always been pleased with how Birdfeed handles mention/DM notifications and unread counts, even I’m willing to admit it has its flaws.

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.

Other Assorted Improvements

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!