What is The Cookie Law?

As an addition to the marketing opt-in law The Cookie Law states that website owners should request user consent before setting cookies on their machines. 

Not all cookies are affected, cookies necessary to the good working of your website are not e.g. cookies used to remember a user shopping basket or session cookies containing vital information to provide a requested service e.g. remembering a user location for a property search.  

All other cookies are affected including third party cookie such as analytics, campaign tracking, advertising cookies etc

How to comply with The Cookie Law

You need to assess the cookies used on your website and sort them between essential and non essential cookies. If you have non essential cookies (very likely) you then need to define a user consent strategy with your user experience, designers and developers or your agency. There are many ways to implement obtrusive and non obtrusive cookie consent devices. 

The ICO website (http://www.ico.gov.uk/), the body charged with enforcing the cookie law has implemented cookie user consent on their site. 

Are you at risk of being fined?

Although the European cookie law is already in place and active is it not yet enforced but will be by end of March next year so you need to plan your website changes now. Fines can be heavy but are unlikely to be handed out if you have started the process of implementing user consent for cookies on your website by May 2012. 

The cookie law is not an option so you'd better start tackling it now. 

If you have any questions about the cookie law or wish to discuss its implementation with us please contact rob@aqueduct.co.uk

Some of our clients find it difficult to understand why it can be tough to run multiple projects on one code base and that we can spend some time 'merging'. 

At Aqueduct we branch aggressively, we follow the 'no junk in the trunk' rule and create branches for every project or new feature. This allows us to support the current live code bases (trunk) whilst safely developing other features or projects (branches). 

However this can comes at a price, too many branches or very lengthy projects and we end up with merging headaches. 

Indeed before we can do a release we need to merge the branch code back in the trunk, there will be conflicts, and there will be more the longer it took for the branch to get developed and signed off. 

To save time and money we do two things:

• We limit the number of branches for a code base to 2, add the trunk and that makes a maximum of 3 code bases to manage
• We only branch and develop once every user story is signed off and the project scheduled to reduce the time the branch lives and therefore the number of potential merging conflicts 

There are many other ways to manage source control (Facebook and twitter are notorious for not using any branching) but in our agency we deal with many projects, different environments and code bases and we find that 'no junk in the trunk' works well and limits human errors and bugs.