Practical .NET

The Myth of Responsive Design

Peter explains why he doesn't believe in "responsive designs" that allow a single application to work in both the desktop and mobile environments.

• By Peter Vogel
• 11/01/2014

Inevitably, when I'm working on a Web application for one of my clients, I'll be asked, "Can you build this application using a responsive design so it will work both on the desktop and on mobile devices?" (And, by "mobile environment" my client means a "smartphone.") If my client doesn't ask that question, it asks a similar one: "Can you repurpose our existing Web application to a mobile environment with a responsive design?"

Essentially, a responsive design organizes the UI into a series of boxes containing UI widgets. At runtime, CSS is used to rearrange or hide those boxes in the browser, typically by stacking the boxes vertically on top of each other (and, occasionally, hiding some of the boxes). My client perceives this as an inexpensive way to kill two birds (desktop and mobile apps) with a single stone, and my client is seldom happy with my answer to the question.

To misquote Bill Clinton: "It depends on what the meaning of the word 'work' is." If, by "work" my client means, "Will the app come up on both big and small screens and respond to user input?" then the answer is, "Yes, we can build a new application or repurpose an existing site using a responsive design so it will 'work' in both the desktop and mobile environments." But that's not what my client means. The client means: "Can you create a single application that will be useful to our users in both mobile and desktop environments?" The answer to that question is almost always, "No," and, "Stop asking."

The Exceptions
I say almost always because there are three exceptions. First, if an application is designed in a mobile-first mode (that is, initially designed to target the small screen), then the application's UI can probably be implemented so that, when displayed on a desktop computer or a tablet, the UI will expand to take up the room available for it.

The second exception is for sites that are primarily just about presenting information. The VisualStudioMagazine.com site is a good example of a successful responsive design. If you haven't visited the site on your smartphone, try it now to see what I mean (or just resize your browser's window to make the window really narrow). Rodrigo Munoz describes the approach the site takes in a series of articles.

Third: There's the odd, very simple, uninteresting page that will be amenable to being designed in a responsive way. But, if you're an application programmer reading the articles on this site, you're almost certainly working more complicated apps than those. It's certainly possible that your application will contain examples of all three cases. But I'm here to tell you: For anything but the simplest, most boring applications, a responsive design isn't going to work for two reasons.

First: 'Rearranging the boxes' only goes so far as a solution in moving a desktop application to the small screen. A UI is more than just a set of widgets spread randomly across the screen -- the arrangement of controls on the page represents your "in-page workflow." That "in-page workflow" describes the relationship between the widgets on the page, including what the user can see at a glance without having to scroll or zoom. Rearranging these relationships into something vertical (with most of the widgets shoved off the bottom or the top of the screen at any one time) is usually impossible. But that reason is the least of your worries in moving to a responsive design.

The Real Reason
Second: The real reason a responsive design doesn't work for any interesting application is because users don't want your desktop application on their smartphone screen. The scenarios a user executes using his smartphone are very different from the scenarios he executes on his desktop.

As one example, according to one study, 73 percent of users expect a company's mobile app to be easier to use than the company's Web site. That may sound like, "users saying silly things" (after all, why not just make the desktop version of the Web site simpler?), but it actually reveals something important about mobile apps: Users expect the mobile app to be something different and more focused ("easier to use") than the corresponding desktop application.

A desktop application scenario might be described as being "All of what you're doing right now." A desktop application usually encompasses a complete task and commands your whole attention. A mobile app, on the other hand, is something you use in the middle of doing something else. A mobile app facilitates the task you're doing -- unlike a desktop application, a mobile app is not the point of what you're doing. Users expect a mobile app to do a very specific task very well ("easier to use"); users expect the desktop version to handle everything (but only just "well enough").

Responsive or not, your users won't thank you for moving your big old desktop application to their tiny screen. Instead, they expect you to work with them to define what they actually want to do on their smartphones and then deliver an app that does that. A responsive redesign of a desktop experience isn't going to come close to what they want.