The web is being experienced on a wider range of screen resolutions than ever, but 1366 x 768 has remained steady as the most common for some years now. So when we were asked to design and build a suite of three websites for the Axis group of companies, we thought we were being ambitious ensuring they worked well up to full HD resolution (1920 x 1080)…
It turned out we were only half way there.
The Conversation
We’re looking at the site on a monitor that’s 2500 pixels or so wide and it doesn’t fill the screen.
That’s right – it centres the content above 1920 wide.
(pause)
Lots of our clients have 4K screens – it needs to fill the screen at 4K.
Oh….
The Challenge
We knew from our analysis of the web stats, and discussions with the client about their industry, that bigger screens were more common in their audience than for other sites, and had to be properly accommodated. After all, their peers, competitors and clients are video professionals working at the highest levels of detail. But this was unprecedented – 4K! That’s 3840 x 2160 pixels, the area of four “full” HD screens.
Fortunately, as we’ll explain, the choices we’d made in building the site meant that the leap to 4K didn’t mean going back to the drawing board.
The Content
Axis and its sister companies routinely generate content at 1920 x 1080, but it’s clear there will be a move towards 4K if they want to remain at the cutting edge.
The website was envisaged as a showcase for their work, with little content besides – so the images and video relating to their projects had to be presented with the best quality. We therefore chose to emphasise quality over bandwidth usage, whilst being mindful of screen size and pixel density.
In practice this meant delivering images that would be
- suitable for retina display where appropriate,
- generally scaled down not up,
- whilst retaining the flexibility to scale up when larger sizes were not available (i.e. above 1920 wide).
However, we also wanted a seamless transition to using those larger images should they become available in future.
We also used Scalable Vector Graphics (SVG) for logos, and icon fonts where possible to ensure rendering at the highest quality.
The Content Management System
Previous research had identified Processwire as a candidate Content Management System (CMS) and on further investigation, we were happy to select it for the project. Some of the stand-out features:
- On-the-fly generation and caching of resized images by simply requesting a required size.
- Developer-friendly, with a rich and well documented API.
- Client-friendly management interface.
- Easy specification of arbitrary content types, their fields and connections.
- Open plug-in architecture, with a range of pre-existing modules and the ability to build your own.
- Flexible templating.
All three sites are hosted in the same instance, using a modified version of the multisite plugin, allowing a mix of shared and site-specific content.
Images are uploaded at the highest quality, with all required sizes and thumbnails generated automatically on first use and then cached. This makes it easy to create a range of sizes on-the-fly to use as sources for the picture element (see below), accommodating various screen sizes and retina displays with ease. A modified version of a pre-existing image cropping plugin was developed to allow custom thumbnails where required.
Videos are hosted on Vimeo pro accounts, that have access to the underlying source file URLs at different sizes via an API. This let us develop a custom field type for Processwire that takes a Vimeo URL and retrieves the URLs of the available versions – usually four ranging from mobile to HD size.
Site editors have found it simple to upload content that just works, without having to care about image resizing, thumbnail generation, or different video sizes – and they can also tag and categorise content easily.
The Framework
For the front end of the site, we selected Foundation as a framework. There was a pre-existing starter kit of templates for Processwire to build on, but Foundation is also one of the best responsive frameworks available, allowing us to easily create flexible layouts with breakpoints that could be modified to suit our requirements (including one for 4K!).
It was rumoured that the first responsive Apple website, which launched around the same time, was based on Foundation.
The <picture> Element
Around the time that we were working on the sites, the
picture element was finalised for inclusion in HTML5. Chrome support was almost immediate (if only in the very latest version), and a polyfill exists for other browsers – picturefill.js.
The picture element expands on the <img> element with multiple sources, using CSS media query-like breakpoints to specify which source should be used. This means the browser only needs to download the most appropriate image for its screen size and pixel density, solving the issue of mobile browsers downloading desktop-sized images.
The code below shows a picture element for the largest image size on one of the sites (note the IE conditional comments make IE9 play nicely with picturefill.
<picture>
<!--[if IE 9]><video style="display: none;"><![endif]-->
<source srcset="/site/assets/files/1457/drak_06.710x399.jpg, /site/assets/files/1457/drak_06.1420x799.jpg 2x" media="(max-width:710px)">
<source srcset="/site/assets/files/1457/drak_06.1024x576.jpg, /site/assets/files/1457/drak_06.2048x1152.jpg 2x" media="(max-width:1024px)">
<source srcset="/site/assets/files/1457/drak_06.1920x1080.jpg, /site/assets/files/1457/drak_06.3840x2160.jpg 2x" media="(max-width:1920px)">
<source srcset="/site/assets/files/1457/drak_06.3840x2160.jpg" media="(min-width:1921px)">
<!--[if IE 9]></video><![endif]-->
<img srcset="/site/assets/files/1457/drak_06.jpg" alt="">
</picture>
There are four sources, each with a 2x retina version specified (except for the 4K width, though that could be easily added in future!). The sources correspond with breakpoints in the responsive layout, and media queries specify which should be used. These have been set to ensure that as soon as the screen size is larger than the image, the next size up is chosen so as never to sacrifice quality (ie, images should never be scaled up by the browser).
With the CMS generating the required image sizes automatically, this is very straightforward to implement. Styling is still applied to the <img> element, and picturefill takes care of browser compatibility. The only gotcha was that when dynamically loading images (eg for infinite scrolling) you have to re-call picturefill to handle the newly-loaded content.
The Videos
Video.js was chosen as the video player for the site – it provides a common interface to either an HTML5 or Flash-based player (for older browsers) and is easily customised.
Our custom CMS field type stores the URLs for the available video qualities, and these are delivered to the front end in a JSON object. This lets us use Javascript to choose the most appropriate version for the current screen size and pixel density, again erring on the side of quality. This could be made more sophisticated – perhaps attempting to detect playback issues and switch to a lower bandwidth version if required.
The Results
All three sites are now live, in their first iterations, and you can see the results on the links below.
The Conclusion
Affordable 4K monitors are available right now, and even if there is not a rapid move towards such larger screens, the move towards higher pixel density ones is already well underway – the new 5K iMac exemplifies both of these trends, and retina displays on mobiles, tablets and laptops have become relatively common in newer models.
The inevitable increase in content creation for such displays, means that we must be able to build websites that showcase that content in the best way possible. The ability to generate content at different sizes in the back end, alongside the ability to present the most appropriate content version with a flexible layout in the browser are key, and the techniques described above will only become more relevant in time.