Better, I thought, would be to always ensure that when a partially-visible cell crops up, the UITableViewController will quietly nudge things to be completely visible.

vs. 

In the first image, you can see the only part of the top and bottom cell. In the second image, the cells have been nudged so that everything visible is completely visible. This took a little noodling around with math but it wasn’t hard to do. Put this method into your UITableViewController subclass:

- (void)snapBottomCell
{
	NSInteger cellHeight = 62; //Cells for my view are 62px tall. Sub your own height here
 
	NSInteger offsetOverage = (NSInteger) self.tableView.contentOffset.y % cellHeight;
	//Use the tableview's contentOffset property and the cell height to determine how much is being cut off
 
	if (offsetOverage > 0)
	{
		//If the overage is more than 0, we should figure out what the new offset needs to be
 
		NSInteger newOffset;
 
		if (offsetOverage >= (cellHeight/2))
		{
			newOffset = self.tableView.contentOffset.y + (cellHeight - offsetOverage);
			//If the overage is greater than or equal to half the height of a cell, pull the cell up so it's fully visible
		}
 
		else {
			newOffset = self.tableView.contentOffset.y - offsetOverage;
			//Else, push the cell out of view
		}
 
		//With the new offset determined, animate the movement:
 
		[UIView beginAnimations:nil context:NULL];
		[UIView setAnimationDuration:0.5];
		[UIView setAnimationCurve:UIViewAnimationCurveEaseOut];
		[self.tableView setContentOffset:CGPointMake(0, newOffset) animated:NO];
		[UIView commitAnimations];
 
	}
}

You’ll need to implement these two delegate methods as well:

- (void)scrollViewDidEndDecelerating:(UIScrollView *)scrollView
{
	[self snapBottomCell];
}
 
- (void)scrollViewDidEndDragging:(UIScrollView *)scrollView willDecelerate:(BOOL)decelerate
{
	if (decelerate == NO)
	{
		[self snapBottomCell];
	}
}

And that’s it. If more than half of the bottom cell is visible, the cell gets nudged completely into view. If less than half is visible, it’s pushed out of view.

You could change snapBottomCell to accept cellHeight as an argument if you need to accommodate cells with variable heights. You might sort out a particular cell’s height like so:

	NSIndexPath *indexPath = [self.tableView indexPathForRowAtPoint:CGPointMake(0, (self.tableView.frame.size.height - 1))];
	//Get the index path of the cell currently visible at the bottom edge of the tableview
 
	UITableViewCell *cell = [self.tableView cellForRowAtIndexPath:indexPath];
 
	[self snapBottomCell:cell.frame.size.height];

There are cases where this isn’t useful: long lists whose primary function is selecting data for loading in another view, for example. Still, any time you’re using UITableViewCells to house controls or chunky bits of data, it might be good to ensure that only whole cells are displayed.

Once upon a time…

Tallymander was born because once upon a time, I worked for the man and that meant wearing fancy pants and shirts that buttoned (the better to establish my image as a professional and advance my career). About once a month I rounded up my finery, counted it, and took it to the dry cleaners.

My mental math abilities could be bested by a fruit fly so I wondered if the App Store had anything to make the counting easier. They did, but it was either crap or too limited for my needs. The idea for Tallymander was born. I wanted to make something simple but useful.

I expected to make about $40 off of it, but I knew I wanted the challenge so I plowed ahead anyway. 1.0 shipped and people liked it. Really liked it! I got a handful of emails with kudos and feature requests. I wanted to get cracking on GlobeJot but decided I would spend a little time adding some customer requests to Tallymander first. A couple more weeks of development and Tallymander 1.1 was submitted. I forgot all about it.

Until one night, around midnight, when I got the “Ready for Sale” email that iPhone developers live for. Tallymander 1.1 was live.

And an App Store Staff Favorite. I peed myself a little. There followed a slew of copycat apps following this prominence. So it goes on the App Store.

