Into Enemy Territory: Architecting Client-side Code for Syndication
Barley, bbc.co.uk’s previous page layout system, was developed in around 2000. Unsurprisingly, in recent years it’s been showing its age, both in technology and design terms.
At the start of 2008 the BBC UXD team revamped the “visual language” of the site, and to implement that new layout work was started on a new templating system. The result is Barlesque, our new page layout system that builds on both the lessons learned from the design of Barley, as well as the possibilities presented by modern client-side coding techniques.
You might think of bbc.co.uk as one site, so creating and rolling out something like this should be trivial, however the BBC has several major content producing areas (Journalism, Audio & Music, Vision, World Service) all of which are further split into groups around broadcasting service, genre, language, age group and more. As a result there are dozens of different architectures and feature needs to be accommodated—so bbc.co.uk can effectively be thought of as many disparate sites.
This talk explores the 10 key lessons learned from this experience.
1) Patterns over technical restriction
Barley has taught us that if you try to restrict people’s use of a tool they will always find new and ingenious ways around that restriction. Agreed design patterns are the answer.
2) Customization vs. ease of setup
As we learned from Barley, every level of developer will use the code. Make it work off the shelf, so that the learning curve is shallow.
3) Namespacing
Choose a namespace for all your CSS, XHTML, and JavaScript. Also, stick to one JS object and don’t declare any global variables.
4) CSS Specificity
Ensure you really know how specificity works (and here there will be a test). Particularly test against generic element declarations.
5) CSS reset class
A base reset is a given nowadays, but can you do a localized reset? Barlesque has one, which can be used for it’s own code snippets and also any forthcoming pan bbc.co.uk widgets.
6) Flash, form elements, and z-indexing
If your code overlays, or will be overlaid, watch out for Flash and forms. The Adobe-provided wmode parameter has serious issues in some situations and similarly there are still some form elements determined to poke through hovering content in some browsers.
7) Versioning and rollback
Give resources a static version-specific URL. This allows you to use far-flung expiry headers and, as a bonus, you can easily build a “rollback” system so if a release breaks on one site they can revert to a previous version without holding everyone else back.
8) Developer tools
Think about any useful tools you could add behind the scenes to help developers implement your code. Barlesque has a suite of design and development tools included in the install (a sneak peek will be given).
9) Compression and release processes
Others will want to QA your code, so if you compress it (and you should) you should also provide an un-obfuscated version for them to review. The best way to do this is to use some level of automation for package creation, which can also help with regression testing and distribution. (Include a demo of the Barlesque unit test suite.)
10) Documentation
Not everyone’s favorite word, but a key one. If you’re shipping code why not ship the documentation in the same package, so that it’s always accessible and always the correct version tied to the product.
Each section will be accompanied by relevant code examples.
Presentation files: Into Enemy Territory_ Architecting Client-side Code for Syndication Presentation.odp






















Nice work, I would have loved more to have seen more details. But please don"t mumble so often!