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.

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.

One question was what practices I think help software teams build better quality products. And this is what I wrote:

There are a few things that helped a lot making my current team deliver quality products. The first parts are processes and technical setup.

• A development environment that involves linting, error and issue reporting while you develop using static code analysis in the editor. Any bug that isn’t written means less work for the QA department and less waiting for results.
• A version control system workflow that involves checks like tests, documentation, peer review, and automated security and data analysis.
• A code standard that is automatically applied on commit to the version control system. People can write any way they want to, but code coming from the repository needs to be in a predictable format.
• End-to-end tests. Code without any tests will not be allowed in the repository.

The other part is the team/human factors that ensure that we all follow best practices and learn from another.

• Peer reviews / team reviews of code with detection of best practices. Once these practices are discovered, they should be documented in and shared amongst the team.
• Presentations to the group of new and exciting tools and processes. I mentored and coached my team on those which also helped them with their communication in their own reviews.
• Learning days that allow developers to try something new or share information with others.
• Documentation days to catch up on missing write-ups.
• Bug bashes – we take a list of long-standing bugs and dedicate a day to fixing those instead of continuously working around them.
• Leaving ample time at the end of the daily stand-up for questions and answers when people are stuck.
• End of sprint reviews and sharing of learnings.
• Including engineers in design reviews and user testing. The former to ensure we can build what the UX team dreams of and the latter to give engineers a feeling of who we work for and that what is obvious to a technical person may not be understandable to others at all.

Another concept I’ve seen work extremely well in two companies so far is a developer rotation. Products get cut up into “work pods” and developers get assigned as needed to the pod depending on how soon that product needs to be finished or new features released. Engineers get assigned to pods on a rotation basis, which means that everybody in the team knows about the different work going on.

This means:

• People can get sick or take time off without the product being stalled.
• If people leave the company, they don’t take all their knowledge with them.
• Documentation and handover are a must as you are not the only person working on the product.
• Engineers learn from each other how their counterpart worked on the last iteration of the product.

Photo by Annie Spratt on Unsplash

Twitter has a list of interests you can define that affects what content you see on your home timeline. This is a list of 150 topics, most not chosen by you but considered something you should see. You can change these settings by going to:

More -> Settings and Privacy -> Privacy and Safety -> Content you see -> Interests

This is a UX nightmare and unchecking 150 boxes isn’t fun, so you can also toggle all 150 in bulk by opening developer tools, going to the Console and running this command:

$$('input[type=checkbox]').forEach(c=>{c.click()})

You can see it in action in the following screencast:

It may give you a “Twitter is over capacity” message, but that’s just temporary.