Drupal Association members fund grants that make connections all over the world.
Concern Worldwide is a leading international humanitarian organization dedicated to tackling poverty and suffering in the world’s poorest countries. Their main website, www.concern.net, plays an important role in their fundraising process. It enables people from around the world to donate towards specific campaigns and ensure that their money is distributed to where it’s needed most.
SystemSeed has the wonderful opportunity of partnering with Concern in leveraging Drupal to power the Concern Worldwide platform for a number of years spanning all the way back to the days of Drupal 5. This particular site was upgraded to Drupal 7 in 2012 as part of a large platform refactor which aimed to consolidate all of Concern’s Drupal websites under a single common platform. We wrote about the transition from standalone sites in this case study.
Since then, we have been leading a large project to bring full responsiveness and optimisations across a wide spectrum of devices to all sites on that platform. Today (July 3, 2014) sees the completion of this project with the rollout of a fully responsive and adaptive theme layer, catering for its widest audience ever. In this case study, we’ll look at some of the components of this project, the processes, the challenges, the successes, and lessons learned along the way.
Drupal’s free and open-source nature, its large and active community base, and its flexibility and extensibility have all played their part in Concern’s ongoing online success story. Drupal provides a framework without imposing too many rules, which leaves organisations like Concern— with many complex internal and external processes—to craft a system that works for them and not against them. Drupal helps to keep Concern’s costs low as they are able to benefit from community contributed code which is open source, well maintained and free.
As the Internet matures and mobile technologies take center stage, a site that caters primarily for users on desktop devices simply doesn’t cut the mustard. Analysis of Concern’s website traffic clearly shows that a large and growing portion of users are attempting to access the site through a variety of devices, all with different shapes and sizes. What works well on a desktop doesn’t necessarily work so well on a device with a smaller screen size.
One of the main goals of the site is to facilitate donations, and conversion rates on mobile devices were low. Usability studies identified clear issues with the donation forms and the presentation of general information on the site for all users, but especially those on mobile devices.
“The number of visitors to our site has been rising steadily over the past few years. But we noticed a problem. There was a drop in traffic to our website from people using handheld devices such as mobile phones and tablets.” - Concern Worldwide
The key goals of this project were to provide an optimal website experience to users across a broad range of devices and to increase overall conversions. Whilst the previous website frontend focused purely on the desktop experience, the revised website would need to adapt and respond continually to its audience.
Design and Specification
Initially, a usability study was conducted with Irish experts Each & Other. This uncovered major issues with the existing site’s user flow and enabled us to hone in on an optimal design that would benefit Concern.
Outputs from the design process included detailed wireframes that outlined intended functionality, user interface elements and behaviour expectations, as well as mockups and interactive prototypes that showed a general design, look, and feel.
The wireframe and mockups were then used to drive a series of discussions between Concern, Each & Other and SystemSeed, through which we further refined these ideas and helped break them down into a series of actionable user stories.
Scoping the Development Project
The SystemSeed development team then went through the stories again and again, piece by piece, breaking them apart until they felt comfortable that what they were looking at captured the full scope of the project. Each user story was given relative estimates of effort, as well as a score indicating a confidence level in those estimates. These points and scores were then extrapolated into a series of range estimates which enabled us to provide a good picture of the likely scope of the development project, with low-, middle-, and high-range estimates and an assumed likely case scenario.
The development process
After switching Concern to the Pantheon platform, we were able to leverage the benefits of best-practice Dev to Test to Live development workflows. The multidev feature enabled us to quickly and easily spin up new development environments for the development of individual features. At any one time, we had 10-15 different environments on the go, which enabled developers to work on new features for the new version of the site outside of other general changes being pushed to the supported live site.
Additionally we used a combination of Selenium Test Suites and Jenkins automation software to regression test the key areas of the site as we built out the revised version. This combination helped maintain all existing functionality and check for bugs automatically through the upgrade process.
An agile development process, with a fixed budget
At the start of the development project we had a huge backlog of user stories laid out in front of us. Some stories were small and we had estimates that we were confident in. Others were much larger and included things that the teams had less experience with.
Nobody can predict the future and we can’t know in advance what challenges a project may throw up at us, so an agile process where we would continually reevaluate our estimates based on increased knowledge and changing circumstances was imperative. What we would learn in two weeks' time or three months down the line could render the estimates from the start of the project obsolete. From a client's perspective, an agile approach where estimates will continually change can sound daunting, scary even. It can be hard to see how a fixed budget can apply to a project that is constantly changing in scope. In the end, it all comes down to a question of priorities. Throughout the project, it was imperative that priorities were continually reevaluated along with every other aspect of the project. The most important stuff stayed at the top, with less important stuff moving down to the bottom.
A fixed budget simply ends when it ends, and as long as the time has been used to best effect along the way, focusing on the highest priority items, the outcome should be one that everyone is happy with. Not all user stories from the original wish list made it into the final project, while others that hadn’t even been thought of on Day One did. Some stories are left unstarted, whilst others have been refined to the nth degree. There is certainly scope for a follow-up project in the future to revisit some of the original wish list items, but at the point where we made our final deployment, when the original budget ran out, the number of improvements that were delivered within that scope were evident in the final product.
Communication and shared understanding is key
As long-term strategic partners of Concern, we have a deep understanding of how to drive global collaboration and participation in cause-based activism. The alignment between the teams was key to achieving the goals of Concern stakeholders, and put SystemSeed in a trusted position to make recommendations or adjustments to enhance the success of the project and its outcomes.
We worked in two-week sprints. Each began with a Sprint Planning session between the scrum team and ended with a Sprint Review with the client and stakeholders, where completed work was demoed.
Throughout the process, we worked very closely with Concern. They had their own in-house project manager, and we have our scrum master and product owner. We would do regular backlog grooming in the scrum team, where we would discuss any obstacles, challenges, or recommendations for adjustments. This was a really key process and helped to ensure that everything was out in the open, priorities were appropriately adjusted and expectations were properly managed. The dev team had a daily scrum to ensure that everything was on track at every stage. Our scrum process helped keep all members of the team up to date on information exchange between the team and the client, while also allowing them to focus on each week’s sprint goals and user stories to complete without continual change from the stated desired work to be completed.
Our development team is spread around the globe and our client is in a different location yet again, yet through constant communication we were able to act effectively as a single team.
After a lot of testing across a myriad of devices, the revised frontend was launched. Some of the highlights include:
The homepage is a good example of the types of optimisations and adjustments that have been made throughout the site to cater for users on different types of devices. Essentially, the frontend is driven by the Omega 4 theme in conjunction with responsive Panels layouts. We work with five primary breakpoints and make different types of adjustments at each level. These range from minor style adjustments, to showing and hiding additional content, through to completely changing the layout and positioning of elements, which is done with the help of the Breakpoint Panels module. We use the Picture module extensively to provide fully responsive image handling throughout, ensuring that the most appropriately sized image is served for each device size. This helps reduce the bandwidth and keep the performance up. Google stated in a recent whitepaper that the short concentration span of a mobile user meant our pages had to load “immediately,” or we risked losing the traffic completely.
Improved donation forms
The donation forms went through a lot of usability testing. The number of fields was reduced to a minimal set and contextual help added where it was needed most. Clientside validation was added, and form error messages were moved inline to help people more easily identify and correct errors with their form submissions.
We also now pass details of any form validation errors through to Google Analytics using custom Analytics Events. This enables us to measure and take steps to further reduce the number of form validation errors our users encounter over time.
Extensive testing was done on mobile devices to ensure that all of the donation forms are quick and easy for people to use. We also added additional payment methods for both one-off and recurring donations (PayPal and Realex RealVault) to give users more choice in how they make their donations.
Usability testing had highlighted clear issues with the registration process for the personal fundraising pages and so these processes were completely refactored. It began as a fairly complex four-page process, and was improved to become a simple one-page form. Users are now only required to provide absolute minimal information upfront, are automatically logged into their new user profile, and can then continue to build out their profile by easily uploading a profile image and setting their fundraising target.
We started with a system where each user could only have one fundraising page in a single currency, and moved to multiple fundraising pages, each with unique currencies. We started with a system that would send out generic welcome emails to all users regardless of the event they were registering for, and moved to a system where administrators have full control over every single communication that gets sent out.
The menu system
The menu system was refactored to include only those links of primary importance, presented in a beautiful and simple primary/secondary menu system. Users on mobile devices can experience a typical “hamburger” style representation of the menu which also incorporates the sitewide search facility for easy access.
Multiple releases across multiple sites
The release process was staggered, delivering value as soon as it was possible. That meant that we were running the new frontend on parts of the site, whilst the remainder of the site was still running the old frontend. We started by delivering iterative improvements to the most important parts of the site—the donation forms on concern.net—before moving onto other important areas of the websites that all run on the same platform, and gradually worked our way through the sites until all sites were complete and running the responsive frontend throughout.
This staggered approach helped to ensure that we could deliver value throughout the project and help concern see a return on their investment as soon as possible, rather than waiting for a “big launch” at the end of it all, as might be the case in more traditional development projects.
We make it part of our standard workflow to get involved with the Drupal community at every level. From submitting patches to porting modules to tweeting about tips and techniques that we pick up along the way, this project was no different to any other in those regards.
Being able to lean on the Drupal community when we need it the most can save us countless hours of debugging and reverse engineering, and saves our clients time and overhead.
Here are but a few examples of where we engaged with the community through this project:
Internet Explorer support for Breakpoint Panels
We use the Breakpoint Panels module to enable us to have panels layouts in which the position of individual panel panes completely changes depending on the active breakpoint, allowing us to move higher-priority items higher up the page for mobile devices, whilst letting them display in a more appropriate place on desktop devices. This is done using enquire.js, matchmedia.js and some AJAX magic. We fixed up some critical issues with the module in order to get it working correctly in Internet Explorer.
Drupal Commerce support for Inline Form Errors
We use the Inline Form Errors module to move the standard Drupal form errors (which by default show up together at the top of the form) so that they instead show up next to the field that triggered the error. This module had some issues when used in conjunction with Drupal Commerce, which we fixed and then contributed back to the community in the form of a patch.
Auto-detection of card type for Commerce Realex
One of the goals of this project was to make it easier for people to donate. Until more Internet-friendly payment methods like Bitcoin become more widely used, people still need to get out their credit cards and copy all of their details from their card to the donation form. We knew that anything we could do to ease this process would be a bonus, so we developed support for automatic card type detection for the Commerce Realex module, so that users no longer need to select their card type from a list. Now, their card type is automatically detected based on the card numbers that they enter. One less field on the donation forms!
RealAuth support for Commerce Realex
Another goal was to provide more payment options for users. Concern are based in Ireland, and as as such they use Realex as a payment gateway. Many Irish companies do this, due to their relatively low transaction fees. We added support for recurring payments via the Realex RealVault service.
Case Study for Drupal.org
If you have just spent the last few minutes reading through this case study, we hope that you have found it interesting and valuable—and there is our final contribution for this project. Now, onto the next project...
The SystemSeed team
Contributions were made to the Drupal project by every single team member, so hats off to the development team!
Do you have a Drupal project coming up? Get in touch with us if you'd like our team to get involved.