Last Wednesday, I went to a one-day session in Chicago titled iPhone Tech Talks. I am currently taking the Cocoa Academy course, and thought that this would be a nice way to get some additional information. The conference had probably about 400 people or so. I was a bit worried because I have neither an iPhone nor a Mac, so I thought that I might have been out-teched. :) However, it seemed like most people did not bring their laptops, and some of the people that I talked to had as much or less experience developing for Apple platforms.
I took like fourteen pages of notes, so I will probably break it up into a few posts. This one, which gives an overview, one about usability (I was writing the entire hour and a quarter session) and one about performance and using different libraries.
What’s in it for you?
Hmm… Well, maybe you are doing or planning on doing some kind of iPhone development. That would be nice.
But I was talking with someone who has the G1, and the features are pretty much the same aside from native multi-touch, so most of the design principles and considerations will be present there. Indeed, any mobile device has at least some of the constraints that you need to think about when creating an iPhone app: usability, market reach, battery life, screen real estate, interrupts, performance, and more.
I would say that this was my first foray into mobile development, so it was definitely an eye-opener. If you have developed for a mobile platform before, then some of these comments will be old hat, but there still might be some gems in there.
Overview
The session lineup can be seen here. I figured that I had a moderate understanding of Room A or could read about it online, so opted to stick in Room B because the C room sessions just didn’t really seem all that interesting. You could mix and match, but conveniently the ones that I wanted were in the same room. I did sit in on the “Using Advanced Web Technologies on iPhone” session, but it was after lunch and not that interesting, so I ended up just going to the other room after about forty-five minutes. It was a lot more engaging. It’s interesting making decisions with very little information on what the actual session will be about. I’d be interested to hear if anyone else has rules of thumb for figuring out which sessions are going to be useful, or what kinds to avoid.
So everyone went to the general overview session at the beginning of the day. They started out with some “get pumped” videos with the standard Apple music, showing off some popular apps like MLB.com and Urbanspoon. Then they gave a business update. The iPhone platform is very vibrant, with four million iPhones purchased in the first 200 days, 13 million to date (not counting iPod Touch), and over 200 million App Store downloads in only 104 days. These are impressive numbers that seem to imply that if you create a good app, you won’t have trouble getting it into people’s hands. The iPod Touch mentioned earlier is significant because it also runs App Store apps and has the same features (even screen dimensions), save for things like phone capability. So that’s another thing to consider.
Next they gave an overview of ingredients for success with an iPhone project. If you have a product in mind, it’s recommended that everyone who will be giving input has at least some working experience with using the iPhone. This makes sense, because there are some pitfalls if you don’t consider what you have to work with. There is no mouse, so there are no rollovers or scrollbars. The metaphor of clicking doesn’t apply because you are actually tapping on the screen. The mouse offers continuous input, while the finger is discrete. The interface is quite a bit different because of user expectations and use conditions. Text input is accomplished with a soft keyboard rather than the traditional one. The iPhone only runs one app at a time.
These are things that are clear if you use the iPhone on a regular basis, but imagine working with people that have never used it before. There would some difference in ideas that would not be easy to overcome.
Also, you want your app to feel like it fits the iPhone, so you need to consider things that are already built-in: microphone, camera, location awareness, ubiquitous internet access.
Typically you should envision that your user will be using the iPhone under a table in a poorly lit room at about arm’s length. This severely alters your approach to designing the user interface and visual elements. The screen needs to have high contrast. There was a discussion about whether white text on a black background was better than black text on a white background. The thought was that you should consider where your user will typically use the app, and go from there. If they would typically use your app in a poorly-lit environment, then you should make it white on black. Conversely, if your app is only used out in daylight, consider using black text on a white background for better contrast with the environment.
As a programmer, you need to handle interrupts gracefully. Because the iPhone is a phone, you should expect it to ring at any time, and should test the behavior frequently. You need to save the state of your app somewhere, cut out your audio, pause the game, and so forth. When the phone call or other interrupt is done, you should also resume in an orderly fashion. Just unpausing the game when the phone call is over will lead to your user being unhappy.
Attributes of a successful iPhone app
Your app should be delightful. This means that it is inviting, intuitive, engaging, exciting, and enabling. It should be a pleasure to use, and is something you would consider remarkable. If your users are to remark positively to others, it must be remarkable.
Your app should be innovative. It should be revolutionary, inspirational, or fresh. This doesn’t mean that you have to create something new, just do it better than what is out there in some way.
Your app should be designed. This takes support from all levels of your organization, and works best with small teams.
Your app should be integrated with the iPhone’s many rich features. One of the strengths of the platform is connecting to other services, so your app should probably be connected.
Your app should be optimized for performance. They made a suggestion that you automate performance tests so that when code is checked in, the performance tests automatically run. If the test fails, the build should break so that the offending code can be cleaned up for better speed. This was a nice idea, and I had not heard it before. But with the importance of performance, it’s almost as important to get it fast as it is to get it right. So this matches up well with continuous integration. Consider it ‘continuous performance.’
Other miscellanea
Over lunch and between the rapid-fire sessions, I actually ran into many people that either had ties to Indianapolis, or actually worked or lived there. So that was pretty exciting. I figured that I would be the only one. There were others from Bloomington, etc.
I enjoyed the tech talks, although I didn’t really enjoy the driving in Chicago. :) It’s quite different beast from Indy. There are like horses and bikers and pedestrians and crazy taxis all over the place.
They gave out a free shirt that had some interesting packaging, which you can see here.