Jonathan Branam is a senior software developer for EffectiveUI, a user experience agency that specializes in the custom Web, mobile and desktop applications. Jonathan Branam recently took time out to take to talk with Dr. Dobb's Jonathan Erickson about developing software for the iPad.
Dr. Dobb's: Jonathan, can you tell us about the iPad app that you developed?
Branam: The app is called Ideate -- it's a digital sketchbook application that was inspired by our own processes and the use of paper sketchbooks in our design and development of mobile and Web applications. It offers an arsenal of templates, clips, and icons that people can use to enhance their sketches. A number of UI-related templates include grids and monitor resolutions for helping designers/developers sketch out ideas for application development. It's a great tool for other industries as well. For example, templates for medical professionals include diagrams that help them better illustrate diagnoses to their patients or different sports templates give coaches a starting point for carving out their plays. The application was created with the user in mind -- as a user experience agency, we wanted to make sure it was as intuitive and easy to use as possible.
Dr. Dobb's: What's uniquely "iPad" about the app?
Branam: A lot the apps out there are just scaled-up versions of iPhone apps, but Ideate was developed specifically for this device. Ideate is built explicitly for the iPad's physical design -- specifically the larger UI that makes sketching and sharing really simple. This app couldn't really work on any other device like an iPhone or a desktop. The iPad's surface area gives you room to sketch and easily share with others. It's like portability meets power -- you have the power of a desktop and the portability of mobile in a device that is essentially the same size as a typical sketch pad.
Dr. Dobb's: What's the most difficult part of developing iPad apps?
Branam: It was actually pretty easy. There's different thinking involved when you develop for the iPad -- there was more development effort into making the app respond in the right way to users' actions. It had to make sense within the current context of what they're doing with their iPad.
People will interact differently with this device than with a mobile or a laptop, therefore we had to try to understand how a user would interact with the application without actually having a device to test. We actually made a wooden mock-up of the iPad to make sure the user experience would be exemplary. We were focused on things like: what does it feel like to hold it? how far does your thumb reach while you're holding it? What does it feel like to draw with your fingers? etc.
There are some limitations within the components that Apple provides -- the tools they provide are great for putting something together that looks nice, but sometimes the constraints became more apparent the more you tried to customize the app. For example, we wanted a collapsible menu because we knew that would provide the best user experience, but Apple's standard is a menu that doesn't collapse. We had to stick to the standard due to time constraints, but now that we'll have a device and will have an opportunity to gather user feedback, we'll be making continual improvements to the application to add functionality and ensure the best possible experience.
Dr. Dobb's: Are the tools we need to develop iPad apps there and ready?
Branam: Absolutely. I was very impressed with the quality of the tools. This was my first iPad/iPhone project, and it all worked great. One example is in finding memory leaks. For iPad development, you could have a mistake in your code that would cause the memory to leak and build up over time. Using a tool called Leaks which is part of Apple's Instruments suite of analysis tools, I was able to see where my leaks were and the mistakes I had made. Once I corrected those, I had full confidence that I'd taken care of the issues.
Dr. Dobb's: Is developing for the iPad a "mindset" issue for developers?
Branam: When you're developing for the iPad, you're developing a different kind of application than for a laptop or mobile. It has a fast processor, a large screen, and it is the first of device of its kind. The way you go about developing for it is very different.
There's not a notion of opening a file, working on it, and then saving it for later. With iPad, you're working with an object -- a sketch, a notecard, a chart, a Tweet. There's a lot of contextual interaction that happens that isn't immediately evident. How these objects are saved and loaded is invisible to the user. If they exist on the local device or on the Web, the user only deals with the object and not with files.
It's also about getting used to touch and gestures, and backing them up with buttons that do the same thing. Since the use of gestures is new, it is difficult to inform the users about what gestures are available. We want our gestures to be natural and discoverable, but it's hard to design them properly without a device.
Dr. Dobb's: From your experience, what's the coolest aspect of the iPad?
Branam: Every platform has a rendering framework -- on this, the Quartz framework is powerful and easy to use. We were able to draw a lot of sketches on the screen and composite them with images that the user can put in, and then scale and rotate. And we did all of this in a way that was really fast and easy to get working. It also allows you to add animation to the user interface to intuitively convey the application's action to the user.
Does your experience with iPad development mirror that of Jonathan's?
What questions would you like to ask?
Post your comments and questions below.