By the time I released the 1.5 version of MindPulse I was starting to feel like a real iPhone developer.  I had been writing apps for the iPhone and iPod Touch for awhile before that, but to do the things I wanted to do in MindPulse 1.5 I had to completely embrace the Cocoa/Objective-C way of doing things (as opposed to just working “around” them).
I was about to go off on a tangent to explan what I mean by “around”, but I’ll save that for another article.
At this point I was looking for a new challenge.  I had several ideas for the next release of MindPulse but most of them were not possible with the current iPhone operating system (this has changed since the release of 3.0).  I started working on some other ideas but they all ran into roadblocks due to limitations placed on third-party developers (or my own capabilities at the time).
MindPulse was sucessful, but it served a niche market.  The upside of this is that customers know what they are looking for and are willing to pay for Quality.  Competition is lower than in general-audience applications, so I could spend time making the app better instead of playing marketing and promotion games.  The downside of course is that the audience is limited, and it’s hard to explain the application to people outside of the primary market.
So I started looking in the opposite direction for my next app.  I knew I could write an app that is sucessfull in an unsaturated market, but could I write an app that could compete in a segment that is packed with other applications?
After doing some research I decided the most saturated app segment was the “to-do” list*.
I downloaded a bunch (and even purchased several) of the top applications in this category and used them for a couple of weeks.  I took notes about which ones I liked and why, and what turned me off about others.  In the end I was able to identify the key factors  for me that made some more useful than others, and from this I was able to generate a design unlike anything else that would be superior to all avaliable applications (at least for me).
This leads me to the first key point of this essay:
1.  Design for yourself
I’m sure that the design I came up with isn’t for everyone, but there’s no way for me to know what is.  If you design for yourself, then the worst possible thing that can happen is that everyone else hates it.  If you try to design for everyone else, and they don’t like it, you might hate it as well.  Which is worse?
This of course limits you to designing things that you will use; I think this is ideal.  If everything was designed by someone who would actually use it, I think we’d all be better off.  If you don’t think you can come up with an idea for something you yourself would use, then you might consider working in another medium.
So I designed a to-do list app unlike anything else out there which suited my needs perfectly.  How did I do this?  
In my research there was one thing that stood out as the obvious reason I prefered some applications over others, and this leads to my second key point:
2.  Optimize for input
The “critical path” for the to-do list is data entry.  The whole point of a list like this is to remind you to do things you would otherwise forget, which implies that the persitance of these items in your mind is fleeting.  Therefore, when something comes to mind that you need to remember, the amount of effort involved in recording it needs to be as minimal as possible.  Secondarilly, these tasks seldom come to mind under circumstances that make adding them to the list convinient, so any data entry method needs to be as accomodating as possible to limitations placed on the user.
For applications like this, gathering input from the user is where everything starts, so we need to make sure it is the most painless of all operations or the application will go unused.  No amount of cool functionality matters if you can’t capture the data in the first place.
——————————————————-
Input Method Execution Time
Keyboard 3 sec.
Picker 2 sec.
Voice 2 sec.
Table List 1 sec.
Button .5 sec.
Tap .5 sec.
——————————————————-
Figure 1: Time taken to enter the value “truth” using common input methods avaliable on the iPhone
I came up with a design that optimizes input by sacrificing flexibility (there is always a trade-off) and designed the rest of the application around this input method.  I started implementing the app and testing, gathering feedback from potential users and things were going well.
I was using alot of things from the iPhone SDK that I had not worked on before and I was facing a stiff learning curve.  There were times that I thought about throwing in the towel on the idea because in the back of my mind was this nagging fear that I was just “re-inventing the wheel” and after all this effort I’d release an app that nobody would understand.  It was during this time that my sister-in-law stopped by to borrow our shop vac.
I have alot of tools.  Having been a hacker all my life, and having bought an 80-year-old house a few years ago, I’ve accumulated a large collection of useful bits.  I’m not sure you’d call the shop vac a tool, but it falls in the same category.  
I love to lend out tools because I like to encourage creativity and work in any way I can.  I also have terrible short-term memory, and I’ve lost many things due to this combination of behaviors.
So when Casey asked for the shop vac, I wanted to take a note of this so when I needed it again, I could remember where it was.  I pulled out my iPhone and fired up Notepad.
After typing in the information it occured to me that it might be just as easy to snap a photo of Casey and the shop vac, that way I would know what was borrowed and who borrowed it, but it would be buried in my photo library and end up as yet another weird photo on my Apple TV.
This is right about the time that it occured to me to combine the design philosophy I was using for the to-do list application to the problem at hand.  The result was the first draft of Lent, which looked like this:

1.  Take a photo
2.  Pick a contact
3.  Add it to a list
Since I had invested the time learning about all of the parts I’d need to build Lent while working on the to-do app, I was able to put together a prototype in a matter of hours and run it past a few iPhone owners I knew over the next few days.  The feedback was positive so I jumped back into XCode to turn the prototype into a working application.
I spent about a week playing with this version on my phone and this is when the idea of the “nag” feature came to mind.  Since we already had a contact associated with the photo, it would be a simple matter to pull out their email address and send them a message when I wanted the item back.  Another night of coding and this was working.
Now it was starting to look like a real application, and this is where the hard work begins.  Getting a working prototype together is one thing, but there is alot of “polishing” to do before it’s something you can release on the unsuspecting public.  The biggest challenge for this application (as it is for many) was memory management.  Working with photos, potentially many of them, requires a deliberate strategy for managing these objects.  I could write alot more on this subject, but again I’ll save it for another article.  Long story short, I spent about three or four weeks getting the app into the kind of shape necissary to distribute to even a small group of testers.
At this point I considered the app “feature complete”.  I had alot of other ideas for potential features and after the Lent beta was in the hands of my test group there were even more, but I wanted to keep the app in line with the original design principles that lead to it’s conception so for the most part, Lent is as it was when beta testing began.
When Lent was released I thought that it would be unique in the App Store.  As it turns out, there are a couple other applications for keeping track of items you lend out; some are specific to a type of thing (books, DVD’s, etc.) and some are general-purpose as well but all of them require more “input overhead” than Lent.  How Lent competes with these applications will be a good test of the design principles behind it, and I look forward to seeing what the market says.
*  Of course this is debatable, and certainly the most saturated area is more likely fart-related applications or the like, but there was a certain strata of software I didn’t want to dip below.

See and download the full gallery on posterous

Advertisements