Wes Dews is a front end developer, a husband, and an expectant father. He’s passionate about the web and what makes it tick.

May 17, 2017

Rethinking Responsive

It’s been years since we first saw the broader public accessing our websites using their phones. I still remember trying to access desktop-scaled websites on my LG VX9900 in high school. It was terrible.

The web knew it was terrible, and we started seeing the classic “m.” or “mobile.whatever.com” as a means of serving content better suited to smaller devices. This was a step in the right direction. The companies that invested their time, money and resources into these sites, though, created a problem for themselves… and for their users.

What was it exactly? Sure, the content was more legible and more easily navigable, but maintaining essentially two different websites became a total nightmare. This made digital marketing efforts more expensive and more time-consuming. If content needed changing, it now had to change in the desktop version and the mobile version.

This problem, which still exists today, doesn’t just affect the companies that are paying for the work to be done on their sites — it affects the end-users, too. How? Because when companies started making separate websites for their mobile traffic, the desktop version of a website would get more of the attention. Separate mobile sites notoriously become “stale.”

Now you wind up with a mobile-specific website which is, albeit easier to use on-the-go, but lacking the most up-to-date content. After a certain point, companies naturally choose to stop fighting the uphill battle of keeping both digital experiences in sync with one another, and eventually strip out the majority of the time-sensitive content on the mobile site, or retire the mobile site altogether.

Enter The Responsive Web

Digital marketing teams rejoice! The web began to support a way to treat the same website differently on mobile versus desktop, and do it in an extremely easy way. Responsive development is achieved by way of media queries, whereby a developer can tell a browser “If you’re a small device, appear like this. If you’re wide, do this.”

This type of development comes at a price, though. First, and bear with me here, designers and developers now have to deal with something called source order when developing responsively. Consider the three components that make a website what it is:

HTML — The content and skeleton of a webpage. Allows developers to outline certain portions of content and additive imagery to make it easier to target those portions to style them a certain way

CSS — The stuff that makes a page pretty. Allows a developer to add background colors to parts of the page, change font faces/sizes, animate content, etc. This is where media queries live, where we can tell a website how to look depending on screen size

JavaScript — The programming magic that helps bring life to a website. Pulls content from other resources on-the-fly, helps facilitate neat effects, tracks user interactions, and so on

Source order refers to the way the portions of the page are arranged in HTML, or the spine of a webpage. In layman’s terms, HTML gets written to determine what content exists on the page, and where that content will ultimately be shown dictates where it’s written in the HTML. In responsive websites, the HTML for a website is shared for mobile and desktop experiences. Therefore, the order in which content appears generally remains unchanged in responsive websites. It is possible to “flip” content on mobile versus desktop with relative ease in responsive sites, but generally:

If Content A appears to the left of Content B on wider devices, Content A will appear stacked above Content B on small devices.

Either that, or one of the two (Content A or B) will be hidden on smaller devices. Maybe both.

Decisions of the Developer

Many companies move so quickly when rolling out new digital experiences that designers can only focus on the desktop-facing website. As a result, the look and feel of the mobile experience is left totally to the discretion of the developer who builds the site.

This developer is (likely) not a content strategist or a designer themselves, and is merely making ad-hoc assumptions that certain content is merely supplemental and should “fall away” on mobile screens. To help lessen the subjectivity of responsive web content, a marketing team may choose to have the designer draft a mobile-specific design to complement the desktop one before moving to the development phase.

Don’t forget about source order, though. The same spine of a webpage can only be tweaked certain ways using CSS until it reaches a point where it’s no longer feasible to arrange content differently on mobile vs. desktop. It’s an often frustrating back-and-forth between a designer and developer when a designer doesn’t understand the concept of source order, or when a designer feels, justifiably, shoe-horned into making the mobile experience look a certain way so that it’s technically possible to achieve in development.

What This Boils Down To

A designer’s creativity is needlessly stifled for the sake of allowing a developer’s path to be as “gotcha-free” as possible. Their designs become narrow, stacked versions of the desktop site, with a hamburger icon, and maybe some slightly different button sizes and images hidden.

Seems like a one-size-fits-all solution, doesn’t it? Beyond that, responsive sites have their own performance implications, too. A user on a 2G mobile connection (really, really slow by today’s standards) is having to load basically all the same images, content, and functionality that may only be relevant to desktop users with a much faster internet connection.

That doesn’t make any sense.

Basically, the same responsive website may load in 5 seconds for desktop users, and take half a minute for certain mobile users.

It’s Costing You Money

Chances are, your website’s purpose is to drive business. Whether that’s done through empowering users with new information that makes your company the leaders in that topic, driving lead conversion, or getting people on the phone, the only way those things happen is because those users have remained engaged with the site for a period of time.

The longer a site takes to load, the more we risk losing those users to a company who values its users’ time more.

In the end, responsive websites are more convenient for businesses and less so for customers. And when the goal of a website is to drive business, it all seems a bit ironic, doesn’t it?

A tear forms in Benjamin Franklin’s eye

We Need An Alternative

Personally, I feel like we were closer to the end goal with using “mobile.whatever.com” than we are with responsive websites today. What we need to figure out, though, is how to manage the woes of managing what are essentially two disparate codebases.

It makes little to no sense that we handle mobile users only slightly differently than desktop users. People interact with sites completely differently on cell phones versus desktop computers. Separating the two gives us the chance to fine-tune the experiences separately, like we should be.

The act of having to mirror content changes in two codebases is insanity. We need to decouple mobile experiences from desktop entirely. Ideally, event content strategy would differ for mobile; we should be mindfully writing content that’s intentionally more lean for mobile that gets the point across sooner, so that we can declutter our websites and get people to where they want to go more quickly.

In the End

Responsive is great — please don’t misunderstand my sentiment here. However, I think we need to shift our mindset on how to best leverage responsive development instead of choosing to use to manage the exact same experience between small mobile devices and large desktop computers.

For example, it makes a lot of sense that we’d use media queries to scale content to accommodate screens ranging from 1200px wide to 2800px. Likewise, responsive could be used for mobile-specific views to allow content tailored for mobile to “flex” to the hundreds of different mobile form factors that exist today.

Because mobile experiences should be so drastically different from desktop, though, I personally think responsive should no longer be viewed as our go-to solution.

There’s got to be a better way.

And it would appear there is. I’m obviously needing to dig more into this, but you can do the same homework. Check out each of these websites on your desktop computer:

Notice that none of those sites scale when you click and drag the right handle of your browser window (the tired “simulation” of transitioning between using a site as a mobile/tablet/desktop user). That’s because they’re not responsive. They choose to load a better experience tailor-made for whatever device is accessing it.

Looks like their digital marketing teams had the same revelation about responsive way before I did.