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.

Further Reading/Tools

• Screensiz.es
• Surveying the Big Screen
• Responsive Images Community Group

Optimizing for Large-Scale Displays originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.