1. The Internet’s Lost Colours

    A short interlude into why Facebook is blue, why I never know if my football team has lost or won, and how a simple tool is going to save your client thousands of pounds.

    Growing up I never realised that I had a colour vision deficiency. Diagnosed with Deuteranomalous when I was very young, it didn’t limit me in any way; I just didn’t notice. In all honesty, I had forgotten about it until now.

    A few days ago, during our daily team banter, one of our technical directors mentioned a free simulator visual deficiency tool called Color Oracle. The tool simulates in real-time how people with a colour vision deficiency see. I was fascinated mainly because I vaguely remembered that I might be colourblind.

    I took an online test called Ishihara (I recommend you try it out, it only takes a few minutes). Within minutes it confirmed my forgotten truth – I am colour blind. Staring at test plate after test plate, I couldn’t see the numbers, with my colleagues looking on perplexed and with interest.

    At Cohaesus we get to implement the carefully crafted designs and UX of many leading agencies but I am not sure colour-blindness gets the consideration it deserves.

    We all know that building highly accessible websites is best practice, but how many designs are tested using tools such as Color Oracle? Not many is my guess.

    A good example of missed testing is from the BBC – somewhat surprising given their reputation for championing accessibility.

    image

    Above: Normal colour vision

    image

    Above: Deuteranopia vision via Color Oracle

    The table is quite clear and I can read all the information easily. The problem occurs for me when I view the last 10 games played by each team. I cannot clearly view the difference between the colours red and green used in the table. The indicator icons used are way too small, resulting in low contrast for someone with a colour vision deficiency like mine.

    Another example that affects me when visiting websites is in selecting colours with colour-picking tools (e.g., personalising the design on Twitter). Did I really want the colour I selected, or select the colour I wanted?

    Online forms can also affect me when incorrect or incomplete fields display errors using red or green text. The impact of ignoring color deficiencies starts to ramp up in these scenarios.

    Now you might be thinking “What’s the problem? After all, it’s only a few people.” But actually, the numbers may surprise you. Colour Blindness is very common globally, with 1 in 12 males and 1 in 200 females being affected. According to Colour Blind Awareness, almost 2.7 million people in Britain (4.5% of the total population) are colourblind; of which the majority are males. Apply this to the recently released figures for Q4 2013 by Office of National Statistics, which show 87% (approximately 44.3 million) of the UK’s adult population use the internet, and that’s roughly 2 million internet-users who are colourblind in the UK – all of whom will face difficulties when visiting websites.

    What’s the cost?

    Assuming you have some type of funnel, arbitrarily your abandonment figure is 60%. Up to 4.5% of that could be due to issues with the experience related to color blindness. Assuming 10,000 visitors start the funnel, that is approximately 270 lost conversions!  

    Now this is some napkin maths. But for a few minutes of extra effort integrated into your design and build process, you could potentially recover a significant amount of revenue for your client. Obviously, your mileage will vary.

    The fix?

    Simply add a tool like the Color Oracle into your standard usability testing. If you are a project manager/producer, add it into the UAT testing too, just to make sure. Most fixes are pretty simple to implement and better done before go live.

    Oh, and why is Facebook blue? It turns out that Mark Zuckerberg is colour-blind.

    Author: Deepak Ark.

  2. Yikes! We entered the Sport Relief London Mile!!

    We are really excited to announce that part of the Cohaesus UK team will be participating in the Sport Relief 2014 event on Sunday 23rd March at Queen Elizabeth Olympic Park. Sport Relief is the biggest fundraising event in the UK designed to bring the entire nation together to participate and raise funds for people who aren’t as lucky as us both in the UK and other parts of the world.

    Our team will take part in the running event called ‘The London Mile’. Given the options of running 1, 3, or 6 miles, we all must be crazy as every team member has chosen to run the longest run of 6 miles! Our target is to raise £1,000.

    We all know it isn’t as easy as it sounds, so preparations are well underway to ensure the event is completed by everyone. We are really looking forward to the run and knowing that we can contribute to make someone’s life a little better.

    Please do sponsor us, via our Cohaesus team mile page: http://my.sportrelief.com/sponsor/cohaesus

  3. Which Web-Design Trends Will Rule 2014?

    image

    There are many elements to a great design. A sure-fire way to make your site look clean, contemporary and up-to-date is to jump on the bandwagon and copy a trend that’s being used by the top brands.

    In this article, we’ll take a look at web-design trends that are likely to dominate 2014. They may not all be entirely new, but they are all highly likely to reach mass-usage this year.

    And if you think we’ve missed out any key trends, please feel free to leave your tips in the comments below.

    Flat Design

    Flat design has been around for a while. In fact, Dieter Rams’ designs since the ‘70s follow many of the same principles. Said principles have been in use in digital for the last few years, with Windows 8 as the stand-out example.

    However, it really didn’t reach trend status until apple released iOS 7; now a significant proportion of the PSDs we’re sent by our clients have dropped the drop shadows and gradients.

    Flat design is non-flashy; the text is concise and to the point; the buttons and links are clear and noticeable. This more minimalist approach can help users easily find what they’re looking for. Making websites user-friendly should be on top of every company’s agenda, and flat design, when used well, can go some way to meeting these requirements.

    Responsive

    We delivered many responsive site-designs throughout 2013, and the tools and methods to build them have matured in a short space of time.

    It’s difficult to say that this is a ‘trend’ in a way (or limit its influence to one year) as it such an important development. Retailer John Lewis recently reported that over a third of their web traffic on Christmas day 2013 was from mobile and tablet devices.

    That said, it’ll still be one of the most important factors being considered in site design in 2014. We’d even go so far as to say that any site built in 2014 that doesn’t consider mobile (which means at least some responsive too) is a failure.

    Video backgrounds

    With more powerful web-browsing devices and faster internet speeds, online video is inevitably becoming more important. This is moving beyond an embedded YouTube player on a page, and seeing video being more deeply embedded into the site experience.

    This trend probably isn’t suitable to serve all types of projects, but we still reckon it’ll be huge in 2014. The Variousways website is a perfect example to showcase what can be achieved with this: http://www.variousways.com/

    Richer content

    Users have higher expectations from websites they visit nowadays. Providing richer content experience will be vital in 2014 to ensure companies can engage well with the audience and continue to attract a high volume of traffic.

    A combination of audio, video and animations along with many other digital elements ‘richer content’ allows web designers to provide visitors with an extraordinary experience. The Kennedy and Oswald website provides a great example of the richer content experience: http://kennedyandoswald.com/

     

    Author: Deepak Ark.

  4. 7 Top Tech Tips for 2014

    What to expect from digital tech, and how it will affect your agency

    image

    As 2014 unfolds, all eyes are on digital tech; with people across the globe eagerly awaiting the newest innovations from one of the world’s most progressive and exciting industries.

    Fierce competition, consumer demand and company pride all drive the world’s leading companies to keep pushing for newer, better technologies – from Amazon’s flying drones to Apple’s iWatch, 2014 certainly shows promise.

    This year, we’ve gathered the highly experienced Cohaesus team to offer their tips on what to expect from 2014, and how innovations might affect agencies.


    Richard Bundock (Technical Director – Enterprise)

    We all dislike corporate IT. When you’re trying to get a project delivered, their slow speed and silod culture tends to drive us and our agency clients mad. Deployments of updates and new projects can be extremely difficult. For 2014, I hope (and predict) to see corporate IT embracing development environments in the cloud, which will reduce a lot of complexity, and some cost, for our agency clients.

    With cloud-based development environments, agencies can quickly get their code deployed into production/staging sites allowing faster feedback and a better service. All we need is corporate IT to embrace and enable this.


    Matt Meckes (Technical Director – Creative Coding)

    2014 will be the year that virtual reality finally breaks through into the mainstream. Although this technology has been touted as “just around the corner” since the ’90s, the latest offerings are finally starting to give a compelling experience.

    We’ve already started to see the potential of combining hardware like Oculus Rift, and gesture-based controllers. A great example in 2013 was PaperDude. We now just need a really smart team to come up with a killer implementation, and the tech will fast find its way into everyone’s living room.


    Mark Pynen (Technical Director – Support & Maintenance)

    Digital currencies and wallets will gain more traction and mainstream acceptance in 2014.  Bitcoin is easily the digital currency with the most awareness as it currently stands; and more and more practical uses for it will continue to increase over the next twelve months as products and services begin to accept digital currencies as payment.

    Digital currency will be making lots of headlines in the coming year, on topics ranging from regulations and legality to security and volatility.  Bitcoin in its current form may not manage to remain the dominant digital currency as alternatives continue to emerge, and digital currencies may never become the currency of the future; but one thing is absolutely certain – digital currency in one form or another is here to stay, and it will be big news in 2014.


    Marfat Abdullahi (Developer)

    The much-anticipated Amazon drones (or Prime Air as they’re marketing them) will influence the market tremendously. Products at your doorstep in 30 minutes will surely change the world of online shopping, as long as Amazon delivers.

    It’s been claimed that a drone can cover areas within a 10-mile radius of their distribution centres; what better way to grab the attention and the curiosity of consumers than a flying drone? This is certainly an opportunity to take advantage of exposure to a large amount of population in a short time, and in targeted areas. I am convinced that the idea of drones will spark the creative ones to take this chance and bring in new and exciting ways of entertaining an audience too.


    Ana Cuesta Biel (Developer)

    Hybrid cloud will change the way business are run, and in 2014 it will be widely used.

    We’re used to the concepts of public cloud (open to anyone) and private cloud (open to an organization); but, according to Rackspace, the future which has already started is the Hybrid Cloud, which consists of public cloud, private cloud and dedicated hosting, all together.

    They defined DevOps as the culture and work methodology that uses a set of tools and deployment strategies to automate all the processes. Some of them are already widely used (GitHub for coding, Jenkins and Gerrit to automate testing, etc.). The hybrid cloud will be key to this change, which will embrace all the DevOps.


    Jose Terrones (Developer)

    3D printing has been a much-touted trend for the last few years. Mostly it’s been used for hobbyists, or very high-end uses, as the cost has been astronomical.

    But I really think that 2014 will be the year where 3D prints have an impact on the wider market.

    We can already see in CES that 3D printers are covering more markets, such as the food, jewellery and gaming. There are already  a few companies where you can orders high-quality products online to be printed for competitive prices.

    This is a great opportunity for brands and agencies to create bespoke, customised products, at reasonable prices. There are many ways this tech could be used in really interesting and creative campaigns. Watch this space!


    James Hunt (Creative Technical Lead)

    This is the year for wearable tech. We saw Google Glass come and go, with very mixed reviews, with the majority being bad. There were also a few other pieces released, such as fitness trackers. But I think this year companies will start to release things that really do change the way we interact with everything and each other.

    These new bits of tech will bring benefits to both our business and social lives. With the ability to make us more involved with our online worlds, while at the same time freeing up our hands to get more involved with what it is we’re doing.

    Author: Deepak Ark.

  5. Digital Project Technical Teardown: British Airways Look Up Campaign

    image

    The web is full of teardowns of consumer electronics but digital projects don’t really get a look in. We thought we would produce an occasional series of blog posts picking apart how a recent digital campaign may have been created.

    For this inaugural outing we are going to “tear down” the wonderful British Airways “Look Up” campaign:

    It’s a great creative idea and the industry press have been keen to feature it. To recap, digital advertising displays show an advert for British Airways (BA), the advert is interrupted with a child pointing to the sky when a real BA jet passes overhead. It’s a great effect.

    No one gives much away about how it’s done, and the The Drum article describes the tech as: “custom built surveillance technology” which sounds very intriguing (and almost illegal). The DailyOoh points out that: “A weather feed reads the cloud height to ensure the plane is visible before showing the advert. The messaging of the creative will change depending on which plane is above the Towers, with the destination of the planes influencing what content is displayed.”

    We gathered our teams of technical directors and technical leads together to look at how you might put a similar campaign together.

    The core challenge on this project is to make sure the creative is timed accurately with the plane in the sky. A few solutions:

    1) Precalculated Data: One approach is to load the flight times into the computer, driving the display and then approximating when the plane will be above the display based on the flight time. We discounted this option as sometimes flights could be running late (or early). At least we hope they aren’t doing it this way, as it’s not very exciting.

    2) Real-Time Data: There are a couple of ways to get real-time data, different only in their accuracy:

    a) They could’ve used real-time data from the flight information system at the airport. This is available via a commercial API here. Again, this data is near-real-time as so some calculations and assumptions would need to be made;  

    b) Data could have come directly from BA. We discounted this option, as in our experience, asking an end-client to provide such data will typically take a long time for their internal sign-off and work to be scheduled;

    c) So, our favourite option was to to use data directly from the planes, and this is the solution we break out a little further below.

    Real Data from Real Planes

    Currently, 60% of European planes transmit details about their location, speed, altitude, flight number, etc. All this is sent through the air to anyone who is interested in receiving it. In fact, air traffic control are moving to use this data rather than radar when managing our airspace.

    To receive this data, you need a £20 USB TV Receiver and some open-source software which converts the signal into a nice text stream. The receiver can be upgraded for better reliability by adding an additional antenna for £50. A custom application needs to be written to take the text stream and match the data to BA flights. (Remember some flights BA might not actually want to display.)

    Once you have the flight number, location and altitude, it’s simple a case of some maths to work out the average view of the location and match that with the video of the child pointing; triggering the interruption at the right time.

    System Architecture

    The next big question is around architecture. There are many ways to deliver the project from this point of view, and the solution should be based around the requirement for control, maintenance, upgrades. Being able to upgrade and control the logic for the displays remotely is extremely appealing and possibly necessary to deal with any atypical events.

    The display provider will dictate this part of the solution to some extent.

    Fallback

    The fallback is pretty easy in the case of issues with the feed, the display continues but without the interruptions about BA planes nearby.

    Other Ideas?

    So this use of transport data gets you thinking; perhaps an agency might try this with train data or bus data soon?

    We hope you enjoyed our inaugural digital project teardown. Let us know which digital project we should cover next via hello@cohaeus.co.uk.

    Author: Richard Bundock.

  6. Does my digital project need a specification?

    image

    Most agencies don’t like specifications. They’re cumbersome, they’re not very visual and they take too long to write. What’s more, most digital producers, project managers and developers haven’t really had any experience in writing them. If the agency doesn’t have a Technical Director, this can be even more of a challenge.

    Nevertheless, a lot of brands have internal processes which demand specifications are written and submitted. Often a project won’t be able to progress brand-side without a specification. That’s not such a bad idea, as specifications help everyone think through the project before too many resources have been committed.

    I have written my fair share of specifications for agencies and continue to do so, and I hope by sharing some of my biggest learnings I can help you.

    There are some good how-to guides about writing a specification, which I’ll link to at the bottom of this article. I won’t repeat what they have to say, but here are a few important things I have learned to take into consideration before you get started:

    1) Level of detail

    A specification needs to be just detailed enough. Where is the line drawn? It’s difficult to say, as it really depends on the audience. Get the spec level too low and you’ll end up with something that raises more questions than it answers. Too detailed and… well here’s a story about that:

    “One of our agency clients, giddy from landing a global financial brand to their client list, set off to help them develop a web-based application which would add value to one of their financial products. A great idea. The agency got their crack UX team on the project and before long a 20 page annotated wireframe was signed off. Everyone was happy and the project began. A short while later, the main point of contact at the brand moved to a different position and the brand appointed a Business Analyst from their IT Group to take over the requirements of the project. Within weeks the simple annotate wireframe had morphed into a 100+ page functional specification. Within months, it was up to 200+ pages. The functional specification was beautiful: a work of art, describing what the annotated wireframes had before, but in a lot more detail. It had a full traceability matrix, appendixes, cross-referenced requirements. So much detail, in fact, that the project budget was blown out the water. But how? The two documents described the same thing. But they described the same thing at two vastly different levels of detail. More detail is not always good.”

    2) Audience

    Specify the audience and make them do some work before they read the specification. Something like:

    The audience for this document must be familiar with {list of documents} and with the {existing system, etc}.

    3) Clear keywords

    The best practice way to identify requirements in the spec should be to use the standard words MUST, SHOULD, MAY as defined in the somewhat wordy but useful “Key words for use in RFCs to Indicate Requirement Levels” in RFC 2119.

    4) Clarity and brevity

    Don’t make it too wordy. Lean on the designs if you have them and the wireframes if you don’t. If you don’t have designs (flats) or wireframes – and this system has a visual interface – get them before you start. There is nothing worse than the specification grossly out of sync with the wires/flats.

    5) NFRs

    Non-Functional Requirements (NFRs) are better referred to as Systemic Requirements because they capture the requirements of the system rather than it’s users but NFR is the most used term.

    Almost every agency, if they have already written a specification, pays little attention to this area. NFRs define how the system (site/app) deals with interaction outside of what we all think of as functionality. For example, must the system cope with 1,000 concurrent users? How quick should the homepage load? How far back should backups go? All these items are good to ask, but again be careful – every additional requirement requires more budget than just the development and project management time. But not asking these questions can place the project outcome in jeopardy. Remember to ask for the traffic plan from the client, and if one isn’t available make some educated guesses from previous similar campaigns.

    6) Walk-through

    Every specification needs to be walked through by the key people on the project. It’s not enough to simply send it round for review. Get the key people in a room, and go through it page by page. Get these scheduled into the timing plan.

    So if you find yourself producing a specification, remember the above: especially the level of detail. In the agency world you need to move fast, and delivering an overly complex specification won’t help you; but getting the balance right is a very hard task and needs your full attention. Remember that without a specification your project will probably cost more in reworking than without.

    If you want to find out more about writing specifications, here are a couple of good places to look at:

    1.     http://www.joelonsoftware.com/articles/fog0000000035.html

    2.     http://www.its-all-design.com/what-actually-goes-in-a-functional-specification/

    About Cohaesus

    Cohaesus is the technical partner of choice to some of the worlds leading creative, advertising, marketing, communication and digital agencies. Based in London, we advise, architect, plan, build, integrate and maintain some of the best digital campaigns, applications and sites.


    Extra Skills - Extra Thinking - Extra Capacity - Extra Resources


    Author: Richard Bundock.

  7. Four golden rules to stop your project falling apart

    image

    At Cohaesus we’ve been delivering projects for agencies for over four years now, and over those four years we’ve learnt a thing or two about what makes a project work – and what can make the whole thing come unstuck.

    No project is plain sailing from start to finish. (That would just be boring, wouldn’t it?) But hopefully these four tips will give you some thoughts about how you can make your next project run that bit more smoothly.

    If you can think of any other key points we’ve not mentioned, let us know in the comments.

    1. Keep a strong and consistent team

    Our clients often hire contractors, which helps with keeping the head-count low but sometimes means that key people get changed mid-way through. It’s one of the recurring nightmare scenarios we face, and more often than not it causes more trouble than it’s worth.

    Whilst a change to any of the ‘trades’ is usually easy to overcome, a change to the product/project owner (typically the project manager but sometimes the account manager) is highly disruptive. They are the guardians of what the client wants and needs. If they change during a project the fallout can be dramatic. The only guard, is good documentation including contact reports after every meeting to capture why decisions have been made.

    At the very least you should ensure all key roles are occupied by full-timers, preferably who are used to working with one another.

    2. Maintain strict document control

    Making sure the ever-changing versions of PSDs, style guides, wireframes, etc. are kept in order can feel like an unforgiving, perhaps even impossible, task. But keeping all these items properly versioned and making sure everyone is kept up to speed with developments is essential to prevent wasted time and crossed wires.

    An extra note worth mentioning is making sure new versions aren’t just assumed to be in scope; the whole team needs to review and agree a new version before it’s accepted as in scope and allowed to proceed. This may sound time-consuming, but believe me it’s far preferable to the alternative!

    We accomplish this simply by having a folder structure that provides three key states (archive, in scope, pending review), at any time there must only be one version in the ‘in scope’ folder; and by making sure that we rename any file with our naming convention which encodes the version number into it. If the document doesn’t have a version number we use the date received in the file name.

    3. Always know where you are

    This is generally useful life advice, but in the context of projects, one great benefit of the Agile movement was to provide a simple means of letting everyone know where you are in a project. Using burn-downs works well. So whatever you granular metric is, use that as a burn-down. We tend to use the number of failing UAT tests, and this method has always served us well.

    Remember: if you can’t measure it, you can’t manage it.

    4. Use a shared terminology

    The final big problem we’ve found with keeping a project on the right track – especially with a distributed team – is terminology. Most other professions have a lexicon of terms – technical terms, jargon, acronyms or other abbreviations that are required for everyone to be able to communicate effectively.

    Maintaining some sort of glossary or dictionary will allow everyone in that profession to understand the meaning of each term. In our field, this hasn’t really happened yet. Does everyone agree what a “hero image” means? What does “UAT” mean?

    Using a shared, consistent dictionary of terms can go a long way to avoiding confusion in communication. (And save a lot of confused Googling in-between emails.)

    Various online sources exist, like the PMI’s lexicon (which requires registration), or this free alphabetized project-management lexicon reference site. But – depending on the scope of your project, and on the size and distribution of your team – you might want to maintain your own collaborative online word-list, glossary, dictionary or lexicon.

    But first you’ll have to agree on what to call it.

     

    Author: Richard Bundock.

  8. Who needs an Agile approach anyway?

    image

    In a previous blog post we talked about some of the problems we’ve encountered using the Agile software development process – especially when working with agencies on fixed budgets and deadlines.

    We talked a little bit about an approach we’ve been using successfully in these situations over the last few months. As previously mentioned, this approach takes elements from both the Agile and V-Model software development processes to make projects run as smoothly as possible for both sides. 

    I thought it might be good to elaborate a little on this and explain how we’ve made this work on some recent projects.

    Firstly, as with any project, we make sure we spend the time required up front to nail down the requirements; we liaise with the various stakeholders to make sure we fully understand what the client needs and what their expectations are from the completed project.

    Based on the requirements captured in the above phase we can then work with the client on the various documents required for the project. This will generally consist of a technical design document, wireframes, specifications document, architecture diagrams, non-functional requirements, and UAT scripts. These documents will be used extensively during the build phase of the project. We like to call them “artefacts”, and they are strictly versioned and controlled to avoid confusion over which version is in scope.

    The UAT scripts are particularly important as these are used to capture all the requirements of the project. The size of the project determines the number of UAT scripts, but it’s not uncommon to have hundreds of UAT scripts detailing all the functionality of the project.

    These scripts can then be used to measure progress during the project and, importantly, will be used to measure completion at the end, checking against each requirement and recording the results.  

    During the project, the UAT scripts will be run at regular intervals so that all stakeholders understand the common state of the project and what’s outstanding. We keep a close eye on the history of the results; having regular test passes means we can quickly spot any test-regression.

    Behind the scenes we’re free to pick and choose the Agile elements that make the most sense for the project without being dogmatic about it; we can use “sprints” and “user stories” as we’re accustomed to doing, but the client doesn’t need to be involved in this process; the client can focus on status reports and UAT-script results to understand how we are getting along.

    The key here is flexibility. When the project warrants, it or the client demands it, we can offer the full Agile approach.  For smaller projects, with fixed costings and deadlines, we can offer the client an approach that they’re more comfortable with – and, importantly, where they are able to easily measure our progress.

    Over time we’ll document more of our processes, in the hope it helps others and drives an appreciation that a great creative idea can’t be implemented in digital without some equally good engineering.

    Author: Mark Pynen

  9. AAA – Agencies Against Agile

    Over our four short years as a company so far we’ve worked hard to deliver projects in the most effective way possible. Part of that has meant using Agile methods – mainly Scrum. When Agile works, it’s great. And we really believe in it; indeed, our entire team at Cohaesus is ScrumMaster-certified. 

    But Agile takes commitment from both sides of the table. When we set out on a project using Agile, we need equal commitment from the agencies we work with; they need to be product owners.

    Agencies might talk about Agile, but in our experience they are very, very rarely able to provide the level of commitment required to really follow it through. And for a very good reason: that tricky word, finance. 

    When a campaign or a marketing project gets the green light, approval is always conditionally attached to a fixed budget. That’s basic business. You pay a known price for an estimated amount of value. Agencies live on margin; therefore the most successful agencies get the biggest budgets but reduce their outgoing costs as much as possible. Again, pretty basic business stuff. You don’t have to wonder why they make it really difficult to spend any money – triple approved purchase orders, expense sign-off rules, etc.; you know the pain. 

    So, the agency has agreed a fixed budget with their client, and in any event they want to reduce the amount of money they spend by as much as possible. Also, to get a purchase order and sign-off from the client they need a “Statement of Work”, which typically includes a set of wireframes, designs, etc. Essentially, the client wants to know what they will get so they can agree to it upfront. 

    You now have a fixed cost and a fixed scope. Add to that, that the client usually has an immovable deadline; you end up breaking all the basic project management rules – not just the Agile ones! 

    It’s ugly, it’s messy, and, alas, Agile just doesn’t cut it in this environment. 

    This is why we’ve developed a brand new process for our work with agencies, and scrapped Agile altogether.

    Well, sort of; we’ve found that by incorporating just enough Agile methodology with tried-and-tested Waterfall techniques, we’re able to offer the right balance. (Our new process is based on the V-model, which is used in defence and aviation.) 

    Agile is great for projects where you’re able to flex scope, but it means not being able to adhere to a “Statement of Work”. And unless everyone’s on board – that means agencies and their clients – something is always going to break.

    Author: Richard Bundock.

  10. Moving your application to the cloud

    There are plenty of options available for running your web application in the cloud, but in order to make the most of the cloud infrastructure and to avoid spending money needlessly there are some steps that should be followed.

    Thinking about working in the cloud requires a somewhat different mindset, the charging model is not the same, especially if you are used to hosting your own servers and as such you need to think about your application in a new way. You should aim to ensure your code is as efficient as possible, as inefficiencies will cost real money in the cloud.

    Below are five considerations for any application that will be running in the cloud, regardless of the technology or provider:

    1. Use aggressive caching.  Cache static resources and data wherever possible.  You’ll likely be paying for bandwidth, so the less data you have to transfer, the better.
    2. Consider using a content delivery network (CDN) for resources wherever possible.  A CDN will allow you to save bandwidth and will typically result in a better user experience for your visitors, as your web application will load quicker for them.  A CDN is a great way to add a little resilience to your web application.

    3. Do as little as possible.  There is no need to load resources until they are actually required by the user and in a cloud environment you simply will be spending money needlessly. Approach each piece of functionality with lazy loading in mind.

    4. Ensure the application has minimal code dependencies.  Loosely coupled code will make the transition to the cloud infrastructure a much smoother journey.  The application will be more resilient and ready to handle multiple instances, which is essential in a cloud environment.  Server affinity has the potential to negate some of the most powerful benefits offered by cloud infrastructure.

    5. Application scaling is one of the biggest benefits of cloud infrastructure, but it requires your application to be built in such a way as to be able to take advantage of it.  In order to ensure your application can take full advantage of the benefits offered by moving to the cloud you will need to minimise the data stored on the file system.  Store persistent information in the database wherever possible.

    Author: Mark Pynen