The future

Tthanks to a handful of enthusiastic users and a little help from Apple, Tallymander managed to make me a tidy bit more money than the $40 I had expected. About $4,000 to date, in fact. Not bad for an app that started as a two week UX trial.

It wasn’t enough for me, though. The best thing about Tallymander was getting emails from customers with wildly unexpected and diverse use cases. I haven’t gotten a single one that’s like another. The greatest commonality across all the customer emails boiled down to two main themes: better organization and data analysis.

My customers weren’t the only ones with ideas on how to make Tallymander better. A minor point release with a bug fix was rejected by Apple in April. The reason? The reviewer didn’t understand how an existing interface element should work and rejected because it didn’t work according to his expectations.

The rejection was dumb — the previous major release that had introduced the interface element in question had been approved just fine. But then it dawned on me: the interface sucks.

Kill the sacred cows

Tallymander’s interface had won many fans, even at Apple, but there was one problem: it was too inflexible. To tally, you tapped anywhere on a tally’s cell:

Each cell had a little indicator that showed what mode it was in: addition or subtraction. You could temporarily change all modes globally with a sort of “shift key” in the toolbar. 1.2 introduced a “caps lock” style option for this shift mode, which is when the whole UI, for me, went to hell.

Mission 1: Fix the interface

Tallymander’s interface, where it worked, worked really well. First, you could count an infinite number of things. Since it used UITableView, which can store as many cells as you want, it could scale to many tasks. Whether you’re counting two things or twenty, Tallymander had you covered. This was an enormous advantage over some of the other early tallying apps.

The other major benefit was ease of interaction. The hit box for the user to interact with any given tally was 320 x 80 pixels. Large targets are easier to hit. Big win, especially if your attention is on something other than your iPhone.

The secret sauce to Tallymander, the reason why people love it, is the one that has evaded almost every other competitor. There’s a user-definable tally setting that lets you shake the iPhone to increment the count. Tallymander  vibrates when a successful tally is registered this way. The first time someone does this, their eyes light up. Then they do it again. And again. And again. It feels good. So no matter what else, that had to stay.

Aside from these things, it was time to take the rest of the UI out and shoot it. Shift mode? That sucks. Separate modes to reorder and edit? That’s crap.

Ending shift mode meant add and subtract had to live together, in harmony, at all times where you’d be tallying. It took many sketches to get something I wanted, but I ended up with this configuration:

Tap anywhere on the left, you get subtraction. Tap anywhere on the right, you get addition. The hit box is still pretty generous and the tradeoff in the ease of switching between those two tasks — just move your finger — made it worth doing. The cell itself is also smaller so that more tallies can appear onscreen at once. The other major change: no more alarm clock style numerals. They had to be pre-rendered as images and while I liked the look, the pre-rendering limited the kinds of data that could be displayed in the counter field. The new counter is stylized in homage to the old, replacing its seven-segment grunge with clean OLED-style pixelation.

The death of shift mode is exaggerated. It’s still around, but now it makes more sense. It is config mode and it shifts all cells into a very different realm of tasks: resetting counts and changing tally-specific settings.

This works very well. You can switch into config mode, make all the changes you like, then get back to your tallying. This is a lot closer to how the user works: adding and subtracting both fit in the same basic mental mode, in the end, and it’s counterproductive to separate them.

Best of all, deletion and reordering were reunited as one edit mode:

With addition and subtraction living in one spot with no clearly defined button, it was important to give the user some kind of visual feedback. Most buttons on the iPhone darken as the user touches, then register an action when the touch lifts. This was inappropriate for Tallymander — counting needs instantaneous feedback. Delays lead to confusion. Instead of darkening a region, Tallymander 2.0 glows according to whatever interaction the user has selected:

The glow matches the color of whatever gem corresponds to the action the user selected. Here, the user has tapped the addition side of the cell. There’s also a satisfying click sound, for users who want it.

