Archive for the ‘Responsive Design’ Category

File Under: CSS, Responsive Design
Mar
27
2013

Resizing Responsive Designs with CSS REMs

By

Photo: Ariel Zambelich/Wired.com

Building responsive websites means that your design has to adapt to different screen sizes. We’ve covered a number of ways to do that in the past, including working with percentage widths, em-based type and other flexible techniques of responsive design.

There’s another way to achieve flexibility that doesn’t involve keeping track of ems or percentages — the new CSS REM unit. REMs are just like ems — REM stands for Root Em — but instead of being relative to the parent element like Ems, REMs are relative to the document root’s font size. Most of the time that means the html element.

We’ve previously looked at REMs as a way to achieve fluid typography, but REMs can help with more than just type sizing.

Mobify’s Roman Rudenko has an article on CSS-Tricks that shows how to use REM units to scale specific page elements while leaving others unaffected. Rudenko even shows how you can use REM units as a replacement for the very powerful, but not very well supported, viewport width unit.

For those wondering why you might want to resize some elements and not others, here’s Rudenko’s use case:

This style of sizing can be useful for user-driven customization, or to adapt layouts for cases that require secondary elements to be more touchable (tablet) or visible (TV). Without REM, every adjustable element would have to be resized separately.

This technique can be applied to whole pages as well. For example, if your type is all sized in REMs and you want it to be a bit larger as screen sizes get bigger, all you need to do is adjust the font size on the html element with each media query and all your REM-sized type will get bigger based on that single line of code.

For more on REMs and what you can do with them be sure to check out Rudenko’s post and our earlier write up.

Tags: ,
File Under: Mobile, Responsive Design, UI/UX, Web Basics
Mar
8
2013

Mobile Browsers Help Users Avoid Bloated Webpages

By

Stop feeding your website donuts. Image: D. Sharon Pruitt/Flickr.

Websites are getting fatter, dramatically fatter, with the average page size of sites tracked by the HTTPArchive now nearly 1.3 MB. If the current rate of page size increase continues, that number will reach 2MB sometime early next year.

That’s bad for pretty much everyone, but doubly so for mobile users with constrained bandwidth.

Fortunately for mobile users, the network increasingly seems to see large page sizes as damage to route around.

Services like Instapaper, Pocket or Safari’s Reader have long offered an easy way to strip out extraneous content. Now mobile web browsers are increasingly taking it upon themselves to speed up the bloated web.

The recently unveiled WebKit-based Opera Mobile borrows Opera Mini’s proxy-based Turbo Mode, or “Off Road” mode as it’s known now. Once only deemed necessary for feature phones (Opera Mini’s primary market) proxy-based browsing will soon be available in all Opera browsers.

Google’s Chrome for Android browser is getting ready to follow suit.

The beta channel release of Chrome for Android recently introduced an experimental data compression feature which Google says will “yield substantial bandwidth savings.” Chrome’s compression is nowhere near the level of Opera’s, but it does roughly the same thing — puts a proxy server between the user and the bloated site in question and then applies various speed improvements like using the SPDY protocol and compressing images with WebP.

To turn on the compression head to chrome:flags and look for the “enable experimental data compression” option.

Here’s Google’s description of the various optimizations:

For an average web page, over 60% of the transferred bytes are images. The proxy optimizes and transcodes all images to the WebP format, which requires fewer bytes than other popular formats, such as JPEG and PNG. The proxy also performs intelligent compression and minification of HTML, JavaScript and CSS resources, which removes unnecessary whitespace, comments, and other metadata which are not essential to render the page. These optimizations, combined with mandatory gzip compression for all resources, can result in substantial bandwidth savings.

In other words, Google and Opera are doing what web developers ought to be doing but aren’t. Just like developers should have been making reader-friendly pages, but weren’t, so “reader” modes were born.

It works too. In the video embedded below Google’s Pete Le Page shows how Chrome’s new proxy options take a page from The Verge and reduce it from a husky 1.9MB to a still fat, but somewhat better 1.2MB.

Want to make sure the internet doesn’t see your site as damage it needs to route around? Check out developer Brad Frost’s article Prioritizing Performance in Responsive Design, which has a ton of great advice and links, including what I think is the most important thing developers can do: Treat Performance As Design. In other words, if your site isn’t svelte and fast, it’s not well designed no matter how pretty it might look.

[Note: It is not ironic to post about web page bloat on a page that is, arguably, pretty bloated.]

Tags: , , ,
File Under: Multimedia, Responsive Design
Feb
18
2013

Stop Squinting at Your Screen Thanks to This Responsive Type Experiment

By

Tracking Webmonkey. Image: Screenshot/Webmonkey.

Responsive design typically focuses on screen sizes, but that’s just the practical application of the larger goal — making a website function well no matter how or where you are viewing it. The emphasis ultimately is on you, not your device.

