RWD testing - questions of responsive design testing

The questions of a RWD testing session

What puzzled me during most of my responsive web design testing sessions was that I’ve seen different results when using different tools, like a developer tool bar, a browser plug-in or a free tool. No matter how carefully I've chosen the responsive design strategy, due to the different results I've never known which tool to believe, especially when not just the layout was slightly different but my media queries were applied differently as well. I usually had to make an educated guess: which one to believe that time and go with that one as 'the' test result.

During this 'responsive guessing', I always asked the same set of questions:

  • Question No.1

    Is the scrollbar width included or excluded from the screen width? Can I be sure that the breakpoints are applied as per my intentions or should I rethink my media queries?

  • Question No.2

    Is this or that resolution important for me to test on? What device would that be and is this device frequently used? With other words, is what I can see on a particular resolution a common case or an edge case; hence, how much effort shall I put into fixing the anomalies, if any?

  • Question No.3

    Does the correction I applied in the stylesheet, e.g. a tablet portrait view, modify the style on the following media queries as well? Do I need to make additional correction on them?

  • Question No.4

    Are the results displayed in standard resolution or high resolutions are also applied (@2x, @3x…), so can I be sure that this or that graphic is sized correctly and won’t look weird on a device, with e.g. @4x screen?

The questions of RWD testing

Making the answers for a RWD testing

In order to take out the guess-work from the responsive web design testing, I selected the most important features, meaning those that would make me sure that what I can see on the test result page is the closest possibility to the reality. I handed over this bucket of requests to my back-end colleague and asked him to make his own research on how to integrate them into a fast loading, efficiency optimized responsive design tester. That’s where our tool, OnDevice, started to form. To turn the 'responsive guessing' into responsive testing, we choose to do the following things:

  • Answer No.1

    Auto detect the scrollbar width of the device, we were doing the RWD testing on and excluding it from the screen width to prevent modifying the application of the breakpoints. Although for bigger devices and on certain operation systems, including the scrollbar is necessary to get an accurate picture, so we made that setting customizable.

  • Answer No.2

    Show the devices in the device list by their brand name accompanied with their screen resolution. We also indicated their market share to show which are the most used ones; hence, they are the most important ones to test on. So the client facing design presesntations can go smoothly.

  • Answer No.3

    Automatically apply the high resolution displays (@2x, @3x…) while keeping the real physical device size, so what is e.g. 10” in the real life will be 10” on the screen (close to 10” to be precise, as the actual size depends on the pixel size of the device we are testing on), even if it’s a @3x retina ready display. Just like in a device lab.

  • Answer No.4

    Show the responsive web design test result in a horizontal viewport for quick scanning, making it immediately visible how a modification in the stylesheet would affect the different media queries. In addition, check (with the help of the Console) within which media query shall the modification be put in to be displayed on the appropriate devices.

  • auto scrollbar
  • most used devices
  • retina ready
  • panorama view

The final RWD testing space

With these answers ready, we had a wireframe of what we need and how it should work and the birth of our responsive design tester has begun. All we needed was an appealing UI and the super fast back-end. Eventually, after several trials, we chose CommonLisp for the backend language, due to its high performance. If it’s good enough for AI researches then it’s good enough for RWD testing, too. In addition, we have chosen a flat/minimal UI style to keep it distraction-free. That's how we ended up with the viewport seen below.

P.S.: We’re testing our responsive web design happily ever after from localhost (since testing before going live was also a very important feature for us, we made sure that localhost testing is available).
OnDevice for RWD testing Start testing OnDevice

What has changed with this new RWD tester?

With OnDevice we got a reliable test result where we could be sure that our tool integrates every aspect of the responsive design testing from pixel density to the physical width and breakpoint accuracy. It also smooths the design presentations and client reviews by showing how the design would look like on a real device, or with other words, how it would really look like 'on device'. The name, OnDevice, probably doesn't require further comment. There are a lot of other aspects of testing responsive design that become faster and more efficient as well.

Quick RWD testing overview

Check OnDevice, the RWD tester, in action

Test your responsive web design OnDevice. Effectively. Thoroughly.