In the comments of my previous post “iPhone UI Vector Elements”, one of our readers asked why we would bother going to the trouble to recreate vector versions of the iPhone user interface. It’s a great question which leads to the larger, more general question of why we would create application mockups in vector format at all.
Stick with what you know
First off, just to clarify, I am a designer. I leave Apple’s developer tools to our programmers and stick to the visual tools that I am most comfortable and familiar with. I am fortunate to be in an environment where quality UI and visual design is valued on the same level as rock solid performance, speed, and reliability. Getting my hands dirty with the developer tools has never really been an option. The developers at Mercury Intermedia handle all of the X-Code and Interface Builder work and do a tremendous job.
Next, I want UI objects that I can quickly and easily modify and manipulate. It is much easier for me to make adjustments to vector objects when I need modified color variations and custom UI elements for new applications. Although the argument could be made for Photoshop, and it certainly has it’s place for more complex or organic visuals such as EA’s Sudoku or Clif Bar’s Save Our Snow for example, the speed and ease of editing and duplicating vector files for standard UI elements in Adobe Illustrator tends to generally be more productive.
Be prepared for the unexpected
Beyond all of this, you never know when scalable graphics may meet unforeseen needs. For example, we had a prominent design publication recently request several print quality screenshots of the USA TODAY application for an upcoming issue. If we hadn’t built this project in vector format, it would have been much more difficult and time consuming to go back and recreate files that the publication could use. We would have likely ended up with less than ideal, tiny screenshots of our app or would have had to set up a photo shoot of the app on the device. Since we had already built all of our mockups in vector format, it made creating these print quality screens much less painful.
Plan for the future
Finally, it is almost imperative at this point to build applications with higher resolution devices in mind. As Sebastiaan de With recently hypothesized in his Cocoia Blog post “Not hosed (for now)”, “In the future, Apple will change to a better (not necessarily ‘bigger’) screen, and developers of iPhone apps will face a huge issue: how do we scale the interface?” There is no clear road map as to when this could happen, but I do agree that it is likely to be an issue at some point.
Arguably more pressing than the possibility of an iPhone screen resolution change is the possibility of a new Apple portable form factor altogether. What if Apple follows through as the rumors have recently suggested and releases a Kindle sized tablet device? What if that device has an App Store environment? We would like to be prepared if our clients come to us wanting their applications ported to such a device. Not that we would port an iPhone application as is over to a device that much larger, but we would certainly have a huge head start.
There are certainly talented developers out there who can handle the majority of their standard iPhone visuals directly in Interface Builder. Others out there who might turn to a graphics based application, have spent years in Photoshop and would find Illustrator so foreign as to greatly reduce some of the above mentioned advantages. However, for those of us comfortable and familiar with Illustrator, it is an excellent tool for user interface design and holds many advantages. If you have been considering exploring Illustrator further for UI work, I would highly recommend it.