What would World of Warcraft look like if it were real? Probably a lot like Ingress. Created by Google’s Niantic Labs, the Android app is an alternate reality game that takes place in the real world. Players interact with the game through their mobile devices and earn virtual energy as they complete missions. Much like World of Warcraft, everyone is playing the same game, and can choose whether to be on one of the two teams: “The Enlightened” or “The Resistance.” Which side will you choose?
A great thing about working at a digital agency like Nurun San Francisco 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.
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.
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 The 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:
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.
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.
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:
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.
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.
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.
1 Apple developer tool used to build OS X and iOS apps can be downloaded from the Mac App Store
This article was originally published on Odopod’s What’s Fresh blog on November 13th.
With all the increasingly complex smartphones on the market, this intentionally simple cell phone caught our eye. Users are able to design their own phone and pick which contacts they would like to be preprogrammed, making the OwnFone a safe and affordable way for parents to stay connected with their children.
It was only this past January that Phil Schiller, Apple’s marketing chief, announced the launch of iBooks 2 and iBooks Author. Dubbed the ‘new textbook experience’ these apps, in conjunction with the iPad, were part of Steve Jobs’ vision to disrupt the lucrative publishing industry –valued at an estimated $9 billion – and reset the education system.
The idea – partner with major textbook publishers and replace expensive and clunky textbooks with digital versions. Engaging, interactive and highly intuitive, these digital textbooks are exactly the type of product we’ve come to expect from Apple.
At Apple’s ‘little’ event in late October, Tim Cook took to the stage to share some impressive statistics: iBooks textbooks now cover 80% of US high school core curriculum and are used in more than 2,500 US classrooms. These numbers can only be expected to increase with the launch of iBooks 3. The biggest problem with textbooks – their tendency to be outdated the moment they leave the printer – is solved with this update. Apple has smartly allowed for publishers to revise current versions of textbooks, ensuring that the information being taught is always the most up to date.
A glaringly obvious, but often omitted, aspect of the digital textbooks story is that in order to read an iBooks textbook, you need to have an iPad (any iOS device would technically work but you probably wouldn’t want to read a biology textbook on your iPhone’s screen).
Sleek and portable, the new iPad Mini would seem like the ultimate classroom companion. Significantly cheaper than the $499 4th generation iPad, and slightly less expensive that the $399 iPad 2, the base model iPad Mini’s $329 price tag was still much higher than most pre-event estimates.
With tight budgets, it will be tough enough for school boards to justify buying tablets, let alone the iPad Mini, when similar tablets are much more affordable:
Bringing new resources like tablets and digital textbooks into the classroom will undoubtedly benefit students. How many students will be able to benefit from it, however, is a different story. Whether the onus is put on school boards or individual families to fund these purchases, it remains unrealistic to assume that everyone can afford to do so, especially at $329 per device.