Responsive Web Design – Best Practices for Usability and Beyond | MMA Global

Responsive Web Design – Best Practices for Usability and Beyond

December 7, 2015
Submitted by 3Q Digital

By Leslie To, Director of SEO

Were you a little late to the mobile party? Maybe you got away with a simple resized desktop site for a while, then took the plunge into responsive web design when Mobilegeddon hit?

You’re obviously not alone in this; many companies have recently turned to RWD only to find that there are a bunch of quirks that need to be smoothed out to achieve a truly improved UX.

To that end, here’s a guide for troubleshooting issues we’ve seen come up with our clients. Enjoy – and note a few additional resources at the end of the post if we haven’t covered one of your questions.

JavaScript_UI_widgets_library_for_building_desktop_and_mobile_web_apps

Say No to Fixed Pixel Sizes

Fixed pixel sizes will not be scalable as screen sizes diversify. Trying to create a responsive experience based on the outdated let’s-design-for-specific-devices philosophy will mean that your site will require further (expensive) responsive iterations. This does not mean that further refinement of the site won’t be necessary anyway, as shopping behavior and UX expectations will no doubt shift, but getting your responsiveness right the first time means eliminating the need for future costly responsive fixes.

image001
Here’s a formula to help with that transition:
Essentially, we are trying to design based on the relationships of individual elements to the element’s container. And because we’re all about practical applications, let’s go ahead and use this formula and see what we get. For example, let’s say you have a title that’s 900 pixels wide and you want to try to get it to size up appropriately to a browser that’s 1920 pixels wide.
We can take this 46.875% and use it in our CSS. Keep everything fluid by applying this model to widths, margins and padding properties.

image003

image005

Let’s do another example with outputs. This time, we’ll adjust a couple of things: a sidebar and content within a wrapper. (I’m using a CodePen by Nick Pettit).

image007

Here, we have a sidebar that’s 300px housed in a wrapper that’s 960px, which works out to 31.25%. Then the content box is 640px with a left margin of 20px housed in the same wrapper.

When my browser is at 908px wide, I see:

image009

 

But when I size up to 1600px, this is what I get:

image011

Gorgeous, isn’t she?

Yes, Percentage-Based Model Applies to Images Too!

image013

Images should also be dealt with fluidly. Thankfully, you can do this via a single line of CSS:

Basically, we’re telling browsers that images should never size above their actual pixel value, preventing the image from stretching or pixelating. We’re preserving UX without sacrificing image aesthetics.

Define Your “Breakpoints” Using Media Queries

Here is a great guide to a lot of device resolutions. I suggest bookmarking it.

Pulling from the same thesis we had earlier (of not designing your site based on specific devices), you should create breakpoints based on content and not on devices or products. And start small and work your way up. I’m going to throw another industry mantra in here for you all: Mobile-First Design. For more on how to choose your breakpoints, check out this post from Google.

Remember: Fingers Are Not as Precise as Mouse Cursors

Unless your users are rocking freakishly small hands, we’re faced with the very likely scenario that fingers require larger targets (larger than what mouse cursors need, at least).

Imagine how frustrating the site experience will be if users can’t accurately select global navigation buttons or your purchase buttons on the first try. If at first I do not succeed, I will definitely not try again.

Contextual Keywords = Best. Thing. Ever.

So this is a small feature, but every time I’m on a site that uses it, I’m so thankful. It’s really the small things that matter.

The best thing about software keyboards is that they can be dynamic, unlike their physical counterparts. Take advantage of that feature and change the layout depending on the requested data. For example, if the input field is an email address, make it easier for the user by showing the “@” symbol, in addition to underscores, hyphens, periods, and .coms/.nets/.edus, etc., on the primary keyboard. And if you’re showing credit card fields, please make sure that you have a number keypad. I’ve lost count the number of times I gave up ordering something online because each time I skipped to the next box, my keyboard changed back to the primary letter-only keyboard.

Customers Lost: At least 1.

Customer Coming Back? Negative

Assume Users on Mobile Have Terrible Vision

Okay, that might be dramatic. But as a best practice, increase your default font size as the screen size shrinks. Imagine if the rest of your site looks great, but users have to pinch to zoom to read your text. Party foul.

To Sticky Navigation? Or Not Sticky Navigation?

That is the question. (Shakespeare would be so proud.)

On this particular point, I really could go either way. I suppose if your page is really long, it might be helpful if your navigation was sticky. Then again, I’ve gotten feedback that some users find it cumbersome and annoying. If it’s not too costly, run an A/B test and see if your users prefer a sticky navigation. Don’t take my word for it; take your customers’. They’re the people whose expectations matter most anyway.

And if you do decide to run with a sticky navigation, have a back-up plan, just in case.

Click-Based Navigation Should Only Be an Option on Touchscreens

A few years ago, when my client was re-designing their site to be responsive, I got feedback from designers that we either had to pick a hover navigation or a click-based navigation. I couldn’t have it all.

Turns out, I can!

If you have a global navigation drop-down via hovering, keep that intact on non-touchscreen devices and only transition to a click-based option when users don’t have a choice but to click to expand.

What About Global Navs on Mobile?

I don't have a problem with the hamburger approach, but I think it's important we at least consider other options. This blog post from Brad Frost does a great job of covering the most popular nav configurations, including pros and cons of each.

Other resources

This CreativeBloq post is a little old, but this is one of the best problem-solving blog posts I've seen in a while. And if you have a few days to kill, check out this list of resources by Claire Dansey on UserTesting.com.