( at some point in Firefox DevTools, and the response was pretty instant and strong — so much that we put it back in! We lacked the necessary customer understanding of how this tool was being used and what unique scenarios it supported.
In 2016, the 3D view panel because it wasn’t supported anymore by the new (back then) Firefox architecture. To this day, more than six years later, people still complain that it’s gone (note that you can still use it
As a final example, the Chrome team
removed the Properties sidebar pane in 2020 but later added it again after seeing how much people needed it. Usage numbers alone aren’t a good measure of a tool’s worth. Some tools may be used by a few people only, but they may depend on them to do their jobs. Proper user research and understanding of the various user roles and scenarios (and DevTools has a lot of them!) are needed to be able to simplify the product. A Way Out?
I want to propose two directions that I think have a lot of potential when it comes to improving the situation with DevTools:
simplifying the DevTools core and opening it up to more powerful extensions, so that users make their own tools; being bold and taking risks with a radically user-friendly user interface. A Powerful But Simple Core, Boosted With Extensions is such an amazing product! Many people use it and not only web developers. It’s built on a very strong core that can be extended tremendously. Visual Studio Code
This way, the people who work on VS Code don’t have to worry about all of the features that people might need. VS Code is a bit like DevTools in the sense that no two people have the same needs and workflows, and there are hundreds of ways to use the product.
So, the team’s job is to build a
solid foundation that allows basic editing and top that up with an extension API that lets other people dig deep into the platform and add extra features.
There are many advantages to this, but one that is of particular interest to me here is that
complexity is opt-in. When you install VS Code the first time, it’s not overwhelming. It’s a text editor, and you can use it to edit text right off the bat. But if your project has special needs, like checking code quality or doing some custom syntax highlighting, then you can install all the fancy extensions you want and get the extra functionality you need.
The VS Code extension API goes really deep into how much you can customize the editor, and I believe this is largely responsible for its success.
DevTools, however, is built differently. You can also install extensions in the browser to add new panels to DevTools, but there aren’t very many useful extensions available outside of the major framework ones (
React, for example). The teams who work on DevTools are the ones who pretty much do all the tools that a web developer might need.
By using the
browser extensions API, creating a new panel in DevTools isn’t too hard, but the API isn’t as advanced as in VS Code. In particular, there is no way to extend the existing tools to augment their functionality. This is a serious limitation that I think is responsible for the low number of useful extensions we have at our disposal.
As an example, the amazing
Motions DevTools extension allows you to view and edit animations on the web. But it’s limited to its own panel container, and it can’t integrate with the Elements panel right next to it, which would have been useful to simplify user workflows and re-use existing components, such as the color picker. Motion DevTools overview trailer
I believe we need to go further than that. We need a more powerful set of APIs that makes it possible to create the specialized features that some people might need without complexifying the default DevTools experience for everyone else.
Extensible Web Manifesto is very similar to this approach. It advocates for providing low-level capabilities for third-party developers to create their own experiences before they — perhaps one day — become part of the core if they prove to be popular. Taking Risks And Designing A Radically User-Friendly UI
Another very much-needed way to move forward and improve the status of our DevTools is to be willing to take a few risks, be bold, and test new UI ideas.
As I said in the intro, the shape of DevTools hasn’t really changed in about 15 years. I think we’re very much overdue for at least some re-design. We need to bring the UI into the 2020s, start using more modern interface patterns, and make the overall experience less daunting.
The folks working on Safari Web Inspector at Apple tried something like this around 2013. They applied some of their design principles from other products like XCode or iTunes in an attempt to simplify their DevTools toolbar.
Image source: WebKit. ( Large preview)
Although they have now gone back to a more traditional tabbed navigation which seems to work better with developers, I appreciate this early attempt to make a more user-friendly interface that’s also more consistent with what people knew at the time.
This also goes to show that very special care needs to be taken to bring developers along a journey of user interface change in DevTools.
This brings me to the team working on the Edge DevTools now (which, full disclosure, I am part of). I believe this is currently the only team doing something in this area.
Our current experiment is called
, and it is effectively the first attempt at redesigning the entire DevTools product UI. Focus Mode ( Large preview)
Focus Mode is available to users of DevTools on the Canary and Dev pre-release channels of Microsoft Edge by
enabling the “Focus Mode” experiment from the DevTools Settings. Most users of these channels should in fact already have it on, as our team is gradually rolling out the feature and listening to user feedback in order to ensure this is not disruptive to existing workflows and a welcome change.
Based on this feedback, we will continue rolling out Focus Mode to users of the Beta channel and eventually to the normal release version of Edge.
Now, it might not seem like a big change at first, but this is only a first step in an iterative approach to creating a more approachable user interface. Again, changing things in this product is complicated, so our team is taking things slow.
But if you look closely, there are a few major changes to the UI that try to make things less cluttered and more streamlined.
The most visible changes are located in the top toolbar. Here is an animation showing a comparison of what the toolbar looks like with and without Focus Mode:
( Large preview) The list of warnings, errors, and infos is now gone from the toolbar, and instead, it appears as colored badges on the Console and Issues panel tabs, removing some clutter. The Settings, Feedback, and main menu icons have been grouped under just one menu button in the top-right corner, further reducing clutter. Tabs now have icons, so they’re easier to see and tell apart.
Here are a few more things coming with Focus Mode.
+ button in the toolbar shows all available tools with their icons making it easier to re-open a tool you’ve closed before and maybe more inviting to try tools you haven’t tried yet. ( Large preview)
It’s also possible to switch the tabs to a vertical orientation. Being positioned to the left and hiding the labels further reduces the noise in the central part of the window, letting you focus on the code. Additionally, it matches UI patterns that people are growing used to in other tools (for example, the Activity bar in VS Code or vertical tabs in Edge).
( Large preview)
And finally, the drawer in DevTools was re-designed. The drawer is this area of the user interface that appears at the bottom when you press the
Esc key on the keyboard, and that normally contains the Console.
It was introduced as a way to have access to the Console at the same time as other tools, and all browser DevTools have this now. But over the years, the Chrome team added more and more things to the drawer, in particular secondary tools that were useful but not quite popular enough for a spot on the main tab bar (e.g., the Rendering panel was added there).
I think it’s come to a point where it’s hard to know for sure which tool is available in which area. Edge — with Focus Mode — is taking a different approach. The drawer is now called Quick View, which is always visible at the bottom of the toolbox (so you don’t even have to know to press
Escape) and can be used to display any tool you want.
( Large preview)
I’m very excited about where Focus Mode is going, and I can’t wait for our team to start exploring what’s next in this area.
If you want to try Focus Mode out, make sure you have a copy of
Edge (you can also get a pre-release version if you prefer to have the latest changes), open DevTools, and if you don’t already have it ON, press
F1, then go to Experiments and check the Focus Mode box.
Let the team know what you think about it — and if you have other ideas — by filing new issues on
our DevTools GitHub repository.
I believe that a user-friendly DevTools that is both more welcoming to learners and inclusive of everyone’s needs is possible, and together, we can make it happen. As a community, let’s demand more from our friendly DevTools teams!
There are full-time dedicated DevTools product engineering teams working for each browser vendor. They keep adding new features and fixing bugs, but they can only do a good job with our collective help.
Tell them if the UI doesn’t work for you. Let them know about your most common workflows. How many clicks did you need? Do you often forget where things are? Do you wish things were named differently? Input like this can lead to changes that make a big difference for millions of users.
As mentioned, we’re actively seeking feedback on this experiment and other DevTools features. You can leave comments on our
GitHub repository. Other browsers also like to hear feedback on their DevTools which you can do at the Mozilla bugzilla tracker for Firefox, on the Chromium bug tracker for Chrome, and on the WebKit bugzilla tracker for Safari.
Thanks for reading! And see you next time.
(vf, yk, il)