Posts tagged ‘uikit’
Lots of Tally Counters
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. More…
Tallymander is in the App Store
I would be remiss if I did not mention that Tallymander has passed Apple’s scrutiny and made it into the App Store. Visit tallymander.com for the official minisite or check out the iTunes Store Page.
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.
Tallymander shipped
After spending the first few years of my career slaving six hours a month on laundry and ironing, I did a cost/benefit analysis and decided that dry cleaning is a better deal. The only chores involved with dry cleaning are gathering your clothes, counting your articles and driving them to the shop.
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.
Oddage Postmortem
Rands said it well: Shipping version 1.0 won’t kill you, but it’ll try. I have the luxury of a full-time job, so getting Oddage 1.0 out the door was made less painful by the reality that survival wasn’t on the line. Still, making a good product is work. I’ve told you about the evolution of the interface. Here’s how Oddage got out the door.
I’m not a Programmer
Well, to the extent that’s necessary, I am now. But I’m not the guy who has been doing it since 12 years old, who can instantly visualize a design pattern in his head, who can take spaghetti code and make it self-documenting, beautiful, elegant, efficient. Wil Shipley is probably that guy, come to think of it. His Pimp My Code series leaves me trembling in awe and inadequacy.
No, in truth, I am a product guy. I see in my head the ideal configuration of certain pieces to solve a problem and then I start building. These days, when you have a limited budget and resources, being a product guy means you build software.
When I was a kid, I was obsessed with Star Trek: The Next Generation. I especially loved a gadget from the show called a tricorder. When the day came where a tricorder toy was available for purchase, I did what any eight year old boy would do and begged my mother to take me to the store for it. (After we were done at the Star Trek convention.) She obliged me, seeing the abject desire in my eyes for this simple object in the Sunday paper toy circular. When I got it, it pleased me about as much as any toy ever could.
Then my eight year old detail-oriented brain kicked in. “Hmm,” I thought. “The blinking lights on the outside. They’re just painted on. They don’t blink like on the show. Why didn’t they care enough to really make this cool?”
And a product designer was born. I still loved my Tricorder, but I desperately wanted it to be better. Just because it felt like it should be and could be. The knowledge of this missed opportunity gnawed at me for years after.
Fun things I learned in Objective-C and Cocoa Touch this week
I spent this week re-writing the application I’ve been working since late-October. It was the right choice — the original app was full of cruft. Way too much cruft, I felt, for a codebase that had only been in existence for three weeks. The new code is much more elegant and should be easier to maintain and expand.
Anyway, on to the fun stuff:
Dot Syntax is awesome.
I’ve been working with Apple’s Utility app template, which includes an info button overlaid on the main view by a separate view. In the old implementation, I went and wrote several methods across multiple classes to hide this button to accommodate the presentation of a couple of overlaid views. I’ve been using dot syntax a lot in the rewrite to set various properties, and so decided to try the following:
appDelegate.rootViewController.infoButton.hidden = YES;
And it worked! I can set that property from any other class instance once I set:
appDelegate = [[UIApplication sharedApplication] delegate];
I couldn’t figure out at first why the various templates defined other classes as synthesized properties. Now I get the power behind it. I also don’t understand why Aaron Hillegass poo-poos dot syntax in his otherwise superb text on Cocoa development. This stuff is incredibly useful and much more satisfying than using brackets to set/get.
I also learned how to avoid the urge to hang myself when writing UITableViews. Hint: use C enums. Thanks, Fraser Speirs.