Dion Almaer

Software, Development, Products

Archives for April 2020

Die, Print Layout, Die…. the Chrome Extension

TL;DR I built a Chrome Extension that forces my layout of choice for Google Docs, all thanks to the escape hatches that extensions give you on the Web!

I admit to having a lil bit of OCD when it comes to my digital life. Seemingly small UI and UX choices irk my brain, and I spend a lot of time in Settings and Preferences tweaking my experience.

It’s because of this that I get frustrated when products don’t have the ability to tweak and change, often on purpose, claiming “a great product shouldn’t need complicated settings!”

I disagree. I want escape hatches, and all humans aren’t the same (nor use the product in the same way), especially for tools that you spend significant time in.

Facebook webOS edition 2010

Back in 2010, I got to work on the “official” Facebook app, for webOS. One of the great side effects here, was that we were able to sneak in a slew of power user features, and have keyboard shortcuts for everything.

The place to turn “Print layout” on and off

One of my ticks shows up in Google Docs. I rarely print documents, and thus rarely see the need for the notion of “pages”. For some reason, elves get into my computer and turn on “View => Print Layout”, even though I was constantly turning it off. Even when off, I don’t like the “——-” page break.

I knew I wasn’t the only one, as one way to bug Ben is to have this turned on as you go through something together, and then I saw this:

It was time to fix this…. once and for all!

Die, Print Layout, Die!

I have been enjoying building extensions recently so I fired up VS Code to create another one Die, Print Layout, Die, (open source code here) which simply makes sure to force off Print Layout mode when loading a document, and kills the page break.

Not only do I sleep better at night, not worrying over the elves and if they are messing with my layout, but this made my day:

Escape hatches FTW

I am very thankful that the Web has these escape hatches that enable the ecosystem to evolve products outside of the product development team.

This week, the local school district banned the use of Zoom, and my kids meetings were all moved to Google Meet. As this happened, teachers were emailing parents asking them to install the Google Meet Grid View extension so the kids could all see each other.

And folk from Shopify got in the game too!

There are trade offs on allowing this type of power, which is why we are looking to rebalance them via the next iteration of extensions (manifest v3). Grid view is an awesome feature, but the extension isn’t able to implement it as efficiently as the team itself, and this is often the case. However, it fills a gap and hopefully gets into the core product some time soon.

Once you get used to the power and extensibility, you feel constrained on platforms that don’t enable this kind of flexibility.

And when you get used to the flexibility, you look to extensions as a way to find functionality:

Browsing the Web while watching it’s vitals

TL;DR I built some Chrome Extensions that show you vital metrics for sites as you browse the Web. Here I discuss the current metrics of choice, the extensions, and finish with some magic.

It sure is unprecedented times. My mental state has fluctuated between anger, frustration, grief, guilt (privilege), and beyond. I am thankful for the people in my life who have been amazing, and I am globally thankful to all of the people who are either staying at home to help flatten the curve, or who are courageously doing their duties.

Working (and loving!) from home has been a reset, and I am trying to use that reset by setting up new habits (tiny!) whilst also not being hard on myself for hitting them all.

One of these has been giving myself time to write a little code on something I have wanted to have in my browser for awhile.

web.dev/metrics

What’s the latest with Web Performance Metrics?

We all want to have great metrics that reflect the quality of our web experiences, and use them as guides for how we can improve.

These metrics have changed over time, as we get better at understand the mapping of the browser engine to parts of the experience.

At web.dev/metrics you will see a current set of metrics that each look to understand a different piece of the overall experience:

This video goes into the metrics and much more on speed!

At the last Chrome DevSummit, we spoke about the evolution of metrics, and how they are rolling out across our tooling.

For example, in the field it always starts with Chrome instrumentation, which will then get picked up in CrUX, which will be reused in tools such as PageSpeed Insights.

In the lab, you get access to them as Lighthouse and DevTools implement support.

github.com/dalmaer/lcp-chrome-extension (The LCP extension)

Chrome Extensions that show the metrics

After spending time looking at metrics while developing, and spelunking in the CrUX datasets, I found myself wanting to feel the impact of the metrics, so I decided to build some ambient Chrome Extensions.

There are individual extensions that show scores as the browser’s PerformanceObserver spits them out, and change color depending on the thresholds of each metric.

For example, the LCP extension will be green if it occurs in less than 2.5 seconds (a good score), yellow if between 2.5 and 4 seconds (an adequate score), or red if it takes longer.

There are equivalent extensions for FCP, FID, and CLS.

Now that I have been browsing around the Web, what has surprised me the most is how variable the results can be with N=1. If I load a page while a message comes in to Hangouts Chat and I am on a VC…. it may be slow. When developing, it’s important to isolate your environment… something that we very much notice with Lighthouse development too.

It is also kinda fun to dive into a page when there is an expectation mismatch. I will think to myself “huh, that seems like a decent load, why is the CLS so bad?” and start digging…. and come to find that the web fonts loaded slow and did a swap, causing layout instability (most of the time its ads loading late and resulting in the change to be fair).

It’s been really nice having the traffic lights give me some feedback as I browse and letting me explore, but this is only the beginning. The product teams are working on much better tooling that can showcase this type of information, and also tie deeper into tooling to give you actionable feedback.

Don’t forget the magic

Hitting these thresholds are good guides for a quality experience, and they are only going to get better over time. It is important that we all take them into account, but also important not to do so blindly.

I like Derren as he explains that his magic is not magic (as it doesn’t exist 😉

I have been enjoying me some Darren Brown action, such as the classic video above. He used a series of techniques in his shows, and good ole misdirection is always involved.

Misdirection is a key trick with UI development too, as the goal centers around the perception of quality. This can sometimes be a touch at odds with pure metrics, as the browser engine may not be fully aware of the tricks that you are playing.

This is why it’s important to consider custom metrics such as the Element Timing API to measure what is really important to see on the page (which may not be the largest element that LCP will fire).

There are some absolutes (human perception research shows those), but it always makes sense to go the extra mile and really understand how users are using your site…. and using the appropriate tricks. It turns out we are simple bears that can only focus on a small area 😉

The right thing to do, is the right thing to do.