8 RWD problems (and how to avoid them)

05. Tables

A number of survey responses mentioned data tables as being problematic, particularly when they had to contain complex information or simply a large number of rows and columns. Squashing all of this information into a small-screen device in a usable way remains a challenge that I'm not sure has been adequately solved. However, some promising steps are being taken.

The solution: Take your pick of the different options

Chris Coyier has blogged reviewing a number of well-thought-out suggestions for tables. Having worked for several years with travel websites, which often involve large, detailed flight timetables, I have to say that none of the solutions outlined by Chris quite met those requirements. However, for most use cases, I'm confident there's an option for your site that would at least provide a good foundation on which to build.

A couple of particularly strong responsive table options are:

• Responsive Tables, from Zurb
• Responsive Tables, from David Bushell
• Break a table out of its container (creator unknown)

I have seen a couple of solutions where hiding "less important data" is suggested. While I appreciate the experimental nature of the tables, I would personally recommend against the practice of hiding content from users depending on their viewing device.

06. Converting old fixed-width sites

One of the biggest issues reported in the survey was the problem of how to update the code base of an old fixed-width site to make it responsive – and indeed, whether you should. As I mentioned above, the responsive design process is often quite different to the old fixed-layout design process, and code is engineered in a less flexible way.

The question of what to do when faced with updating an old site is whether to reverse engineer existing templates and stylesheets, or to opt for a greenfield rebuild.

The solution: Aim for a greenfield rebuild

Almost without exception, those surveyed said either that they'd opted for a greenfield rebuild of templates and stylesheets, or that they only reverse engineered code because there were other factors involved and they had no choice.

Typically, older fixed-size websites didn't need to take into account mobile-first design, and the sometimes different ways in which content must be structured. While it's possible to reverse engineer code to make it responsive, on bigger sites it's almost certainly going to be easier (and actually quicker) to rebuild than to work backwards.

07. What to serve users of old IE

I'm sure you've all been waiting to for me to mention Internet Explorer in a negative light. I can indeed confirm that when working with older versions of the browser (IE8 and earlier), the main issue you'll encounter is the lack of support for CSS media queries. This means that if you're working with a mobile-first technique such as 320 and Up, your media queries won't kick in and your layout won't display properly on desktop browsers, so you'll effectively end up with a small-screen layout on a big screen.

The solution: Polyfill or gracefully let go

The bad news is that, despite the wishful thinking of the design world (and to be fair, actual progress from Microsoft), you do still need to consider older versions of Internet Explorer (particularly 8) when you plan a site. The good news is we have some strong options for supporting older versions of IE while pushing forward creating great responsive sites.

If you're keen to maintain your layout as much as possible in older IEs, consider conditionally including the respond.js polyfill from Scott Jehl in your pages. For a fuller explanation of options, I recommend reading Techniques For Gracefully Degrading Media Queries, by Lewis Nyman.

If you're looking to phase out support for older versions of the browser while keeping content accessible, it may be worth considering … doing nothing. If you've built your site mobile-first and you don't include a script like respond.js, your old IE users will effectively see your mobile view.

This may not be a perfect experience on a bigger monitor but at least the content remains accessible. Failing that, you could consider a simple conditional IE stylesheet and add in some rudimentary styling (fixed widths) because a simple linear view may not be best for a lot of users.

In my opinion, what to serve users of old versions of Internet Explorer comes down to the requirements of your client. I just ask that you don't discount versions of IE earlier than 9 without at least considering the people using them.

08. Testing time and cost

One of the most common answers in the survey was the issue of testing: how to test, what devices to test with, and the potentially huge cost of building a test suite of devices.

For many designers, especially freelancers and very small businesses, it's difficult to build up a test suite much beyond the devices you own personally. This came across loud and clear in the survey. Many people are making do with browser inspection and window dragging, along with testing on a personal handset and maybe a tablet. Obviously, this isn't ideal. Building even a modest collection of devices is now a necessary business expense.

Testing time is also an issue. Although the time needed to test a site has certainly risen, I do feel that some of this is offset by better prototyping, designing in the browser and less reliance on static, fixed-size visuals.

The solution: Share devices and keep resizing

It's great to see bigger agencies such as Clearleft sharing their huge range of test devices with anyone who wants to visit their offices. While this is not yet commonplace, I'm confident local creative communities can do their bit to get organised and at least discuss this sort of initiative.

If you're interested in seeing what other fellow designers have in their testing toolkits, I recommend taking a look at Stu Robson's My Test Suite site. Brad Frost has also written a useful guide to how to test on real devices without breaking the bank.

There's no substitute for testing on real devices but if you can't afford to put together a large device collection, you can at least make sure the bigger parts of your site work as expected by using one of the many responsive testing tools, bookmarklets and frames. It all helps!

Words: James Young
Main image: dConstruct archive, by Jeremy Keith

James Young is the creative director at Offroadcode and an experienced freelance designer. This article originally appeared on net magazine's website.