The Good and Bad of Responsive Web Design

Two decades ago, the rapid adoption of the web interface brought to the proliferation of different versions and types of browsers, each of which built on the ashes of another one. In short, the source code of web pages became a messy tangle of lines trying to generate the same output regardless of the various behaviors of different browsers. It was a nightmare for developers to detect the user agent signature of the browser and route the workflow accordingly. Worse yet, the list of detected browsers had to be checked and updated regularly and more and more often.

About a decade ago, Responsive Web Design (RWD) emerged as a set of techniques that could reduce to nearly zero the effort necessary to produce a useful and nice-looking view on any known browsers. The key factor of RWD was the use of a rendering technique based on a virtual grid built on top of the physical screen view. In this way, the size of the screen became the determining factor driving the layout of elements. According to most developers, RWD freed the community from the chains of depending on detection of user-agent strings.

The present article looks at RWD in retrospective. Devised with the best intentions, RWD simplified a number of common and repetitive frontend development tasks but, in the end, failed at providing a new web development platform that was agnostic of the nature (mobile or desktop) and the form factor (smartphone, tablet, PC) of the underlying device.

Myths and Facts

I’ve never been a fan of RWD, but I had to surrender, accept and use it in production. Ineluctable is the adjective that better describes my feelings about it. In the end, like many, I survived it, but it NEVER managed to grow to be what a group of loudly speaking gurus envisioned a decade ago.

RWD heralds a fascinating idea that for its internal chemical composition has a stronghold on developers. The idea is: write your web views once and host it on any possible device. It’s the timeless and catchy myth of reusability, no more, no less.

RWD, however, has a few technical issues that have simply been ignored or worked around but never completely solved to date. RWD is based on CSS media queries, but CSS media queries (even in the latest version) don’t consider the actual signature of the underlying agent (the device).

• All you can do is applying different CSS styles based on a query that can only filter by screen width (and/or height).
• RWD assumes that a 480px wide screen is always the same, whether it’s a resized desktop browser window or a full-screen smartphone.
• On a smaller screen, fonts should be scaled down automatically, but this won’t happen so nicely, and anyway no RWD-enabler library (e.g., Bootstrap) takes care of data effectively probably, because it’s tough. Yet, it’s a big pain in the proverbial neck for web developers.
• Images should be media-queried too, and the PICTURE tag has been supported and popularized on purpose. Unfortunately, the PICTURE tag solves the problem in a highly impractical way.
• The PICTURE element forces you to maintain multiple copies of the same image—one per breakpoint, at most. This amplifies the burden beyond imagination. It also drastically slows down the page rendering. Google reports that 60% of page load is due to images, and most visitors feel irritated if a page takes more than 2 seconds to fully render.
• User agents are demonized, and devices are ignored by design. Hence, images can hardly be optimized for devices and dedicated, OS-specific features can’t be implemented. For example, you end up using the same Bootstrap-style date picker instead of intelligently switching to native Android/iOS date pickers on devices.

RWD was popularized around the silly idea of mobile-first as if it were realistic to have the same frontend codebase adapting (and without code!) to tiny mobile screens and also fitting very large smart TV displays. Sure, you can achieve that via CSS. At which cost? The cost of just hiding things as that’s all you can do with CSS. All the resources are downloaded regardless of the device and then just hid from view on smartphones—precisely the scenario where the download of unused resources is more costly! Amazing, isn’t it?

From Mobile-first to Mobile-last

Mobile-first design means just starting your design from the things you absolutely need and add those you need only on a larger screen. It’s a wonderful idea which in theory rules out device detection. In practice, though, it can only be implemented with device detection. This is what happens when developers follow the crowd of technology pundits instead of doing their job.

As a result, RWD today is only a good way to build a desktop web site and, at the cost of dealing with Bootstrap and media queries, making it render acceptably well on small mobile devices. The problems of adapting font and images and adding OS-specific or form-factor-specific features remains unsolved and abandoned on the table of tech-quackery.

As a result, RWD today is desktop-only and only an acceptable fallback on mobile devices.

Realistically Responsive Web Design

