Barlesque: Going responsive
Post categories: 91Èȱ¬ Online,Ìýmobile
| 12:15 UK time, Thursday, 15 November 2012
Hello I'm Dan Forys a software engineer in the Future Media Platform team. I work in a small team dedicated to front-end frameworks and libraries used by the rest of the 91Èȱ¬. One of those frameworks is Barlesque.
Ostensibly Barlesque is the header and footer of most 91Èȱ¬ web pages. In reality it's a framework providing global templates, styles and modules.
It currently provides three main versions - a 'Legacy' version for older pages, a fixed-width desktop version and a mobile version - 'Mobilesque'.
Mobilesque
Today, delivering two different versions of a page for mobile and desktop is not always desirable. There is a development overhead to creating and maintaining two different codebases and users don't want to learn different interfaces on different devices.
Also, increasingly there is no clear delineation between what constitutes a mobile device and a desktop device. Supplying a 'desktop' experience with a (normally) higher download weight to a netbook on a train with poor connectivity might be a poor experience, even though it is equipped with a desktop-grade browser.
Similarly, a connected TV - whilst not physically mobile - might have poor browser support for a desktop-grade experiences.
As a result there are many teams now working on device-agnostic and Barlesque has to work in a similar way.
Because Barlesque is the 'glue' that binds the page together with every other team's products we need to be one step ahead to deliver optimal experiences, whatever the device.
With this in mind a few months back we started developing a new version of Barlesque - codenamed ORB - or 'One Response Barlesque'. The One Response referring to our goal of having a single, cacheable response that will be quick to load on slow devices and connections.
Get ready
Having one response is especially important when pages are delivered through caches or even a (CDN). If we delivered a different masthead for different devices we would need a cached copy for every single variation - potentially making the page completely uncacheable and therefore every request hitting our servers.
We decided to take a 'mobile first' approach. This means we'll deliver the minimum possible code to the browser and then enhance that code on larger screens and more capable devices. The benefit of this is that we don't send code to devices that can't use it.
This meant we had to throw away some of the existing behaviours of Barlesque - no more loading of on every page for example!
ORB has a new, smart menu at the top. As the width of the browser decreases menu items drop out and become part of a bigger drop-down menu.
Similarly, as width increases, items pop back into the main menu. This behaviour isn't tied to any text size or particular width, ensuring that any unusual or future screen sizes will still be catered for. At very small widths the search box and 91Èȱ¬ iD button collapse into icons.
Tabs for the smart menu
In-page there's a new (optional) responsive grid in development by our UX team. There's also a fluid footer which flexes to any width like the header.
I'll go into more technical detail in future posts - but for now here's a summary of some of the techniques and libraries we're using:
- to help us manage our cross-browser rules. We have different stylesheets for some browser widths and early versions of IE. Sass compiles these into regular CSS files.
- CSS rules based on great work in , Eric Myer's and the work done by our very own . Our new rules are optional and designed to be very lean. This will allow products to design as they wish without being constrained to overzealous reset rules or a fixed-width column - both problems with the current Barlesque.
- to provide modular Javascript loading across the 91Èȱ¬. This is how we load JQuery and Barlesque's Javascript enhancements.
- and to help maintain code quality. Every time we commit to our code, we run these tools to make sure we conform to various coding standards.
Right now we're busy porting over some internal libraries around cookie privacy opt-outs, statistics gathering and a way of getting user feedback. We're also testing like mad on as many devices as we can get our hands on. Hopefully you'll start to see the first ORB sites rolling out in the very near future.
Dan Forys is a software engineer in the Platform team in Future Media.
Comment number 1.
At 15th Nov 2012, Mark Stickley wrote:Nice work. Too many responsive designs and implementations are actually just adaptive to fixed breakpoints and conditions. It looks like this covers all bases & setting a fine example!
Complain about this comment (Comment number 1)
Comment number 2.
At 15th Nov 2012, Nikos Tsouknidas wrote:Thanks for the post Dan; best sum-up of all the work we've been doing.
Get excited, it's coming.
Complain about this comment (Comment number 2)
Comment number 3.
At 15th Nov 2012, Mo McRoberts wrote:I should probably already to know the answer to this, but will you be able to get the responsive Barlesque when using the webservice?
Complain about this comment (Comment number 3)
Comment number 4.
At 15th Nov 2012, Dan Forys wrote:Hi Mo - Yes, full webservice support. It's already up and running actually!
Complain about this comment (Comment number 4)
Comment number 5.
At 18th Nov 2012, Nick wrote:This comment was removed because the moderators found it broke the house rules. Explain.
Complain about this comment (Comment number 5)
Comment number 6.
At 22nd Nov 2012, Dan Chambers wrote:Great post Dan, I particularly like the point you raise about there being no clear delineation between what constitutes a mobile and desktop device.
Would be good to hear your thoughts on taking ORB up to a TVP/HD experience and what that might mean in terms of implementation and level of complexity in terms of interaction methods? (remote control, keyboard, iPad/iPhone, kinetic input etc.)
Thanks,
Dan
Complain about this comment (Comment number 6)
Comment number 7.
At 26th Nov 2012, Henry Bemis wrote:Nice. The new smart menu looks very much like the Android Action Bar. It's a concept that I think works very well. Nice work and thanks for the post!
Complain about this comment (Comment number 7)
Comment number 8.
At 26th Nov 2012, Russ wrote:The 'show more'/'show less' toggle on programme pages is really infuriating, especially because the full text flashes up for an instant before the script kicks in to show the default truncated version. Seems to me to be a pointless script overhead in loading a page. Sometimes the 'show more' consists of only one extra line.
Russ
Complain about this comment (Comment number 8)
Comment number 9.
At 14th Jan 2013, orchidgrey wrote:This comment was removed because the moderators found it broke the house rules. Explain.
Complain about this comment (Comment number 9)
Comment number 10.
At 17th Jan 2013, Alain Mostert wrote:@Russ - think pre-loading the content is probably a more efficient solution rather than making multiple calls to the server. If anything it might be better design to preload the style completely before loading the content (that way you wouldn't see the full text flash up beforehand).
Complain about this comment (Comment number 10)