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.
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.
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.
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.
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:
There are thousands of apps that use this same design pattern.
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:
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:
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.
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.
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.
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.
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.
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”.
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.