If you've ever been frustrated or confused when working with an application or a Web site, blame the UX designers. If the application seems like it "just works," then you can thank them.
While it may not be obvious to most technology users, each new form factor -- desktop, Web, mobile device -- requires a whole new set of research, testing and design principles.
Apple's recently released iPad is no exception; despite some snark that "it's just a ginormous iPhone," developers of iPad apps have found that the size does matter -- and that's in addition to the iPad's unique multitouch functions and interface elements. A properly designed iPad app is not just a pixel-doubled iPhone app, nor is it a desktop app with the mouse replaced by a finger.
I spoke with UX designers and product managers at two companies -- The Omni Group and Zinio LLC -- to find out more about the challenges they faced developing for the iPad. In particular, I wanted to know more about whether it confounded their initial design plans, or whether they were surprised to find new possibilities for user functionality.
'Room for content'
"First, we really found that it's not just a larger iPhone," said Ken Case, founder and CEO of The Omni Group. "There's room for content, and interaction with gestures, that you couldn't do on smaller real estate. It's a larger iPhone the way a swimming pool is a larger bathtub."
Initially, says Bill Van Hecke, Omni Group's UX lead, the company thought it would need to use every pixel on the iPad's 1024-by-768-pixel screen: "It was our first impulse to fill up the space, but we found in the design process that it was more important to see the content." As a result, he said, the user interface on the iPad for two Omni apps, OmniGraffle ($49.99) and OmniGraphSketcher ($14.99), takes up the same percentage of screen real estate as the company's iPhone apps.
For instance, initial interface designs for the apps included a sidebar that would show open documents and allow quick navigation among them -- a feature not unusual on desktop interfaces. But on the iPad, that felt like wasted space -- screen space was more valuable as free area for drawing.
"It was a good exercise in getting rid of our excess chrome [toolbar and window frames]," said Robin Stewart, lead developer for OmniGraphSketcher. "We think we ended up making this app more usable on the iPad than on a laptop."
62 days to wrap up the job
Case noted that his team had just 62 days from the initial iPad announcement in late January to design and test the app and get it through Apple's App Store approval process. "For this round," he said, "we were looking first to bring our Mac apps to the iPad. We're looking to bring our iPhone apps also, but later."
That tight schedule, he said, made Omni really think through "the core things we're trying to do with the app, without introducing a lot of clutter."
That's in addition to making use of the iPad's multitouch capabilities, which expand on those of the iPhone. "There were some things we wanted to put in but backed off of -- and hope to put in later," Case said.
"When we first started, we had a large library of multitouch things, like a four-finger swipe for use like a key modifier, to put in," Van Hecke explained. But the designers found those gestures sometimes meant more cognitive work for the user, who might have trouble remembering which gesture did what.
"Even if it took two seconds or more to open an inspector and tap a button in it [to access a new tool, for example], this was more approachable to a new user than having to learn a new set of gestures," he said. That's true even though common iPhone gestures, such as double-tapping, pinching and others, are likely familiar to many users by now.
"Drawing with fingers is well suited to a touch interface," Case said. Developers found it was easier to "touch" back and forth between two points on a screen than to mouse back and forth.
That realization influenced how they thought of the mental "cost" of moving between areas on the iPad screen and how it would be different than the same movement on a desktop screen.
An iPad mockup
Much of what the developers learned about how to create apps for the iPad came during the design process, which required many versions of their ideas. And it required them to build a mockup of the iPad, because they didn't have access to one at that time. "Since we didn't have a device, we felt it was important to have a physical thing to work with," said Stewart.
(For more information on that prototyping process, including photos of sketches and the physical prototypes Omni Group built using table saws and a 3D printer, see the company's blog post.)
"We had to think a lot about the social nature of the iPad," said Case. As a result of handling the mockup, he said, he realized that "you can use it easily in a group for showing things off -- a desktop is more of a solo experience. So we made the default sizes of things more readable, and larger than you'd think you needed for a single user," he said.
"Using a laptop, the screen is a barrier between people," he said. "The iPad can be used in a more level fashion, more collaboratively."
According to Stewart, the various mockups helped them realize that "many of our first instincts were wrong in regards to the iPad."
"We're really used to the Mac user interface paradigm: widgets, windows, etc.," he said. But for the iPad, they had to think about many things from scratch, including the fact they couldn't rely on precise cursor positioning (fingers are fatter and wobblier than mouse-driven cursors) and a menu bar.
Using a real iPad helped
And moving to a real iPad for testing their initial ideas brought some new awareness, said Case. "We had to test specific timings, such as what fraction of a second meant the difference between tapping and holding your finger down, how swiping and other one-finger gestures worked in the larger interface," he explained.
"There's a whole invisible heuristics going on that you don't think about when you're using the iPad," Case said, meaning that your actions are almost automatic, though filled with commands for the interface.
As the developers worked through various iPad-specific designs, they moved toward a "modal" paradigm -- which involves using a different screen for each task, such as drawing or writing.
"This was tough to discover," Case said. "We're used to making anything available to the user all at once. But we found when you give people more modes, each mode ends up being more focused."
"We didn't even realize this until late," he said, "but none of our iPad apps have preferences -- that's not usual for us."
A 'consistent user experience'
"It was a sprint to April 3," agreed Brian Yu, director of product management for Zinio's free magazine reader app. Zinio has desktop, Web, iPhone and now iPad versions of its reader. "We crammed about six months of application development into six weeks."
Yu's role in developing his company's iPad app was primarily setting the development road map and identifying what features to include. But he also served as an important "gatekeeper" for the overall UX process.
"We wanted to present a consistent user experience" among Zinio applications, Yu said, "but we also wanted to take advantage of the iPad's features. We were able to take a lot of what we learned from iPhone development," he said, noting that Zinio's iPhone app shipped only two weeks before Apple unveiled the iPad.
With the iPad's larger size, he said, "we could present a 'lean back' experience," in a size approximately that of a print magazine.
Something as simple as the iPad's larger size allowed Zinio to add interface functions not possible on the iPhone. For one thing, the iPad's size made it possible to offer a full-page "title view" in portrait mode and a double-page view in landscape orientation. Moreover, the extra room inspired Zinio's UX designers to implement a "stack of magazines" view, in which users can "pinch out" to see the stack's content.
He also pointed to new interface elements introduced for the iPad. One of them is the "popover," which, Yu said, "allowed us to keep users within the magazine experience" while also allowing access to Settings and an FAQ.
"With the iPad's screen real estate, it didn't make sense to take over the whole screen for these," he said. To do the same on the iPhone required modal views, in which the settings or FAQ took over the whole screen. "On the iPhone," he said, "navigation is really screen to screen."
Yu's design team also made a paper prototype of the iPad before they had an actual device to work with. Theirs was placed on a wall and involved a lot of Post-it notes; the team tested designs by having some of their non-designer staff members attempt to walk through the app on the mockup.
This gave the designers a more concrete sense of how users might move interface items, or expect them to be in one place rather than somewhere else.
Once they had access to a prerelease iPad and moved to a digital prototype, they discovered some things that had to change. "We found that swiping didn't happen as fast as we liked," Yu said, so the team had to reconfigure a basic part of their planned interface.
Working until the last minute
"Design iterations went into the last week of development," Yu said, "which is very unusual."
"Working with a blend of metaphor from both the Web and the iPhone was one of the greatest challenges," Yu said, "so we just had to iterate."
He promised that development isn't over, even though the app has already been released.
"We'll go through a round of usability testing now that our app is public," he said. "We have a list of questions we compiled while we were testing and from users."
From: http://www.computerworld.com
-small_270x186.jpg)
