The following is a guest post by Jon Yablonski. Jon told me he recently worked on a project where there was a lot of emphasis placed on giant screens. Jon is going to show us that just like RWD work of any kind, it requires planning. Extra media queries are useful for targeting the huge displays, and typography can take you far.
With the rise of ultra high-definition displays and devices that enable browsing the web via smart TVs, the internet is increasingly being accessed and viewed on screens that dwarf traditional desktop displays. Most websites fall short of being optimized for this scale. But if you’re building responsive websites, it’s likely that the tools you need to scale your content are already in place. In this article, we’ll take a look at the challenges and techniques for optimizing your site on large-scale displays.
Identifying Large-Scale Displays
First, let’s identify what exactly constitutes an large-scale display. According to W3Counter, screens with a device width of 1366×768 pixels are the most common large device resolution. The next common large resolution is 1920×1080 pixels. These values come primarily from desktop monitors, and most websites will adapt to these screens without much problem.
Traveling up the scale, the next most common device width lands at 2560 pixels wide. This width is what you will find with most high-definition desktop displays that start with 27” monitors. It is also the range at which most websites begin to struggle because of excess screen real-estate.
Take for example the image above, which depicts a small sampling of popular websites that were each captured at a screen size of 2560×1600 pixels. As you can see, none of these sites are optimized for this scale: text is too small, the volume of content packed into a relatively small space makes it difficult for the eye to know where to focus, and everything seems to be dwarfed by the whitespace that surrounds it. Each of these factors contribute to a decrease in legibility and less than optimal user experience.
So what is preventing designers and developers from optimizing for large-scale displays? The answer is sure to vary by team, but there are definitely a few technical challenges at this scale. Let’s identify what these challenges are.
The Challenges of Large-Scale Displays
The challenges of optimizing for large-scale displays center around how to scale and manage content. Broken down into categories, these challenges would look like the following:
Content choreography
Content choreography refers to how content is adapted proportional to screen size, serving the best possible experience at any width. The larger the screen, the less proportional the content will seem. This is a problem for a few reasons: 1) the awkward space that results is distracting, 2) the excessive space can dwarf the content, which makes the content seem smaller than it is, and 3) legibility will most likely suffer as a result of being too small.
Generally speaking, the way content adapts on small screens is pretty straight-forward: we stack content within a single column and adjust the visual order if necessary. On the other hand, the way we approach this on large devices can vary greatly, depending on the content and the space available. If you avoid adapting your content to the excess space made available on large-scale displays, your content will most likely seem dwarfed in comparison to the negative space that surrounds it. But, if you attempt to fill the space with content by introducing more columns, you risk visually overwhelming the user by presenting too much content in a relative area of the screen.
Images
Images pose a number of unique challenges on large-scale displays. Since most large screens are also higher resolution, we must manage additional variations of each image to ensure the appropriate image is served. In addition, we must also manage how the images will behave in the context of the layout. Images that don’t scale with the screen can leave awkward gaps of space between them and other elements. In contrast, images that scale too large can take away from other elements and become overwhelming. Since there is no one-size-fits-all solution to the challenges that images pose, you must carefully consider how you want to manage them based on the unique needs of your content.
Techniques for Optimization
Now that we’ve identified the various challenges that come with large-scale displays, let’s take a look at some approaches to optimizing our content for this scale.
I’ve created a site to demonstrate each technique we’ll be looking at for optimizing for large-scale displays. Given the topic, I chose a theme that seems appropriate in the context of scalability, the Death Star II. I will be referring to bits of code from this demo, but you can see it in it’s entirely here on CodePen.
The method you use to optimize your content for large-scale displays will vary, depending on your content. One option is to simply adjust the layout in order to present your content in a way that takes advantage of the additional screen space. Another method is to responsively upscale your content so that it fits the space proportionately. And of course, you could also leverage a combination of both methods. In our demo, we will responsively upscaling our content in order to provide a superior experience for users on larges-scale displays.
Plan Ahead
The first step in optimizing for large-scale displays to is plan for them. By planning ahead, you are minimizing surprises and ensuring that everything works together before diving in, at which point it’s harder to make changes. If your design process involves working in a design application in order to visualize how you want content to behave, then do so by creating a canvas size that represents a extra large screen alongside your other comps that represent more traditional screen sizes. If you prefer to design in the browser, then plan how you want your content to behave on large screens by first sketching out your ideas.
For our demo, I chose to start with sketching out the general idea for the layout and content. By doing this first, I got a sense for how I should break the site down into sections, and how the page as a whole could be structured to accommodate these sections. Next, I explored design aesthetic a bit by creating a high-fidelity composite in Sketch, which allowed me to identify design elements such as fonts, colors and proportion. The key here is to stay loose and don’t worry about pixel perfection — the important things like interaction, scaling and even font-size should be decided in the browser.
Build with Relative Units
Relative units such as percentages, EMs, and REMs are essential to responsive web site because they provide us a way to build on a flexible foundation. By using relative units everywhere, we can ensure that measurements will remain proportional, regardless of the font size set by the user. This is in direct contrast to explicit pixel values, which will not scale relative to a user’s settings, and therefore measurements will not be proportional if the user scales up or down the default font size.
// Breakpoints
$bp-small: 48em; // 768px
$bp-medium: 64em; // 1024px
$bp-large: 85.375em; // 1366px
$bp-xlarge: 120em; // 1920px
$bp-xxlarge: 160em; // 2560px
// Media Queries
$mq-small: "(min-width: #{$bp-small})";
$mq-medium: "(min-width: #{$bp-medium})";
$mq-large: "(min-width: #{$bp-large})";
$mq-xlarge: "(min-width: #{$bp-xlarge})";
$mq-xxlarge: "(min-width: #{$bp-xxlarge})";
$mq-retina: "(-webkit-min-device-pixel-ratio: 2), (min-resolution: 192dpi)";
Take for example the media queries used for our Death Star II demo. By defining our media queries in EMs, we are ensuring the design scales proportionately without enabling awkward scrolls bars in the browser if the user was to adjust the zoom level.
Scaling Text
In addition to media queries, relative units also come in handy for text. Font-sizing can be controlled globally by adjusting the font-size property on the <body>
element, as long all text on the site is defined in relative values like EMs. This is especially useful when it comes to large screens because it allows you to proportionately scale type up globally as screen size increases, thus avoiding the text in your design from seeming too small in relation to the screen.
To implement this on our demo, we began by defining some variables. As you can see below, the first step is to define what the base value of your font sizing will be. In our case it is set to 1em
, which means we are defaulting to whatever default font-size
is set by the browser. This base value can easily be adjusted in browser, but it usually defaults to 16px
. It’s also useful to define the base line-height
values here in conjunction with font-size. You’ll notice we are leaving off the unit at the end of these line-height
values, also known as ‘unit-less’ values. By setting line-height this way, we ensure that child elements can compute their line heights based on their computed font size, instead of inheriting this value from its parent.
// Font-Size
$base-font-size: 1em;
// Line-Height
$base-line-height: 1.5;
$header-line-height: 1.25;
Next, we apply these variables to our <body>
element and increase both font-size
and line-height
gradually as the screen gets larger. As mentioned before, this will scale up the text size everywhere if you have set font sizes in your content as a relative unit like EMs.
body {
font-size: $base-font-size;
line-height: $base-line-height;
@media #{$mq-medium} {
font-size: $base-font-size*1.2;
line-height: $base-line-height*1.2;
}
@media #{$mq-large} {
font-size: $base-font-size*1.3;
}
@media #{$mq-xlarge} {
font-size: $base-font-size*1.4;
}
@media #{$mq-xxlarge} {
font-size: $base-font-size*1.6;
}
}
So how much of a difference does scaling text up to fit the proportions of the screen? Turns out, pretty significantly. Take a look at the image below, which illustrates the difference between our demo when font-size isn’t scaled up on the body (on the left), and when font-size is globally scaled up (on the right) at 2560 pixels wide. Not only is the scaled-up version more legible, but all elements on the page have been proportionately scaled up to activate the space.
Containment
When it comes to controlling content, there are few tools in the responsive web design toolbox as useful as the ubiquitous ‘container’. This element has one purpose, and that is to control the maximum-width in which our content can extend to. Take for example the following, which is the most common way you see these elements defined in CSS:
.container {
margin: 0 auto;
max-width: 1024px;
}
This approach works but, but it doesn’t scale to large screens because the maximum width is too dependent on a specific width. Even if the max-width
value was increased to something much larger, it isn’t relative to the viewport width. A better way to approach this is to define the left and right margins as relative units and gradually increase these values as the screen size gets larger. As a result, content will be contained in relation to the screen width and feel more at home if the screen is extra large.
.container {
margin: 0 4%;
@media #{$mq-medium} {
margin: 0 8%;
}
@media #{$mq-large} {
margin: 0 12%;
}
@media #{$mq-xlarge} {
margin: 0 18%;
}
}
Manage Images
How you manage images on extra large screens is entirely dependent dependent on your project needs, but you will most likely need to serve up higher resolution variations of each image to ensure images aren’t too small. The approach we take is different, based on how the image is applied.
.detail {
height: 0;
padding-bottom: 40%;
margin: 0 0 $base-spacing*2;
background-image: url(/Death-Star/detail_sml.jpg);
background-position: center center;
background-size: cover;
@media #{$mq-xlarge} and #{$mq-retina} {
background-image: url(/Death-Star/detail_sml%402x.jpg);
}
@media #{$mq-medium} {
background-image: url(Death-Star/detail_med.jpg);
}
@media #{$mq-medium} and #{$mq-retina} {
background-image: url(/Death-Star/detail_med%402x.jpg);
}
// Additional media queries
}
For background images, this is quite simple: define the background image on the appropriate element, give the element dimensions, and define higher resolution sources of the image within media queries. The image above illustrates how this is done on our demo. Notice that we are setting the height property to 0
, providing bottom padding, and setting the background-size
property to cover
. This is a technique known as “Uncle Dave’s Ol’ Padded Box”, and allows us to maintain an aspect ratio by percentage padding based on the width of the parent element.
For inline images, we now have an HTML specification that allows us to extend the img and source elements to provide a list of available image sources and their sizes. This allows browsers to use this information to pick the best image source. The image below details how this is implemented on our demo, in which we are defining additional image sources and their sizes with srcset and sizes attributes. This enables the browser to switch image resolution based on screen size and pixel density, thus providing the most appropriate image.
<header role="banner" class="header">
<div class="header__img">
<img
srcset="./death-star_sml%402x.jpg 400w,
./death-star_lrg.jpg 600w,
./death-star_sml%402x.jpg 800w,
./death-star_lrg%402x.jpg 1200w"
sizes ="(min-width:1336px) 75vw, 50vw"
alt="Death Star 02">
</div>
</header>
You might notice that we aren’t including a src
attribute on our inline image. This is because we must leverage a polyfill to enable support for srcset and sizes in browsers that do not yet support them. Browsers without support will prefetch the img’s src if specified, often causing wasteful overhead. To prevent this, it is recommended by the polyfill author to omit src and only use srcset.
Conclusion
Serving the best possible experience at any screen size is imperative. When it comes to optimizing our content for large-scale displays, we shouldn’t stop short of common desktop resolutions. With the proper planning, we can leverage the tools already available to us when building responsive websites to scale up and adapt our content for large-scale displays.
I think it’s also important to take window height into account. I use a 27″ monitor, but I don’t run the browser fullscreen (why would I?); instead I run it taking up half the screen, so it’s ‘only’ 1280px wide, but still 1440px high, so I feel like I need to have larger text than if I was running a browser fullscreen on a 1280×800 laptop screen.
It’s important to ensure that your content is readable at any size and readability is not just a function of font size but also line length. Reads can lose their place when lines are too long or too short. 50-60 characters per line seems to be a sweet spot. http://baymard.com/blog/line-length-readability
Indeed — thanks for pointing that out Sunny!
If I don’t have a high definition display available for testing, what is the best way to test my design? Is zooming out in the browser a good enough approximation of what the layout would look like?
Firefox’s Responsive Design Mode and Chrome’s Device Mode both allow you to enter large resolutions like 2560×1440, but on Firefox you have to scroll horizontally and vertically to see the whole layout, whereas on Chrome, it zooms out.
Great question Flimm.
Unlike testing for mobile, we are limited when testing for large scale displays if there isn’t one physically available. I recommend using an emulation tool like CrossBrowserTesting (crossbrowsertesting.com), which allows you to select the screen resolution that you want to test. If you are on a smaller screen, it will scale down the content to fit your browser window, but you’ll get a good idea of proportion and of course you have developer tools available to check font sizes, etc.
What makes this sort of thing even more complicated is not only are some monitors ultra wide, some also have very high pixel densities.
This article, as far as I can tell, is referring only to very wide display resolutions, not HiDPI monitors.
If by High Definition Display you mean HiDPI monitors, then you are totally out of luck in how to test how your site will look without physically owning one. Your standard DPI monitor is not capable of displaying a higher pixel density, anymore than a 480p TV is capable of emulating 1080p.
So, a 1500 wide resolution on a standard DPI monitor would display things quite differently than a 1500 wide resolution on a HiDPI monitor..small text won’t be as easy to read, images might appear blurrier, etc.
Great point Daniel.
And yes you are correct, this article is primarily in regards to large displays and optimizing for scale. Testing proportion and scale is possible via the method I describe above, but not accurate when it comes to pixel density of images and text. For this you would need an actual HiDPI device.
I think this is an awesome article, but there’s another viewpoint to consider. Take Apple’s 30″ Cinema displays. They’re 2560×1600. No one maximizes anything on those monitors, for the same reasons that you wouldn’t maximize a window across a dual-monitor setup. So, the examples of Reddit, Wikipedia, etc. are somewhat irrelevant in a case like that.
Also, let’s not forget about zoom. Zoom works a lot better going up than going down. So, whereas zooming out doesn’t help much for mobile devices, zooming in helps quite a bit for larger displays.
Of course, none of the above applies in cases where you simply want to present more information to fill up the screen space, or you want to present the existing information in a better way that genuinely makes use of the space. In those cases, by all means, write media queries to take advantage of the screen size! And I think this was really the goal of the article.
Thanks Agop — your exactly right: the point was to demonstrate some simple techniques for taking advantage of the space available. And yes I agree, the zoom feature in browsers is helpful, although I think optimizing your content in the first place is a better option at large scale.
Regarding maximizing browser window at large-scale: while I agree this is not likely for casual browsing, I can imagine (and have seen) this done in other circumstances like presentations, etc. Whether this is common or not is beside the point though — the point is to ensure the best possible experience at any screen size.
I tried to prove this once.
Great article Chris. I agree — having information is never a bad thing, especially actual browser vs window size.
Yup, presentations and such would ideally be full-screen, no matter the size or resolution.
And I guess we can have the best of both worlds as long as we stick to ems for media queries, right? If you don’t zoom in, you get regular-size content, just lots of it all at once (especially if you maximize your window at 2560×1600). Then, if you zoom in, you get less content at once, but it looks bigger (the bigger media queries no longer apply). Eventually, you can become so zoomed in that you’re just looking at a huge version of a mobile screen.
Great article, thanks. I’ve always been intrigued by this and am now going to have a play with ensuring that my work in optimised for larger screens, future-proofed!
Good Article Jon,
Would be very interested in seeing – after applying the principles, what would a mock of the 4 problem sites look like. e.g. would wikipedia be centered with a container or would yahoo spread out to use the full real estate of the screen?
Thanks Susan! Interesting question — perhaps a follow-up article is in order. Every website is different and decisions should be made specific to its content, but I think both sites that you mention would benefit from the approaches demonstrated here.
Easiest way to handle this – writing everything with rem units. Then you just need to change global font-size and everything will be auto-scaled with correct proportions.
The only expection is one-page scroll websites when it comes to situations where aspect ratio is different. But one-page scroll sites are not standard thing and having a lot of pain with situations like this is not a surprise usually.
Thanks for addressing this. I dare say one of the reason people don’t put their browsers full screen when on large monitors is that there are basically no sites that take advantage of the larger canvas.
Even now that everything is ‘responsive and adaptive’, large monitors still don’t get any love, only tablets and phones. The tools and affordances in CSS are there, people just need to take advantage of them.
What about TVs? If people want to say their site is truely adaptive and responsive, would not large low res TVs be part of this mix? Also, how do you navigate such sites with a remote control or gestures? Before you dismiss these offhand as edge cases, do consider that just considering such possibilities opens your eyes to different approaches to enhance your site for all users.
Well said — I couldn’t agree more Thurstan. We should be building sites that can adapt to any screen size, no matter how large or small. Too often I think the focus is on today’s common screen sizes, while forgetting that we cannot predict those of tomorrow.
Totally agree. The future is about screens, not a certain screen on a certain device.
Being able to use a site or ‘thing’ great on a TV, a desktop, 13″ laptop with 4k res, phone or tablet is very rare even though there are tools available to target things such as TV’s (with ‘device pixel ratio’).
Finally I see someone noticed this No1 RWD problem. Many developers and designers don’t undrestand that RWD does not means mobile only and most popular websites on large screens looks like a small column with unreadable text and only increasing default zoom level helps.
Thank you for an article. I’am also having many breakpoints and different font-sizes, paddings for each of them. Have you been using Bootstrap 4/3 or any other CSS/SASS framework/library for large screens? I don’t know anyone optimized for real modern RWD and currently having many custom code in Bootstrap 4.
Your very welcome Mevrael!
Regarding frameworks or libraries: I have a tendency to use my own boilerplate projects, which are essentially ‘mini-frameworks’ of code I find myself using on each project. This approach tends to work well for me because it results in more control and less code bloat.