Prototyping iOS Apps with Storyboards

A great thing about working at a digital agency like Odopod is the variety of projects that come our way. With new types of projects come exciting opportunities to explore new tools and workflows. For example, mobile projects continue to evolve and their unique requirements are driving the evolution of our internal process in interesting ways. More than ever, our projects demand a high collaboration between disciplines and a nimble, iterative approach. For this, we love using prototypes to bridge the gap between UX design (usually in the form of wireframes) and having a functioning application.

At Odopod we’ve always been big proponents of prototyping as an intrinsic part of the work we do. We continue to look for ways to make prototyping part of the fabric of our process and this seems especially helpful when designing mobile applications. It’s a fertile territory for innovation but it’s also a relatively new field which means less experience to refer to and infer from.

Additionally, our relationship with mobile touchscreen devices is very intimate. There’s something visceral about how it feels to directly interact with them. It’s challenging to visualize these experiences on paper. Touch input is still relatively new as are the fast-evolving mobile form factors. The quicker you can get something in your hands to react to and iterate on, the better the end result will be.

For native iOS applications we’ve been using Storyboards—a feature of Xcode1 that was released with iOS 5—as a prototyping tool. Storyboards is a visual editor that allows defining all application views and connecting them with iOS transitions such as a navigation push or modals. You can do all this without writing any code so this tool is very accessible, even to non-developers. A key benefit of using Storyboards over other tools such as AppCooker or refine.io is that it outputs a native iOS app. We can load the resulting prototype on iOS devices, interact with it, and quickly iterate. It also means that it can serve as a foundation for building the application itself.

At Odopod we recently built an interactive employee directory in the form of a native iOS app. The Directory App is a fun way to see photos, contact information, and a seating chart for everyone in the studio. I’ll be using it as a simple case study of how to use Storyboards to get a quick prototype done. Keep in mind, Storyboards isn’t just for basic apps. It is a powerful tool that can help you tackle more complex application flows as well.


Our internal Directory iOS app

Our Directory app has a common layout with tabs on the bottom and views within those tabs. The views have their own navigation bars at the top of the screen. Xcode has basic app templates which are great for jumpstarting your prototype. We started by creating a new project using the Tabbed Application template. This gives us two tabs already setup with their own views. We’ll assume that the first tab will be the list of employees and the second tab a seating chart. We wanted to see how it would feel if both views then linked to an employee detail view. Here’s what the Storyboard looks like:


The storyboard that we get when we start with a Tabbed Application template in Xcode

Next we will take images from the UX team’s wireframes representing these views and import them into our Xcode project; then we’re ready to start editing our Storyboard. Each view has its own navigation bar, so we embed them in a Navigation Controller. Next, we delete the placeholder content in each view and replace it with an Image View component that we drag from the Objects Library. Then we set the imported wireframe image as the source.


By using Image View components we can use images of our wireframes as view content

Finally, we place Round Rect Button components from the Objects Library over the images so that tapping anywhere on each view will display the next view in the flow. To make these buttons invisible (so that we can still see our images behind them) we need to set their type to “Custom” and then stretch them to fill the entire view.

Before we connect the views we need to add the employee detail view which is currently missing. To do this we just need to drag a View Controller from the Objects Library to our canvas and add an Image View to it just like we did in the previous two views.


Connecting one view to another using a button

Now we can connect the views by holding the Control key and dragging from the button on the list to the detail view. Once we let go, a little popup menu will appear and we select “Push” which is the type of transition that we’re expecting. In our case we want both the list of employees and the seating chart to be connected to the employee detail view. Once the connections are in place it should look something like this:


Connecting multiple views together

So now we’re ready to run our application and see it in action. At this point we have an application with two tabs that display a list of users and a seating chart. Tapping on any of these views takes the user to the detail view of an employee. By having wrapped our top-level views in a Navigation Controller we get a back button to show up automatically so that we can go back to the previous view.


We can run our prototype in the built-in iPhone simulator

Xcode provides built-in simulators for iPhone and iPad which enable a quick way to preview and test your prototype or application. However, it’s not a substitute for testing on an actual device where we can interact using touch input. Also, features that require specific device hardware such as GPS, accelerometer and the camera are not available in the iOS Simulator.


Running our prototype on a device provides the most accurate testing

This is the simplest form of an iOS prototype where we’re only connecting different static views together to evaluate the overall flow of an application. While you can get pretty far by just using Storyboards it’s only meant as a first step towards building a functioning application. With some additional code you can do things like move data between views, add gestures, etc. But this is the beauty of this tool, the transition from here to adding functionality with Objective-C code is seamless since Storyboards is part of the actual development tool used to build iOS apps.


1Apple developer tool used to build OS X and iOS apps can be downloaded from the Mac App Store

Comments

  • Chris Charlton says:
    Posted: 11.13.12

    Agreed. Originally I was using MockApp, basically a Keynote slideshow with links between views. When Storyboards came around to Xcode I could see two things happen: 1.) mockups with branched paths being quicker to produce, 2.) white-label template apps to be visually customized by rising app engineers.

  • Marc says:
    Posted: 11.21.12

    Thanks Boris... I think that many UX team are exactly looking to prototype more in iOS! ;)

  • ebox says:
    Posted: 11.22.12

    Whatever it’s shortcomings, and security really isn’t an issue on iOS, the fact is Flash animations are very widely used, and will continue to be so for the foreseeable future and many Apple users are justifiably irritated buy its http://www.shanghaienvy.com absence.

  • ebox says:
    Posted: 11.22.12

    Not only doesn’t iOS support Flash, the late Steve Jobs, Apple’s co-founder, was an ardent critic, citing problems with security, performance, battery life and reliability, and his faith in HTML5 and JavaScript http://www.shanghaidoll.net standards.

  • MacBoy says:
    Posted: 11.24.12

    Consider two other tools that I use on every other project: 1. Blueprint for iPad is a user interface mockup tool. It does what you described with Storyboards. Several advantages for Blueprint are: 1a. Build an interactive prototype entirely on iPad. That means anywhere you are! No computer needed. 1b. Email the prototypes for feedback and validation to your users / clients / customers. No need to go through hurdles for loading into their devices. The only drawback of Blueprint is the lack of scroll ability in table lists. Because Blueprint mockupa feel so real, the Testers want to interact with every element on the screen. I usually "wire up and connect" most of the UI elements. But the lack of scrolling through a list of items is only a small drawback. 2. BuzzTouch.com allows one to put together a real iPhone and iPad and Android app with no coding. Use the provided plugins or write your own plugin (coding required) to include capabilities into your app. BuzzTouch let's you configure your User Interface and the interactivity through its web-based service. Even the data and content of the app is hosted on the BuzzTouch service. The app automatically updates and adjusts itself when you change the content, the interactivity or the User Interface. The App will also cache and store the content in the device for offline usage. After you are done configuring the app and have the content uploaded to BuzzTouch's service, then click on the Build button. You then get the source code for iOS and Android. Compile that code with your Computer and install onto a test device. That last step is just the same as the Storyboards approach. We can build great iteractive prototypes with Storyboards, Blueprint and BuzzTouch. Get started! :-)

Want to say something?

Your comment may be reviewed by a moderator for approval.

Associate Technical Director

  @borispique

Tags

WANT A REGULAR DOSE?

subscribe