Part One: Experimentation & Proof-of-Concept for UI Smooth-scaling

Hey guys, it's been a bumpy couple of days. For some strange reason, I haven't been feeling 100% in the last few days, so I've been focusing on bouncing back. And as of today, well, fellas...I'm officially back from feeling emo EMO. You know what that's like, right? What do you usually do to help you bounce back more quickly? Any good tips/ideas to share?

Media Queries are a Thing of the Past

As someone who has worked with Media Queries since the beginning, I have plenty of firsthand experience with their useful benefits and limitations. When media queries were first made available to web developers/designers, they were troublesome and often not very friendly for developers to use. But back then, it was the only available option, so there was nothing we could complain about.

/* What media queries might look like. */
@media screen and (min-width: 1600px) {

}

@media screen and (min-width: 1440px) {

}

@media screen and (min-width: 1280px) {

}

@media screen and (min-width: 1024px) {

}

@media screen and (min-width: 768px) {

}

It is also worth noting that back then, mobile devices had a very limited range of screen sizes, and dimensions were relatively narrow. So, using media queries to set up a series of styling options didn't feel as much work as it would be today.

Today, when working with any kind of customer-facing website, it is crucial to ensure that the UI can scale smoothly and dynamically. To make matters more challenging, we also have split-screen options on tablet devices. That means, when a user is dragging the view horizontally, we need to ensure that our UI doesn't feel janky.

Larger Screen Estates & Wide-ranging Screen Sizes

One thing that the old responsive web design standards haven't caught up with is the growing number of hardware displays that are no longer stuck in the old CRT monitor and 1024px width. Even fewer laptops come with a default 1400 x 900px resolution. For years, I have always felt like the responsive web design guidelines are still stuck in the 2010s. And it is time for us to move on.

Today, we have a much larger screen estate (for nearly 80% of the world's population that faces a monitor to some degree in their daily lives). Therefore, I believe that it is way past time for us to update our responsive web design standards.

Designing a UI Scaling System that is Independent on Hardware Specs and User-Controlled Scaling Factors

The other thing that is becoming more and more common today is the custom scaling factors that are built into various desktop environments. For example, when I was using a laptop with a stated 3K screen resolution (i.e. 3200px), the default Windows scaling factor was 150% or 175%. I can't remember. And because of that, everything on the desktop has been scaled up. Now, the other thing that web designers and devs cannot account for, and should never depend on, is the user's web browser zoom size. I'm currently working with a 1440px monitor at home, so I often prefer to view my web pages at 150%.

Now, assuming that everything at 150% looks perfect/ideal, I would then use that as a gauge for the kind of size my web app should be, regardless of the browser's zoom factor, or my desktop's zoom factor.

Introducing a More Fluid, Buttery Smooth, Scaling

Part of the reason I'm loving my current FocusFlow web project more and more is how simple the idea is. Working with simple ideas gives us more room to tinker and experiment, and in this case, push the boundaries of what is possible.

function  calcFontSettings(width: number): string {
  if (width >= 1600) {
    setBtnIconSize(Math.floor(1.65 * 20));
    return "1.65rem";
  } else if (width >= 768 && width < 1600) {
    let currScaleFactor = 1 + (((width - 768) / (1600 - 768)) * .65);
    setBtnIconSize(Math.round(currScaleFactor * 20));
    return `${currScaleFactor}rem`;
  } else {  // Anything smaller, we can assume to be a mobile phone.
    setBtnIconSize(Math.floor(0.95 * 20));
    return "0.95rem";
  }
}

What I'm showing you here in this article is something that I've been experimenting with, a way to calculate the font size, line height, and icon size that I can use for my UI in real time. It is a work in progress, but I can scale everything from the texts in a KendoReact button to the slightly more complex CircularProgressBar that I created earlier in the week.

 Set Focus Time

As you can see from the above code snippet, I have my work cut out for me this weekend. I want to enable smooth scaling for everything in my web app. So, no matter the page is width, the app will scale nicely and proportionally according to the dimensions of the layout (independent of user's screen scaling factors).

Part Two: Implementation of Smooth-Scaling UI Completed

Hey guys, I'm happy to be back and report that I've successfully implemented a UI with pixel-perfect smooth scaling.

I initially thought scaling the CircularProgressBar would be much more challenging. But as it turned out, I may have been overthinking it quite a bit, when in fact, it is much easier to implement than I had thought. So here's what I did with it:

{/* Everything else */}

When it comes to scaling the SVG, I found that the simplest and most elegant solution was to set a percentage for the width. And then at the different breakpoints, I will ensure that the CircularProgressBar doesn't enlarge beyond the boundaries of the left panel, or shrink too far down. Notice two things that I've specified using the Tailwindcss responsive design classes:

  • 2xl:min-w—[600px]: This helps ensure that the width stays at the minimum viable width between transitioning from 1600px to the next breakpoint level.
  • xl:max-w—[600px]: At the next lower breakpoint level, I also want to ensure that its max is the same as the upper level's breakpoint width. Now, when I scale, everything feels much more responsive and less janky.

Please do not get me wrong; occasionally, I do appreciate using the breakpoint-style approach when working with responsive design. They still have some usefulness. But maybe they are only more helpful when dealing with certain kinds of content (e.g., graphics, photos, movies, high-level layouts, etc.).

In my professional opinion and observations, when it comes to inner layouts, typography, and other UI-related dimensions, it's still better to use a form of dynamic scaling, as you saw in the previous section of this article.

Closing Words

So, who says that media queries are the only way to build a truly responsive web design? If any web designer or developer tries to make that statement now, you know it is a lie. Media Queries are janky in today's standards and hardware capabilities. They do still present some benefits, but those benefits diminish with time and hardware innovation. So, perhaps we need to consider some other way, a more efficient way to craft buttery smooth scaling for our UIs.