Birdfeed is participating in Indie Relief, a great project Justin Williams and Garrett Murray put together to raise money for the Haiti earthquake relief efforts. All sales for participating applications on January 20, 2010 will be donated to a charity doing work in Haiti (in Birdfeed’s case, Doctors Without Borders). There are a lot of fantastic developers participating, so this is a great opportunity to discover great new iPhone and Mac software while helping a good cause.
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:
- 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 be 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 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:
- 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 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:
- 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 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.
"Mark as Read" Improvements
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.
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!
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.
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!
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:
- Added support for the iPhone OS 3.0 in-app Mail sheet when forwarding a tweet or a link (the Mail app will still open if you are still using 2.2).
- Implemented a URL scheme and posting bookmarklet.
- Added support for nearby searches with no search term.
- Added a refresh button in the search view, and implemented “scroll to first new tweet” behavior for search refreshes.
- Added support for the Bit.ly URL shortening service.
- Added Posterous as a photo upload service.
- Addressed compatibility issues with the upcoming iPhone 3.1 OS.
- Slightly increased tweet font size.
- Overhauled the multiple account system to completely address the Account Amnesia problem.
- Overhauled the posting interface code to address a number of problems related to low memory conditions (existing post text being overwritten after returning from the camera interface, for example).
- Fixed bug that caused a zero follower count to be displayed for users with large followings.
- Made sure mentions count doesn’t update if you’re in the Mentions view.
- Compensated for a Twitter API bug that caused fewer than the requested number of tweets to be downloaded, resulting in a gap between the new tweets and the older, cached tweets.
- Addressed problems with using browser URLs for Instapaper or URL shortening before the page finishes loading.
- Worked on memory efficiency and performance throughout the app.
- Fixed a number of crashes that could happen as a result of invalid search queries.
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):
- Open in Main Timeline:
- Open in Mentions:
- Open in Direct Messages for a specific account:
- Open profile by username:
- Open tweet by ID:
- Do a search:
- Do a post with URL from a specific account:
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.