CSS Media Queries Device Breakpoints vs. Windows Display

Windows 10 Display Settings, with text size at 125%.
Windows 10 Display Settings, with text size at 125%.

Ran into an interesting problem last week, and wanted to share it here while it was still fresh in my mind.

I’d received a support ticket from a client who was seeing the mobile version of our website, even though she was viewing it on a desktop with Google Chrome’s zoom level set at 100%. If she decreased Chrome’s zoom level to 90%, the website would suddenly transition into the desktop version.

It turns out there were two factors contributing to this issue:

  1. Her older monitor supported a maximum screen width of 1280 pixels.
  2. Her Windows Display settings had a “Change the size of text, apps, and other items” feature set to 125%.

Since the 125% setting effectively removes 25% of the total screen width (1280 – 320 = 960 pixels), Google Chrome fell beneath the 1024 pixel width for the desktop media query, and was displaying the tablet/mobile version.  Changing Chrome’s zoom level down to 90% was an effective increase of 10% screen width, increasing the effective screen width to 1056 pixels– which caused the CSS media query for desktops to suddenly come into effect.

With the higher resolutions on newer monitors and/or laptops, you’re less likely to encounter this issue because it would take a greater percentage to drop a higher resolution below the 1024 pixel threshold.

Hope this helps someone else solve this issue, if they encounter it.

The Situationally Aware Algorithm

Mountain lion lounging in a cottonwood tree during the heat of the day.

Developers often pick an algorithm for its speed, but sometimes it makes more sense to dynamically pick an algorithm based upon the resources available at a particular moment. For example– the “Update All” feature for installing available updates for applications on Android Lollipop devices. “Update All” will download and unpack available updates one after the other, without waiting for the first update it unpacked to be installed. This parallel work queue approach makes sense from a time-saving perspective . . . until you try doing it on a phone with only 400-500 MB of storage space.

When storage space is limited, the processes of downloading the next update and unpacking the last downloaded update rapidly fill up the storage, usually faster than the installing process can use and dispatch the files. Suddenly, you have multiple update error messages in your notifications due to “insufficient space.”

Now, our annoyed Android user has a choice:

  1. Clear their cached data in “Settings -> Storage” and hope this frees up enough space for the “Update All” feature to work properly.
  2. Update each Android app one at a time.

But what if the “Update All” process checked the available storage space before it started downloading updates, and based upon a particular threshold, decided between downloading all the available updates in rapid succession or downloading the first available update and waiting for it to be updated and purged before proceeding with the next download?

The idea of a “situationally aware algorithm” is not new. We can dynamically apply different sorting algorithms to data by determining the size of the dataset beforehand. We can determine how much free space remains in storage on an Android device by using the getFreeSpace() method. We have the means to inspect the resources available to us before we decide to tackle a particular problem, and yet more often than not we plunge ahead with a predetermined “one size fits all” approach.

I blame satisficing. I’m also guilty of it.

When I walk in the woods in my neighborhood, I never look up to see if a mountain lion might be perched on a limb I’m about to pass under. Mountain lions are a non-issue for me, and walking beneath tree branches is an experience which I take for granted will be uneventful.

Until, of course, it isn’t. 😉

Similarly, if we apply an algorithm for sorting large datasets to a smaller dataset, it will still give you results. It’s only when we come across a dataset which completely breaks the algorithm and get no results back (e.g. the dataset is so large it consumes all available RAM) we begin to question if the currently implemented approach to the problem is the correct one.

On the bright side, I think the adoption of practices like User Stories and Test Driven Development– particularly in team approaches where the stories, tests and code are written by different people– is gradually pushing development beyond the satisficing “just make it work” mentality into a more nuanced, situationally aware paradigm.

In the meantime, the best we can do is keep learning our craft, be patient with the status quo, and . . . start checking tree branches for mountain lions before we walk under them.