The Road to Proximity
It’s finally over. The stealth program I’ve been killing myself over was finally finished and submitted to the Apple Design Awards early last night. Unfortunately for all of you, it’s an iPhone OS 3.0 application, and it won’t be available until it’s 3.0 is officially released by Apple. This could be next week, it could be months. I really don’t know. But I promise you, Proximity will be available on the App Store as soon as humanly possible.
Until that time, I’d like to distract you with this postmortem of the Proximity release story.
First of all, it might help to explain what Proximity is. Proximity is an application designed for commuters that rely on transportation other than their own — busses, trains, planes, even light rail such as the San Francisco BART. Proximity allows commuters to set a destination where they plan to arrive after their ride, and then fall asleep. We all know that such transportation can be a little unpredictable, so setting a timed alarm may ring too early — waking you up before you need to, or too late — meaning you miss your stop. Proximity uses the iPhone’s GPS (or the iPod touch’s Skyhook triangulation) to notify the user when they arrive at their destination, regardless of how long the trip takes.
Proximity is the first major application I’ve done without designer/developer Ollie Wagner. Unfortunately, he was hired away by the Apple mothership. This meant that for most of the time, I was on my own as far as having to design application UI and layout. I, did, however, grab fellow University of Missouri student Adam Hosp to do the application icon that you see above. Another Mizzou student, Douglas Henderson, made the actual alarm noise, which turned out pretty awesome as well.
Proximity started as a small idea Ollie and I had come up with before he was hired away. At the time we came up with it, however, it would have been restrictively difficult to develop — the user would have way too much trouble setting a location when we were unable to use the Google Maps API. However, some months later, Apple held an event where they revealed what would be released in 3.0, and MapKit was revealed. As soon as 3.0 was released to developers, I jumped on it and started working on Proximity.
Work on Proximity started out pretty early. I had a few ideas for where I wanted it to go somewhat early. The image above is an early mockup for what the screen would look like. When I show you actual screenshots of Proximity later, you’ll see that this is essentially what the app looks like at the end, with only a few tweaks.
Without a “real” designer on hand, as Ollie usually was for most of my other applications, most of the application design was helped along massively by what I call “design by algorithm”. Many of the design elements you see in Proximity were designed by various other programs. For instance, the tutorial on Proximity’s first run consists of a series of cards that look like this (this is another mockup, not a screenshot):
I definitely didn’t design those cards, with their fancy drop shadows and light edges. I wouldn’t even know where to start. Fortunately, there’s a script for Flying Meat’s Acorn application called “CurvedDropShadow.py” which can do these automatically.
Many of the buttons in Proximity were designed, not by me, but by Apple’s Dashcode. It allows you to design buttons according to certain presets, and applies macros like gloss, recess, and shine to them. When you export to the web, you get those buttons in nice, easy little .png files that can be edited and used in Cocoa apps. They aren’t always completely done (for example, I had to add some “etched glass” effects to some of the toolbar buttons), but they give you a great head start.
The hardest part of the development process wasn’t what I had expected. I’d expected that I’d have a lot of trouble dealing with the MapKit and CoreLocation, getting them to agree with each other, and to accurately ring the alarms when users reached their destination.
I was completely wrong.
MapKit and CoreLocation are both really well designed frameworks. The only fault I can give MapKit is that it doesn’t include something I wish it did (and which I can’t say here, due to the Apple NDA). I’ll be filing a feature request with Apple when I get it nailed down as to exactly how I wanted it to work.
I can’t say the same about the iPhone’s audio support. It has a lot of unexpected twists and turns that were difficult to navigate. It may have been that I was dealing with this very late in the process, under a heavy deadline — the ADAs were due by 7 PM on May 4th, but it seemed like dealing with the audio issues took an inordinate amount of time. For example, setting the audio category so that an alarm will play even if the phone is locked seems like it should “just work”, and all audio sources will respect that. It’s not true. AVAudioPlayer has it’s own way of detecting interruptions like that and dealing with it — and they both have to be set in order for audio to play. It “works as designed”, but the design is poor. Again, a feature request will be filed.
But enough of the boring development stuff. You came for excitement! You came for features! You came for screenshots! Here they are (click to embiggen):
I don’t mean to brag… well, yeah, I do — that tutorial is probably one of the coolest things I’ve come up with. It was done solely to try and win over the ADA judging panel, but I think it makes for a much better app overall anyway. It’s got some cool little features to it, too. As you can see in the image, you can shake your iPhone to skip the tutorial. That text even changes — if you view the tutorial on an iPod touch, it says “Shake your iPod” instead of “Shake your phone”. The tutorial also shows a simplified user interface, slowly adding buttons as it explains them. For example, you can see between the first two images that the tutorial image doesn’t have “Edit” or “+” buttons — the “+” shows up when the tutorial explains how to add an alarm, and the “Edit” button shows up only when there’s actual alarms showing.
I have no delusions of grandeur — I know I’ve got a 0% chance at winning a Design Award, even in the 3.0 prerelease category. I’m using almost completely standard UI all the way through (the only non-standard buttons are the ones I got from Dashcode), not something that’s been handcrafted by a talented designer like Classics or Groceries. But the ADAs are my yearly chance to force myself to make a great app. I figure if I do it enough, eventually I’ll hone my skills to where I *can* win one, designer at my side or not. This is easily the best designed app I’ve come up with on my own, and I hope I can continue learning and getting better.
So that’s Proximity. I had a great time working on it, and I can’t wait until you can have it in your pocket.
