Collapsing Gracefully

August 29, 2016 • By

Responsive design has been one of the most significant inventions in the history of the Internet. Our rapidly changing hardware technology and the incredible range of different devices we have to support means we would have faced a massive challenge without the help of responsive design techniques. And there really isn’t much of a choice: you can’t simply decide to ignore the needs of mobile users because there are too many off them now and Google has a vested interest in making sure you do support these users.

But not everything that’s good is necessarily great, and even great things are not so great when they’re used inappropriately. As things stand today, most designers who employ responsive design techniques are doing it inappropriately. It would be good to see that situation changed. Although it’s probably unintentional, a badly designed responsive site gives off a vibe of laziness on the part of the site’s creator.

Responsive design is about collapsing and scaling

Unfortunately most of us rely too much on the former and not enough on the latter to get the job done. We try to use a one-size-fits-all approach because that seems like the right way to do it, but in many cases, that’s not good enough. When space is compressed horizontally (due to column collapse) it causes a subsequent growth in the vertical height of a div. Users tolerate this, but there are only some types of divs where it’s appropriate. Essentially, the more important the content of an individual div is to meeting the user’s needs, the more appropriate it is for that div to grow vertically. Divs that are not important to meeting the user’s needs really shouldn’t undergo too much growth. It’s something you should look for on the sites you visit and on the sites you create.

Many people have written articles suggesting that responsive design is bad, or that it can hurt your business, negatively affect SEO, and make you lose potential customers. But this advice is incorrect. It’s not responsive design that is the problem, it’s incorrect application of responsive design and failure to fully understand how it is supposed to be implemented that can make trouble for you. The number one rule is “don’t be lazy”… invest the time into doing quality work and it will reward you.

Another reason why some people think “responsive design” is bad is because they’ve confused it with a different type of design. It’s just that so many responsive sites are using the same layout, it has become unfairly synonymous in the collective minds of the public. Sites that employ massive hero units and full-width graphics just because they can are the culprits here. It has led to the use of larger graphics, more widespread use of PNG graphics, and more recently to the more widespread use of animated hero units. This is not responsive design and the blame is being misdirected. You can create good responsive design if you avoid the temptation to put style over substance.

All too often it is forgotten that the site is supposed to be all about meeting the needs of the user, and you’ll find corporate sites putting things on their pages because it’s what they want to display, not because it’s what the users want to see.

No individual image on a page that is not summoned as a direct result of a user request should be more than 100kb, and that is being very generous. Strategies to reduce image file sizes include altering the physical dimensions, reducing the pixel depth, reducing the number of colors, and changing the format. Images that are summoned are different, because then you know the user wants to see them. Everything else is decoration that you want the customer to see, and it’s fine up to the point where it begins to cause problems for the user.

Scaling is simple enough to achieve. You should, of course, scale down rather than up, so determining the maximum size of an image should usually be your first step. Small amounts of up-scaling are acceptable, and image quality should never take priority over page loading time.

It’s the matter of the collapse which we really need to pay attention to. We need to make sure that our sites behave appropriately under all circumstances, and that we don’t cheat ourselves with a sloppy responsive layout. Needless to say, many CMS products will limit your ability to override their defaults, especially if you use third party templates (MODx being the most obvious exception), so it’s way better if you can get the correct layout before the design is published. It’s a lot harder to correct things later if you’re using a typical CMS.

Your multi-column layout isn’t supposed to collapse to a single column

This is probably the most difficult thing for people to understand about responsive design. They think that because their multi-column layout can collapse to a single column effortlessly, that is what they should be allowing it to do. That approach doesn’t require adding any extra code and it’s not the least bit difficult. But it’s also wrong.

What you should be doing is designing your single column layout first, and that’s your default. Then from that point you can start thinking about how awesome you can make things look on a bigger screen. But you should always be starting from the viewpoint of “mobile first”. And what does that mean? It means a dedicated single column layout (although you can possibly create multiple columns for mobile under some circumstances) and extensive optimization to get your total byte count as low as possible. Also it means not autoloading video content, especially on sites where users wouldn’t necessarily be expecting to see video. You can offer it, but don’t force it onto the users by preloading it for them.

