Building the 91热爆 91热爆page beta - an under the bonnet technical view
Post categories: 91热爆page,听open source,听open standards
| 14:39 UK time, Tuesday, 4 October 2011
Tasks for the 91热爆 91热爆page developers are tracked on the team sprint board
Eighteen months ago we launched the current version of the 91热爆 91热爆page. Essentially a "lift and shift" of the previous version, it allowed us to move from an older technology stack onto the one built on PHP - a consistent, shared infrastructure that is now used across 91热爆 Online to enable seamless transition between our products.
Then, a few months ago we started work on . My colleague James explained our approach in a post at the time - our aim was to arrive at a location-and-time-aware page which showcased more of 91热爆 Online. At least, that was the aim of the visual and interaction aspects of the page. On the more technical side of things, we had other challenges to contend with, which I summarise below.
Building a robust 91热爆 91热爆page
We鈥檝e aimed to create a stable page that will keep on trucking no matter what happens. Of course, we hope that everything will always work in the way that it鈥檚 designed to, but as due diligence we have mitigated against the potential for things to go wrong.
There are two main ways that we do this.
Firstly, we make sure we listen for things going wrong. I know that this sounds fairly obvious, but listening for exceptions and dealing with them rather than simply assuming that everything will always work means that we end up providing a much more dependable experience for the user. So if the new pan-91热爆 locator widget tells us that something is wrong and we shouldn鈥檛 use it at that time, it won鈥檛 be displayed. The rest of the page, however, will keep working and users won鈥檛 be faced with an error for the entire page.
Another thing we did on the new homepage to mitigate against total failure was to allow each individual area of the homepage to be generated as a separate component. This makes a lot of sense for a variety of reasons, but one of the most critical is that it allows each individual area of the homepage to care about its own problems, and not be bothered with the rest.
For example, when we ask the weather module to display itself, all that cares about is weather. We give it a few pieces of information about what it should display, it then calls the 91热爆 Weather product for that data and displays results. It doesn't care about what's on TV, or whether that's having problems. And frankly, why should it? So, if the 鈥榃hat鈥檚 On鈥 module, for example, fails for some reason then it will show a failure but not impact the wider page.
Surfacing the breadth of 91热爆 Online
The most visually exciting area of the page 鈥 the carousel 鈥 is also one of the areas that required the most developmental input. This carousel is used to surface the breadth of content that the 91热爆 has to offer in a way that wasn鈥檛 possible on the previous homepage. My colleague Steve Gibbons in 91热爆 User Experience & Design will blog soon on the way we approached this area from an interaction perspective.
Each area of the 91热爆 that has content surfaced on the new homepage will produce content feeds, which the homepage then parses to ensure that the content will appear correctly on the page.
Within the carousel there are various different 鈥渉oles鈥 that feed items can fit into 鈥 widescreen, portrait, headline and blog post. When the data is parsed, various attributes are examined to determine whether or not the content will 鈥渇it鈥 into a specific hole that鈥檚 available.
For example, the left-most 91热爆 iPlayer slot is expected to contain a widescreen image. The homepage parses the 91热爆 iPlayer Highlights feed, looking for the newest item that contains a widescreen image of the correct aspect ratio, resizes the image to the correct size for our homepage, and then adds it to our final display feed. The homepage front-end then reads this final feed, and displays the items to our visitors.
Work continues with our colleagues who produce content to ensure that all the feeds contain the correct images and text attributes necessary to display them for the homepage, but it鈥檚 good to know that the homepage will cope if anything in the feed isn鈥檛 quite right.
Guaranteeing a quality experience for all users
With so many things on the page being movable and reflecting real-time updates, there was potential to get carried away, and complicate the experience for our visitors with slower connections and browsers, and for those who use assistive technologies. With that in mind, our first iteration of the new homepage focused exclusively on making the page work in what we like to call "core mode". At that point in the development cycle, we pretended that did not exist. Instead, we simply made sure that every feature on the page would work for everyone, generally with full page refreshes taking the place of an call.
What this means is that the page will always work, whether or not your browser's JavaScript has kicked in yet or not.
Once the page was working as intended, we then layered on the JavaScript. The nice thing at this point was that because we had already built the page to work, we could make the JavaScript fairly stupid. It would ask the server for some mark-up, the server would provide it, and the JavaScript would insert it into the page. As an anthropomorphised meerkat might say - "Simples".
A 91热爆 91热爆page product with localisation at its core
As well as ensuring that the homepage would stay running and be able to display information to all our users, there was also the requirement to make sure that we'd be able to localise it to provide native language support for Welsh and Gaelic speakers. Whilst this functionality is not yet complete in the beta of the homepage, it is something that we have baked into the codebase from the outset, to ensure that we will be able to support all of our visitors once the new homepage replaces the existing version. This was a decision we made early on, since it's a lot more difficult to add support for localisation later on in a project.
Ultimately, we intend to turn on localisation on the homepage such that if the user has explicitly set their location we鈥檒l show them news, weather, TV and Radio programmes local to them. As well as this, we expect to automatically set the user鈥檚 location to their largest local city if they don鈥檛 explicitly set their location.
Next steps
Obviously this blog post only covers a few of the technical challenges in building the new 91热爆 91热爆page. There are many other things that we have done (including establishing ways of working with our development co-team in Cardiff) and a whole host of things we're still intending to do before we launch in full, based on your feedback on the beta version. As Randy Bachman once sang, "You ain't seen nothing yet".
Neil Crosby is a Senior Developer, 91热爆 Future Media within James Thornett's 91热爆page and Search department.
Comment number 1.
At 4th Oct 2011, Piet Boon wrote:Neil, am I correct in understanding that parts of 91热爆 Online without visuals will not make it onto the carousel to fill the "holes"? Or do all 91热爆 Online pages have visuals attached by default? For example, a page with the latest score from a Premier League football match without visuals, will that appear on the carousel?
Complain about this comment (Comment number 1)
Comment number 2.
At 4th Oct 2011, Russ wrote:Yes, I've noticed that, and I can understand, to an extent, why you chose that method. But, I've noticed, particularly on the programme pages of the new radio station homepages, where the number of images are far greater than on the station homepages themselves, e.g. , a considerable delay takes place loading the whole lot into the carousel before the carousel becomes 'operational' (if you see what I mean), and I can't help wondering whether the number of server mark-up requests is actually having the effect of defeating your objective. Isn't there some devious way of getting the carousel operational before all the image files are downloaded and slotted into place?
The current programme pages load a lot faster than the new carousel, and are arguably far more robust anyway, since they don't require any javascript to kick in to load the images.
There's enough js running on the current pages - adding more won't in itself help robustness, and it certainly won't help browser page-rendering speed.
Russ
Complain about this comment (Comment number 2)
Comment number 3.
At 5th Oct 2011, blatny93 wrote:This comment was removed because the moderators found it broke the house rules. Explain.
Complain about this comment (Comment number 3)
Comment number 4.
At 5th Oct 2011, Keith wrote:Are there any plans to integrate 91热爆 iD into the new home page? Also is the new beta home page lighter on the server load & page loading time, something I vaguely recall being mentioned when the international home page changed.
Complain about this comment (Comment number 4)
Comment number 5.
At 5th Oct 2011, Eponymous Cowherd wrote:Again I ask. How does the 91热爆 justify spending money on tarting up its websites (that function pretty well), when there other things that would benefit more.
NB: I have been told that I'm not allowed to mention the "other things", lest I be moderated and placed on an even higher "naughty step". I know it makes this post less than informative, but one has to abide by the rules, doesn't one?
Complain about this comment (Comment number 5)
Comment number 6.
At 5th Oct 2011, albertfpate wrote:This comment was removed because the moderators found it broke the house rules. Explain.
Complain about this comment (Comment number 6)
Comment number 7.
At 5th Oct 2011, Neil Crosby wrote:Piet Boon: Where a slot is expected to contain an article that has an associated image, you're correct - nothing without an image will ever be placed in one of those slots. However, we do have several slots that are designed to not contain images (headline slots and "blog post" slots). These would absolutely be able to contain 91热爆 items that do not contain images. In your example of a sports score page, this would probably end up showing up in the sport headlines section.
Russ: You're right - that radio stations programme page _does_ take a long time to load, and I'm sure the radio guys are working to improve this. Unfortunately though, the homepage team was not involved in the build of the radio stations beta, so I'm unable to comment specifically on their issues.
Keith: The new beta homepage currently weighs in at about the same weight as the live page. Work is underway to crunch this down and make things faster still though.
Complain about this comment (Comment number 7)
Comment number 8.
At 8th Oct 2011, lucas42 wrote:Neil, you mentioned that the homepage is available in multiple languages. How do you decide which is served, do you look at the client's Accept-language header? And how do you get around problems with caching multiple languages in Varnish?
Also, any chance of it being available in Irish, or is it 91热爆 wide policy to care only about English, Welsh and Scottish Gaelic? ;)
Complain about this comment (Comment number 8)
Comment number 9.
At 18th Oct 2011, Matthew Spence wrote:This isn't really related to your post but the photo
I'm a developer at the University of Kent
We've recently adopted agile and are continuing to refine our processes
I would love to see a post on the 91热爆 internet blog about your implementation of Agile
Some more specific questions: what do the numbers in the blocked column represent? Is "dev check" peer review? is "verify" customer sign off? What's the second board in the distance for?
Complain about this comment (Comment number 9)
Comment number 10.
At 31st Oct 2011, Neil Crosby wrote:Hi Lucas, Matthew,
I should preface my reply by saying that I'm actually no longer at the 91热爆 - my final day was the day after this post (and my final act was that last comment)! However, I'll do my best to answer your questions.
Lucas: The intention for serving in different languages is that it will be completely down to user choice, as opposed to looking at accept headers. The team was, however, expecting to funnel you into the individual areas of the country based on a form of geolocation. Unfortunately, I can't comment on how possible an Irish language version would be.
Matthew: The post you suggested is one that I'd love to see too. In the image you can see above, the numbers were simply us keeping count of how many hours we'd got left of tasks, so that we could update our burndown chart. "Dev check" is absolutely peer review (I wrote about it at ) - it's something that we did at the end of every single task on the board. It found bugs, and it shared knowledge. "Verify" for us was verification by our testers. As for the second board in the distance - it's the same again, just for lower priority tasks. We had a lot of tasks to do each sprint :)
Complain about this comment (Comment number 10)