James Young reports on the results of his survey on responsive design – and offers his advice.
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:
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.
Get the Creative Bloq Newsletter
Daily design news, reviews, how-tos and more, as picked by the editors.
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.
Lack of browser support for 'browser width variable' can cause problems. Lewis Nyman outlines some of techniques that address this
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.
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.
Clearleft shares its range of test devices with anyone who visits its studio. Other agencies, do likewise!
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!