Finally, I hated the initial look of the UI and rebuilt it. The shipping app looks like this:

The last excision of suck was the reset confirmation. Previously, Tallymander popped up an action sheet asking the user to confirm whether or not they wanted to reset a given count. Time consuming. Worse, this option could be switched off on a per-tally basis, leading to inconsistent expectations. In 2.0, tapping a cell’s orange reset button puts it into a temporary “are you sure?” mode, changing its title label with instructions to confirm. If the user taps again, the count resets. If not, after a brief delay, it switches harmlessly back out into its normal mode.

This lets experienced users quickly reset things while preventing accidental data loss. It’s a small detail but it’s one of my favorites.

Another small refinement: the table that contains the tallies will never come to a stop with a tally half-on, half-off the screen. The cells are always nudged so that they’re completely visible.

Mission 2: Customer requests

You’ve got a lot of data. You’ve got questions about your data. What do you do?

If you’re using a spreadsheet, you type up an equation for some quick analysis. I’m a huge spreadsheet nerd, so I like this freeform approach. Customers wanted percentages of this and that and while I could easily provide a one-size-fits-all, pre-canned percentage tool, that’s not how I roll.

Tallymander 2 lets you build chains of equations, called computations. Comps can use any tally as input. They can also use other comps. You build comps with this UI:

Each step uses the result of the previous step as its first input, lets the user select an operation, then a second input. As each input changes, the result of the computation is updated accordingly. You can even format the final result as a percentage. This kind of data analysis has a lot of benefits, especially for those keeping scores for athletics or tabletop gaming.

