In our last blog post on mobile app layouts, we covered the basic terminology of mobile development. That post also served as a mobile app primer, to help our readers understand the reasoning behind mobile app layout. We also made clear the amount of work involved to create the various forms of content needed to support mobile users’ wide variety of devices, screen sizes, and resolutions.
In this follow-up, we’ll revisit some concepts from the previous post and learn how they might apply to the process of designing a mobile app. We will also outline some best practices for creating an excellent user experience.
In another previous blog post, we explained why trying to make your mobile app exactly like your website is a bad idea. Keep that thought in mind when you consider designs for your mobile app.
Progressive enhancement design strategy typically applies to the world of the web, but it works in the mobile app space, too. Under this strategy, designers build critical content and functionality with the lowest common denominator browser in mind. For example, you shouldn’t publish a graphically complicated and feature-rich web page as the only version of that page, because some mobile users will find it useless. The designer should find a way to make key content and functionality available to those users who lack the device or browser that can handle the more complicated features.
Once you’ve designed for the bottom, add the next set of features for the next most capable browser -- and so on, until you reach the point of supporting all of your desired features without limiting universal access to the critical parts. This strategy helps draw clear boundaries between absolute necessities and “nice-to-haves.” These distinctions can clarify priorities and assist stakeholders as they decide which features to keep and which to cut.
This strategy, commonly applied to technological features of web browsers, can also inform mobile app layout. Start with the minimum device size you are willing to support; determine the critical elements (e.g., images, text, buttons, etc.) in your layout, and provide only those elements on those smallest screens.
With progressive enhancement guiding our thinking, let’s dive into some of the best practices for smaller screens. We’ll examine how screen size, screen density, and resolution factor into our design decisions. (To keep things simple, I will stick to Android terminology (DPI) for this discussion.)
Assume that we will build a mobile app that allows sales staff to register new customers into the base CRM tool. We want a way to register our clients, so we know who they are. We also want a streamlined process for placing future orders built into the app.
When the sales staff makes phone calls from their desks in the office, they can use the website. But when they meet customers in the field, they can’t always get online. So the app must record the customer’s information and sync it back to the base system. The registration page seems like a great place to start.
Let’s also assume that the smallest screen size we want to support is 4.3” – tiny and rare in today’s world of bigger-is-better-phablets. (Smaller phones exist; 3.5” is typically the floor. Your call where you want to bottom out. I have chosen to leave them out of this discussion.) Remember our progressive enhancement strategy: For the 4.3”, we will consider only minimal content and functionality.
A 4.3” phone comes in one of several different resolution groups. We’re thinking lowest common denominator, so we’ll look at lower resolutions first and then scale up.
To review, Android has broken down the millions of combinations of screen size vs. density into six groups:
We’ll focus on the mdpi as our lowest common denominator. In mdpi, the ratio of absolute content size to rendered size on the device screen is typically 1:1. A 100px x 100px image or button will display on the screen without scaling. To figure out the overall available space, simply multiply DPI by our screen’s height and width. On a 4.3” screen, the approximate height and width are 3.74” and 2.15”, roughly 600px x 340px.
Most mobile phone manufacturers provide this information in their technical specifications. But we’re working with a theoretical screen size, so it helps to figure out the dimensions. The grid below represents our digital real estate. Each square is 10px x 10px.
Say that on a first pass, the stakeholders want the registration in the app to function exactly as on the website. The form on the website collects the following required fields: first name, last name, e-mail address, company name, company address, company city, company state, company country, company phone number. Optional fields? Oh yes: personal contact phone number, role at company. Links? Yes: to privacy policies and terms of agreement policies in PDF. We’ll also provide the user with action buttons to cancel the registration process or submit the form, along with company look-up within the app. A user would tap a dropdown and select a company, an action that pre-populates the company’s data from the database. A user can, alternatively, create a new company on the fly and fill in the appropriate information.
The final hefty tally of things to consider: 11 form inputs with labels, two links (with PDF downloads), and two action buttons. Each form input has a corresponding label, so we must make space for 22 elements + two links + two action buttons = 26 items.
To avoid confusion, we must follow some guidelines for action buttons on a mobile form:
So far so good, let’s add the other “must have” form elements.
The user can easily see the action items, but the screen already looks crowded. People with less than perfect vision will have problems reading this form. Clicking on the small inputs may be difficult for people with larger hands or fingers. And we still need to cram in two links, two labels, and two more form inputs. We’ve also left out the ability to select a company from a dropdown or create a new one on the fly. Is this too much for one screen? What can we do about it?
I almost always recommend Approach 2 to clients when smaller devices are involved. Keep the interface clean, quick, and simple, and your users will put it to work. Let’s assume after stakeholder review, the consensus is that the optional fields can go, the company address and contact information can be filled in at a later time, but the customer’s information and company name are must-haves.
These sensible concessions allow us to build a screen that supports all essential requirements:
The background grid’s reasonable approximation of the pixels for the 4.3” screen size allows developers to easily build numbers (dp) into their development system for this size. It also relieves them of a lot of trial and error with the prototype to see what sizes work or fail.
Progressive enhancement strategy reveals how reducing the amount of content to critical path elements also reduces the app’s development cost and improves user experience.
What else could we do to further align with the design patterns prescribed by Apple and Google? Follow these links to find out: