主播大秀

I am David Marland, Technical Development Lead for .

Since October 2007 /programmes has been a continuous rolling archive detailing 主播大秀 Programme information for TV and Radio. The central 主播大秀 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.

/programmes publishes a vast amount of content with pages such as (deep breath): ,, , , , , , , , , , , , , , , , , , and even .

All of this makes /programmes a big project, but it is not a 主播大秀 brand in its own right. Visitors don't generally arrive on the , but rather , The , or the. /programmes is intended to invisibly power these brands, which is achieved through extensive collaboration with teams from all over the 主播大秀.

What's new today

As of today the homepages for individual programmes, known as the , 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.

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 in the same space. Links to related and even information on 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 , 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鈥檛 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 example above is the latest clips carousel on the brand page. The brand page URL is . The carousel is a way of showing a sample of the most recent clips for that programme, but there is already 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 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 , who have open-sourced their solution as .

Icons are another source of images that could use bandwidth, so for iconography we have chosen the route of an. The main benefit is the core set oficons 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 . This has allowed us to build CSS in a very modular way, creating vast amounts of reusable code. We follow the , 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, 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.

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 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 evolvingand keep an eye on the ever expanding.

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