Cloud Four Blog

Technical notes, War stories and anecdotes

When responsive design will make sense for your application

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.

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?

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.

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.

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.

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.

Icon Fonts: Mind the Baseline

Earlier this week, I made my first custom icon font using IcoMoon (implemented with Filament Group’s “bulletproof” technique).

I set my grid sizes and exported, but all the icons felt a little higher than I wanted them to be in relation to their surrounding elements. I did some finagling in CSS, but found the results varied (sometimes wildly) between platforms.

After some fruitless Googling, I trudged through the font’s preferences and found the culprit: A rather diminutive baseline height value. In IcoMoon, this is under Preferences, then Font Metrics.

Here’s a quick example at the default height (6.25%):

Here are the same elements and icons, but with a larger baseline height (18.75%):

Lesson learned: If the icon font’s vertical alignment is off, adjust its baseline height before resorting to CSS tweaks.

The more you know…

Defining Responsiveness

When people say that something is responsive, what do they mean?

I’m not being facetious. I think many of us think we know what is meant, but when you dig deeper, there is disagreement about what it means for something to be responsive.1

Responsive web design has a clear definition

To his credit, Ethan defined responsive web design clearly with three technical pieces:

  • Fluid grids
  • Flexible images
  • Media queries

That seems simple enough. But when it comes to defining what is responsive, things get a bit fuzzier.

Is Google Plus responsive?

The best way to understand where the differences of opinion exist is by looking at an real life example: is Google Plus responsive?

It looks like it might be responsive. The layout varies from one, two or three columns depending on the width of the page. The size of elements on the page change as well.

Let’s look at some reasons why Google Plus might not be responsive.

Reason #1: Google Plus is not responsive because it has a separate mobile site

The first time I cited Google Plus as responsive example, I was told that it didn’t qualify as responsive because it doesn’t go all the way down to support small screens.

This is silly to me. Nothing in Ethan’s article says that responsive web design has to support any possible screen resolution.

We’re perfectly happy calling things responsive designs that have a fixed width past a certain point on wide screens. And we praise the efforts by the BBC, Guardian, People and others that build a responsive mdot site that will eventually replace their main site.

So why would the fact that Google Plus doesn’t support small screens preclude it from being considered responsive?

Reason #2: Google Plus doesn’t use media queries

Google Plus isn’t using media queries the way you might expect.

As far as I can tell2, none of the major layout changes you see in Google Plus are handled by media queries. They are controlled in JavaScript.

This is similar to Nathan Smith’s Adaptive.js library which puts breakpoints in JavaScript instead of CSS.

So by definition, Google Plus is not a responsive web design. It may look like one, but it doesn’t contain the three technical pieces necessary to be a responsive web design.

Getting off on a technicality?

So I exaggerated a bit. Google Plus is using media queries. But as I said, they aren’t being used the way we normally think of them.

All but one of the media queries is looking at viewport height instead of viewport width. The one that looks at viewport width only applies at less than 340px; only adjusts a single icon; and I can’t get the rest of the page to adapt to less than 340px so the entire media query seems moot.

But perhaps we can give Google Plus a pass as a responsive web design because it technically has media queries even if they aren’t being used to make the design responsive?

Nah, that’s cheating. And even if we did let Google Plus off on this technicality, it would still leave us with designs that use JavaScript like Adaptive.js and wondering what we call them.

When does something stop being a responsive web design?

What happens when you use responsive web design, but add to it things that seem to be at odds with the philosophy of responsive design?

For example, do any of these change whether or not something is a responsive web design:

  • Device detection used to select the best-sized source image?
  • Redirects based on user agent string to a mobile site that is responsive?
  • Less content on small screens with more content on larger screens? What if the developer uses AJAX to pull in the additional content? What if they use device detection to make decisions before the page loads and then AJAX after?
  • A couch-mode design that only worries about resolutions from 720p to 1080i but uses responsive web design techniques for those resolutions?

These questions may seem crazy, but I’ve seen people use the presence of device detection as a reason to discount a responsive web design.

When people are looking for reasons why a given implementation doesn’t fit their perspective on what responsive web design is good for, it is pretty easy to find reasons why any given site isn’t a “pure” responsive web design.

Doing responsive web design well often requires more than responsive web design

When a client comes to us to help them make their existing site or app responsive, we know that we’re going to be using fluid grids, flexible images and media queries.

But we also know we’re going to be using much more than just those three techniques. The best responsive web designs are doing much more. And when we teach workshops or train client teams, much of what we’re discussing are the things that you do after you’ve got the three techniques down.

