Most of us have been there at some point. The boss walks in and needs a functional demo of an app concept that they can show to potential clients at the trade show next week. They don’t expect everything to be fully functional on the back-end, but do need a set of interfaces that will actually run on a device so people can interact with them to get a better sense of the finished product. This used to be a fairly stressful situation; however the new release of iOS 5 includes a new feature known as storyboards for Xcode 4.2 which is a considerable improvement.
First things first, why even bother with a prototype? Well, people tend to be visually oriented by nature. It can be difficult to convey an idea with words alone or by showing them a set of requirements on paper, especially at events where information overload is a very real possibility. Handing a potential client your iPhone or iPad with a working prototype allows them to get a feel for what the finished product might actually do. They can take the app for a test drive and actually see your design ideas, both graphically and from a usability standpoint. Does the app look good enough to lure potential users? Does it contain enough functionality? Does it “flow” from a usability perspective or is it too confusing? At the very least, the prototype should inspire feedback, constructive or otherwise. Ideally, it’ll create enough excitement to green light completion of the project.
Before storyboards came along, iOS developers had a harder time building prototypes on short notice. The process required creating a bunch of view controller classes with their associated interface files, manually coding the transitions from one view to the next, and the application flow had to be more or less set in stone before coding began. If the flow changed mid-stroke, it required a significant amount of work to rearrange views within the navigation stack or across tabs. The storyboards feature has alleviated that pain by grouping all the interface files into a single visual workspace. This allows the developer to organize interface files by dragging views around the workspace and connecting them together, all using interface builder elements that most developers should already be familiar with.
For example, let’s say you’re given a flowchart crafted by requirements or business development folks with the purpose of providing a general idea how the application should flow – with the end goal being the development of an application which flows in exactly the same fashion. You’ll begin by creating a new project, choosing the appropriate application template, and checking to make sure you have the storyboards option selected. Once the project has been created, you’ll select the storyboard item in the file navigator and you’re ready to work. Just drag view controllers onto the workspace, add all your interface elements, and connect the views together as shown on the flowchart. It’s really that simple. Later on, if the flow changes, you just rearrange the views in the workspace and reconnect them according to the new design.
If all you plan to do is show a collection of views to a user, then that’s all there is to it. No coding, no fuss. However, most prototypes are rarely that simple and some minimal amount of coding may be required. Two situations I personally encountered involved segues (the transitions between views) and table view controllers containing dynamic cell prototypes. When creating segues between view controllers the developer has the option to create a push, modal, or custom transition. Most segues will be of the push type, which require no special coding in most cases because a back button is automatically created on the navigation bar. But what if you want to use a modal segue? How will you get back to the previous screen when you’re done interacting with elements in the modal view? In my case, I had to write a button click handler to dismiss the modal view, otherwise I remained stuck on that view when testing the prototype. In addition, if you use table view controllers in your prototype, you may need to code the table view delegate and data source methods to populate your table view with test data. The storyboards feature is great for populating static cells with test data without having to include delegate and data source methods, but if you want to present a custom design using dynamic cell prototypes, the delegate and data source are required.
Even though some coding may still be required, it is still possible to create a fully functional prototype in a mere fraction of the time it took prior to the storyboards feature being introduced. I anticipate this new feature will grow in capability as new versions of iOS get released. However, it is already easy to learn and has allowed me to create a prototype in a very short amount of time that ended up bringing in new business, so I highly recommend that you explore its benefits to your development efforts.
