You might have recognised that the workbench of the SharePoint Framework has a responsive design tester included. In this blog post, I take a look what possibilities we have to properly test the responsiveness and the user experience of a web part.
There are also some pitfalls included if you entirely rely on the integrated too.
Workbench responsive design tester
To start the responsive design tester in the workbench, you have to choose Mobile or Tablet. The buttons are located right below the suite bar on the right side. The “Preview” on the other hand has nothing to do with the responsive testing it merely allows you to trigger a read-only view.
When you click for example “Mobile”, an overlay pops up, and you see a preview of an iPhone 5s. You can also switch to other devices such as a Samsung Galaxy S6/S7, iPhone 6 Plus and a Microsoft Lumia 1520. With these pre-selected devices, you are now able to test web parts even portrait and landscape mode.
It is a neat little tool but is it enough to test your web parts? Honestly, the answer to this question is maybe yes and maybe not. Let’s take a look at the caveats of this tester.
This responsive device tester uses an Iframe overlay. With the size set to a device-specific height and width. Let’s say you test your web part in Microsoft Edge for example. The result you see is how Microsoft Edge desktop browser would behave on an iPhone.
The Iframe cannot switch the browser engine, so you are still in your desktop browser. In case of Microsoft Edge, you don’t get close to an Apple Safari on iOS. If you use Google Chrome, for example, you maybe come closer to an Android device, but you might run into troubles on real Android devices. Even Safari on a Mac you won’t get the same result as you would get on an iPhone. Tests done with the local workbench can cover only how your web part behave at device specific screen size.
Another thing you cannot test with the built-in tester is the user experience and the behaviour. The content of the Iframe still behaves like a desktop browser and not a mobile browser. Touch and hover events are only two examples that a test with the built-in tester cannot be covered.
Better testing with native browser tools
At the beginning of Responsive Web Design, around 2011 / 2012, those Iframe overlays were the only chance you had to test for Responsive Web Design. From my point of view, a simple “Browser-Window-resize” always served a better purpose because it uncovers potential problems across a broader range of screen resolutions.
Meanwhile, nearly any browser have matured their capabilities for responsive device testing.
Especially Google Chrome and Mozilla FireFox have great tools to test responsive design already built-in. Besides, the multiple pre-defined devices to choose from these browser tools simulate touch device interactions and turn your regular mouse input into a touch input. The mouse pointer also turns into a circle that represents your fingertip and gives you feedback if, for example, a button is big enough to touch it.
Other interactions that are covered by tests with native browser tools are closer to a real device too. You will get an idea how touch-enabled devices interpret your CSS defined hover effect.
Besides a more accurate user experience, it allows you to throttle the network traffic to give you an idea how faster your web part loads on a bad mobile connection.
To answer the questions, how does it look on XYZ device and how can I interact with it, this is one of my preferred weapon of choice.
A small tip when you work with the local or online workbench. In some cases, you might see the following overlay.
SharePoint framework shows this popup because you don’t have official support for editing of web parts on mobile devices. Well, there are ways around this, and you can sometimes trick the modern experience. In general, to edit web parts on mobile devices haven’t been considered and if you get it running the user experience is not that great at all. This overlay tells you precisely about this limitation. The solution to avoid this overlay is to switch the workbench to the “Preview” mode. This mode gives you an indication how your web part loads on a supported read-only view and you can interact with your web part without the overlay ever getting launched.
Professional grade testing
If you have a lot of time and energy, you can install multiple VM’s even with mobile device operating systems, different browsers on different operating systems and device emulators and all that stuff. This scenario is time-consuming to set it up and maintain them to keep it up-to-date.
You don’t have to do this because there are professional services available that allow you to test all those different setups.
Browserstack, SauceLabs, Lamdatest and CrossBrowserTesting are just some of them available on the internet. You can fire up different virtual machines, mobile devices or an emulator directly in your browser. This way you have a wide range that you can cover with your tests because those services provide nearly any browser, devices, operating systems used in the wild. Event legacy operating systems like Windows XP can be covered with these services if required.
Also, those services support automated tests and return you screenshots and videos of the interaction that happened in a specific browser of a particular device.
I use one of those services a lot because it saves a lot of time and money. The most significant benefit is that I don’t have to assume how a web part behaves really on any iOS, Android and still even Windows Mobile device.
I can reproduce bugs a customer reported on older devices for example.
From my perspective, the last option is the only valid option to test instead of buying all the real devices available.
“It looks good in my browser”, is no more excuse. Excellent tools like responsive device tester built-in your browser or those professional services make your life easier.
Keep in mind the default responsive device testing capabilities, provided by the workbench, are undoubtedly a helper for quick tests but also has a lot of limitations that can merely not uncover the reality.
Option two, the native browser developer tools are far more accurate than the workbench tool. The third option is the most accurate testing setup to work with but sometimes you still have to test on a real mobile device.