Which led me to the idea that there is a difference between “being responsive” and responsive web design. That responsiveness was something bigger.

So I asked Ethan for his thoughts.

A more web appropriate design

As you might expect, Ethan had great thoughts on this topic. I’m republishing part of our email exchange here with his permission, but this is just a fraction of his insights. I hope he gets the time to share his thoughts in more detail.

I suggested that “being responsive” or “responsiveness” might be characterized by larger principles such as:

  • Designs that utilize the size of the viewport to determine the layout.
  • Designs that adjust the layout and the size of the elements in the layout as the size of the viewport changes.
  • Designs that ensure content parity across devices.
  • Designs that treat URLs as sacrosanct and ensure they work across devices.

Now, Ethan disagreed there was a need to revise the original definition. But he replied:

All of them—but the last two especially—seem to me to be pretty foundational tenets of good web design, full stop. If an interface doesn’t adapt to the display—be it responsive or device-specific—its utility is pretty limited; if it doesn’t honor and respect URLs—be it responsive or device-specific—its utility is pretty limited; and so on, and so on.

The web’s still digging itself out of the constraints of the printed page, in many ways, and we’re still—some twenty years on—trying to articulate the best way to design for this medium. What you’re describing feels bigger and more foundational to me than responsive design. It really feels like you’re describing the way the web wants to be: fluid, addressable, and accessible to all.

So Google Plus, to use your closing example, might not be responsive, but maybe it’s adopting a more web-appropriate design model. And maybe that’s enough.

I think Ethan is right. In the long run, “being responsive” is simply designing for the web the way it was intended.

But in the short run, I find myself struggling to describe the new toolbox and mindset that is required to do responsive web design well. And I see people talk past each other because of their mistaken belief that they have a common understanding of what responsive means.

I’m left with Justice Potter Stewart’s definition for whether or not something is responsive, “I know it when I see it”, which is wholly unsatisfying.

I take comfort ignoring the definitions and instead asking these questions about a design and its implementation:

  • Does it adapt to screen size?
  • Does it take advantage of device capabilities?
  • Is it accessible anywhere?
  • Does it work well?

For our users, those are the things that matter.


  1. Not addressed in here is the fact that responsive is also used in the web performance community to refer to something entirely different.
  2. Google Plus CSS and JS is quite complex. I’ve done my best to confirm they are using media queries only in the ways I’ve described here, but I can’t guarantee I’ve got it right.

  3. Don’t get me started on the definition of adaptive design. Unless I’m talking to Aaron Gustafson, I know I don’t know what someone means when they say that.

Why Chrome not shipping with Android 4.4 might not be a bad thing

Maximiliano Firtman broke the news a couple days ago that Android 4.4 (Kit Kat) will not ship to manufacturers with a browser:

At first blush, this seems like a bad thing especially for those of us who have been waiting so long for the Android browser to die and Chrome to take its place. However, I think this may actually be good news.

The first thing to keep in mind is that what ships to carriers and manufacturers is not the same thing as what ships to the store. Android doesn’t include Google Maps by default. If you want that on the phone you’re building, you have to license the Google apps services separately from Android’s open source code.

I attended the Mobile Summit during Google I/O earlier this year. One of the questions we asked was when will Chrome be the default browser for Android. The answer was that couldn’t say precisely because the handset manufacturer would have a say in the matter.

This has been one of Google’s biggest challenges with Android is the speed at which handset manufacturers adopt new versions of Android (if they ever do). Over the last year or so, Google has developed a strategy for addressing this problem.

Ron Amadeo wrote a great article for Ars Technica earlier this year that outlined how Google is now side-stepping the carriers and OEMs. In the article he describes how Google is using its Google Play Services which it licenses to OEMs as a way to keep applications on a frequent update cycle.

Google Play Services takes care of lower-level APIs and background services, and the other part of Google’s fragmentation takedown plan involves the Play Store. Google has been on a multi-year mission to decouple just about every non-system app from the OS for easy updating on the Play Store.

With that in mind, let’s go back to the question of Chrome. The slow pace of carrier and handset updates is the complete opposite of Chrome’s frequent release cycle. The Chrome team prides itself on the frequent releases and touts how they’re bringing that same release cycle to mobile.

If Google released Android 4.4 to carriers and handset manufacturers with Chrome installed, they would have no control over when Chrome is updated. By bundling it with Google services that the handset manufacturers sign up for and license, Google controls the app and how frequently it updates.

The big question is whether or not when a handset manufacturer signs up for Google services if Google forces the manufacturer to ship Chrome as the default browser. Because they dictate the terms of licensing of Google’s proprietary services and apps, I don’t see any reason why Google would put that condition on usage.

