Skip to main content

When responsive design will make sense for your application

By Jason Grigsby

Published on January 28th, 2014

Topics

A few months ago, I found myself in a Twitter debate over whether or not responsive design can work for web apps.

While it was a fun debate, trying to answer the question of whether or not responsive design makes sense for your app is futile. Let me explain.

Permalink to We don’t have a common understanding of what responsive means.

We don’t have a common understanding of what responsive means.

I wrote about my struggles with figuring out what is “responsive” recently. People think they know what others mean when they say something is responsive, but our definitions often differ.

The best responsive designs use much more than responsive design. When that is the case, it is easy to find faults with any given responsive implementation that can be used to say, “Well, that’s not really a responsive design.”

What happens when you use responsive web design, but add to it things that seem to be at odds responsive design? Is it possible to add something that make it no longer responsive? If so, where is the line?

Permalink to What is a web app?

What is a web app?

If responsiveness has a murky definition, “web app” is considerably worse. Jeremy Keith has long argued that “like obscenity and brunch, web apps can be described but not defined“.

Chris Coyier recently polled his readers about whether or not it was useful to distinguish between “web apps” and “web sites”.

See the Pen SVG Doughnut chart with animation and tooltip by Chris Coyier (@chriscoyier) on CodePen.

While people agree that the distinction is important, there was little consensus on what the distinction was. Chris summarized his findings thusly:

I was kind of hoping we could get somewhere close to a solid distinction between these two classifications, but I don’t think it’s going to happen. There is very little agreement and heaps of opinion.

So any time we’re discussing web apps, we’re going to have trouble agreeing on what we’re talking about. Discussing responsive web apps is just asking for trouble.

Permalink to A case study in different perspectives

A case study in different perspectives

Here is a timeline of articles and discussions that illustrates my point perfectly:

June 17, 2013 — Responsive design Web apps – good or bad?

On a content only site it [responsive design] probably is very wise to start small and scale up. But in a highly interactive functional UI the UX will be damaged by the time you scale up. Or vice versa. Take a demanding environment such as online betting or a tipping platform. The users needs are potentially very different between device environments.

July 4, 2013 — Why Responsive Web Design is a Must for Gambling Sites

I personally have no doubts that responsive web design will become an official standard for all good web pages and web content design to comply in the future, so now is the right time for you to start using it on your gambling and sports betting sites.

June 13, 2013 — Case Study: Betting on a fully responsive web application

Kambi is one of the top sports betting providers and their services include popular sports from all over the world…At Kambi we went all-in on this bet and decided to build a web application that scales across the board. The value was clear, unified development process and consistent user experience on all platforms…Fully responsive web applications is not just a pipe dream anymore*. With the right mindset, tools and processes it all becomes possible.

July 9, 2013 — I point to Kambi as an example of responsive design being used for a web app. Nick Finck replies:

To summarize:

  1. Gambling apps are too complex to use responsive design.
  2. All gambling apps should be responsive.
  3. A case study of how a popular gambling app was built to be responsive.
  4. The gambling app in the case study is too light-weight.

Therein lies the problem. Even when we have a specific niche app/site (e.g., gambling), we can’t agree on the definitions. We have a case study of how a gambling app was made responsive, but we derive different conclusions about how applicable the case study is.

And I’m fine with that. I don’t mind ambiguity. People don’t have to agree.

I just think it points out how futile it is to try to convince others that responsive design for web apps makes sense.

Permalink to My thoughts on responsive design for apps

My thoughts on responsive design for apps

For my own part, I believe responsive design for apps is a no-brainer. We’re building apps for clients that use responsive design. I’ve seen large, complex apps for Fortune 500 companies that are in development. I’ve seen what other agencies are working on.

This stuff is coming. And perhaps when enough of these projects launch, we’ll move on from the debate about whether or not responsive design works for apps like we’ve moved on from similar questions about responsive design for ecommerce. (We have moved on, haven’t we?)

But even if I wasn’t fortunate enough to get a behind the scenes look at upcoming responsive app projects, I would still argue that responsive design for apps is inevitable:

