BBC Programme pages: content driven responsive redesign

Technical Development Lead

Tagged with:

I am David Marland, Technical Development Lead for bbc.co.uk/programmes.

Since October 2007 /programmes has been a continuous rolling archive detailing BBC Programme information for TV and Radio. The central BBC programmes data store (PIPs) has accumulated over 1.6 million individual episodes and /programmes surfaces a page for every single one. This means a permanent URL and historical record, even after they have stopped being available to watch or listen. Some programmes have had special attention and have a complete archive going back even as far as 1942.

/programmes publishes a vast amount of content with pages such as (deep breath): brands, series, episodes, clips, episode guides, broadcast histories, galleries, credits, tracklists, chapters, character profiles, contact details, live blogs, collections, seasons, day schedules, week schedules, a-z lists, programme search, categories and even experimental QR codes.

All of this makes /programmes a big project, but it is not a BBC brand in its own right. Visitors don't generally arrive on the homepage, but rather The Voice website, The Archers website, Doctor Who or the Radio 4 schedule. /programmes is intended to invisibly power these brands, which is achieved through extensive collaboration with teams from all over the BBC.

What's new today

As of today the homepages for individual programmes, known as the brand page, have been relaunched with a new design. This design is responsive, making it flexible for all devices and joins the A-Z, Category and Schedule pages that were built this way last year.

A programme page on different devices

The main change is that the new brand page has a clear area at the top showing how to find the latest episodes. Previously the information in the top panel would move around as episodes became available or expired. The new panel has clear boxes for On demand (iPlayer/iPlayer Radio) and Next on (upcoming broadcasts on TV/Radio). These panels will not move, even if they are empty. Previously many visitors would keep searching the page for available episodes, even when there weren't any to find. Now the answer is given immediately in the same space. Links to related podcasts, clips and even information on how to purchase have been promoted to this area allowing you to always find some way to enjoy the programme. A greater emphasis has been placed on new programmes, with a "New Series" flag on TV indicating when something is fresh.

The brand page is a fully responsive page, meaning it fits no matter how wide your screen is. This is necessary with the explosion of mobile and tablets in the marketplace. 39% of visitors are now arriving from these devices (mobile 24%, tablet 15%) and we have to ensure the pages are suitable for all. The pages are touch friendly with larger hit areas for links, swipe-able carousels and no content in hover states, but they are not touch-priority. The detection of a touch capable browser doesn’t mean touch is in use, so all interfaces must support both scenarios.

Soon we will be rolling out the remaining pages as part of this responsive rebuild. /programmes releases updates to the site every two weeks so there are always tweaks and improvements happening.

How we built it (the technical bit)

It wouldn't be possible to build and maintain a website so big without a framework and some principles. Once this system is in place new pages can be constructed in a very short period of time, and automatically match the look and feel of the rest of the site.

Our intention is to build a website using content driven, progressively enhanced, responsible web design.

Content Driven

/programmes is built from the URL upwards. It important to know which content truly belongs on a page, especially when building a responsive page. If some content can be sacrificed on mobile due to lack of space, then it has to be questioned whether it belongs on the desktop too. We look at the content and see if it has a canonical URL of its own. If so then by default we show a link to it and if there is enough space on the page we may choose to lazy load the content with JavaScript. This is strictly only used on content that has a page of its own. Mobile users and those without JavaScript MUST be able to able to get to the same content.

The latest clips carousel on the Silk brand page

The example above is the latest clips carousel on the brand page. The brand page URL is http://www.bbc.co.uk/programmes/b01hzsch. The carousel is a way of showing a sample of the most recent clips for that programme, but there is already a page that has that list  so by default the brand page will just show a link that page. If there is room JavaScript will bring the first 6 items from the list into the main page. As the clips box is generally outside the initial viewport this usually happens before the user has seen it.

The benefits of this approach is that the initial page download is much faster as we don't have to prefetch the content to generate the whole page, and we are sending less data to the user in the first response. This also helps where /programmes can't rely on caching to be fast. Due to the archive nature of the site you don't have to navigate far before you're on a page nobody has visited recently and it will be noticeably slower to load. By requiring less data in the first request we can help speed up requests where caching alone is not enough.

On the brand page this lazy-load technique is used for the "Clips", "Galleries" and "You might also like" boxes. Promotions (high priority links to key content) do not use this technique as they do not have a home of their own. Their home IS the brand page, so they are there from the beginning.

JavaScript is used, but as a light touch and is NEVER as a core requirement of a page. Any link that is activated through JavaScript must work without it, which also has the benefits of allowing all links to be opened in a new tab. Using href="#" in links is not allowed.

Images

Images are generally the largest source of download size for a webpage and on responsive webpages images of several sizes are needed, due the the unknown sizes of the containers they may be in. We have taken the "Content driven" approach to images too. On aggregation pages containing many links to programmes the core content of the page is the list of links to other pages. As the canonical home of each image is the programme page, having it in the aggregation page is a visual enhancement. Therefore by default these aggregation pages don't display an image and the image of appropriate size for the current container width is loaded in via JavaScript. Also, only the images that are currently visible are loaded. As you scroll the page, the images you are about to reach are pre-loaded. This has the benefit of only downloading images that you view, which can save up to 1MB on longer pages if the user doesn't scroll. A similar technique is also used by the Responsive News team, who have open-sourced their solution as Imager.js.

Icons are another source of images that could use bandwidth, so for iconography we have chosen the route of an Icon Font. The main benefit is the core set of GEL icons is just 8kb to download. All the icons can then be used multiple times on a page, at different sizes and in different colours, without incurring further downloads.

CSS

We have setup a CSS framework making extensive use of Sass. This has allowed us to build CSS in a very modular way, creating vast amounts of reusable code. We follow the BEM syntax, which does introduce extra markup into the HTML. However this is mitigated as the back end system allows the HTML to be generated easily and gzip is highly efficient at compressing repetitive HTML. The modular components we use are detailed on the /programmes Styleguide, which describes common patterns across /programmes. Re-using these patterns makes building a new page from scratch very fast and minimises the need to write additional CSS. The /programmes global.css is currently only 15.4kb after gzip and this powers everything regarding layout so far. The remaining responsive pages shouldn't need to increase that too much further.

CSS modular components

Our CSS is constructed "mobile-first" with media queries defining breakpoints for changes in layout where needed. Continuing with our "Content driven" approach, we allow tweakpoints outside of the main set of breakpoints if an individual component needs to make some adjustments in its own design.

Sass allows us to easily support both old and new browsers. Internet Explorer 8 and below do not support media queries, and therefore cannot do proper responsive pages (without a JavaScript-intensive polyfill). We use a Sass component named Breakup that allows us to name and wrap blocks of media queries. We can then generate a separate stylesheet for IE8 and below that serves the "desktop" set of media queries unwrapped. This means there is no need to write the code twice for different browsers.

By following these principles we have rebuilt /programmes pages to be robust, semantic, accessible and future-proofed for devices we don't even know exist yet. The codebase is maintainable and scalable to support the vast size of the site as it grows even further.

As we rollout responsive views of the rest of the page types remember to take a look at the evolving styleguide and keep an eye on the ever expanding archive.

David Marland is Technical Development Lead for bbc.co.uk/programmes.

Tagged with:

Loading...

More Posts

Previous

Next