Yes, there is the potential that more devices will come out with browsers that aren’t using Chrome. But those are the Android-derived devices that don’t play in the Google apps space regardless. We’re talking about the Android devices in China or forks like the Amazon Kindle. It was unlikely they would use Chrome anyways so at least when they ship a browser, we’ll know it is something different.

But for end consumers and web developers, this seems like the best possible scenario. If you buy a phone that utilizes all the Google services we think of on Android (e.g., Google Maps, Gmail, Calendar, etc.), then you’ll get Chrome and I’m speculating here, but I suspect you get Chrome by default.

More importantly, you get real Chrome. The Chrome that updates every six weeks. And not a hobbled version of Chrome that would be limited by whims of the carriers and the manufacturers as to when it is updated.

PhoneGap makes mobile app development more accessible

Editor’s note: This is a guest post from our friend Dan Moore. He recently wrote a book about PhoneGap’s new command line tools. I asked him to share what it was about these new tools got him so excited that he would do the most insane thing I can think of and become an author. Hope you enjoy. —Jason

Use of applications that run on your phone or tablet (aka apps) is growing rapidly. Building apps typically requires a specialized skill set–developers have to know languages like Objective C and Android Java. In addition, they need to have a design sense as well, because they are building user interfaces. Few developers have this combination of skills, and so those who do can charge for it.

But PhoneGap, a four year old project, now lets developers leverage standard web technologies such as CSS, HTML and JavaScript to build mobile applications. Designers who know CSS and HTML can create fantastic mobile friendly user interfaces (leveraging frameworks like Topcoat and Junior) and developers can focus on functionality and performance.

PhoneGap lab illustration

PhoneGap, and its open source foundation project Cordova, democratize the development of mobile applications.  (PhoneGap is built on top of Cordova the same way Safari is built on WebKit, so there are many similarities between the projects.)

For end users, applications built using PhoneGap are indistinguishable from those built using native technologies.  PhoneGap applications can access the camera, GPS and other device specific functionality. There is even a way (called ‘plugins’) for independent developers can write native code and access it from JavaScript.

PhoneGap Challenges

For most of the past four years, developers using PhoneGap faced a few problems when developing or maintaining PhoneGap applications. Among them:

  • The PhoneGap framework moves fast, typically releasing a new version every month.  Upgrades require understanding exactly what components beyond the standard JavaScript, HTML and CSS had changed.
  • Plugins were not separate from look and feel or business logic.
  • Every plugin had its own set of instructions for installation and/or upgrading.
  •  Supporting multiple device platforms with one set of JavaScript, HTML and CSS was a goal for PhoneGap development, but required either homegrown scripts or manual syncing between directories. Platform feature drift was difficult to avoid.
  • Specific IDEs had to be set up for each supported platform.

All of these problems are tough enough for small applications, but for apps maintained for more than one release, the issues add up quickly.

CLI to the Rescue

Version 2.9 of PhoneGap, released in June of 2013, included a command line interface to manage applications. Instead of plugins being manually installed according to a README, standardized installation procedures are available. There’s a nascent plugin directory so that discovering a needed plugin no longer requires hunting through Google search results.

Instead of having to choose how to sync JavaScript, HTML and CSS, there is one location in a project for platform independent code, and one for platform specific code. Developers can develop outside of an IDE, in the web browser, using the web development technologies they are familiar with. There even is a system for calling scripts at various points of the application’s build cycle, so the CLI can be extended.

Developers still have to install and maintain device specific platform SDKs, but once they’ve done that once, they can add or remove a platform for a given project with a single command.  And if a developer is just doing a quick prototype or can live with the (considerable) constraints, there is PhoneGap Build, a cloud service, which can build PhoneGap applications without requiring platform SDK installation.

With the PhoneGap/Cordova CLI, a developer can code and test a mobile application without running the device specific tools (like an IDE or ant script) even once. Of course, if an IDE makes a developer happier or more productive, they can use one for developing application code as well.

The CLI makes coping with change easier

The breakneck pace of PhoneGap development hasn’t changed, but the cost of upgrading has dramatically decreased. Instead of having to recreate platform environments entirely manually, or (more likely) simply not upgrading, most configuration has been pushed into standardized files. In some cases, upgrading can be as simple as running a few commands.

The command line interface opens up new worlds of automation, and continues PhoneGap’s march to democratize the mobile application development world.


Dan Moore is Director of Technology for 8z Real Estate, a Colorado and California real estate brokerage, and the author of “Developing Cross Platform Mobile Applications with Cordova CLI”