The painful point is found with smartphones and, to some extent, mini-tablets. Realistically, a large tablet form-factor (e.g., an iPad) can be treated the same as a desktop site from the font and image perspective. Are there any solutions?

• First and foremost, you should wonder if you need a smartphone version of the site. If you want to provide a genuinely native (simulated) experience over the web, then make it a different project and use completely different views, libraries and technologies.
• If not, then add a device detection engine. An effective (and freemium) library you might want to seriously consider is WURFL. At the very minimum, WURFL will inject—for free and without the need of subscriptions—a JavaScript object in the DOM with name and form factor of the device and a Boolean statement about whether it is a desktop or mobile device. That’s the starting point as it allows you to figure out at your coding expense the underlying OS. If you need more information on the detected device, then you create a paid account and get a dedicated service with an associated SLA.
• If you only need the Boolean answer of whether the device is a mobile one or not, then one option is using some regular expression (StackOverflow is full of examples) that checks for one of the substrings that most commonly identify a mobile device. It’s a naïve solution, it but works if you don’t have strict requirements and a coarse level of tolerance.
• CSS supports various metrics to define scalable fonts such as binding the font size to the screen or height of the display. You can try that, but my personal experience (for what it matters) is not positive as the factor to use to scale fonts up and down is hardly linear. With this approach a lot of trial-and-error is necessary to even find good candidate factors. In the end, properly sized fonts can be defined to a good extent via classic measurements switching to different CSS classes via media queries.
• For images, you have to resort to a dedicated Content Delivery Network (CDN) that provides device detection and image compression on the fly. The ImageEngine library is not precisely a CDN but works like a CDN dedicated to images (it doesn’t work with other resources).It guarantees—I personally confirm it—at least 60% payload reduction for images and subsequently a faster page load and reduces latency.
• Using ImageEngine (or similar frameworks) over changing your HTML code to use the PICTURE element (instead of IMG) is beneficial for two reasons. It works with the IMG element, and it doesn’t require you to manage multiple copies of the same image. You just point any IMG elements of your web pages to the absolute path of the image on the server. More precisely, each IMG element path will be prefixed by the URL of your ImageEngine account followed by the absolute image path on the query string. Under the hood, the ImageEngine endpoint will download the image from the server and start proxying access to it from various devices. Devices are recognized and classified by their user agent.
• The effect is that images are resized in a device-specific way so that each device is intelligently served the same image just of the proper size. This is cost-free for you. A scenario in which a framework like ImageEngine may not work and PICTURE is preferable is when there is some strict art direction on a specific image and when you want an image to be cropped rather than just bluntly resized. While ImageEngine does support some parameters (cropping is one of those), it might not be sufficient to meet your needs and expectations.

Responsive Web Design is a great half solution. If you stop at the surface of what words mean then it’s no question that it honors the name it has. In this perspective, RWD just allows designing web views in a way that is responsive when the display size changes. The devil is in the details, though. Fonts and especially images are out of the media query syntax, and this is a huge problem for those writing web views every day. Finally, knowing the main characteristics but not necessarily the capabilities of the device is important as it enables small optimizations that are otherwise impossible. Those optimizations are not for highly trafficked sites, but just any decent web site.

Summary

If I look back at the message from device detection a decade ago, when RWD appeared, I note that the emphasis was more on the capabilities of a given device (what a device is able to do) whereas today it is more on the characteristics (what a device is and looks like).

Finally, it is worth noting that the ASP.NET platform for years, and since version 1.0, had an internal framework specifically designed for capturing device information and injecting it in the request lifecycle. Once mobile devices started becoming ubiquitous and numerous, a dedicated team constantly gathered and classified user agent strings. The project, however, was dismissed in 2011 because of prospected rapid and general adoption of Responsive Web Design.

Ten years later, it turns out to be a shortsighted decision that leaves developers in trouble when it comes to building web sites that not just render well on mobile devices but also perform and function nicely. The overall idea of “Design once, View anywhere” is gone. At a minimum, you must distinguish smartphones and the rest of the web.

 

The post The Good and Bad of Responsive Web Design appeared first on Simple Talk.

from Simple Talk https://ift.tt/36gRmV6
via