We’re building the new Lloyds.com

It’s now public that we’re building the new Lloyd’s of London website. The news went up on Aqueduct’s blog last week.

Progressive enhancement

This site is pretty feature rich and has been a lot of fun to put together so far. It has been very important for me to keep to good web standards and to make sure the front end is accessible to the broadest audience. We’ve used the progressive enhancement approach and built a rich interface on top of an underlying no-javascript-required base.

More info

The site is looking to launch in 2010, more info at http://www.aqueduct.co.uk/blog/2009/12/were-building-new-lloydscom.html

Javascript development and deployment strategy – Part 1

With the popularity of JavaScript rising significantly the amount of code within one project has grown to the extent where it needs to be separated in to separate files unless you want to be scrolling through thousands of lines of code. Whether you do this per class or namespace is another debate but I have been thinking through how all these separate files might be combined appropriately and compressed at deployment.

I have decided to itemise what I would ideally want to achieve and maybe some thoughts on how i could do it.

1. I want to be able to split code in to appropriate sections so that i can save them across multiple files.
   • this will make it easier to find code
   • this will make code more modular and help to debug
2. I only want one script reference within the html file even at dev time
   • i don’t want to annoy the back end devs with the hassle of different versions of the html head area
   • i want to manage easily the order in which scripts are loaded and which scripts are grouped together.
   • i want the dev to mimic the live environment as closely as possible
3. I want a system which is flexible enough to allow me to specify which scripts get combined on deployment
   • if there are sub sections to the code which change more frequently to others i don’t want the client to have to download the full whack when something small has changed
4. I want this to be extremely painless to implement
   • pain is not that desirable to me

With these four requirements in mind I set about my strategy and have come up with this:

1. a root file for each set which at dev time dynamically adds the linked files to the page
2. You can have as many root files as you want and you only need to maintain one list of links within each root file.
3. It only takes 3 very simple steps:
   1. copy and paste short section of standalone code in to a root file
   2. set the root file js name
   3. include a list of files which will be combined on deployment

In part 2 I will give a demonstration of this in action.