Cloud Four Blog

Technical notes, War stories and anecdotes

Responsive Design for Apps — Part 3

This is Part 3 in a series about Responsive Design for Apps. Part 1 talks about why responsive design for apps is inevitable. Part 2 presents a case study in redesigning a desktop app to be responsive and the interfaces in Part 2 are instructive when comparing them to the screenshots in this post.

After working on the expense reimbursement form app, I realized that the end result was very similar to what Apple and Microsoft are doing in trying to provide a cohesive experience across devices.

Desktop operating systems are leading the way

One of the big shifts that both Apple and Microsoft have undertaken has been to incorporate the lessons that they’ve learned from mobile and start to apply them to their desktop operating systems.

The features of OS X Lion centered on innovation from iOS being taken “Back to the Mac” and Mountain Lion continued that trend.

While Apple has taken a gradual approach, Microsoft has made a radical shift by taking the design developed for Windows Phone 7, formerly called the Metro UI, and applying it to all devices.

We’re seeing how both Apple and Microsoft are reusing patterns across all their devices and how those patterns have their roots in the mobile design. As I mentioned in Responsive Design for Apps — Part 1, it is much easier to go from something designed for small screens and touch and adapt it to large screens with keyboard and mouse than it is to go in the opposite direction.

Let’s take a look at Apple’s Mail App as an example.

iPhone Mail App: Nested Doll Design Pattern

The iPhone’s Mail App uses what Rachel Hinman described as the nested doll design pattern in her book The Mobile Frontier: A Guide for Designing Mobile Experiences.

Rachel writes:

Mobile experiences that employ the nested doll pattern are all about funneling users to detailed content…It’s a pattern that has a strong sense of forward/back movement.

You can see pattern in action in this screenshot of the iPhone’s Mail App:

Multiple screens of the iPhone’s Mail App showing the funneling nature of the user interaction

There are thousands of apps that use this same design pattern.

iPad Mail App: Bento Box

The Mail App on iPad uses a different design pattern—one that Rachel describes as the Bento Box pattern:

Just like a bento box from a Japanese restaurant, this pattern carves up the surface area of a mobile device’s screen into small compartments, each portion contributing to the overall experience. This pattern is a good way to express sets of information that are strongly related to each other, and it is more commonly used on tablets than smartphone experiences.

You can see how the selection of information on the left side of the screen affects what is visible on the right side in the example below:

iPad Mail App

One of the things to notice in the screenshot above is that the panel on the left is still acting like the nested doll pattern until an individual email is selected. Once a single email is selected, the details of the email show up on the right.

In fact, the left panel is almost exactly the same both in look and experience as the iPhone version of the app. The panel is even the same width as the iPhone screens. The only difference is that the panel has become taller to fit the size of the screen.

Looking at the Mail App in portrait orientation on the iPad finds a similar pattern:

Mail App in Portrait on iPad

Again, the nested dolls pattern exists, but is now operating inside a pull down menu instead of in a left panel. And again, the size of the panel is consistent with the width utilized on the iPhone, but the height has been adjusted to take advantage of the larger screen.

Mail App on Mac

I’m not sure what to call the design pattern on the Mac version of the Mail App. We can see the same patterns that we saw on iPhone and iPad have been extended to take advantage of the fact that there is more available screen real estate.

Mail App on Mountain Lion

The mail accounts and folder screens have be combined into a single view on this screen. The nested doll pattern is gone. But the email list and view an email screens are almost exactly the same as what we saw on the iOS devices.

The similarities between all three versions of the apps are striking.

How different is the Mail App from a Responsive Design?

When I look at the way Apple’s Mail App uses the same elements across the different screen sizes, I see many similarities to responsive design. While the design is probably more accurately described as an adaptive layout because of the multiple fixed sizes, it seems pretty clear how the Mail App design could easily become responsive if necessary.

Were I to rebuild Apple’s Mail App as a responsive design, I would start with the mobile screens as modules. Then as the screen got bigger, I’d use something akin to the AJAX include pattern to bring more modules into view.