Developer Marko Dugonjić takes responsive design’s emphasis on you to new levels of interactivity with his experiment in typesetting by face detection.

Using a very cool JavaScript headtracking library — which taps WebRTC and getUserMedia to access your webcam — Dugonjić’s app calculates how close you are to the screen and adjusts the font size to make text more readable.

To see it in action, head on over to the demo page and grant it permission to use your webcam. For the most useful example, check out the onload-based implementation, but for a better sense of how it works be sure to try the “Realtime” version.

It may not be the most practical experiment and how well it works depends on plenty of factors well beyond the control of the site (how good your eyes are, whether or not you’re wearing your glasses and so on), but it’s not hard to imagine how this could be very useful in some situations — for example, bumping up font-size when your site is displayed on a television.

When you’re done playing with the resizing demo be sure to check out Dugonjić’s more practical and more immediately useful Typetester.

Tags:
File Under: Responsive Design, UI/UX, Visual Design, Web Basics
Jan
15
2013

Turning Off Responsive Design

By

A handful of the many canvases your site will adorn. Photo: Ariel Zambelich/Wired.com

In the bad old days of just four years ago it was pretty common for mobile users to get shunted off to some half-baked, feature-deprived “mobile” version of the website they were trying to visit. This misguided practice was common (and annoying) enough that even today Chrome for Android and other mobile web browsers ship with a feature that allows users to “request desktop site.”

To make that feature work Chrome for Android changes its user agent string. Any site that uses user agent strings to redirect mobile users will no longer because to redirect them and the desktop version is displayed.

Responsive websites don’t rely on user agent strings though. Instead they adapt to screen size based on CSS media queries so even if a user has the option for desktop sites checked in Chrome they still won’t get the “desktop” site (of course with responsive sites there really is no desktop site, just a desktop layout).

Provided your responsive designs are good, this isn’t a problem (and if they aren’t then you have bigger problems). However, Opera web standards evangelist Bruce Lawson raises an interesting edge case: what about users that have never seen the mobile layout and are disoriented when they do? If you were expecting, say, the desktop layout of the BostonGlobe.com and instead saw the mobile layout for the first time you might be understandably confused. Here’s what Lawson has to say:

My reason for wondering [about turning off responsive design] is watching my dad use his Xmas Android phone and seeing his puzzlement that some sites look completely different on that device. Non-RWD sites loaded the layout he was familiar with — the desktop layout — which meant he could verify he was on the right site, he knew where in the layout the content he wanted was, and then scroll and zoom to it. When a site looked radically different, he’d check the URL bar to ensure that he’d typed in the right address. In short, he found RWD to be confusing and it meant he didn’t trust the site – no way would he buy anything from these sites.

The first thing to note is that this isn’t a problem unique to responsive sites. The same thing would crop up with a separate mobile experience. The difference is the inability to opt out of the responsive layout. An edge case? Sure, but Lawson isn’t alone in wondering about turning off responsive designs. CSS guru Chris Coyier tackled that very question last year, writing:

Why don’t we see opt-out responsive design? My guess is two-fold:

  1. It’s a bit technically challenging to implement and there aren’t a lot of precedents.
  2. It’s admitting you didn’t do a very good job on the responsive design.

The latter likely being the bigger factor. Like: why are we creating this responsive design at all if we aren’t sure it’s a better experience?

I would agree with both points, but clearly there are at least a few edge cases where offering an option to turn off responsive design might be a good idea. Of course it may not be worth worrying about the edge case of unfamiliar visitors — that’s the sort of decision you can only really make by looking at your own visitors and doing your own testing.

If you actually want to try it, Coyier has some ideas on how to go about creating an option to opt out of a responsive design.

Tags:
File Under: Responsive Design
Jan
10
2013

Take Responsive Design Beyond Media Queries

By

The basic elements of responsive design — fluid grids, flexible media and CSS media queries — are key to building successful websites that work across platforms and devices, but these three components are not the end of the responsive design story. In fact, as developer Brad Frost argues in the talk embedded above, there is, or should be, much more to it than that.

While many would call the broader approach “adaptive” design, Frost wants the phrase “responsive web design” to go the way of Corn Flakes, as he puts it. That is, to become a more general term that can “encompass all the things that go into creating a great multi-device web experience.” That means things that go beyond fluid grids, flexible media and media queries — things like performance, device support, device optimization and future-friendly designs.

In Frost’s analogy responsive design is the tip of the adaptive design iceberg, where all the good stuff is under the water. “Below the waterline, that’s where the true opportunity is,” says Frost, “that is where we actually have the potential to basically reshape what the web is, what it can do, where it can go and who it can reach. And that is powerful.”

Just what’s below the waterline and how do you roll these broader ideas into an actual website? Well, be sure to watch the video — Frost walks through an example of a mobile-first responsive design, which you can also read about on his site. If you prefer a tutorial sans video, Frost’s write-up from last year is available on HTML5Rocks.

Tags:
« OLDER POSTS