Redoing the Responsive Web
Creating a consistent, responsive web experience across all devices
Note: This was written 3~4 years ago (2017~2018). I plan to release an update post soon, encapsulating all the new ideas I’ve explored.
As a designer, I often end up coding out my own designs for the web (usually for my side-projects, and sometimes for Fountain, where I currently work). This usually happens due to a shortage of resources, but it’s also great because there’s a significant amount of time chopped off in the designer-to-developer hand-off process (zero need to spend time speccing out, already-established understanding of the designer’s intentions and how certain elements should behave).
Understanding and owning the entire process from start to finish, I eventually found it funny (dumb) how I (and other designers in general, included) spend so much time designing such pixel-perfect, detailed screens to have it never fully, accurately translated in implementation (and even when our developers are super detailed about the pixels, it only looks great on our MacBook Pros.)
This is partially because of the difference in nature between design tools and web development. Though there has been a lot of initiatives to bridge the gap between those two, design tools still remain mainly pixel based while web development works mainly through constraints. My dilemma stems from this — because I design on my MacBook Pro, the scaling and development of my websites and web products are optimized for my MacBook Pro. And if I was to design for another, smaller screen size (e.g. 1024px) to combat this issue, it would be optimized for that size (which translates to an inferior experience for much larger screens). Given this, the only (existing) way to deliver an optimal experience for most screen sizes (devices) seems to be to design many different sized artboards, and use breakpoints.
But there are a few problems with this existing solution
- Breakpoints are absolutely necessary for responsive design. There is a need to deliver different experiences for devices of different nature (i.e. mobile vs desktop).
- But, the problem with using breakpoints between sizes for the same device (e.g. 1280px wide and 1440px wide), especially for typography, is that the window being one pixel too wide or too narrow can make the difference of the website looking too big or too small, causing a “breakpoint jump” (behavior shown below). The website should be “optimized” at every screen size.
Isn’t that kind of funny given that the whole point of breakpoints is to be able to modify your site to provide consistent experiences throughout multiple resolutions?
Understanding the audience
For the sake of simplicity, I only looked at the status quo for desktop users, since designers & developers at Ueno seem to have figured out behaviors for between mobile and desktop sizes pretty well.
Here’s some statistics from W3Schools, on the screen sizes of their users.
Of course, these numbers just indicate W3Schools’ visitors, and may not be accurate towards your audience. I didn’t take statistics in school so I don’t really know what I’m doing, but it generally shows that people are moving towards higher resolution screens now. Given this, I wanted to make the point that there needs to be more than just designing a 1024px wide artboard with a container that centers as you stretch the screen. It just doesn’t look great on higher resolution screens. In this example below by Stripe, the container is 880px wide, and stays that way regardless of how wide the screen gets.
Enough complaining, what’s the solution?
Given this problem, I thought the first immediate way to improve is to scale the website entirely. This be similar to when a user presses cmd & + or ctrl & +. By being able to scale properly, websites would look great in both small and large screens (in smaller screens, things wouldn’t look so huge, while things wouldn’t look too small in larger screens). But, it’s also worth noting that while it scales, larger screen devices should still provide a more spacious experience.
How to actually accomplish it
To be fair, breakpoints are already being used to “scale” websites. It’s just that we need a better way to scale, more smoothly. So that’s why developers started using v-units in CSS (vw, vh, vmin, vmax), so that elements on the website would size proportionally to the screen resolution. But using only v-units make things scale too quickly (larger screens don’t get a more spacious experience).
The graph above shows how units scale as the screen size increases, and vw-s scale too fast and pixels don’t scale. Developers have already figured out how to scale slowly and achieve the behavior depicted in the “desired” curve, but it’s way too annoying to apply to everything on the website to scale the entire site up (and using transform: scale breaks things way too often and easily).
While figuring how to best do this, I had two goals: to minimize repetition in the designer’s workflow and that the developer shouldn’t have to do something crazy annoying. And here’s how I do it.
Step 1. Design for Low-Resolution Desktop (1024px ~ 1280px)
(16:9 in this example)
Step 2. Scale up to High-Resolution Desktop
Duplicate the artboard, resize to a High Resolution Desktop Screen Size (1680px in this case), and scale up the content. This is just to figure out the “scale factor” (the percentage you scaled it up by).
Step 3. Use rem instead of px (in dev), and scale the base font-size up by the scale factor as the screen widens
I designed in a 1280px wide artboard, and ended up scaling 117% in a 1680px artboard (make sure your scale factor is less than the new artboard‘s scale, which is 131.25% in this case). With simple math, I get that I need to scale up everything by 117% for every 400px screen size increase. Using the responsive-scale SCSS mixin, you can apply that to the base HTML font-size to scale the entire website as you increase the screen size — with just 1 line of code. (Ok fine, you need to convert px into rem, but that can easily be done by wrapping all px values with a unit conversion function).
It’ll probably look something like this (for desktop).
html {
font-size: calc(0.0068 * 100vw + 7.296px);
}Notes
- This works even better if you can get the CSS base-font function to go in more of a curve through multiple breakpoints and multiple-sloped lines, instead of just one best-fit line (though you would have to re-figure out the sloped curves for each breakpoint).
The Result
But, maybe in the end, I’m being stupid
It could totally be possible that no one actually cares about this, and that I’m overcomplicating things. (I wouldn’t doubt it since no one [to my knowledge] does this). I also had a thought that maybe the reason why fonts and other elements on websites don’t scale as you size up is because the OS system font size doesn’t change as you scale up. (Whether you’re on a Macbook Pro 12", or a 5K iMac, the font size by default in your menu bar, Finder app, etc, remain the same — just like how the pixel-based web is, right now). It makes sense that websites might not be scaling since the user is already used to the scaling / sizing on their machines already.
Or, if you look at it more technically, I might be absolutely wrong in this, but — the PPI of many modern devices seem to be pretty close to one another (note: PPI to describe the counted pixels per inch, not to measure crispiness of the display. i.e. You would count a standard 15 inch MacBook Pro with 1680px width, not 2880px width). This would mean that many websites show up similarly in size physically (i.e. A header could be about 3cm tall in both two differently sized screens), even though the ratio from element size to screen size might be drastically different. I don’t know if this behavior is intended, or desired — just an interesting thought and discovery.
Either way, what do you think?
