Imarc recently took on a mobile-first initiative. To streamline this process, our UX department needed better tools to test responsive web applications. Through identifying some common pain points in our workflows—and a common love for music—our team came up with an innovative (dare we say ingenious?) solution.
Enter, Imarc's very own, custom device lab.
But first, a little backstory about what prompted the need for a new and improved testing center.
Overcoming Workflow Challenges
One of the main issues we found in our workflow was device accessibility.
Before our device lab, we kept a cache of various mobile devices in a lockbox in the back of the server room. The cache itself wasn’t very impressive, as it was a mixture of dated devices of varying operating systems with few that were actually useful.
If a developer was inclined (i.e. not lazy) to go up and walk across the office to grab a device, it wasn’t even guaranteed that devices were of use; Some devices weren’t charged or perhaps someone else was already using it. Mind you, this is all assuming the dev remembers that these devices are even available. Needless to say, we needed a better solution.
Another workflow challenge we faced was emulation.
Originally, our developers used simple browser resizing and device emulation, as it was the most convenient option. The problem with resizing the browser to test a web app’s responsiveness is that a developer won’t get the full context of the environment. Although resizing the browser will give you a wide range to test breakpoints, it will fail to simulate mobile-specific features.
Emulators—whether a web based service (i.g. browserstack.com, mobiletest.me) or built into a browser—help test mobile-specific features. Technically speaking however, emulators only simulate user agents in the request header sent to the server. It does not simulate the OS or even the one specific browser that may be available on that OS. Using an emulator may get mobile-specific features to work, however we won’t know a webpage is truly rendering the way it should unless we get a physical device in our hands.
Out of all the tools at our disposal, built-in emulators yielded the best results. However, it still left a lot to be desired when it came to capturing the true user experience on mobile devices. Developing without a device will often make a dev neglect the real physical interactions we have with mobile devices on a day-to-day basis. For example, it’s key that important call-to-actions are within the physical and comfortable limits for all thumb lengths, but how we would ever know this unless we experience this first hand?
Adding GhostLab Software and Device Lab v1 to the Workflow
Vanamco’s GhostLab was a great addition to our workflow. Devs can add a project directory or URL and then continue to connect multiple browsers and devices to it via internal IP address. So long as the devices are all on the same wifi, Ghostlab will capture all browser events such as scroll, click and redirects on one device and will emit those events to every browser that is on the same ip address. Perfect.
Along with the Ghostlab software, we bundled their DeviceLab stand to hold up our devices. However, the stand didn’t come with out limitations. Messy, undersized, overcomplicated Exhibit A:
So, we sought out a better replacement for the DeviceLab to combine it with the GhostLab software. It needed to address all of the shortcomings of the original DeviceLab and then some. With help of a few musicians here at Imarc—and incredibly creative thinking—we stumbled upon an ingenious solution.
A Music-Rooted Solution Was Born
While our UX engineers were working to solve the problem with the device lab board, our Director of Experience was working on a different problem. By day, Thomas heads up THE Imarc UX team, but by night, he plays guitar with his band. He has about 8 guitar pedals that are all daisy chained for power and connection while mounted to a board that’s compact, organized and ready to go every night. He had recently built a board for a tour a month earlier, and as he thought back to his experience building that—and thought about our UX device board dilemma—he couldn’t help but make the connection between the two unrelated, yet oddly similar, problems. The issues were the same; Mounting the device, connecting and powering all the devices, and portability (for both guitar pedals and mobile devices, you need something that’s lightweight, well-organized and allows you to easily remove and add fixtures as needed.)
The solution really came to fruition after researching custom pedal boards from a new company Temple Audio Designs. Thomas contacted the company about their willingness to alter the guitar pedalboard slightly to meet the device testing lab’s needs.
Ryan Dyck, the CEO, immediately obliged and took order of a custom version of his guitar pedal boards. He was extremely helpful answering any questions we had and building the board to Imarc's custom specifications.
Of course, we changed a few things from his designs to better adapt the guitar technology to suit a more device-centered solution. For example, instead of a normal wedge shape that makes sense for guitar pedals that are usually on the floor, Thomas requested a board that could mount flush to the wall. We would also need to add a power connector on the bottom of the board, installing a powerstrip underneath to help minimize cable clutter.
We opted for the LED option to add a little bit of slickness to the overall package. It looks awesome at night when illuminated from behind.
Our new and improved device lab has been a phenomenal addition to Imarc's arsenal and has already improved many of the pain points we were previously experiencing. Our devices are neatly organized and testing has never been more productive.
Now that Imarc has adopted the mobile-first approach, our team is fully equipped to seamlessly handle multiple device testing in an organic and efficient manner. We’re able to test faster, build better and ultimately create higher quality websites for our clients. Imarc always strives to think outside of the box and we encourage our peers to do the same.