Transitioning to Drupal: read about how we helped a publishing company shift off their legacy, proprietary system into the world of Open Source.
The editor's perspective: "It's an absolute dream!"
Over the last year Redactive Media has been migrating a number of sites away from their legacy Easysite CMS to Drupal. Code Enigma has been assisting in this, providing mentoring and extra development resource. We spoke to their digital and editorial teams to find out how this had worked out, and whether Drupal had proved an effective replacement for Easysite.
Background to the project
Redactive describes itself as the leading provider of magazines, digital media and live events for membership and professional services organisations. Some example organisations serviced by Redactive are the Royal College of Midwives, and the Chartered Institute of Marketing. Its main business used to be in publishing print magazine and while that remains a significant area, there's an accelerating move towards digital first.
Originally Redactive built their online magazine sites using a system called Easysite but in 2013 they took the decision to move to Drupal. As they already had an in-house digital team they wanted a Drupal agency that could help them to skill up in Drupal rather than just build sites for them. Their original request was to watch us build a site but we suggested instead that we put a senior developer on site with them so that we could train their team and get them working on Drupal immediately.
The Digital Manager's View
We interviewed their head of digital – Aaron Davies - to find out how the process had worked and whether Drupal had fulfilled their expectations. We started by asking what had made them go to Drupal in the first place and cost was a major consideration in two ways, proprietary licensing and the availability of freelancers. On the question of whether Drupal had vindicated the choice to go Open Source, he has no doubts. The speed comes from Drupal's modular structure, but also from building sites where as much as possible is exported to code. Aaron can already see how Drupal features will allow for productizing features. Some of the needs of magazine clients are predictable so there's potential to package these.
Another impact of Drupal on use of time is that the digital team are no longer burning time helping editors grapple with an unwieldy CMS. The benefit of this reduced build time is that more focus can be given to user-centred design as on the recent rebuild of the Royal College of Midwives site where they had the benefit of working with a focus group to get things like section titles right. The other benefit Aaron can already see with Drupal is that it's much easier to build custom functionality such as smart forms or integrations with external membership databases, and that means they can provide added value for customers – particularly useful when the traditional incentive of banner advertising is no longer delivering as much. Increased user interaction opportunities also improves data capture; customer information is potentially much more valuable than general advertising. As Aaron puts it “we've now got blog sites that can compete with our titles so we have to be smarter to deal with competitors”.
We discussed the impact of some of the processes we introduced to Redactive, including Agile methodology. The user centred model has proved really useful with the concept of the user story being embedded. That's also reflected in a wider re-organisation of editorial teams to cover specific sectors such as health, acknowledging the need to have a more sophisticated understanding of user needs and behaviour.
We also introduced detailed task breakdowns and time-based estimating, and again that is bearing dividends. As head of digital Aaron has an internal market to manage and editorial teams really value having an understanding of what things will cost to implement. It means everyone can make more informed decisions, particularly the new business section where they have an improved sense of what's worth chasing. As Aaron explained “nobody benefits from over-promising”. Detailed estimating followed by auditing of what actually happened also helps identifies time that used to get lost in activities such as planning. This is also helped by using logging tools such as scrum diaries so that the team know how they spent their time.
Of course, it's not all perfect. The digital team may be trying to work Agile, but their customers still like fixed price: “We've gone Agile but our clients haven't” Also, if working to a tight schedule late change requests are a pain, Agile or not.
In retrospect Aaron also reckons that we seriously underestimated how long would be needed for the initial mentoring. The length of time needed to master Drupal was also raised by the developers particularly in a context where they are also learning new tools like Git. Looking to the future, we wondered what was on the roadmap as use of Drupal gradually beds down. The most important area seems to be better use of metrics. The previous CMS was so hard to work with that all the focus was simply on getting stuff produced. Now they can start to really drill into how people are using sites. Aaron explained that quite a lot of design decisions in the past had been best guesses based on general web use: “The BBC has a news carousel so that's probably a good thing”. Now Redactive can carry out analysis of user journeys, implement A/B testing, and optimize markup.
Wrapping up with the head of digital one of his observations that we found really interesting was that the move to Drupal has changed his sense of what he needs in the digital team: “People must be communicators – they must be multi-disciplinary”. Maybe another way to think of this is that Drupal makes a lot of tasks easy so digital team members can cover more bases. Admittedly, that might apply less in a large team where there's scope for things like UX specialists but in a most organisations, this logic makes sense.
We get a better use of time with Drupal – it still take 22 weeks to do a complete new site but the actual build only takes 4 to 6 weeks.
The developer view
We were interested in finding out how the development team at Redactive has taken to Drupal so spoke to Pierrick Senelaar and Bhanu Chawla. No surprise to find that they're enjoying Drupal, particularly its flexibility to build virtually anything. They're particularly positive about using features and the Drush command line tool to speed up work and re-useability. In fact, as a result of working with Code Enigma, they are using a lot more command line in general. That no doubt is partly associated with moving away from Windows, as the team are now standarised on Macs, and the continuous integration system that has their local environments matched to the linux hosting environment.
They did admit that learning Drupal has proved a challenge. It's easy enough to get started but then it gets harder. They reckon it took a full eight months to reach the point where they'd consider themselves free-standing Drupal developers. The process of learning was also new:
“mastering Drupal requires a problem solving mentality – the solution is out there but you have to go find it.”
One real advantage they identify when learning Drupal is the community, which was something new to them. Pierrick pointed out that when you google a Drupal problem, the chances are you'll find the results on drupal.org, indicating that it's an active community.
Apart from Drupal the development team were very positive about the continuous integration systems we introduced, using Git branches and three stage deployment automated with Jenkins. They thought our use of IRC to communicate within the development team was amusingly old-school but actually works.
They also approved of Agile-scrum although they do find our model of very detailed task production can be tedious. On the other hand, they recognise that detailed task breakdowns make for great metrics so you can't have everything. Also, for a team supporting multiple sites there's lots of scope for re-use of task backlogs so they can already see things speeding up. As their knowledge increases they can see how they can re-use and improve features to get productivity gains. But, like every other developer who has to use features, they've also hit problems:
“Features is the best and worst thing in Drupal”
Mastering Drupal requires a problem solving mentality – the solution is out there but you have to go find it.
“It's an absolute dream!” Talking to Helen Bird from the digital team, the picture of Drupal was positive but they also acknowledged challenges around learning and adopting it. Talking to an editor, we couldn't find a serious complaint. “It feels self-explanatory. I was shown it once. Anyone could do it.”
This feels like a real endorsement not only of Drupal, but of the work done by the digital team to tweak it so that it's really easy for editors. Back in 2009 when Drupal 7 was being developed, there was usability research carried using a theoretical user called Verity, who was the archetype for someone who has to use a Drupal site on a day-to-day basis to get stuff done. What emerged then was that Drupal was seriously problematic for Verity. Without intending any insult, Helen's work puts her in the Verity category, and the fact that she finds Drupal so easy reflect how much better Drupal 7 was over previous versions, and how much can then be done by developers to customize the editorial interface. In particular, Redactive are using Workbench module to provide workflow. The fact that Helen can make changes to a draft document without taking things offline or having to go through a cumbersome republication process directly addresses the user needs of a busy editor. She also likes how easy it is to drop images into the wysiwyg text editor. Speak it softly but her kindest words were “it's almost like working in Word”. Hopefully by Drupal 9 we'll have genuine inline text editing, at which point it should be Word is almost like working in Drupal!
It's almost like working in Word.
At one level, assisting a company to move from a legacy CMS to Drupal can feel like shooting at an open goal. We know in advance that Drupal will make things much quicker and more flexible. In part this is simply because Drupal represents an update to a legacy system, and the immediate benefits would be very similar if we used Wordpress or a modern proprietary CMS like Expression Engine. For us, some of the more interesting aspects of adopting Drupal emerged during our initial onboarding with the client, and through the process of mentoring and coaching the internal team.
During onboarding, we got the opportunity to speak to various stakeholders with the result that what seemed initially like a technical exercise to be handled by the digital team became much more an exercise in business analysis looking at what the potential value of moving to Drupal might be, and more importantly, how that might be evaluated. We produced detailed business plans for the initial stages of the move and we believe that helped our client to take a more strategic approach to the process. Lessons for us that emerged from coaching the in-house team are that learning Drupal properly takes a while - no surprise there – but what also takes time is learning and adopting what we'd class as professional development practice.
The core of this is working as a team, which requires people to work in line with an agreed and consistent system rather than relying on individual knowledge: i.e. no more “oh, let's just wait until Frank is here - he knows how to do the database changes”. This covers things like version control, and getting everything into code to achieve zero-touch deployment (i.e. the developers never need access to the production site's edit interface to make configuration changes, and deployment to live can occur without any down time). It also covers using tools such as terminal commands with Drush in order to speed up the development process.
A further potential complication is that we take a fairly custom approach to Drupal development, relying heavily on panels to achieve semantic markup and responsiveness. However, where an in-house team has no previous experience of Drupal this turns out not to be a problem because there is nothing to unlearn, whereas site builders who are used to traditional theming can find panels quite intimidating. Finally, we've been struck by how our project management processes have proved useful to Redactive's digital team. This isn't to say they have adopted our models wholesale but they have definitely cherry-picked ideas. For us this really vindicates a collaborative model between client and agency, working in an integrated way to share ideas.
What also takes time is learning and adopting what we'd class as professional development practice.