Responsive Guessing vs. Responsive Testing

Wondering about the accuracy of responsive design testing

responsive guessing

I’ve been in responsive design testing for years now, and it’s always been a riddle why I got different results with different testing tools for the same resolution. I’ve used the most common tools such as developer toolbars, browser plug-ins and a couple of free responsive tester available online.

By function these responsive testers do the same thing (or at least they do if for the same purpose), showing the design on different resolutions. Somehow, though, I still got different test results. So when it came to decide which one to optimize for before I show the design to the clients, I was just guessing which one would be the closest to the real device testing. That meant a lot of responsive guessing, trying to answer the questions going around in my head during responsive testing:

(original article discussing the history of my responsive guessing)

1. Would the design look different in real physical device size?

Trying to test devices with high resolution (e.g. @4x device pixel ratio, UHD devices) usually means that I get that resolution displayed on my monitor one-to-one as a large frame that occupies my entire screen. This is because most tools I’ve found don’t deal with pixel density whatsoever. (Based on the purpose of the responsive design testing in some cases it’s not a problem.) The graphics look good in that big, they make sense and all is clear, but the actual phone is only 3.07" wide, for instance, and the whole picture can look very differently in that physical size.

2. Would the dark device body alter the overall perception of the design?

In most cases it would. I’ve had a design case where we had to redesign the original dark menu because it was almost invisible when checking on real devices. When I’m doing responsive testing on free tools I usually don’t get device images around the frames or only get a schematic white flat graphic of them. To be sure that my design would look as intended on real devices I’d need a photo-realistic image of the device around the design.

3. Is the right media query applied on the right resolution?

Setting the media queries right has always been one of the biggest challenges of responsive design, especially when targeting specific device types or groups. When I’m testing on an HD monitor, it’s inevitable to scroll within the frame that represents the mobile resolution. Unfortunately, operating systems have their own preferred scroll bar width (17px or 20px or 6px…) and the browsers have their own understanding of displaying them. However, the area occupied by the scroll bar has a huge effect on how and when the media queries are applied and whether the layout changes on the right resolution.

4. Which resolutions are common and need to be tested carefully?

Honestly, I’ve never known by heart the resolutions of the most common devices, and never thought I should do. What I’ve always been curious about, on the other hand, which are the most common devices I have to test on, because the client or the client’s client have just those. Guesswork here can easily lead to ignoring important resolutions. For example, a couple of years ago I wouldn’t have taken seriously the 1440px resolution, since my last memory about that width was an old office monitor from my last job. Now there are many mobile devices with that resolution, which makes it an important one to test on.

5.Under which media query shall I put my style snippet?

I usually do mobile first development, where all the higher resolutions inherit the style from the smaller one before them (further responsive design methods discussed here). I usually do mobile first development, where all the higher resolutions inherit the style from the smaller one before them. (further responsive design methods discussed here) The downfall of this method is that every correction I make impacts every subsequent resolution. To be sure that I haven’t screwed them up by putting the correction into the wrong media query, hence further correction would be required, I’d need a quick overview of the resolutions in question. Checking every one of them separately is a painstaking work to do.

6. How can I present live design overview to the clients without giving the code away?

So far my most common process was making tons of screenshots and send it over along with a long descriptive note of how the interactions should work on certain resolutions. That took a lot of time to compile and usually several additional rounds of explanation were needed. I’ve been really wishing for something simpler to minimize the correction rounds and eliminating as much ambiguity as possible (more about how it led to the birth of an online responsive tester here).

What turned my ‘responsive guessing’ into responsive testing was a call from a former client struggling with the similar accuracy problems. He asked me to collect all the questions from my side while he was working on the answers on his side. Eventually OnDevice App has been formalized and soon (more or less) launched.

The work you’ve done in panoramic view |

The displayed physical size of the devices still depends on the pixel size of the tester device. Also, there are browser compatibility issues affecting the accuracy of the test result, but for the overall experience, this is probably the most accurate responsive tester I’ve had so far.

Take a look on YouTube

For creating your own responsive test space go to