Once you start accepting the reality that the lines inside form factors are as blurry as the lines between them, then responsiveness becomes a necessity.

I’m not saying there isn’t usefulness in device detection or looking for ways to enhance the experience for specific form factors and inputs. This isn’t a declaration that everything must be built to be with a single html document across all user agents.

What I am saying is that even in scenarios where you’re fine-tuning your app code and UI as much as possible for a form factor, that the differences in screen size and the various forms of input within a form factor alone will be enough to require you to design in a responsive fashion.

Sure you can build a complex web app without responsive design that only targets tablets, but that app would be limited. There is too much variation in the screen sizes of tablets for a design that isn’t responsive to work on more than a handful of devices.

I’m much more interested in skating to where the puck is going to be, no matter how difficult, than to fixate on what is easiest to do now.

We’re focused on helping our customers make their apps work across devices. And that means taking on many complex challenges. Making apps responsive is just one of them.

Permalink to So how will you know when responsive design makes sense for your app?

So how will you know when responsive design makes sense for your app?

When you decide it does and put in the hard work to make it so. The rest of the discussion is just noise.

Jason Grigsby is one of the co-founders of Cloud Four, Mobile Portland and Responsive Field Day. He is the author of Progressive Web Apps from A Book Apart. Follow him at @grigs.

Comments

Healy Jones said:

For me, it all comes down to the user. I’ve found that the users I’ve tried to serve generally have different use cases on mobile vs. the traditional desktop browser – and this makes a lot of sense, given how/where people are using their phones/tablets/phablets/etc. So offering the feel of the web UX/flow, but with the features they are actually going to use on the mobile made more prominent has worked. I also firmly believe in testing, both with in person and also using data once you have enough users. Then you’ll really understand the difference between the mobile and desktop browser use case.

Tyler Sticka (Cloud Four Team Member) said:

I suspect that one of the challenges of embracing responsive app design has to do with reconciling the audience’s needs and comfort level now versus weeks/months/years down the line. As users gain experience, their expectations broaden. I remember thinking WordPress for iOS was amazing when I bought my first iPhone, yet today it feels limiting (and frankly, redundant) in comparison to the newly responsive, full-featured web UI.

To put it another way, it’s impossible to predict if a user will do something on a device until they can. And if we believe we’ve already experienced the limits of what people can accomplish with even the smallest of form factors, history suggests we’ll be swiftly and handily proven wrong.

Ethan said:

We don’t have a common understanding of what responsive means.

…oh, really? 🙂

That nit aside: great post, Jason. From my experience, most of the perceived pain around highly transactional responsive “apps” comes from projects that attempt to retrofit a responsive experience upon a complex legacy interface. It’s a larger problem than making it flexible—it really requires that whole “mobile first” discipline up front, as most successful responsive projects do.

Sam Reynolds said:

Just to add fuel to the fire, the responsive eCommerce site you pointed to as an example (Fathead) isn’t really responsive. It’s adaptive. It’s essentially two different sites, one for desktop and one for smart phones. It’s doesn’t truly scale based on the view port. So now we can throw the responsive vs. adaptive debate into the mix. I’m here to help. 😉

Sean Hogan said:

Where I think “the puck is going to be” is:

1. Design a simple but comprehensive Web API that delivers HTML pages by default. These pages contain only primary content plus meta-data and minimalist styling.

Now you have a web-site that is robust and easy to maintain and works on any browser, even lynx. It’s minimalist, but someone using lynx or noscript will be fine with it.

2. Use DOM scripting in the browser to progressively enhance the UX in a way that is appropriate to the device, browser and user preferences.

Secondary and decorative content (including stylesheets) is treated as progressive enhancement and is installed with AJAX.

Use stylesheets with media queries, or do scripted media queries and select between stylesheets. Either way it will look like responsive design.

3. Use AJAX plus history.pushState() / onpopstate to manage transitions in the primary content of the page.

From my perspective, “responsive design” is just a tool for progressive enhancement. Don’t bet on “responsive design”. Bet on a simple, robust Web API. Plus progressive enhancement.

(Maybe this is what everyone else is saying anyway)