(This post uses formatting and features not visible in the Tumblr Dashboard. If anything below doesn’t make sense or looks plain ugly, consider viewing the post on my website. I love the Dashboard, I hate the Dashboard.)
There’s no better home for a fast-paced, goofy arcade game than your pocket. Remember the original joy of gaming - you know, before the distraction of drawn-out story lines, tutorials, endless dialog, and complicated rules? You want to just fire up a game and go, cucumber-cool 8-bit graphics blazing under your fingers. Swipe left, swipe right, eat all the berries, avoid the angry chefs chasing you around their pie kitchen. Then repeat at a higher speed.
The Sweet Solution
And there’s no easier way to get an app than by installing it right from its website - that’s right, easier than the App Store. One tap and you’re set. Because it’s a web app, see. Not one of those where you need to be online either - once you add Pie Guy to your home screen, it’ll run even when you’re not connected to the Internet. And of course, your game will be saved to a local database. Read on.
Pie Guy will run on iPhone 3GS with OS 3.0 or higher installed. Swipe anywhere on the screen (no need to point at Guy himself) and feel free to queue up your turns as in classic arcade games (meaning, once you swipe, Guy will turn that way next time this is possible.) With each level, the chefs get angrier. Godspeed.
If you find Pie Guy a fun game to play, well that’s grand.
But, I hope Pie Guy will also be an opportunity for the code-savvy among you to learn a trick or two about making serious web apps for the iPhone. Just grab my source code and tweak it. I’m not talking about just a fancied-up webpage here; this is a fullscreen game, with fast gameplay and responsive touch controls. I can’t wait to see what a better programmer does with this stuff (it’s not hard to program better than me!)
Go go go
Pie Guy is available for totally free from http://mrgan.com/pieguy. Hit that on your iPhone, install once, and play forever. By the way, if there are updates to the game and you’re online when you launch it, the updates will be automatically installed. Web apps, dudes.
Listing of artists appearing in the annual event are up at Tokyograph’s forums. I’m looking forward to Fukuyama Masaharu’s performance and hope he’ll do a medley of songs or his self-cover of the lovely “Saai.”
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 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
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.
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!
When you imagine meeting the woman of your dreams and eventually marrying her, you probably don’t imagine a blogging platform, a music blog, and a little-known electro artist from Oregon playing a big part in it, but for me, it did.
Heather and I have a lot to thank Tuneage for. We met on Tumblr — when we started following each other, of course — but it was me asking her to contribute to Tuneage that really gave us the chance to get to know each other.
We got married this weekend, some 11 months after the first time we met, and more than a year since asking Heather to contribute to Tuneage. She visited me in Brighton, and we spent a cold, winter week holed up in my dorm room listening to music, playing Guitar Hero, and just getting to know each other. During that time, Bill posted this song on Tuneage, that both Heather and I immediately loved, and it became “our song.”
I’m reposting it today for her, for me, for Tuneage, and for you guys. If Tuneage hadn’t taken off the way it did, we might never have met. So here’s to many more happy years, for Heather and I, and for Tuneage.
And just to keep this relevant: Gejius released a new album in September called The Last 46:08 of Your Life that you should probably buy.
Google’s new feature, launched today, gives you an overview of your Google Account - what all services you use, with a bit of data on each. It’s a good way to remember that oh wait, I have a Google Voice account. Let’s hope this grows.
My first Okinawan pop song composition titled “Ti tu Ti.” The theme is based on the Okinawan folk song “Tinsagu nu Hana.” Big props to my big bro on chorus (soon to be joined by my SIL when she has her part ready) and my SIL for the very cool piano accompaniment. (I’m on sanshin and singing the verses.)
We’re about 90% complete on the song and it’s been a great learning experience for me as a songwriter. Before having my SIL lay down the piano part, I never thought about measures, signatures, etc. Well, next time. :)
I think the recording came out pretty good considering that I used my MacBook’s built-in mic with Apple’s GarageBand (of course).