Hi, I'm Jeremy Foo.
I write software to make lazy people lazier.
tweet @echoz email jeremy@ornyx.net
Background
Recently an app was posted to the App Store that had exactly similar functionality to my first foray into proper iOS development, Traversity.
Initially, I welcomed the new entrant. That lasted until I actually saw the app for myself. Right off the bat within the App Store, I could clearly seem some form of plagiarism (or flattery, but that would require some credit where its due).
So yesterday Apple finally approved Traversity after 2 weeks in the App Review process. My education with regards to developing and deploying an app on the iPhone platform is more or less done. Save for bugfixes and feature improvements, Traversity should be on hold until I get the next app out.
Still, important lessons were learnt and it was a worthy project as a first foray into the whole thing. Go Dutch was not such a good platform, but I’ll save that for later.
So what did I learn?
- MVC works. Bringing the model portion of the project into a stable state proved invaluable in speeding up development time with regards to the Views and the Controllers. There wasn’t much context switching with a rock solid model. It became just an exercise in getting the model API right and having the views and controllers happy together. 1 week of intensive model development = 2 weeks of pain free UI work. Traversity took 3 weeks to complete.
- UI design should be functional. And 2 simple reasons at that. Familiarity and performance. If you really need functionality that does not exist in the system, try to logically extend existing controls. Make sure it makes intuitive sense and follows the HIG.
- It helps if you can find a good designer when it comes to icons. UI helps too.
- It is a bitch working alone. Between writing code, and designing the app, you still have to work on the publicity, the support options, the website, etc.
- Version Control is your friend.
- Its actually really fun!
- Waiting for app review totally sucks. The rush to complete everything is just suddenly replaced by restlessness while you wait.
- #ifdef means to remove the #define if you want to disable a feature.
- Erica Sadun’s APIKit roughly catches stuff. Better if you just do otool and nm against known private APIs.
- Its easy to talk about what you want to do, but eventually the best measure of everything is whether it is shipping. Prototypes are useless apart from saying that an idea exists.
- A good release workflow helps speeds things up.
- Strike a good balance between best practices and hackery to get things shipping.
- Go back and do better by the hacks once you ship.
It was a fun experience nonetheless and I will be applying what I have learnt into the next app that I’m planning.
Too often we get too caught up with features and frameworks available to us that we go overboard with using everything. There are many developers that overuse custom user interface elements, and others that misuse system user interface elements.
When I was developing Traversity, I was looking around to see how best to make the App look good. Of all the Apps on my iPhone, one that stood out the most was Tweetie. It was simple, thoughtful and very Apple-esque. That was where it hit me that the thoughtful or lack of usage of custom elements provides an infinitely better experience. That is unless you are Bjango or Tapbots.
Instead of throwing all your custom elements onto your app to showcase your design prowess, consider that perhaps user experience is more important than just plain aesthetic appeal. A picture is still a picture unless it does something after all.
Apart form following Apple’s guidelines, there are some additional things that should matter when thinking about design for iPhone applications.
- Progressive Disclosure
If there is not data to be displayed, removed the section completely from the tableview. - Custom, but not so custom
Add features, not graphics to UI elements provided. Users expect familiar controls, but also will be delighted to know if they also provide additional solid functionality. Cue Facebook’s usage of a UIButton in the Nav bar to bring you back to the home view. - Performance
No one wants a slow performing application. - Flow
At the end, it is also largely about information architecture. How and where you display/gather information and how they are related to each other. This provides context and easy understanding for the various functions of your App.
You don’t have to be an design god to make applications that work fantastically. Even little tweaks can help immensely.
