Your browser (Internet Explorer 6) is out of date. It has known security flaws and may not display all features of this and other websites. Learn how to update your browser.
X

Tallymander 2.0 Post-Mortem

Tallymander 2.0 has been in the App Store for a few weeks. Here’s the story on my favorite product, so far.

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:

IMG_0080Each 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:

oldbasecellTap 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.

oldconfigmodeThis 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:

photo

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:

glowThe 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:

Basketball

BasketBallEditing

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.

photo-9

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:

photoEach 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 8) – 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:

photoTwirl 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:

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.

Tallymander Sharing

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.

Leave a comment  

name*

email*

website

Submit comment