Subscribe via RSS

Do Different Relay for The Guardian and MAA

Last week we spent a day doing differently for the Marketing Agency Awards #DoDifferent relay and the entire day has been caught in a short film now showcasing on The Guardian website.

Taking the theme seriously we sent Ringo, our Creative Strategist, and Project Manager Nick off to spend the day carrying out agency business while relaying across the beautiful city of Bristol, where our studio is based.

Sounds simple enough? There was a twist. Ringo and Nick had to spend the day travelling on a tandem bike and hit all the sights of (very hilly) Bristol to celebrate becoming the first UK city to win the European Green Capital Award.

The guys had to think on their feet (literally) as they attempted to collect stories from sustainability experts across Bristol – including Sustrans Cycle Network, TriodosUK and Bristol 2015. We will be featuring these #SustainableStories in detail on our blog throughout October and the the plan is to feature them as part of an online resource we're developing to help young people learn about sustainability.

For us, the day was all about challenging the way agencies work and seeing what could be achieved when we take a different approach to our work. Ringo and Nick had to spend a day away from their beloved technology, warm studio and coffee on tap, but they came back inspired by the stories they’d heard (and a little bit fitter!).

We can’t wait to share these stories with you, just look out here on our blog or for #SustainableStories @PositiveBristol

Check out the short film of Nick and Ringo’s big day out in Bristol (as we’re calling it!) now on The Guardian website.

posted by

Going headless with Drupal

Headless Drupal - An introduction from Positive.

head•less (hĕdˈlĭs)

adj. Formed without a head

adj. Decapitated.


Headless Drupal is a way of utilising Drupal to build solutions where the user does not directly interact with Drupal.  Examples include building a front end with a JavaScript framework, rather than the Drupal theme layer, or building a data store for an iOS app.

In this article I’ll show you how to get started building a REST-full back end, and how to approach building an HTML front end app to this.

I’ll give some ideas about how you could use Drupal as a part of a S.O.A. (Service Oriented Architecture). I’ll review some of the pitfalls of taking the headless Drupal route, and some ways to mitigate them.

Finally I’ll give some examples of headless Drupal in the wild, and where things might be going with Drupal 8.


How do you go about ‘Headless Drupal’?

The best way to start is with the services module. Out of the box this gives you the tools to create a REST endpoint to your Drupal site.

REST – representational state transfer – is a standard way to interact with systems over HTTP. It uses the HTTP verbs (GET, POST, PUT, DELETE) against resources.

So for example you POST to /node to create a node, and you GET from /node/1 to read a node.

The core services module provides a REST API for nodes, comments, files, taxonomies, users and system resources.

On a site with this enabled, lets look at interacting with it via REST using an app called postman (a chrome app). I could have used curl, or written code here, but I like to test API’s like this before writing any code.

On the Drupal side we have our api located at ‘/api’ on the site:


Headless drupal code example


And the system resource is enabled


Headless drupal code example


We can then call the POST method to the system/connect method.


Headless drupal code example


You’ll see a couple of important things from that screenshot. The first being you have to set the content type (its important). The second that it is really that easy!

This endpoint is a useful one, as it tells you who you are.

The information returned here is important too – that ‘sessid‘ and ‘session_name‘ are used in the authentication cookie.  Lets have a look at another method key to authentication before moving on to something more complex.

The services module has a ‘Cross Site Request Forgery’ security measure through using a token.

‘Cross site request forgery’ is basically session jacking. By taking your session tokens with a click, an attacker is getting an authenticated session as though they were actually you, and will be able to do all the things your user can do.

Without this token – the session isn’t valid (and it isn’t kept in the session so can’t be highjacked)


Headless drupal code example


We now have the information to log in as an authenticated user.

Lets step through what that looks like, logging in, creating a node and requesting that newly created node.

1)   post to /user/login


Headless drupal code example


Here we post the username / password to the user/login.json end point, and it returns the data needed to continue our authenticated session.

2)   By using that new token and session we can call system/connect to check our identity. You can see it doesn’t return the token – its not part of the session, hence the protection.


Headless drupal code example


3)   No we know we are authenticated – lets create a node, and read it back.

To do this, we post to /api/node


Headless drupal code example


And as easy as that we’ve created content.


Headless drupal code example


Remember – this is REST, so to read it back, we do a GET against the resource.

And if we want to delete it, it’s just a DELETE request.


Headless drupal code example


With the core services module – regular operations such as authenticating a user, creating and reading content are quite easy.

Services has a very healthy ecosystem of companion modules, services views, and services entity are key, and with them plus the core, you’ll be able to build 95% of what you want.

The services module provides a programming API, with this you can add your own resources and expose them as a service via a custom module.

This combination means you can create a very rich, functional backend for any front end.


What are the advantages?

So now we know how to create the back end to the app. Let’s look at the advantages of doing things this way.

There is definitely a ‘cool factor’ to headless Drupal at the moment, and whilst it’s great to do cool things, it shouldn’t be the only reason you do something.


Front End Ops.

Just as Dev-Ops has revolutionised the data centre, front-end ops is beginning to do the same for front-end web development.

