And that’s a wrap. I recorded my last video in the German LinkedIn Learning video course on “Browser developer tools for non-developers”. My favourite stumbling block over the course of the last few days was me starting a sentence with “Und hier verwenden Entwickler:innen…” (“…and here is where developers use…”) and making a pig’s ear out of it by saying “Und hier verenden Entwickler:innen” (“and here is where developers perish”).

I will now do some demo recordings of an English version of the course we will offer LinkedIn US, so fingers crossed that this will be taken on. I think there is a lot of good in explaining the power people have over the web we are given if they know what they can do using tools built into their browsers.

We don’t need to click through annoying, redirecting overlays or wait for download buttons to become active in a minute’s time. We also don’t need to install dozens of extensions just to download some images or be able to control or download a video.

A lot of these annoyances can be worked around using browser developer tools. Where this gets problematic is that developer tools are obviously built for developers, so they are not the most user-friendly. But I think that if you explain the basics and show people how to use them, they can be a great help.

And maybe it is a good thing to ask non-developers to give browser makers more feedback that a design-by-committee, let’s-add-another-tool-why-not approach to developer tools design isn’t the best idea to start with. I’ve tried hard to make browser developer tools more approachable the last three years and we had some successes. Now we need others to follow suit and re-think tooling.

I am currently in Graz, Austria to record a video series of “Developer tools for non-developers” for LinkedIn Learning. We had a massive ride by car down here from Berlin as my partner isn’t too hot on flying.

The city is ridiculously pretty and we arrived on first of May which is the day of work in Europe. We ended up looking for a first of May celebration and ended up stumbling on one of the communist party of Austria, which was a massive surprise until I learned that the mayor of Graz is also a member of this party.

Anyways, I am spending my days now in the recording booth and I am confident that the material will be done by the end of the week. Here’s the demo pages in English, in case you are wondering what it all will be about.

I also really appreciated the swipe-in gadget at the office:

My personal highlight so far was getting continually stuck calling “Main Tools” (Hauptwerkzeuge) “Crown dwarf witness” (Hauptzwergzeuge). I guess it is a wrap for today.

I was incredibly excited to see that from Microsoft Edge 111 onwards you can now emulate different viewing modes and vision deficiencies right from the device emulation toolbar.

This has been one of my pet projects that I really wanted to see come to live ever since I created the Skillshare Course on Accessibility testing in the browser and wrote the detailed documentation on how to test for accessibility in Microsoft Edge.

This new device bar makes it incredibly easy to see your product in:

• Emulated dark/light mode
• Forced colours mode even when you are not in Windows
• Blurred display
• Without colours or colour deficiencies

All from within the tool you use to test your responsive designs and mobile version of your product.

I am super stoked to see that this finally is live, after having put such a long time into it to make it work.

Background: I’ve been asked in a few applications for new roles to do written interviews. I thought it might be worth while to release some of my answers as posts as it was fun to reflect a bit on these things.

I’ve been a big supporter of open source from the get-go and worked at Mozilla for five years before moving on to Microsoft and spearhead the opening of new projects to the outside there. When I took on the role of Principal TPM of the Chromium Developer Tools in Edge, I established the repository and pushed to have all the documentation on GitHub with outside contribution.

One repo I started and maintained until recently is the Edge Developer Extension for VS Code and the Developer Tools themselves using GitHub for collaboration in the open.

The reason I pushed for open sourcing everything my team does were several:

• It keeps us honest, as you work in the open and can’t hide any shortcuts or “good enough” code.
• The contribution of everybody is visible. Large corporations often have the problem that you work for years on excellent products, but the outside world doesn’t know about it. You can’t prove your work when you apply elsewhere. With open source, this isn’t a problem. Even interns have their names associated with a highly visible product and get the kudos they deserve.
• User research is a lot easier – as people have access to your product, you can conduct quick surveys and offer previews in own branches.
• Community building is simpler, too. When people have access to the product rather than to slide decks, stickers and T-Shirts, there is a higher chance to get outside contribution.
• Hiring new people is easier. When people already work with and contribute to your product, they can hit the ground running when you hire them. And you already see not only how good they are as a developer, but also how they interact with other people. How well they comment, how readable and understandable their pull requests are and similar soft skills hint at how they could work as part of a larger team.

The CSS aspect-ratio property is pretty amazing. You can define a ratio of width to height and it will resize the element accordingly.

You can try it out in this pen :

See the Pen
CSS aspect ratio is awesome! by Christian Heilmann (@codepo8)
on CodePen.

Where this shines is videos, image content and embeds. No more hacks with relative positioning and percentages. Browser support is green all over, so, like me, it makes sense to upgrade your CSS habits.