With a perfected single column layout, you will already know that your site will look good on any device, because a design created to work for mobile will always work on larger screens, but the opposite is not true.

Use column hiding to simulate a collapse instead of actually collapsing

With good responsive design, nobody notices a difference between a true collapse and one that is caused by a layout getting hidden. So your responsive instructions would look something like this, if we use Bootstrap (currently the most widely used responsive framework) as an example:


So in reality it’s not really much extra work, but the benefits are actually very noticeable, and your code actually gets easier to maintain because you’re changing things in an external file that are not associated with the layout. That’s actually the correct separation of content from design that you should be aiming for anyway.

Make sure to create custom footer for each layout type you use

If you want to cram a whole bunch of links and a search bar into your page footer, it’s not really going to be a good look on a mobile device, and that is especially true if you use a static footer. In fact, in many cases such a footer can make a page hideous on a small screen, and close to completely unusable.

Footers need to always appear as a thin band at the bottom of a page. They’re meant to convey a subliminal message that it’s time to stop reading now, not be a collection of links, but such is the way things have evolved. You can still have your big gaggle of links in the footer, but you should restrict the display of them to larger viewports.

If the links are important, you could shift them up into the content section of a mobile display, or you could use an expanding button to store them, something like “Click for more links”, and then have the footer links appear in a modal window. Don’t use a hamburger menu in the footer, these are navbar elements and putting them in the wrong place looks silly and is bad practice.

All this is possible because you can hide and display content relevant to the size of the viewport it’s being accessed through. A desktop PC can have multiple sized viewports in a single session. A mobile device typically can only have two: portrait and landscape. What it means is the desktop user can resize their window through a very large range of sizes. You can’t guess what kind of device is being used solely on the size of the viewport.

A related problem is the user can open toolbars, sidebars, and other things that further modify how much space is available to actually display the page content. This is your problem up to a point, but you don’t need to worry about supporting those users who intentionally destroy their own UX by loading a ridiculously large toolbar into their browser.

The layout and style don’t necessarily have to be consistent across different display types
Just because Google wants you to support mobile users doesn’t mean you need to make the experience an exact duplicate of the UX encountered on a PC. You can create a completely custom UX for smaller screen devices, where the look and feel of what you show can be totally inconsistent with the larger versions. This is not necessarily a bad thing, as long as it is handled intelligently. Typically you should make the experience consistent, but you don’t have to, and that is something to not forget. Some of the best sites do give a different experience in different circumstances because they’re designed that way.

Make sure columns are collapsing in the right order

If your responsive design comes courtesy of a third party template (meaning it’s not really your design), there’s often a chance that columns won’t collapse in the order you’d really want the viewer to be seeing them in. It’s a solvable problem, but templates can make that difficult by their very nature. Plus of course many of those who resort to third party templates don’t really have the skills to fix it. It again comes back to looking at your columns and setting them to hide at the correct break points. This way you can always be certain that your left column will show first in the stack. Also you don’t need to necessarily show all your columns on all kinds of devices, you need to make strategic decisions about this kind of thing, not just leave it to automation and display-by-default.

Be sure that your design actually needs to be responsive

If you’re using responsive design when you don’t really need to (that means your content would display just fine without it), you’re just making extra work for yourself and you’re actually putting more strain on the connection of the user. Never assume your site is the only one waiting to load, or that the user has unlimited bandwidth to spare. For that matter, if enough people connected to your bloated page, you’d be churning through your own bandwidth quota as well, but that’s not going to be a problem for many people.

So, here’s what you need to know…

Responsive design is really cool, but you have to use it correctly to get the best results from it. In reality, the only way to do this is to treat it as adaptive design which is not device-centric. You can also consider using genuinely adaptive design instead, but that means a lot of extra work and it’s not necessarily going to be any better. In truth, it’s a healthy hybrid between adaptive and responsive, but without the negative effects of either one. And that means you’re getting all the positives, which has to be a good thing.

header image courtesy of negativespace.co