I do not know why anything works. English, electronics, cooking, driving, name anything. In middle school, when it was time to learn about subjects, predicates and all those other sentence diagramming miseries, I got some of my worst grades ever. Writing was definitely my strongest suit at that point, but when it came to understanding why writing worked the way it did, I was hopeless.
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.
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.
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.
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.
Continue Reading…
Today Oddage went live on iTunes. Incredible. It seems like only yesterday that I started building the randomizer engine that powers the gameplay of Oddage. Of course, it’s been two months. In that time I designed an app while learning Cocoa Touch and the iPhone SDK. The adventure has been fun. I’d like to tell you a bit about it. Check out the gameplay video here before we get started.
I made Oddage based on everything I would want from a simple iPhone timewaster myself: quick launches, short games and an experience that was easy enough to jump into that playing it wouldn’t become a project you avoided.
When I first started developing software for money in Second Life back in college, I followed the rule that I should make the best possible product that I would love, instead of worrying about what other people might kind of like. Years later, John Gruber and Tim Bray bear witness to this approach to building products. In Second Life, I made extensive use of everything I sold — and sold enough stuff to pay for my food bills during school. In Oddage, I feel like I’ve hit the same mark. I’ve solved my problem, boredom, while delivering a unique and polished experience. I’m excited to see how it’s received.
Building the Interface
I knew from the start how I wanted the gameplay to work. Random sets of three words plus one word that didn’t belong, for a total of four selections. Then six selections, then eight, then ten. How to present this experience was harder. At first I thought that instead of having buttons (so 20th century!) to represent the words, the words should just appear to exist as directly touchable entities:
Unlabeled UIProgressView bars lurk at the bottom, inscrutably detailing the user’s game stats. One represents the amount of bonus points the player gets for the current round. The other represents the player’s progress to the next level. Can you tell which is which? Of course not — neither can anyone else. Continue Reading…