Last week my mother died. After we put her urn into the ground next to my father’s we went back to their flat to talk about next steps and dividing up their belongings amongst us three children. One thing I immediately called dibs on were my father’s two books.

Both were printed in 1955 and he purchased them with his first wage as a 14 year old coal miner. One boastingly calls itself “I tell you everything” and the other is a world map and almanac. They represent my father’s desire to educate himself and to travel – something he shared deeply with my mother.

Over decades, these books stayed my father’s one source of truth for anything historical or related to maths, physics, chemistry, astronomy, biology and – to a sadder degree – grammar and politics.

But let’s remind ourselves of this amazing purchase. A 14 year old, spending 9 hours a day underground mining coal goes and buys these books to make up for the lack of education he encountered growing up in war-torn Germany.

Fast forward to my story. I had a good education, but access to learning materials beyond those given out by the school in very tattered and often woefully outdated books meant cycling to the library in my village, the next village over or even the city further away. You had to be quick in pre-ordering books you needed or wanted and the library wouldn’t call you when they came in – you had to take a chance. Local calls in Germany weren’t free like they were in the US, so that’s how libraries saved money. I spent quite some time of my youth in the library researching as at home I also shared the room with my sister who had an unfortunate penchant for listening to her Nena record on repeat.

Working in media

I inherited the same thirst for education from my parents but I also skipped university as we couldn’t afford it. So I started working right after finishing my A levels. I had to go to the army – which I refused and spent 15 months working for the Red Cross instead – and upon return I took a chance and applied at the local radio station as part of the news team. I had a knack for computers, having spent quite some time with my Commodore 64, and thus became the expert on the radio stations computer network.

Enter the WWW

This is where the big breakthrough happened: one day we got internet access and I got information a lot faster than any other news outlet in town. Before that, we got faxes twice a day with the national and international headlines.

I knew there and then that the internet is the perfect library and place to gain knowledge. Books can’t be unavailable as you can have as many copies as you want. And you can even save them locally. Often this meant looking through the cache folder of Netscape and moving HTML files to a floppy to take home.

Heck, it was better than any library. You could contact the authors of the things you consumed, you could cross-reference without piling up books, and – best of all – you could edit some of the content and become a publisher yourself. A real read/write web.

The global library is burning

Except, it isn’t any longer. The web we have these days is in a sorry state. On the one hand we have the “social web” firmly in the hand of marketeers, bots and political propaganda. On top of that drowning in memes, reposts and funny things you already read in newsgroups in 1998. On the other hand we have the publisher web after 25 years still not being able to embrace the concept that you can’t control the distribution of your content once it is online. On the social web, knowledge is smothered by agenda and on the publisher web by ads and paywalls and contracts. Ever tried to look up some news from 12 years ago? Back in library days you were able to do that. On news portals, most articles are deleted after a year, and on newspaper web sites you hardly ever get access to the archives – even with a subscription.

Let’s keep the web library open and in great shape

I still want the web to be what these books meant for my father: the sum of all knowledge. The best humans can collect and via peer review and quality control archive for the next generation to come. The platform works, the idea is solid.

This is why I dedicated my working career to the web. I worked as a web developer on huge projects and portals, I worked on browsers, standards and CMS, and I now work on the browser that comes out of the box with any Windows machine (working on a Mac most of the time). I’ve written and contributed to 10 books, I’ve been tech editor for quite a few, wrote for dozens online and paper magazines and published this blog since 2005 – without ads, free of charge. I’m a freelance writer for Golem, a big German IT portal and a principal product manager in Microsoft working on tooling to enable people to do more on the web.

I don’t think everybody should do this. But I think you can do your part. Use snopes.com to check if the shocking thing you just read is real. Dare to post something with substance – even if it isn’t perfect. Point out issues of things you read and liked to the author. Don’t just consume, remember – for now – we do have access to an unfiltered web full of amazing content and things to learn. So let’s keep this “I tell you everything” in good condition and let’s not surrender it to the whims of political trench fights, blatant consumerism and time and soul stealing mediocrity.

It is possible to accidentally open the developer tools in browsers. Either by pressing F12, selecting the “Inspect” option of the context menu or hitting one of the many keyboard shortcuts that open different tools.

These tools can look intimidating and as if someone is hacking your computer. Especially when you see the Console tool displaying a lot of error messages, information about tracking and security violations.

To people conditioned by Hollywood that being hacked means seeing lots of random text and windows popping up on your computer, this can look really bad.

As a product manager working on browser developer tools, I get hundreds of messages each day from the in-browser feedback system. Many of these fall into a few categories:

• Help – I’ve been hacked
• People are spying on me using the Network
• There are devices that connect to my computer
• It shows that there are a lot of errors – what did I do wrong?

These are all based on a misunderstanding of what developer tools in the browser are and who should be concerned about them.

Let’s be very clear here: these tools are for developers to find out what is happening to their products while they develop them and to find out problems that need fixing. They aren’t giving any important or actionable information to you as a consumer of the web.

These tools do not mean that:

• You’ve been hacked – these tools don’t have any access to your account information
• You’ve done something wrong that you need to work on – all these errors and warnings are coming from the web site you’re looking at or extensions you installed. They are meant only for developers to track down why something isn’t working.
• Something external and sinister is connecting to your computer – these tools only show what is happening on your computer and you can’t use them to change anything on the web – everything people do in these developer tools happens locally on their computer.