I’m pretty happy with how this came out, with one snag: since there’s no way to do PEMDAS with this, you need to set up other computations to handle parenthetical parts of a given equation. 3 + (Red roses x – 4, for example, would require the creation of two computations. I think I can solve this by allowing sub-computations that don’t show up in the many tally list. Something for 2.1

The other big request was the ability to group tallies together.

Done. Set up as many groups as you like. An implementation detail currently means you can’t move a tally from one group into another. I’ll find a way around it for 2.1.

Mission 3: Object Model

Implicit in any new version of Tallymander was the need to create a proper object model. The Tallymander 1.x model was, and I’m cringing here, a collection of NSDictionary objects stored to, yeah, NSUserDefaults. C’mon! This is not how you want to build your object graph, folks. It was an easy way to wrap my mind around the data I needed to store early on. It worked in the beginning but only with much nasty, nasty code.

Luckily, two things happened since I first wrote Tallymander. First, I learned how to build model objects and their relationships by hand. Second, Apple brought Core Data to the iPhone, which does all that heavy lifting for you. For 2.0, I was ready to do it right.

Joyful. That’s the only word to describe working with Core Data. It’s an outstanding, powerful and well documented framework. What would have taken me days to code by hand I can set up in Core Data in one afternoon. I hit an occasional bump or two but always had Stack Overflow to get me back out of the woods. Very glad to have this tool as a developer. 2.0 would have taken a lot longer without it.

But I wasn’t done with my rickety NSDictionary-based model from 1.x. I got to play with it one last time when I wrote the import code that converted the old data to use the new, shiny model. The worst code is what you wrote eight months ago, I swear it.

Kitchen sink

Thanks to Core Data, it was easy to build a pile of new options for tallies. Some of these are customer requests, some are just ideas I had that might be fun.

One of my favorites is the icon picker:

Twirl the wheel to change the icon. There are about fifty to choose from. Of all the UIs I’ve ever built, this is one of the most fun to use. The icon in the preview at the top updates as the wheel is moved. I like playing with it.

The icons are from the excellent Glyphish collection. Awhile back I contributed to the author’s Kickstarter project. As a backer, I was rewarded with access to the source vector files that make up the icons. Useful stuff and a great starting point to build Tallymander’s icon collection. Sadly, Tallymander is not blessed with the Glyphish “awesome” designation, but you can’t win ‘em all.

If the built-in icons don’t strike your fancy, you can insert one from your library, too.

I’m also liking the color picker:

Another advantage of ditching pre-rendered graphics for the counters: color options galore. I picked some tasteful ones, mostly from Apple’s Crayon Picker palette.  I like this arrangement better than picking colors off of a list. Everything is visible on the screen at once.

Broke some new ground with custom UI in 2.0. In all, I like how it came out. These are big wins that add a lot to the user’s ability to make Tallymander their own.

Sharing

The final chunk of functionality that needed to be built was better sharing options. 1.x allowed an email report to be sent from the application. This was decent but with all the new features and depth in 2.0, I wanted to go further.

CSV export ended up being much, much easier than I could have guessed. So that’s in there, it works and I’m happy.

More exciting is every time I play with the new, full-on sharing feature. Tallymander will let you send your whole setup to someone else.  It’s a combination of Core Data, Amazon S3 and the ASIHTTPRequest API. ASIHTTPRequest is a superb bit of code. Drop it in, read the docs and you’re putting and getting data from the web. Stable, easy to understand and an enthusiastic developer at the wheel. Saved me much pain, I’m certain.

And beyond

So that’s 2.0. Already I have a mounting list of new refinements and additions I’d like to make. It’s a fun app, though, and my proudest yet. Thanks to my enthusiastic customers. I couldn’t have done 2.0 without your excellent feedback. It was quite a trip: Tallymander 1.2 had about 2,000 lines of code in it. 2.0 has around 8,000 and it’s a complete rewrite.

I’m excited to keep tearing into the future of Tallymander and my other apps. As the first full-featured app I’ve built since going full-time, Tallymander really helped me find my tone and style as an iPhone developer. This stuff is so much fun.

Since Tallymander was made a Staff Favorite last month, I’ve noticed that there are more solutions to the tally problem in the App Store than when I began.

There are, of course, many ways to skin a cat. For me, Tallymander does the job best because I built it to my exact desires. Still, while many elements of design are subjective, there are good and bad ways to do things. Let’s look at some of the other approaches to the tally challenge.

Tally Max

A few things jump right out:

Inefficient use of space: The entire width of the iPhone’s screen is available to each tally cell, but the tally title is confined to a much more limited area. The title is the only element that the user can customize beyond the rails of your design — give it some room.

Unfriendly controls: A good, obvious rule is that the larger a control is, the easier it is to interact with. This is why, for example, the title bar of a window ends up being much larger than the controls to close it. You use the title bar more. It’s a puzzling choice, then, that Tally Max’s plus and minus buttons are the same size, since any given counter is likely to flow mostly in one direction. In Tallymander, the entire table view cell is the button. You’ve got a big, fat, 320 x 60 target to hit to accomplish your task.

Unmotivated interface: I have a neurotic obsession with LEDs. I have always loved them. That’s why they appear in pretty much every interface I’ve ever designed. Tallymander’s seven-segment counters exist because they’re readable and because I love how they look. I lovingly built each numerical glyph in Photoshop with the pen tool and spent hours tweaking the glows and highlights for each color. In Tally Max’s case, the counters are just flat output from a commonly available font. If the author didn’t want to bother motivating their appearance, why not use a simple text label, like Calculator does, and get a competitive edge from the ability to count beyond 9,999?

Tally Max makes other decisions I don’t agree with. Tallies are tied to calendar dates and they reset each day, with a record stored for previous days. It also organizes tallies into categories, which could be useful, but puzzlingly, you create new tallies from the Categories view instead of the Tally view. It’s weird and, ultimately, trying to do too much.

The one inarguably bad bit about Tally Max, though, is this note on its App Store page, screenshot taken 3/20/09:

That feels like a show-stopper. I would remove my app from sale until that business was resolved.

Clicker Tally Counter Plus

This app has a terrible name. I’m fortunate in having a girlfriend whose beauty is matched by an arresting, powerful wit and who comes up with terrific branding to replace my awful project codenames. I sympathize with the challenges involved here. At the same time, the name is very descriptive, so while it gets no points for imagination it will be easily found on the App Store.

The interface is simply gorgeous. I like the aesthetic a great deal, hearkening as it does to chunky, clicky analog gadgets of forgotten days. The font selection is tasteful and motivated to the overall look and feel of the interface. Bang up job.

For me, I sometimes find myself wanting to count multiple things at once. This app doesn’t address that need especially well, but it’s still the one I would pick if I had to choose something that wasn’t Tallymander.

Counters

Meh. The button lighting isn’t even consistent.

Game Keeper Plus

Game Keeper Plus touts itself as a score keeper, but can do other things:

Hmm, okay. I honestly can’t figure out how the hell this application works, though. Here’s another screenshot:

There’s a bit of backchat about the other apps that are built for keeping scores:

This sales copy explains everything, I think. In trying to do so much, it feels like the developer has overwhelmed himself and the user with… a whole lot of stuff. Admittedly, Tallymander wasn’t exactly built with scorekeeping in mind, but for basic game-related tasks I think it does pretty well thanks to a focused, easily-navigated user experience. When you try to do too much, you end up doing too much.

On the subject of doing too much, back to this app being positioned as a stat tracker for non-game related stuff:

That’s fine; I think everyone here, myself included, isn’t doing much more than building digital versions of the abacus. Still, with so much game-related terminology baked into the UI, it’s tough to create a pitch for this app’s versatility outside the scope of tracking scores. The user ends up having to build a mental translation table between the meaning of the game-related words and whatever custom use they’ve imagined for themselves.

I don’t know what the deal is with those eyewatering, heavily aliased pie charts, either.

The Upshot

Every problem space has a multitude of ways to approach its solution. This is a great example of that truth. Each of these apps brought different spins to the task of counting things, with varying levels of success. Gruber’s maxim about iPhone apps is proven once more: Figure out the absolute least you need to do to implement the idea, do just that, and then polish the hell out of the experience.

Except for Clicker Tally Counter Plus (say it five times fast), I think each of these apps could probably do with trimming some amount of functionality in favor of making cleaner, more easily navigated experiences. Remember that the iPhone screen is a cramped, tightly-packed place and that mobile users are hasty, impatient people. The less stuff your users have to navigate and the less time they spend having to consider their options, the happier they will be. Functionality and power is good, but it’s best if you can tuck it away until the last possible moment before the user actually needs it.

On that note, I wonder what I ought to trim from Tallymander.

Reader Benjamin wrote to me tonight and asked:

I have researched some into iPhone programming as I am obsessed with every application that is available for my own iPhone. The problem is that the amount of books and articles out there about programming for an iPhone is enormous. Do you have any recommendations for a few killer books to read in order to learn the process/language?

What a great question. It’s one I’ve been getting a lot from people I know since my apps went on sale.

Thanks to the popularity of the iPhone and the lure of the App Store’s profit potential, there’s plenty of crap floating around promising to teach you how to program for this new platform. Much of it sucks. Thankfully, there’s some gold to be found for iPhone SDK autodidacts. Let’s check it out.

Wikipedia

Say whatever else you want about it, Wikipedia is, unsurprisingly, host to some thorough Computer Science articles. Any time you encounter a term about programming you do not understand, consult Wikipedia. Here are a few examples to get you started:

Arrays

Loops

Model-View-Controller, the design pattern advocated by Apple for iPhone development.

Cocoa Dev Central

An incredible resource, Cocoa Dev Central hosts some excellent tutorials on Cocoa and Objective-C. It’s a great place to get started if you don’t know much and want to learn more.

C Tutorial

If you know nothing about programming, the C Tutorial is a great way to break yourself in gently. You’ll get the basics that will become your best friends throughout your work as programmer.

Objective-C Tutorial

Once you’ve done the C tutorial and you understand why it works, the Objective-C tutorial is a tidy intro to Objective-C, which is the programming language you’ll be using for much of your iPhone development.

Cocoa Programming for Mac OS X

After spending some time doing online tutorials, you’ll want to know whether or not you want to keep doing this. If the answer is yes, Aaron Hillegass’ excellent book is for you. You’ll learn about Objective-C and the Cocoa API. This is all translatable to the iPhone, as the iPhone SDK uses many similar frameworks and conventions in the Cocoa Touch API. About midway through, you’ll start hitting some material on desktop-specific technologies like Core Data. Once you’re at that point, it’s time to move on to…

Beginning iPhone Development

Beginning iPhone Development is accessible and friendly. Assuming you’re comfortable with what you learned in the previous resources, this book is a snap. Helpful, digestible tutorials and plenty of useful code for use in your own applications. This book covers every single thing you’ll need to get most apps up, rolling and submitted to the App Store.

Other Resources

This is by no means an exhaustive or complete list of the great resources out there for iPhone development. This is just what worked for me. Once registered through Apple’s developer program, you’ll also have access to developer forums. That community is indispensable and will help you around countless, seemingly insurmountable blocks.

Bringing it Together

Holy crap, you’re thinking. That’s a lot to read and absorb, Danilo. It is indeed. It takes some time, especially if you’re starting from scratch. Be patient with yourself. This may be the steepest learning curve you’ll ever encounter as an autodidact.

For me, I started Danilo’s Programming School. That was a commitment to myself that for one to two hours every night of the week, I would work through a tutorial or scribble notes from important subjects in previous chapters. After about two months, I hit a point of epiphany and suddenly the code was a breathing, friendly, understandable creature instead of an inscrutable block of text.

This only works if you commit to learning it consistently. It’s quite literally another language and another mode of thinking.

The results, like seeing your first product cough to life after compiling, or customers writing you because they love your work, are incredibly satisfying. If you want to bring a product into the world with your own two hands, nothing is more satisfying right now than building it for the iPhone.

The reason for this is because I function almost entirely on intuition. I’m the ultimate learn-by-doing kind of person because the theoretical substance of any given thing is simply not something I am capable of grasping without considerable effort. With repeated exposure to many books and magazines, for example, I knew how a sentence should flow and what words belonged where. I didn’t know why. I could just sense the rightness or wrongness of the details.

This quality of existence is a curse in school since the bulk of studies rely on the absorbtion of theories or factoids. In a world where results matter, though, intuition serves me well. I make many mistakes in the process, but intuition lets me accomplish a great deal with minimal starting information. It also means I can fix any configuration of technology, short of breaking out a soldering iron (although even then, sometimes).

So it goes with usability. I don’t actually know what makes for good application usability, beyond obvious things like button size/placement and readable text. I do know what feels right, though, and more importantly, I know what feels very wrong. When I build an interface, it usually starts out pretty wrong. I beat on it and beat on it until all the suck goes away and I sense that it’s what it should be.

This is work. I can’t muster the effort to do it without a very specific lure: I need to know that the resulting product has a shot at being the best at what it does. This made Tallymander in particular very seductive: the competing products were so shockingly awful, both in appearance and usability, that all I had to do was apply love and attention to my own solution and I could easily ship the very best counting app in the whole store.

I have a hole in my soul. A deep, ragged, sagging, gaping wound in the very core of my being. The only way I know to fill this hole is to provide exceptionally good solutions to whatever problems I encounter. This makes product design an obvious vocation for me. (Incidentally, it also makes me a brutally effective salesman when I’m aligned with an array of products I love.)

Today I got this review in the UK App Store:

5 Stars

Very useful, well made.

I tried other counting programs and this one came out on top because of :

- Ability to count multiple things at once.

- Email feature.

- Ability to label subjects.

- Nice, pleasing  interface.

A polished program. Thankyou.

I didn’t build Tallymander because I thought it would be a blockbuster moneymaker. I built it because I knew someone, somewhere needed to count things, just like I do. When that someone went searching for a solution to that problem, I wanted Tallymander to satisfy their need without annoying them or worse: leaving them with the nagging feeling that something about it could have been done much better. For a customer in the UK, I seem to have made that magic happen. Even if I made not another cent off of Tallymander, it has done what I hoped for it.

With that pleasant surprise, the wound in my soul heals a little further.

Time to get crackin’ on 1.1.

Screenshots:

Tallymander: The original use case

Tally parameters

A childhood obsession with bar LEDs manifests itself in almost every UI I've made for the last four years.

The business of counting always sucks for me — I get distracted and lose count. Pen and paper are out of the question for this task, since I need at least one hand free. I figured that someone had already solved my problem in the App Store. I was right:

My competition

For $6.99, that lovely application could be mine.

Hell no.

Naturally, this meant I was going to have to write my own. I took on the challenge of solving the tally problem in the most flexible, effective way possible. I wasn’t going to write just a tallying application. I was going to write the killer tally app.

Tallymander is a UITableView-based tally manager. You can count up, you can count down. You can count as many different things as you like. You don’t even have to touch the screen: entries can be set up to respond to a firm shake of your iPhone. You can use it to count things, to keep score, whatever. It has swipe-delete. My favorite feature: you can email a report containing all of your tally data.

The interface was inspired by the alarm tab of the Clock app, which I love. Clock is a perfect example of how UITableView is the most badass interface scaffold ever.

I submitted Tallymander for App Store review tonight. It’s a good palette cleanser, having just shipped Oddage. I don’t want to turn into casual iPhone game programming guy. It’s also a fun experiment in usability, trying to balance power and flexibility with fun and ease of use.

Is it the killer iPhone tally app? We’ll see how it goes.

I know you have a lot on your mind lately, what with your bank purchases and the whole of the finance industry falling apart. Still, I’d like to inspire your engineers to embark upon a simple, fun skunkworks project.

You may remember cashing in the iPhone App Store craze with your free BofA app this summer. You did promise to make it less ugly. You haven’t followed through yet.

Now, we’re all busy and I sympathize. Making a nice app is hard. So I did the hard part and designed a UI for you. It’s a gift. Repay me by implementing it and sparing us all the hideous orgy of Times New Roman that is your existing iPhone UI.

Remember, I’ve done the heavy lifting. This isn’t hard. You don’t even need to do it in Cocoa. You can keep using the WebKit display your app currently uses and implement my design in John Gruber’s “shit sandwich.”

Now, the existing home screen is okay.

It’s when we actually want to get down to some banking that things go downhill:

Wow. That’s a lot of Times. Ugly, small, hard to read. Fix it like this:

Next, let’s get logged in:

Blegh. Let’s get a tab bar going. Not just because tab bars are handy, which they are, but because making the user tap an area as tiny as those menu links is just cruel to iPhone users:

There we are. The tab buttons are much easier to strike with a fingertip — less time wasted by hitting the wrong selection. We’ll start the user at the accounts breakdown, since your balance is almost always the info you want first. Next, let’s check out account detail:

Painful. Let’s better group the transaction information and use some visual cues to explain individual entries:

Not so hard. You already use those icons for desktop online banking. Now let’s transfer funds:

Making the user step through multiple screens for a single task sucks, especially in 2008. Let’s streamline this:

Better! The user doesn’t lose track of what’s going on.

Nothing crazy, here, just some simple suggestions based on existing iPhone UI conventions. I hope this helps you guys.

I built these mockups using the excellent iPhone UI PSD file. The payroll information above is speculative. I do not work for Apple. Yet.