Roughly Speaking: Working within Mobile UI Design Limitations
Today we chat with two mobile user interface designers about how they design successful mobile interfaces and intuitive navigation solutions. We'll learn how Sacha Greif works with the limited space of the iPad by using space saving UI Elements. Eryk Pastwa discusses how to design for multiple mobile sizes, and how to properly test designs for maximum real world uses. Take a peek at their workflows, and the best practices they both put into place in their projects.
Overcoming Limited Navigation Space
Navigation is especially important for mobile interfaces because of the limited space and constrained interactions. People cannot open your app in multiple tabs, use keyboard shortcuts, or create macros, so it's vital that every part of your app be easy to access.
Sketches (shown here for LePost iPhone app) let you quickly iterate through different ideas.
For Le Monde's newspaper app, navigation was one of the biggest concerns. How do you keep a newspaper's linear structure, yet provide fast access to any single page or article? And how do you take advantage of a newspaper's beautiful layout, while still offering maximum readability on a smaller physical surface?
Tools like Omnigraffle can help you plan the app's overall architecture.
Working with Modes
First, we knew that we wanted to provide two modes of navigation: a "physical" mode which would let you browse the newspaper's actual layout, and a "text" mode that would contain just the article's contents. The challenge was making it easy to switch between modes.
Our solution was to create a spatial relationship between each mode.
Our solution was to create a spatial relationship between each mode. For example, in the iPhone app each mode exists on parallel top and bottom tracks, and switching from one to the other triggers a vertical sliding animation. This ensures that the user's mental model matches the app's architecture. If you just leave your app's sections as a series of disjointed screens, it becomes much harder for the user to get a sense of where she stands. This is why horizontal slide transitions are so prevalent on the iPhone.
A big advantage of physical newspapers and books over their digital counterparts is that you can open them at any page you want. You can start from the front page, but if you prefer to read the sports section first there's nothing stopping you. We wanted to recreate that same freedom with a mobile interface, so we explored multiple options. First, we added a table of contents that can be accessed at any point in the app. It's a very fast way to jump to a specific article or section in the newspaper, but we knew it wasn't enough. We didn't want to reduce the whole newspaper to a dry list of articles.
The scrubber pop-over
Space Saving UI Elements
So for the iPad app, we also used Apple's new pop-over UI element in conjunction with a scrubber to display a page preview when you "scrub" across the newspaper's pagination. And to ensure that the physical newspaper was never too far away, we added a navigator pop-over to the text mode. This pop-over contains a thumbnails version of each page, which lets you tap an article to access it without ever leaving the current mode.
The split view
The key here is getting all those features out of the way, as long as they are still discoverable.
Lastly, we also took advantage of another Apple UI innovation, the split view. When in landscape mode, you can use the left pane to navigate through the table of contents while reading on the right pane. With so many different navigation modes, there's a risk that your app will become bloated and unusable. The key here is getting all those features out of the way, as long as they are still discoverable. A good technique to achieve this is overloading existing elements.
For example, in video players such as Youtube's, the timeline indicates your position but also acts as a scrubber that lets you control it. Contrast this with rewind and fast-forward buttons, which let you move around in the video but don't give you any information about your position. If you apply this principle, when the user is ready they will naturally discover the feature that had been hiding in plain view all along, and the transition between newcomer and power user will happen seamlessly.
Eryk Pastwa - Mobo Studio S.C.
Mobile Means Diversity
Mobile is currently one of the fastest growing industries. Everybody sees how much has changed in our everyday environment after the first iPhone was released in 2007. Had anyone posted anything on the web via mobile devices before? These are obviously clichés, but they show how rapidly things are changing.
Let's get back to 2010. The first half of the year brought the iPad, new iPhone with iOS 4, the quite new Samsung's platform: Bada, a new version of Android's system and a bunch of new devices over a six month period. It shows the key-point of all mobile connected design: simply overwhelming diversity. That's why we love mobile so much.
What Device are You Designing For?
So every project must begin with this very fundamental question: what device/s are we designing for?
Generally speaking, on the market there are about six main systems, on which different devices work, and for which we currently design and develop. Each of them can work with very different input methods and follow other User Interface Guidelines. So every project must begin with this very fundamental question: what device/s are we designing for?
It's the first point that determines the whole rest, it sets the range of possibilities and technologies we can choose from later, and shows us our limits. At first glance it seems straightforward and simple, but it can easily become very hard, when you have to design one application intended for many different devices. What's important then? To give users the most similar experience regardless of system or, contrary, to take advantage of more advanced devices and their technologies?
The next thing we take into account at the very beginning is the number of resolutions the application must support. Asking about resolution sounds recently a little bit outdated when the majority think "only" about iPhone. But everything gets back to mobile standards – now thinking about iOS you must think about 320x480, 640x960 and 1024x768 resolutions. It's not a big deal when comparing to JAVA ME – if your application has to work there, you should support at least twenty different display resolutions and even more physical sizes!
The application for Allegro was to be distributed through bluetooth devices (bluAir) during the company's annual event. We had to reach the majority of all devices present in the polish market at that moment. We chose also JAVA ME as a cross-platform framework but at the same time we had to support twenty-one different display resolutions.
Knowing Your Users
In my opinion, trying to think from the user's point of view is a basic rule, valid for every UI design process and generally for every commercial design, as the goal is simple: users must appreciate your design. You have to define what's your target group, who's going to use your application, what is in the content you serve? Answers to these questions can help you determine how you can improve the initial concept and what to do in order to help users find desired content easily or to perform the exact tasks.
Allegro application color scheme.
The Allegro application was quite an extended agenda. It contained a lot of information grouped into several categories that guided users through an event.
Knowing your users also helps to determine limitations. It's quite clear that for example, younger users learn faster and are more open to curious news. With this market you can consider less common or quite innovative navigation systems. But for banking applications I would be rather conservative and would try to think about middle-aged users with eyesight problems, as these defects are very common in modern populations of that age group.
GUI Design Workflow
It becomes clear that information architecture in mobile counts even more than how things look.
After the requirements and limitations are established, we draw first mockups. We set the flow of the application and work on layout of the navigation elements. So, basically, we create a skeleton, we're going to skin later on. It's the phase, when the application can become usable and intuitive or not. The basic rule here is to keep the whole interface as simple as possible. The mobile GUI's need to be really straightforward.
We test our ideas drawn on sheets of paper and/or simple wireframes on devices, and try to imagine their "mobile context." When the application is quite complex, we create simple HTML prototypes, which give us the experience that can be very similar to final products.
We also start to think about visual aesthetic then, but to be honest, I think that even most outstanding looking application will fail if the navigation isn't straightforward. Of course visual design can change the overall impression of an application, but especially in a case of utility apps, users dive deeper into them very fast. It becomes clear that information architecture in mobile counts even more than how things look.
Allegro application navigation.
The Allegro application was navigated with direct pad or left/right hard keys. Since it had hierarchical navigation, we decided to use breadcrumbs that showed current location in a form of straightforward icons.
Favorite Part of the Job
Graphic design is for sure our favorite part of the whole development process. Of course visual design helps to build good first impression, but we enjoy it mainly because we just love when our products look great. Mobile graphic design is a very young discipline, so in reality we are still exploring its possibilities. If you work with an experienced team of developers almost nothing is impossible, even on more development unfriendly platforms.
We chose Pixel fonts, because they were legible on both small and big displays.
The most important rule here is to test designs on real devices. There is a big difference between "desktop" display and mobile screen, and these differences still increase. And it's not only about pixel density differences but also about color shifts. Even some of the modern smartphones still don't support 16M of colors, so when we design for such devices, we are always aware of blue hues.
Working with display size.
We take the phones and try to look at our designs at home, at the pub nearby, and on the street in all weather conditions, especially when it's very sunny or cloudy. These are the places where mobile applications are used. We figure out then where to adjust contrast, change the font size or make the buttons bigger. This rule is valid no matter if you're designing a utility application or just a simple game. We always test at this stage, because later during coding it's sometimes very difficult to rearrange things. So go on and test it!
About Eryk Pastwa & Mobo Studio S.C.
Eryk is a highly experienced designer from Poland. His work is concentrated on design for web services and mobiles. He develops intuitive and clear User Interfaces for both small and big applications. Visit Eryk's portfolio, take a look at the great work by Mobo Studio, and follow @mobostudio on Twitter.