November 2008 Archives

Brent Simmons has a post up about the amount of polish and thought that goes into an iPhone app. It’s true—I’ve never put as much effort into the details of an application as I’ve put into the app I’m working on.

Case in point: the initial settings dialog that’s presented when a user first loads our app. This dialog gathers the user account information necessary to login to our service. It also persists the information into our root.plist file so it can later be edited by the iPhone settings application (I hate shunting our users to another application just to edit login credentials, but that’s a rant for another time).

Our initial architecture put a simple “Welcome! Enter your information, etc.” sort of message at the top of the screen and a group-style UITableView below it with cells corresponding to each user credential item (username, password, etc.) When the user touched a cell, we pushed in an editing view that allowed them to set the credential item. The editing view consisted of a single UITableViewCell with an embedded UITextView, and the iPhone keyboard for text entry.

The user interaction worked like this:

• Tap an item in the settings dialog to edit
• The app slides you over to the editing view controller and displays the iPhone keyboard to do your editing
• Tap the Done button in the upper right when you’ve completed editing.
• The app slides you back to the settings dialog and displays your newly edited item

So this worked fine. It was solid, gathered the data properly and got the job done.

But it bugged me that there had to be so much moving around just to edit these couple of fields. When I would debug the app’s initial load experience, I’d have to blow away the app each time on the simulator to go through this process literally dozens of times. And sometimes I’d forget where I was in the process and type in the wrong credential. Sometimes I’d get so tired of the whole back-and-forth process, I’d hardcode credentials for the debugging session just to avoid having to enter into the dialog at all.

Warning bells. This was a point of friction in the interface. A small point, but frustrating for me. True, I was going through the process dozens of times, but it still bugged me. If I was having these issues as the developer of the application with a debugger in front of me, our users would be guaranteed to have issues. Not showstopper-type issues, but I’d hear about it.

So I took a few hours yesterday and did something about it. I decided that our screen should work almost exactly like the iPhone settings app—if a user interface works and works well, copy what it does.

I reworked the editing mechanism. Gone is the movement to a separate screen for editing. In it’s place are text fields embedded in the table view cells that are activated when the user taps a credential item in the initial screen, allowing for in-line editing of this information. This brought up a second problem. When the user tapped on a field toward the bottom of the screen and the iPhone keyboard was displayed, the keyboard hid the field. This was a stumper. No amount of calls to selectRowAtIndexPath:animated:scrollPosition: would work. Finally, a bit of googling revealed this gem by Matt Gallagher to get me over the top. The view would now automatically scroll to display the selected field if it was occluded by the keyboard.

So the final result? Let’s check out the user’s interaction with this dialog again:

• Tap an item to edit
• iPhone keyboard slides up and you edit the item
• Hit return or select another field to continue, or hit the “Save” button to exit the dialog altogether

That’s around 1-2 fewer steps, with the added bonus that users have a very clear context in their minds of what they’re editing—something which they didn’t have when they were forced to another screen each time to edit a simple text field.

I never would’ve done this with a desktop application. It wouldn’t have been an issue. Need to gather user information? Put together a dialog with the correct number of text fields, some labels and an OK button and you’re done. Not enough real estate? Resize the canvas.

Not so with the iPhone. Since the platform is so limited, the thought you put into an interface affects your users an order of magnitude more than it would on a desktop app. It’s a bit like a fractal—the deeper you think about your user’s interaction with your app, the more interaction scenarios you uncover, the more code you write to handle these interactions, the more rewarding your app is to use.

There are a few things I think are essential to being a good developer. I'm probably parroting Joel Spolsky here, but I wanted to get them down while they're fresh in my mind:

Exposure to more than one platform and language

If your only experience is with one language on one platform (i.e., perl on Linux, C# on Windows, etc.), this is a signal to me that you're inflexible and not willing to stretch yourself to do new things. It's definitely uncomfortable to do try new languages and OSes, but that's the only way to stretch yourself and get better.

Exposure to pointers

Lack of exposure to pointers is one of Joel's pet peeves and I've adopted it as one of mine as well. Where I went to school, Java was the language of choice for freshman year CS courses. This was a bad decision since the first sophomore year course was Architecture and Assembly language, something which Java does precious little to prepare you for.

When I first started in industry, my first language again was Java and then C#. Another bad experience, since this left me with a rather steep learning curve for my next experience, working with low-level C++ code on HP-UX. But, to tie in with my previous point, I specifically went after this position because I saw a gaping hole in my experience and wanted to fill it in. And I'm much better off for it. I'm confident with my feel for how memory is being managed and manipulated during the course of a program's execution, be it managed, unmanaged, embedded or desktop.

But I sure wish I'd had the low-level introduction to C in my first year as a CS student.

Exposure to things that are not code

I'm talking about documentation, gathering requirements, interacting with users and customers, creating a design document or diagram. These are the things that you will most certainly not learn in college, and they're definitely not as fun as just coding all day, but they're essential to being anything more than a coding monkey.

There's probably more that I'm forgetting, but if I'm going to interview you or be interviewed by you, these are the big things I'm going to be looking for besides competency with your hard skillset.