Nothing happened to your computer or your account information by opening browser developer tools. You can close them and not worry about them as they aren’t meant for people surfing the web, but for developers who build products for it.

If you want some more explanations of the different things that caused the confusion, here are some quick notes.

The Elements Tool

Web sites and apps you use on the web are built using a few standard technologies. One of those is HTML which describes what something is, like a heading, a paragraph or a button. Another is CSS which defines how something looks, like a color of red and a background of blue. The Elements tool allows developers to see what HTML is responsible for what element on the screen and shows the CSS applied to it to make it look the way it does. This helps developers to tweak the look and feel of a product in a visual manner. You can play with the Elements tool to peek under the hood of the web and see some of the machinery, but none of this is yours to fix or worry about.

The Console Tool

The Console tool is like a scratchpad for developers. When you want to analyse what is going on in your program, you can use a command called `console.log()` to write something on it. This is how developers find out why something isn’t working. As developers use this, the browser also displays information on it when something happened – like your security and privacy settings preventing something from getting loaded. As a developer, this tool is incredibly useful. Technically we should not keep any messages displayed on it once the problem has been fixed, but as with any scratchpad, you often forget about it. That’s why the Console is so full of messages. As you aren’t the developer responsible for the current web site you’re looking at, you can safely discard these as not your problem.

The Network Tool

The Network tool shows the traffic on the network that happens when the current page is loaded and when you interact with it. This is not the traffic of your computer and all the things that come from the web or go from your computer out to the web. It only shows what the current web site does and allows developers to find out why some functionality is broken because something could not be loaded. It also allows developers to find out why the product may be slow to load or respond. You can use the Network tool to download images or videos if you want to, but on the whole, this tool doesn’t show anything that happens to your computer or has any information why your internet connection may be flaky or slow.

Device Emulation

The great thing about the web is that it works on many different devices. The problem for developers is that testing your web product on many different devices costs a lot of time and possibly money as you need to buy, maintain and know how to use these. That’s why Developer Tools have a device emulation tool that allows you to see the web site you are working on in the dimensions of a different device. For example, this is this web site as a laptop would show it:

And this is how it looks on a mobile device, in this case an iPhone XR:

All the device emulation mode does is show the current web project with the right screen size of different devices. When you use the emulation mode and load a web project, your computer also tells that web site that it is that device, which is why you get the different look and feel. None of these devices exist, and none of them connect to your computer. This is different from “find my device” services on the web. All the device emulation does is give developers a quick and easy way to see what their products look like in different environments. Everything happens on the current computer and no external service or device is connected to your computer.

Don’t fear the tools – they help us build great web products for you

You can also refer to the official documentation and read up on things in more detail. We’re trying to make the documentation easy to understand and would love to know what we can do better. If you got interested in developer tools, you may also check out what they can do for you as a non-developer.

Sometimes you come across web sites that have a lot of images scattered all over the page and you don’t care much about the content, but only want the images.

You can use the browser developer tools as a media browser.

1. Load the page you want to get the images from (here is a demo page)
2. Open Developer Tools by pressing F12
3. Go to the Network tool (the wifi icon)
4. Reload the page
5. Scroll all the way down to load all images
6. Filter the Network results by Img type
7. Click any of the image names to get a preview and download or copy the image

You can read more about this trick here or deep-dive into the official Network tool documentation.

Every browser these days comes with built-in developer tools that help people create, test and fix products for the web. You can right-click any website and select `Inspect` to get to them, press `F12` or `CMD + Shift + I on Mac` or `Ctrl + Shift + I` on Windows/Linux.

These tools are for developers, but they can also help you to fix some annoyances of the web. That’s why I created a collection of tricks how to make the web less annoying for you by using browser developer tools .

I work on these tools as a product manager and daily I get about 20 – 30 feedback messages that people opened them accidentally and are sure they “have been hacked”.

I get it – to non-developers these tools look daunting and complex and all the errors they display can be intimidating and worrying. And that annoys me. Tooling for the web shouldn’t require you to be an expert. On the contrary – the more you use them, the more you should become an expert of the web.

This is why I put together this collection with demonstrations for you to see what developer tools can be: your cheat codes for the web.

When I look at the web as a whole and especially, let’s call them “fringe content” web sites, I am disappointed at how we use this medium. Instead of giving people content they came for, we smother intrusive ads all over, prevent people from using the context menu which is full of accessibility enhancing tools and make people jump through hoops just to get to some content they found in a search engine.

That’s why I wanted to show you how you can use the browser developer tools to work around some of these annoyances.

As the browser of choice I use Microsoft Edge, because it comes for free on any Windows machine, is available for all other platforms, and I work on it. You’re free to use whatever you want, and most of the functionality should also be available in other browsers.

Another important reminder is that you are not doing anything illegal here nor can you get traced by the products you change to your needs.

Everything you do in these tools happens on your computer. You do not change the live product and if you reload it, your changes are gone, too.

Here are the tasks and how to do them with browser developer tools:

• Get the mobile version of the current document
• Remove annoying overlays and page elements
• Inspect the uninspectable
• Get back the context menu
• Avoid unwanted redirects
• Take screenshots of web content
• Get a simpler video player
• Check the document in different modes
• Download images

Do you have some other task you’d like to know how to achieve it? Do you have a recipe you use yourself? Comment in an issue on the “GitHub Repository”https://github.com/codepo8/web-cheatcodes of this or ping me on Twitter.

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.