We’re seeing the emergence of dependency managers like Nodejs’s npm and bower . There are  JavaScript task runners like Grunt.js and Gulp for process automation..

There are mature Frontend application frameworks like Angular and the continued evolution of front-end responsive frameworks.

We used Zurbs’ Foundation Foundation for Apps  (FFA) to build a headless site for The Childrens’ Society.

Zurb claim this as ‘The first front-end framework created for developing fully responsive web apps’

But the clothes don’t maketh the man…

Some clever SCSS mixins, UI components and a nifty grid aren’t enough to build a compelling web application experience. This is why Angular JS is wrapped up with FFA,  providing some easy to use helpers like Motion UI and YAML front-matter routing.

De-coupled means just that. Separation. We could build the SPA front-end without reliance on the backend functionality what so ever.

This led to what you could truly call an agile approach to creating the frontend of the app.  I’ll outline how we approached it. We found it was a remarkably freeing departure from the traditional Drupal theming process.

1 ) Using flat .html files with YAML front-matter blocks (provided by Foundation for apps) we created our ‘pages’ within our SPA


2) We could then write a controller for this route to use, and provide this to the route via the front-matter block again.


3) An Angular service was then written using the $resource factory in the ngResource module (including this in our application dependencies) to consume a mocked up json file that could be served locally for testing with the intent of being swapped out for the finished api service calls mentioned earlier.

4) We then use Angular’s dependency injection to inject this service into our controller and use promises to retrieve out content from the service.

Foundation for apps uses gulp for task running which made our workflow nice an easy. Any SASS compiling, auto-prefixing, concatenation and minification where triggered when watched directory’s and files where changed, meaning a short wait and livereload firing and our finished product was in the browser ready to view.

This modular approach front-end developing goes hand in hand with the modular manner of modern dependency managers . Over the course of development we found instances where we needed symlinks being created at build time, or using browser-sync for device testing, even regression testing with wraith. All of which where resolved by installing plugins when we found requirement for them.

In short we found that any time invested into the set up and customisation of front end tooling and its repeatability of tasks and processes was just that. An investment, which we saw a great return on.


Deep integrations.

You can now view the resources in your Drupal site as a toolbox you can reuse across an organisation, keeping the same first class CMS experience.  Any application that can ‘talk’ REST can integrate with you now. There are almost no limits , but here’s a few ideas .

·      Pull information from a profile on the intranet to your staff address book

·      When a new starter joins, automatically create them a listing in the intranet.

·      Pull recommended content from one site to another.


Using an industry standard CMS for the data store of an app.

One of the biggest and best use cases for headless Drupal is to use it as the backend of an app (either iOS or android), where they handle the entire rendering for the app.

The Drupal community provides MASt  - the mobile app services toolkit

An app back end module to kick start this development and an iOS SDK and a reference application that works with the MASt toolkit.

The DrupalGAP project does similar for Android devices going through PhoneGap.

What are the disadvantages?

You have to be aware of what you are giving up by not using Drupal directly.  Its easy to get caught up with the cool factor, and the newness of it all and forget how immensely useful Drupal is when it comes to building websites.

A few key things you’ll have to do yourself:


  • URL mapping – automatically making nice urls .
  • Redirects
  • Authentication – logging in and creating user.
  • Internationalisation – supporting different languages in your application
  • Caching – for performance


You have to look carefully at whether you need these, and the cost of implementing them.

That being said – there are ways to blend the two approaches to make things easier.

Authentication is the big one. Whilst services does supply methods for user creation, and authentication, I would recommend you don’t use them.

Either use another authentication scheme (OAUTH2 / social networking), or implement a user hub – and make that do the User creation / authentication for you. OAUTH will work for applications as well as HTML based properties.


Examples in the wild

This is a list of some notable headless Drupal sites, including the site Positive built for The Children’s Society.

· – foundation for apps front end

· built with Angular.js

·      The Tonight Show with Jimmy Fallon is using Node.js and Backbone.js


On to Drupal 8

Using headless Drupal, I believe, also starts you on the path to Drupal 8.

Drupal 8 has REST-ful services in its core.  Have a look at this Drupalize me article for a quick introduction

