The Fractal Geometry of iPhone App Design

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.