Northwoods Blog

Mobile App Layouts Part Two: Progressive Enhancement

Progressive enhancement and getting the essentials on every screen, no matter how small

April 05, 2018

Mobile App Layouts


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.


Progressive Enhancement

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.


Designing for Smaller 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:

  • ldpi (low) ~120dpi
  • mdpi (medium) ~160dpi
  • hdpi (high) ~240dpi
  • xhdpi (extra-high) ~320dpi
  • xxhdpi (extra-extra-high) ~480 dpi
  • xxxhdpr (extra-extra-extra-high) ~640dpi

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:

  1. Mark action and style buttons clearly.  Users like to know exactly what they’re doing without really thinking about it. So place the Cancel button below or to the left of the Submit button. Set a transparent or white background. Consider a smaller or non-bold font for Cancel, to send  attention to the true action button, which is Submit. The Submit button could have inverse or opposite features, in relation to Cancel. It would reside above or to the right of the Cancel button, a simple thing that suggests that pressing this button will move the user forward in the workflow. A solid color background (blue and green are common) with white lettering, possibly larger or bold, will contrast with Cancel and draw attention.  Experts debate over whether a top/bottom approach for action buttons is easy to understand; I typically recommend left/right positioning for these types of things.  Left says back and right says forward for most users.
  2. To make typing easier, these types of action buttons should reside at the bottom – closest to user thumbs, to spare the user the effort of reaching across the screen to complete the form. Also, this approach keeps both thumbs and buttons out of the way of any of the other content. 
  3. Don’t make the user scroll around to find the action buttons. Bad design, that. If you make users dig for the next thing they want to do, you will send them to the Uninstall button.




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?

  1. Introduce additional screens to better manage the number of inputs.  No rule requires a single form on the website to exist as a single form on the app.  Simply breaking up the form into multiple steps is one option, but that means more work and time for the design and development teams to build and test each screen. The other downside to this approach is that in the mobile world, you want users to complete tasks as quickly as possible. If users must fill out five screens just to set up a customer, they might just write down the information until they get back to their desks to enter it.
  2. Reduce the number of inputs needed to complete the task.  This is often the harder approach, as it raises human engineering challenges. Stakeholders inevitably feel that the data they care about is the most important data. You might have to demonstrate that that’s just not the case.  You could point out that it’s possible to simply collect first name, last name, e-mail, and company name during the first pass, save that, then provide the additional data directly in the CRM at a later point, or edit it directly in the app at a later point. In all cases, reducing the number of things on the screen will ameliorate the cramped appearance and horrible usability.

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:



Nathan Grier

Senior Mobile Developer

Nathan Grier delivers enterprise quality mobile apps and manages the Northwoods Mobile team. He provides clients with insight and guidance from start to finish when designing and developing mobile applications. Nathan brings a healthy knowledge of the vast set of technical landscapes that make up modern mobile environments and applies that knowledge when helping clients reach their goals.

Read Nathan Grier's Blogs

Ready to Learn More?

Contact us with any questions, comments, or suggestions.

Northwoods Web Solutions

1572 E Capitol Drive

Milwaukee WI 53211


847-752-1095 (Chicago)

Microsoft Partner SIlver
© 2018 Northwoods - all rights reserved.