Drupal 8 core also contains guzzle ( an open source pure PHP http client that makes consuming REST services in Drupal a breeze.

Content negotiation won’t be shipped in Drupal 8 after all (see which is a shame, but I understand the reasoning.

Never the less, in the process of ‘getting off the island’, Drupal 8 has become an open platform with REST at its core.

As such, I feel that as we enter the period where Drupal 8 will be released, we’ll see a lot of integration patterns and hybrid offerings- as Drupal 8 takes a role delivering some functionality. Where instead of building a full D7 site, I am sure we’ll see content management in Drupal 8 feeding lightweight front ends. I am sure we will see Drupal 8 front ends to SOA applications, gradually migrating more content and functionality into the Drupal 8 layer.

Exciting times ahead… very exiting times.


In Conclusion.

Headless Drupal is fantastic if you approach it in the right way. Never lose sight of what you can get done in a standard site build, and don’t be too set on doing ‘full’ headless unless you think it’s absolutely the right approach for your project.

Being able to adopt modern front end tooling, and being able to integrate a CMS tool into other systems is a brilliant way to get more value from your Drupal skills and sites, and to get your Drupal skills into more places that might not otherwise have occurred to you.

Positive have released the demo code from a talk called Decoupling Drupal at Bristol DrupalCamp 2015. Think of it as a companion quick start resource for headless Drupal 7 - you can find that here.

Feel free to use the issues list there to ask questions, fork it and if you add something useful – please do issue pull requests.

posted by

Our new Drupal development infrastructure

Setting up Positive's development environment.

At Positive we've recently renovated and overhauled our development infrastructure.

Technology moves incredibly fast. Just as we are agile with the sites we build, we recognised a need to be agile with how we build them too.

Our natural conclusion was that one central development server wasn't the right solution any more. In this article, I'll go in to some of the things we've put in place, why we've done that, and how it makes things better.

Normalising our operating systems.

Originally we used Ubuntu LTS for our development server. Whilst this is a great solution, a lot of our live builds happen on RedHat Enterprise Linux, or Centos.

For this reason we have made the decision to standardise on Centos 7. This doesn't mean we won't use other operating systems. In fact our architecture means we can embrace differences in environments (more of this in the virtualisation section). Having a default - a standard we'll use, means things are so much more straightforward.

Whilst at the Drupal level you won't really notice the operating system you are on, all the other processes, tasks and activities will have an impact. Standardising on one operating system means we have consistency of these operations through all environments. This has both impacts on time, and on quality. As it's always the same now, we can develop a stable best practice and over time we just know what the right way of doing things is.

Virtualizing and Containerizing.

One of the old dilemas of LAMP hosting is the upgrade dependency hell you can get into. If you've got different versions of Drupal to support, plus some Wordpress, maybe some other specialised CMS work and other custom code - balancing PHP and mySQLl versions can be a nightmare. This is one area where virtualization steps in for us. We can have small and upgradable working components rather than a monolithic server we dare not upgrade as we dont know what will break.

What we have built is a Centos 7 host running libvirt virtual machines. Each developer gets a Centos virtual machine to develop on. We manage these via Foreman, which also acts as our Puppet master.

We have also added Docker to the main host. We use Docker for tools that cut across concerns - currently we have Docker running :

  • an html validator
  • a version of gitlist mounting a host folder containing mirrors of all our GitHub projects.
  • a Dockerfile that we have built for Continuous Integration of our Drupal builds.
  • a copy of DeepDream we've been playing with.

Consistency through recipies.

We are using Puppet to provision all our environments now; Dev, UAT and Live. Foreman acts as the puppet master and we use mostly community puppet modules, with some custom manifests.

This means we have consistency in our approach and consistency through environments. A bonus of this is that it democratises the environments. You don't have to be a sysadmin to add node.js to your development environment, you just select that class in foreman, puppet runs and you have node.js.

Puppetforge, the home of the contributed puppet modules is an amazing resource. Basically, it's a self contained, self documented best practice on server provisioning.

Some of the modules we use are

and we've recently written a puppet module for an HTML email development environment.

Continuous integration and repeated tasks.

We run Jenkins. We think he's pretty great too. Jenkins is built as a continuous integration server, but can do so much more. Jenkins is a replacement for all those scripts you collect over time and it provides a front end to processes that can be run on demand, or on a clock.

So - how do we use jenkins at Positive ?

Firstly, we use Jenkins for continuous integration - on push to develop , Jenkins polls the GitHub repository and pulls the changes. Jenkins then builds the site via a drush make inside a docker container, runs the Drupal tests, and runs a sitespeed test on the site. That is something close to the holy grail of Drupal development. All of this is for new builds only for now. We will roll this backwards as the need arises.

We also use Jenkins as a command and control server. Jenkins syncs down databases and files from live servers to our development environment. This way, if we need to build a test version of a site - we've got all we need to hand.

We use Jenkins as a test bot too - all client sites have a sitespeed test that can be run from Jenkins and we are gradually rolling in selenium tests.

We can run drush commands across all the live, and UAT servers from Jenkins (to clear cache, run update scripts etc.).


It's all still bedding in, but it's already proving it's worth. Having sites build on push to the develop branch in GIT, having a reliably consistent development environment and being able to try new things; either via a new VM, or a docker container. These all add up to a happy, agile development team.

posted by

Positive at DrupalCamp Bristol 2015

Some of the Bristol Drupal community on developer day

On Friday 3rd and Saturday 4th July 2015 Positive supported the first DrupalCamp in Bristol. 

A long time in the making. 

Since we’ve been in Bristol and developing websites with Drupal there has been talk of a DrupalCamp. Bristol has a vibrant Drupal community and it was inevitable that there would be a camp here eventually, it was just a case of when!

For six months we were part of the committee thatwas planning, preparing and organising the two day event, meeting every fortnight to get things ready. There were designs to be created, a site to be built, t-shirts to be printed and speakers to be arranged.


Drupal Camp Bristol 2015

A design to make Brunel proud.

One of the many ways Positive supported the DrupalCamp was through design resource and by creating the DrupalCamp Bristol identity and logo.

Capturing the essence of Bristol and of Drupal in branding that works large or small, on stickers, t-shirts and of course online wasn’t easy – but we love what we came up with.


The Business Day

The business day was based around a single track of events on the Friday from a host of business speakers (full list here: kicked off by the ever memorable and charismatic Jeremey McGuire AKA "jam".

Jam waxed lyrical on business and governement really embracing open-source technologies, specifically how European governments and local councils have changed the way they approach ther technlogy sets. Moving towards open source has had a huge effect on keeping investment within their local communities. Open source technologies can help us all keep our data and finance local, and help us all compete with the big boys on a level playing field.

Next up Kit Hunwicks talked about learning to love the brief. His insights on making sure that when tendering for digital products the objectives and goals of a product are specified honestly and clearly were solid advice for anyone on the other side of development from the agency and freelance bods in the room.

The discussion session included Positive's very own Founder and MD Mike Jenkins, alongside Nick Torday from Sift and Dan McNamara from Microserve. This insightful topic session covered everything from team make up, lessons learned from years delivering Drupal and how we can work better together as a community.

Ben Wilding from Cameron and Wilding took us into lunch with a talk based around a the variables of doing business and doing drupal. There was an excellent Q&A session for this talk where Ben asked the audience what they felt were the important variables of their businesses, including some deeper discussion around developing your business for growth or developing for purchase.

Following lunch, Paul Johnson from CTI Digital did a fantastic job giving insight into thir recent work with GOSH and how their processes had to adapt to work with the client. Of particular insight was how they used a highly experienced data planner who was not an obvious hire, but a perfect fit for mapping and translating the content and database records from old site to new.

Matt Connoly took us into the networking session. Currently ruuning a global innovation agency; Tällt, Matt gave an intriguing talk about startups and the traditional agency revenue model, suggesting that a move to partnership and revenue share can often be a far more profitable way to structure agency remuneration.

Going out with a bang! on day 1 we were treated to a talk by the ever wonderful Matt Jukes. Matt has been at the Office of National Statistics for a while now and his brutally honest talks highlight the highs and lows of taking a website that was described as "the worst website in the world" into a beta that people will love. Matt is always excellent value and was currently in the throws of a beta launch of the new ONS site.


The Developer Day

There were some great sessions on the Saturday (there a full list of what you might have missed here: and it was all kicked off with a great keynote from Leonie Watson on how accessibility has changed over the life of the web. 

It was a real honor to see someone using accessibility tools to use a computer, enabled by technology. The take away being that we’ve done the hard work making things work cross browser, and its down to us to ‘code like we give a damn’ to bring accessibility into everything we do was a powerful way to start the day. 

Marek Matulka from Sensio Labs gave a really interesting overview of bridging Drupal and Magento, using Symphony components from a Drupal 7 build. I can see this being a way to smooth the progress to Drupal 8, writing good object oriented code that we can use in Symphony components now seems a great way to lower the cost of entry to Drupal 8.

David Hughes from Cancer Research UK talked us all through the approach they took to theming Namely, a pragmatic use of SMACSS and BEM, designing in the browser starting on Github pages and moving to a Drupal theme when the design was ready.

A real take away was his recounting from the client that ‘it looks just like the design!’ , this approach meant it really was just the design. 

Mike Dixon from Computerminds took us through their build pipe, and visual regression testing. Their internal tool ‘jeff’ (codename) looks to be something that takes visual regression testing like wraith to the next level with easy to interpret visual differences.


Decoupling Drupal 

I gave a talk on our recent project with The Children’s Society –

This is a ‘headless’ Drupal site. I talked about the process we went through, the lessons we learned and the problems we overcame. 

I touched on the JustGiving implementation – and it turns out lots of people in the Drupal space are looking at this – including CTI Digital, FlowMoCo and us at Positive. 

To round out my presentation I gave a few technical demos, and I’ve released that code here : for anyone to have a look at.

It’ll give you a kick start on angular development with Foundation for Apps as a front end to a headless Drupal back end. Feel free to ask me any questions on that via either @timmarsh, or the issue queue on that project.


Integrating with Drupal

Ringo gave the final lightening case study on the work we did with Mytime Active, using Drupal to vastly simplify their IT infrastructure, integrating their booking system with their website via Drupal Commerce, and much more. 

Having the chance to look back at a large site build like that, with commerce, API integration and responsive designs make you realise just how much you can do with Drupal.

Ringo also told the best jokes, and rounded the day of on a high point.

All in all this was a fantastically successful 2 days. Many thanks to the organising committee , and here’s to next years event, and many more.

posted by


Every development team and even every developer has a set of ‘go to’ tools.

At Positive, we feel that every Drupal developer should have these 5 in their toolbox. They help monitor site performance and code standards. They help you take on new modules and new approaches. In short they help you be a better developer.

There are a couple of ‘no brainers’ that I haven’t included in this list, because they are just a given.

Namely Drush – the command line for Drupal, it helps us manage maintain and monitor all our sites. And GIT, distributed version control done right. We use Github, and couldn’t imagine any other way of delivering sites.

Without further ado – here’s the list, and some examples of how to use them.


1 / 

Web performance is important to us, and at Positive we use to analyze the speed and performance of all our development.

It’s quick and easy to use, and is one of those things - it just works.

We can point it at a site, and get reports like this example one in minutes. The ‘hot list’ tab getting us our quick wins, the summary giving that feel of how we’re doing. We always turn on the screen shots mode, and do two runs – one for mobile, one for desktop.

These are the commands we use with a native install. It takes all the urls in urls.txt and tests them: --sites urls.txt -d 0 --profile desktop --screenshot --name "desktop" -b chrome --sites urls.txt -d 0 --profile mobile --screenshot --name "mobile" -b chrome

We also use it via Docker – if you’re going to go that way – after a Docker pull, you can use these commands (more on Docker later):

sudo docker run --privileged --rm -v "$(pwd)":/ sitespeedio/ --sites urls.txt –d0 –profile desktop –screenshot –name”desktop” -b chrome --seleniumServer

sudo docker run --privileged --rm -v "$(pwd)":/ sitespeedio/ --sites urls.txt –d0 –profile mobile -b chrome  –screenshot –name”mobile” --seleniumServer


2 / PHP_CodeSniffer  and phpunit

Every bit of code we write is written to be functional, maintainable and readable.

The code sniffer, allows us to keep an eye on our code standards. We aim for everything to be to the Drupal coding standards [ ]and the code sniffer runs across our code, does static analysis and reports back any violations.

Assuming you’ve got phpcs in your path (that’s the script it provides), this:

phpcs --standard=Drupal --extensions=php,module,inc,install,test,profile,theme,js,css,info,txt ../modules/ > coding_standards.txt

phpcs --standard=DrupalPractice --extensions=php,module,inc,install,test,profile,theme,js,css,info,txt ../modules/ > bestpractice.txt

when run, goes over our modules directory for a site and gives us two reports, one for standards, one for best practice.

Phpunit is the other tool in our arsenal that helps us achieve quality code. It’s a programmer oriented testing framework, which means we as developers can write tests that tell us our code is behaving. 

We find them so useful that we’ve even submitted this pull request to the JustGiving API with an initial set of tests. We feel that by using composer and a phpunit.xml it lowers the barrier to entry, and aids understanding of a complex API like this.

If you check out that repository from GitHub, you can run:

  • composer install

and then

  • phpunit 

And you’ll run the test suite.

Speaking of composer…


3 / Composer

Composer is a seamless, flawless package manager for Php.

It can manage the dependencies of a project, and it can manage the installation of tools. Think of it like a cross between Drush and magic for the wider Php ecosystem. For Php libraries it does feel close to magic , when you have an autoload.php created for your project, and it just works , it’s a timesaver.

Every server we commission we globally install Drush with Composer.

  • Step 1) This goes into your bash profile.

export PATH="$HOME/.composer/vendor/bin:$PATH"

  • Step 2) Then in the terminal (so the path change is applied)

source ~/.bash_profile

  • Step 3) Then you run

composer global require drush/drush:dev-master

You now have Drush in your path, ready to go.

We also use it to install PHP_CodeSniffer.  In fact this is the composer.json from our tools project, loading up code analysis tools


    "require-dev": {

    "phpunit/phpunit": "4.3.*",

                  "squizlabs/php_codesniffer": "1.*",

                  "phploc/phploc": "*",

                  "pdepend/pdepend" : "2.0.3",

                  "phpmd/phpmd" : "@stable",

                  "sebastian/phpcpd": "*"


    "require": {

        "drush/drush": "dev-master"



Running composer install gives us all of those tools in the vendor/bin directory of the project.


4 / Gulp or Grunt

Gulp or Grunt [] – the choice is yours (or install both).

They are both JavaScript task runners.

Why do I need a JavaScript task runner I hear you ask? .

Well, beyond them being awesome and a chance to get into the node-js-a-sphere, they automate things. Boring things. Which in turn makes our lives as developers that much more interesting.

Lets start where we began at performance. We can automate performance aspects like JavaScript mini-fication and compression. When we are developing we get full fat JavaScript to debug, but when it goes to a live environment we compress and minify the JavaScript to optimally serve it. We have a SASS workflow that is powered by gulp. We can optimize images when building for live deployment.

Gulp can also serve content. Whilst building a recent headless Drupal site, the developers working on the front end were able to test against a version served from gulp – making it very light weight and responsive to use.

And did I mention it does file watching – so when the saved a change to a SASS file, the workflows kicked in, and gulp ‘Livereload’ magic kicked in and reloaded the page showing the changes.

One final thing to touch on why a task runner is so awesome!

Browsersync.. that’s why.

Navigate your site on one browser, all other connected browsers follow it.

When you say cross browser responsive testing, I say bring it on – We’ve got Browsersync on our side. We fire up our virtual machines, connect them all to Browsersync, and test away.


5 / Kitematic (or boot to docker)

Kitematic is a lovely (mac only) tool for managing Docker containers. A container is a bit of a stretch if you’ve never used them before – in short they are environments that last for as long as their command needs them.

That command may be a test, or it may be running a database server. They are lightweight, easy to manage application holders. So if we need to test something on a different version of Php, we can spin up a container.

Or if we want to test a particular tool – there’s invariably a container on DockerHub we can use to try out.

If you’re looking for an intro to Docker, this is an ideal starting point: and can get up and running quite quickly.

I love Docker because it gives us freedom from the operating system and their dependencies / libraries. And it gives us the freedom to break stuff  - which is where the interesting / fun stuff happens. If all of a sudden its cheap, and quick to test something – with no risk. Why wouldn’t you?

So there you go; 5 invaluable tools, to round out your toolset and help you have a better, more fun, less stressful life delivering Drupal websites.

posted by

Behavioural Economics for charitable giving - Part 2

If you haven’t seen it yet, the best place to start with Behavioural Economics for charitable giving is by reading part 1 of this blog series.

To provide a quick overview of Behavioural Economics, it can be briefly described as borrowing insights from the science of psychology in order to make small and simple changes (behavioural scientists call these ‘nudges’) that encourage supporters to make more of the decisions we want them to make, like increasing donations or taking campaigning actions.

Adding to Part 1 of this series, the following article outlines some more of our favourite behavioural economics techniques for charitable giving.


The power of peers

Using other people’s giving behaviour to set an example can be a great way to increase charitable giving. By displaying the behaviour of others to potential donors, it has a ‘normalising effect’ that can encourage desirable actions from supporters.

This is what behavioural scientists often call ‘groupthink’ or ‘herd’ behaviour, where people have a tendency to do things because many other people have done the same things before.

People are strongly influenced by the actions of those around them, what they see other people doing and the decisions that other people take. Including ‘social norms’ within donation asks can have a huge effect on individual giving behaviours.

Research conducted by The Cabinet Office’s Behavioural Insights Team changed a legacy donation ask in a will writing service to include peer-based social influences, creating a marked change in donation response.

The question was changed from:

  •  “Would you like to leave any money to charity in your will?” 


  • “Many of our customers like to leave money to charity in their will. Are there any causes you are passionate about?”

In the second legacy ask the number of people leaving a legacy increased by 42% because they were prompted to conform to the ’social norm’.

Within online donation and fundraising, we can use social proof to take advantage of this peer effect. A simple way to do this might be to add share prompts to the success page of a donation user flow. This allows donors to encourage their network to donate too by normalising donation as an expected behaviour.


Giving more tomorrow

Monthly contributors are some of the most valuable donors to charities. They give more than donors who give irregularly and help stabilise the long-term financial planning of the charity whilst reducing administration and fundraising costs. For these reasons alone, increasing the contributions of regular givers is very worthy of some behavioural efforts.

It has been found that for this donor type, delaying the start of an ask will usually encourage more donors to give a larger regular donation. Behavioural economists call this ‘present-bias preferences’ and describes how people often tend to less readily take action on things that have an immediate cost, but have no short term benefit. Equally, it means that people are more likely to agree to something that doesn’t have an immediate impact on them. 

Research was undertaken by Anna Breman at the Stockholm School of Economics as part of a routine fundraising campaign for a large charity involving 1134 donors; regular givers were contacted via telephone and asked to increase their donation, being randomly given one of two options:

  • The increase starts now.
  • The increase starts in two months’ time. 

In the second option (a delayed start to the donation increase), those choosing to increase their donation amount was 32%higher than the immediate increase group. As well as this, those in the delayed increase group increased their donation amount by an average of 19% more than those who increased their amount immediately.

The study shows the power of ‘giving more tomorrow’. A simple addition to regular giving forms implementing 'present-bias preferences' would only require a small percentage of donor action to make a significant increase to regular giving; making it a very powerful technique for your charity.


The Personal Touch

When someone receives a gift, they will usually feel the need to give something back. Within charitable giving, these gifts can be given to create a powerful personal touch alongside other personalisation efforts. The idea being that by adding to the personalisation with a gift, people will be more likely to make a donation.

In behavioural science, this is called ‘reciprocity’. This is the theory that in response to a friendly act such as gift giving, people are frequently much more cooperative than expected, replacing ‘self-interest’ for altruism. 

Deutsche bank wanted to test this theory during an employee fundraising campaign for Meningitis Research UK that asked employees to donate a day’s salary to charity.

Employees were randomly allocated into different communications funnels. One group received a standard email from the CEO addressed to ‘Dear colleague’ with a second group addressed by name (e.g. ‘Dear Steven’). This was a test on basic personalisation approaches which are tried and tested so these were expected to show a clear result in favour of the personalisation.

However, in addition to this, people from certain offices were also greeted by volunteers who gave them a gift of sweets branded with the campaign logo.

In the non-personalised email group approximately 5% of people gave a day of their salary to charity, when these people were also given the branded sweets this increased to 11%

The personalised email group (‘Dear Steven’ rather than ‘Dear Colleague’) showed a similar effectiveness to that of the branded sweets for the non personalised group, with 12% of people in this group giving a day of their salary to charity.

However, when the two approaches are combined, by giving people both the branded sweets and personalising the email from the CEO, donation rates tripled to 17%.

This result of the campaign meant that if they had only run the non-personalised email, the campaign would have generated around £295,000. If all of the staff had received the personalised email and the sweets, the bank would have raised more than £1million.


Experimenting is fun

The examples above and in part 1 of this series are proven to be highly effective and low cost ways to increase fundraising with small changes, so why not make the leap and try some things out. 

If you are making changes to online fundraising efforts, its easy to set up experiments and measure your results with the host of tools available like these:

You might test something as innocuous as the wording of a donation ask, right up to implementing gifting for your most valued donors. Either way, it can be fun and exciting to try things out and see what results you get, you might be surprised how much value you can add with the most minimal of investments.

For more like this, sign up to our email newsletter here.


posted by

We attended Smashing Magazine Conference Workshop 2015


We recently had the pleasure of attending one of the renowned Smashing Magazine Conference Workshops. Hosted by Vitaly Friedman (Mr. Smashing Magazine himself), the workshop pivoted around Responsive Web Design and Development.

The list of topics the workshop covered was extensive. Exactly how extensive was only realised when we arrived - a preliminary show of hands for who had to leave by 6 was a promising insight into what lay ahead.

What seemed certain was that we wouldn’t be leaving mentally undernourished. Vitaly covered the front-end ‘syllabus’ with thoroughness, enthusiasm, practical application examples and a primary focus on achieving the best user experience possible on smaller pixel real-estate. This was particularly relevant with the impending release of the Apple Watch.

Here are some key take-aways from the workshop:


  • A paradigm shift is required to adjust expectations for responsive sites. Reproducing responsive designs as ‘pixel perfect’ websites shouldn’t be encouraged and can result in diminished returns - the web is not that simple any more. At Positive we have embraced this early, making a shift to ‘atomic design’ - designing the smaller components of a site and letting them inform the broader design. This has worked really well for us in a number of recent projects and has allowed us to move away from the tired and sometimes unsuitable ‘pixel-perfect’ methodology. 


  • Truly responsive agencies do well to adapt their workflow to responsive website development. A basic waterfall project management approach seems too simple - collaboration in small mixed-skillset teams during the build seems to be the ideal scenario. We take a blended approach to project management at Positive that gives us the best elements of an Agile methodology; completing work in sprints, regular iterative development and an evolution from a prototype. This is then structured within a loose waterfall structure, giving our clients the security of a ‘definition of done’, fixed timescales and defined budgets.


  • There was a lot of discussion about the importance of ‘above the fold’ design (ie. having your most important content visible at the top of the page) and its declining validity as the ‘fold’ of designs become so variable. This is especially true on mobile devices as recent research suggest that users will often scroll before they even view any content.


  • We also spent time discussing the (semi)importance of carousels and how to make them more effective, icon design and label placement, SVGs, image compression techniques for multiple device loading, performance tweaking and a host of other topics that left us full of conversation on the journey home, bringing new techniques and ideas back to the studio to fold into our work. 


More information is available about Smashing Magazine Conferences and Workshops here

posted by

Why Drupal could be the best platform for your Charity website.

Charities and not-for-profit organisations are faced with a growing reliance on their digital platforms and websites for campaigning, fundraising, supporter information and service provision.

With that in mind, having a solid website platform is becoming a priority for the sector and Drupal has become a “go-to” option in recent years with everyone from smaller start-up voluntary organisations, right up to the biggest charities and not-for-profit websites in the world (including Cancer Research UK and The White House).

Our specialism in charity and not-for-profit work is complemented by our expertise in Drupal website development, so in this article we investigate some reasons why Drupal can be an excellent choice for your charity’s website platform.


Why is it great for charity websites?

There are plenty of reasons why Drupal is a great choice for a lot of charities and its open-source, community led and non-profit ethos is at the root of a lot of them.


Open Source and Sustainable

Drupal is free to download, modify and use, carrying no ongoing licence fee and it has been this way since 2001. This means that a massive community of core product developers has sprung up around the platform to keep it sustainable by continuously improving its central functionality, monitoring and reinforcing its security features and updating its codebases to take advantage of the latest technologies.


Community Led Enhancements

Outside of the Drupal core developers, an even bigger community (including us) are developing modules for Drupal for specific website functionality, sharing them when they do. These modules work with the Drupal platform to provide off-the-shelf website functionality without the need for specialist development. A great example that we often use is CiviCRM, a major communication and constituent management tool. Used by over 8,000 not-for-profit organisations, it is supported by an entire directory of its own modules and extensions to tightly integrate it with Drupal.

“One of the biggest pros to me as a Digital Editor is the range of Drupal modules that are available. We can add new content types and formats very quickly and easily. We are confident in the modules too because they are supported and documented by the open source community. It makes the platform very flexible.”

- Matthew Summers-Sparks, Digital Editor at The Children’s Society

This community development and testing effort prevalent within open source technologies leads to an unrivalled speed and integrity of new features. An excellent example of this was highlighted in a talk given by Jeffrey A. McGuire at Drupal Camp London last year. He showed that as Pinterest hit 10 million unique users in February 2012 a new website module was developed for user’s pinned images, it was then community tested and verified as stable by March 2012. By April of 2012 it had been implemented effectively on 15 major Drupal websites, it is still widely in use today.


Well Supported

This huge development community also means that your website will be very widely supported, so finding an agency or developer to work with will be easy. There are lots of agency and development providers to choose from and friendly support forums that will provide an answer to any questions or issues you might have, often within minutes of asking.

As part of the Drupal community we are actively engaged in these forums, often providing tips, resources and help as well as reaching out to get advice on the latest best practice too.

“One of the main benefits to us of using Drupal is the fact that there is such a massive network out there, we are able to support Drupal really effectively with a mixture of our 3 in house developers, trusted freelancers and specialist agencies. It prevents that ‘patchwork situation’ where you are supporting all sorts of proprietary platforms and have to seek multiple specialist teams for support.”

- Nick Capeling, Digital Infrastructure Team Manager at Save the Children


Widely Used by Charities

In our experience, Drupal’s popularity in the not-for-profit and charity sectors creates a virtuous cycle, where internal charity staff hires like content editors and website managers will often have experience of updating and administrating Drupal websites. This makes maintaining the day to day site requirements easier, with advanced team members able to take advantage of Drupal’s powerful administration area to make considerable site changes without the need for agency or developer support.

We find that the conversations and working relationships we have alongside our charity clients with in-house Drupal experience makes for a really effective partnership too. Ideas are rapidly exchanged and challenged which leads to faster and better progress through projects and tasks.

“We find that for a Charity like Cancer Research UK the Drupal content types work amazingly well for of our teams, even the non-techy ones amongst us. The way Drupal content types are structured allows us to then re-purpose content across our web estate which saves us time and facilitates mobile-first design.”

- James Dodd, Senior Solution Designer at Cancer Research UK


Charity Specific User Groups

Because so many charities use Drupal and open source technologies, the Open-Charity user group has emerged. The group encourages those using and working with open source technologies like Drupal in the charity sector to work together.

As members of this group, alongside organisations like Cancer Research UK and the Wellcome Trust it is a great place for discussion of shared areas of concern or interest and creating and implementing best practice guidelines. Open-Charity creates an efficient working group that helps us all to make a bigger difference together, a real benefit of choosing an open source technology like Drupal.

““We part run and find that it’s a really positive experience to share ideas. I’d advise charities thinking of taking on Drupal to get involved with the Drupal community generally,- fix core bugs, contribute your code back and take part in community events” ”

- James Dodd, Senior Solution Designer at Cancer Research UK


Easy and safe to learn

Drupal is designed to be easy to use, but for those new to it, Drupal’s multiple user permission system prevents any mistakes being made during the learning process.

Our general approach is to limit access to the more powerful controls for less-advanced users, providing moderation alerts to an administrator within the charity when content additions and site changes are made. These changes can then be checked fully before they are visible to the public.

As team members become more competent, more of the administrative functionality can be made available to them, scaling with their experience and needs, the ultimate objective being to provide as much of a charity team as possible with Drupal expertise, in a safe and managed way.

“On our previous proprietary system we spent a lot of time and money supporting our site editors, with Drupal, it is really easy to configure in a way that means our editors now need very little support, if any.”

- Nick Capeling, Digital Infrastructure Team Manager at Save the Children



Similar to how Drupal scales across user capability, we find Drupal itself is also highly scalable, its core functionality works really well as a basis for even the smallest charity client. As these charities grow and the digital needs of the organisation develop, we have seen some of our Drupal work extend with modules and custom development to match the ability of the world’s biggest charity websites; a lot of which also use Drupal…

“We have found Drupal to scale well for us, we keep an eye on the speed of things like form submissions and our current install is load tested for 5000 per hour. We are considering things like breaking the site down into services and micro-services within Drupal to distribute functionality”

- James Dodd, Senior Solution Designer at Cancer Research UK


So who else uses it?

If you are considering a move to Drupal for your charity website, you’ll be in good company. Drupal is used by some of the best charities in the UK, including:

“We moved to Drupal in early 2011 upgrading to 7 the following September. We moved over to drupal because of its huge community that provides a huge amount of flexibility and resources for us. It allows us to develop very small enhancements that we can iterate up to major pieces of functionality.”

- Nick Capeling, Digital Infrastructure Team Manager at Save the Children


Where do I sign?

We love Drupal and find that it’s normally a great fit for our charity clients, but everyone is different and we would never recommend it without being confident it is the right tool for the job. So in the interest of a balanced article, a word of warning.

Drupal won’t always be right for you, and it’s important to take an objective approach when choosing a new Content Management System (CMS) as they might not be compatible with things like your Customer / Constituent Relationship Management System (CRM), donation services, even the financial and organisational make up of your charity.

We always advise a full audit of these factors before making any decisions and often complete them even when we have been engaged to develop a new Drupal site to ensure we don’t hit any roadblocks later on.

Once you have done your homework though, if Drupal looks right for your charity, we couldn’t recommend it more highly.

For more like this, and to receive regular insight from our team, sign up to our email newsletter here.

Many thanks to our article contributors:

James Dodd - Senior Solution Designer - Cancer Research UK

Matthew Summers-Sparks, Digital Editor - The Children’s Society @mttsmmrssprks

Nick Capeling, Digital Infrastructure Team Manager - Save the Children 


UPDATE: the wonderful people over at have recently created a very handy Drupal Resouce Guide for Non-Profits here.

posted by