And in fact, this is what we have in mind for the expense reimbursement form that I discussed in Part 2. It starts with a nested doll pattern design pattern that shifts to a bento box pattern as the screen gets bigger.

The future of web design

I believe this is where we will be heading not only for apps, but also for web pages as well. We’re going to evolve beyond designing pages to building discrete building blocks (or modules) that are inherently responsive unto themselves. Then we’ll build systems and rules that define when and where those modules are pulled into the page and displayed.

This is one of the reasons why I think JavaScript UI frameworks will follow the lead of Apple and Microsoft and start to seek consistency between their mobile and desktop frameworks. If the widgets in these frameworks were designed to be responsive and accomodate different inputs, then they would be ideal building blocks for a responsive app.

How we build the systems to pull in the necessary building blocks will shift from project to project. I suspect many will use solutions like the aforementioned AJAX Include pattern to dynamically add modules to a page based on screen size and capabilities. But some may require device experiences or RESS-based solutions.

But regardless of the techniques used, I firmly believe we will be building apps that are responsive in nature. As Stephanie Rieger said, “choosing responsiveness, as a characteristic shouldn’t necessarily define the wider implementation approach”.

Responsiveness for apps is inevitable

When I look at the landscape of devices and the diversity within form factors, I find it inconceivable that even solutions built around delivering different code to different form factors won’t also find it important to be responsive.

The lines are blurring so quickly now that when we design web apps, we need to take into consideration how that app will respond to different screen sizes and inputs even if the app isn’t built exclusively using the three main technical pieces of responsive design (media queries, fluid grids and flexible images).

So it’s time to give up our collective hallucination and embrace the inherent nature of the web for apps as well as for pages.

These aren’t easy problems to solve and the implementation may require more than “pure” responsive design, but when we do take the time to think about our apps in a responsive manner, we build better, more future-friendly solutions for everyone.

10 Comments on “Responsive Design for Apps — Part 3”

  1. Brad Frost says:

    We’re going to evolve beyond designing pages to building discrete building blocks (or modules) that are inherently responsive unto themselves. Then we’ll build systems and rules that define when and where those modules are pulled into the page and displayed.

    Nailed it. I want to be able to build independent components, drop them in (or have a system drop them in) anywhere (sidebar, main column, whatever) and have them automagically adapt to their environment.

    We’re not there yet, but I can’t wait for the day!

  2. Remi Grumeau says:

    Android native SDK has been providing “drop them in” adaptive UI components based on input type, screen width & density for a freakin’ long time now (2.1+, more or less 3 years ago now).

    This is actually something native SDKs are way more advanced than any web components library out there imho

    • Ben Nash says:

      These patterns have existed for years in Android and have proper names already.

      • John says:

        >These patterns have existed for years in Android and have proper names already.

        Ben (or any other knowledgeable person), could you provide a link to a page that lists these patterns with their names?

  3. Joe Snell says:

    Great article Jason! I totally see this type of accordionish + conditionally loaded content + off-canvas fusion into adaptive web design to be the way at the moment. I was working on a social web based application utilizing similar principles. Logical and UX oriented. Makes sense.

    YOU are the MAN!

  4. Luca Candela says:

    I can’t see the point of making up your own silly name for a pattern that has been used for decades, it’s called Master-Detail and it’s nothing new. This very thing makes me challenge your understanding of traditional application design patterns. It’s hard to take anything you write seriously after reading that.

    • Jason Grigsby says:

      Thanks Luca for the pointer the Master-Detail design pattern. FWIW, I didn’t come up with the names. I was referencing a book on mobile patterns. And I never claimed to be a UX person or design patterns expert.

      I’m sorry you can’t take anything seriously after this. But frankly, you interrupted a beautiful and fun Easter with your comment. It was like the Easter bunny brought coal this year.

      So perhaps we’d both be better off if you didn’t take what I write so seriously in the future. :-)

    • Ben Nash says:

      Agreed, those on-the-spot names were also atrocious.