Device Emulation in developer tools is great, but it doesn’t deliver to all users of it and could be much better. Please help us improve it.

When developer tools of browsers came out with Device Emulation and reponsive design tooling , everything changed.

As a developer, you didn’t need to resize the browser window any longer to see how your designs changed. You also had a way to test what your product may work like on a mobile device.

Testing on phones isn’t fun. You either have to tether to the phone, and get performance delays, you need to publish your product to an available server, or set up a tunnel to your local server on your computer that the phone can access.

This is why developer tools have device emulation. You can simulated different devices, rotate them, and you even get touch emulation, which is great to find out that the hover effect you love so much is pretty much inaccessible to most of your users.

Now, a few years in and with advancements in the devices space, the tooling we have starts to be inadequate to the needs we have. It seems we need to re-think the tooling we have to embrace a larger world of devices and a bigger audience.

I work as a product manager on the browser developer tools of the Microsoft Edge browser and I get roughly 400 feedback items a day of people using the browser.

Not every user of emulation is a developer

As a developer, I am intimately familiar with developer tools. I love that I can emulate different devices and states and use the tools to fix issues I encounter. I am, however, frustrated that the emulation parts are scattered all over the tools. Some are in device emulation, others are in the rendering tool and yet others are part of the Elements/Styles editor.

As a PM I get dozens of messages a day that people are freaking out about the complexity of those things and why someone is “hacking my computer” or “showing lots of errors I couldn’t have caused and don’t know what to do about”.

This makes me wonder what we could do to disconnect the emulation part of developer tools from the tools themselves. Following I’ll discuss a few things I encountered and point out problems the current implementation of the tools have when it comes to delivering to the needs of different users.

Emulation needs for non-developers

I get requests from people who love to use the emulation features to test products they themselves don’t work on. These are testers, project managers, designers and similar people who want to verify that their products work, but don’t need to work on the code or fix them themselves.

These people have the issue that developer tools take up a huge part of the screen without giving them any functionality they want. This is increasingly problematic when you simulate high resolution devices and work on a laptop yourself. As developer tools take up quite some space of the browser, the simulated devices will have to get zoomed out to a level where it isn’t quite as usable as you’d like it to be.

If you have a second monitor, you can undock the developer tools to that one, but it is pretty amazing to learn how many people never realised that this is even an option.

Users like these would like to have:

• Device emulation in the browser without developer tools taking up a lot of space
• A simple way to emulate different states of the product (dark/light mode, slow connections, low end device performance)
• A simple way to view a device around the content and take screenshots of that
• A simple way to annotate issues they found and maybe file bugs with their development team

These are all spot-checking tools and don’t need perfect emulation. But it would be great to use these without any extra efforts.

Emulation users that want to game the web

One other interesting group I found in feedback are users who emulate mobile devices to get a better experience of the web or access functionality they don’t get in the browser. The main use case is services like Instagram that only allow for uploads from a mobile device and not from a computer. As a lot of people are on metered connections on their mobile device they use the emulation to upload images from their computer. Furthermore, mobile versions of web sites tend to be slimmer, easier to use and not full of popups and demands to sign up for services and the like. Many video sites also use a native HTML5 player on a mobile interface instead of one with lots of interaction and popups. This allows you to save videos in an easy fashion.

Users like these normally don’t need Developer Tools, so they’d also benefit from a simpler way too get into emulation mode.

Possible changes to the emulation experience

The main difference I am proposing is that the emulation experience should be independent of Developer Tools.

The Microsoft Edge Extension for Visual Studio Code currently features a screencast with an own toolbar that offers such functionality. In addition to easier access to emulation, it also allows to see the product in different themes and emulate accessibility issues.

Firefox also has an emulation bar that is available independent of Developer tools being open.

The question now is how would a user turn on this emulation without opening Developer Tools? Firefox has a keyboard shortcut, but these are hard to get people to adapt.

Emulation concerns

One big problem we also need to solve is to manage expectations. Any emulation we have right now only shows webviews with the dimensions of different devices and a simulated touch mode. You can also simulate flaky connections and rotate the devices. You do, however, not see how the device would show the product as any emulation still uses the browser it is built in to display it.

This is especially problematic with iOS devices, which use a different rendering engine and emulated devices are very likely to give you a false impression that everything works. The more closely we emulate the experience (simulating notches, padding issues, overflow bugs, etc…) the more likely we are to overprimise and underdeliver.

We’ve been playing with leveraging something like Playwright to show content in emulated devices using other rendering engines, but the overhead is quite high as of now.

Your help needed

I’ve published an explainer on GitHub that covers possible scenarios and will get more design ideas soon and we have an Issue on GitHub tracking the progress. I would love to hear more what you think would be a better experience than what we have right now.

When debugging or analysing JavaScript, you often see people trying to find out how often a certain function is called. The common way to do that is to use a global counter variable to increment and log in the function.

var i = 0;
function test(){
  // other functionality
  i++;
  console.log(i);
  // other functionality
}

There is, however, a better method. The Console of the browser has a `count()` and `countReset()` method that event takes a label. That means you can avoid the global.

function bettertest(){
  console.count('bettertest');
}

You can see it in action in this screencast.

This is part of the standard Console API and should be supported in all browsers.

When you write markdown files, headings automatically also get an ID generated so they become in-page targets to link to. This is also used to create a table of contents in various publishing systems.

Today I learned that VS Code also offers these generated IDs as an autocomplete when you type links. If you wrap the word you want to link in square brackets and you add the parenthesis to type the target the link should point to starting this one with a # will offer all the possible target IDs in the current document.

Neat!

I’m currently putting things together for a new flat and I realised that there are a lot of similarities between assembling IKEA furniture and doing web development.

• You get a huge bag of seemingly random parts and you should sort them before you start
• Everything is standardised and uses building blocks
• The manual is meant to be universally understandable and such needs some effort to grasp
• Forcing something to fit means you’re doing it wrong
• Leftover items mean you skipped a step
• You can use power tools to speed things up but you are likely to break things if you do
• Plan to assemble it right the first time, because taking it apart will mean you break it.
• Some parts are impossible to put together on your own – partner with another person and get a second pair of eyes to prevent you from doing something stupid
• Things look small and easy to handle when flat packed, but once you assembled them they take up a lot more space and are harder to move elsewhere