Mosaic is dedicated to exploring the science of life.
This is how Wellcome Trust describe Mosaic, their new online science magazine. We built the site for them in Drupal and this case study examines the experience of moving to Drupal.
Open source content on an open source platform
Female condoms, faecal transplants, clinical depression – just some of the stories that mosaicscience.com has covered since it launched in March this year. The site is a popular science zine that specialises in long-form 5,000 word articles, and is the brainchild of Mark Henderson, Editorial Director at Wellcome Trust, who worked previously in science journalism at the Times. Since launch, the site's content has been viewed over a million times, either directly or through syndication, vindicating the editorial team's belief that there's a market both for popular science and long-form content delivered online.
At Code Enigma we're thrilled that Mosaic has gained traction so quickly; it's nice to be associated with something that's clearly valued for its quality. Plus, we don't find ourselves reading our clients' websites on every project; Mosaic is actually interesting. Apart from the content, Mosaic was a major project for us, because the Wellcome Trust digital team was using it to evaluate Drupal as a potential platform for other sites. That meant we were on trial in several ways; was Drupal right, could it work with the design model used at the Trust, and was the in-house team able to learn Drupal to a point where they wouldn't be dependent on an external agency?
It's widened my knowledge humongously.
It's wonderful. There are so many modules, you generally find you can just do stuff.
Was Drupal the right choice?
I put this question to Mike Parmanand – senior developer at WT – and Kate Welling – developer and system administrator. Kate's response: “It's wonderful. There are so many modules, you generally find you can just do stuff.” This is good to hear because if you work full-time as a Drupal developer in an agency you spend your time wrestling with modules that don't quite do what the client wants, and you can forget how empowering Drupal can be, particularly when someone is moving across from a legacy system where many feature requests just can't be met.
Sometimes developers can feel a bit de-skilled if all they have to do is configure modules but so far Kate hasn't felt that. The continuous integration model introduced by Code Enigma means all configurations go into code so there's always some coding to be done. In addition, working on an Open Source stack means there's new stuff to learn on Nginx and the team have found the amount of work done in a terminal window is exciting. On the face of it, that's plain odd – why would anyone enjoy going back to a primitive tool? My guess is this also about empowerment; you're a professional, get it done the most efficient, least patronising way possible.
When we originally pitched to Wellcome, we stressed that it's much easier to become a pro Drupal developer if you engage with the Drupal community so it's gratifying to see their digital team get on-board with that. Kate isn't scared to shout for help in the drupal-uk IRC channel, Dipak attended Drupalcon in Austin, Texas, and they'll all be in Amsterdam. Obviously we'd like to think that community involvement has been facilitated by Code Enigma, but you need a basis for doing it and they said they just like the idea of giving stuff back.
So far so good for Drupal; it's proving a good tool for the developers and editors seem impressed. Chrissie Giles in the editorial team gave it high praise: “I'm used to Wordpress, but Drupal seems straightforward”. To be fair, this accolade was only made possible by our developers doing a lot of work on the editor interface with the business requirement to make this as easy as possible for editors and to ensure that no developer input would be needed for content production. Of course, that work was only happened because Wellcome Trust got the value of doing it, but as a rule of thumb, we reckon you should always design the interface so that it barely needs documentation. In this case, Chrissie said “we did a couple of half day training sessions, but you can work it out, even despite me having a terrible memory”.
I wondered if Drupal had thrown up any surprises or disappointments
Even if Drupal is a good tool for rapid development, it's reputed to have a steep learning curve so we were curious about how the developers in Wellcome had found it. Mike acknowledges that learning Drupal is not straightforward; it's got to be challenging, given that Drupal is such a deep CMS. Mind you, it had taken five years to learn their previous system, and having a Drupal expert onsite for four months had been a real help, giving them an intensive exposure to Drupal's inner workings. In fact, Mike reckons there is no way they could have come so far without having assistance.
That raises the question about how far they have actually come, given that in October 2013 none of the team had any Drupal experience. For Mosaic, the development was led and largely delivered by two Code Enigma developers, with Wellcome's digital team 'watching along' whilst being trained. However, they've now gone on to build two more sites – ukbiobank and the Big Picture education site – and are currently working on the Wellcome's book prize and the Wellcome Collection sites. Now some people might think that building five sites in Drupal is no big deal, but that ignores the fact these are all fully responsive sites built by a team using version control in a continuous integration environment largely working on Macs for the first time. Oh, and I forgot, they are routinely knocking out entities rather just relying on nodes, which is not bad, less than a year in. In fact we think Wellcome Trust now has the makings of one of the best in-house Drupal teams in London.
We did a couple of half day training sessions, but you can work it out, even despite me having a terrible memory.
It was a key requirement for Wellcome Trust that their own digital team would be proficient in Drupal by the end of the Mosaic project. As a large organisation making a strategic commitment to a specific technology, you don't want the risk of having to buy everything from external agencies. Our conversations with the digital team suggest they are more or less there, although they would say they lack some confidence when it comes to architecting a large, multi-faceted site. Getting the team to this point has been a good example of an approach we describe as mentoring or coaching.
The basic idea is that a lead developer - in this case Alasdair Cowie-Fraser - from Code Enigma works with an in-house team providing a mix of project design, training, and team-leading. As we started the project knowing that they wanted to learn what we know, we spent a chunk of time at the beginning planning how the site would be built and documenting that in great detail. That helped their team understand what we were up to but it turns out it also makes it easy for an experienced developer to drop onto the project and help out, and it makes for very accurate estimating. We describe this phase as sprint zero because we're working but not committed to working software. We were also very detailed about the tests for each task using a behaviour driven model. We kept these manual as it kept things clear but we did introduce Behat towards the end of the project, and will definitely be encouraging that as they move forwards.
Our lead developer took the view that the in-house team would learn more if they weren't actually under pressure to deliver so we built a parallel version of the site where they could follow along, and experiment. In part, we did this because we've been over-ambitious in some previous mentoring projects, failing to recognise just how much there is to learn. Drupal would be bad enough but we're also using Git version control, and an 'everything in code' approach.
Another important dimension of the mentoring approach was that our lead developer worked onsite with their team. That helps foster trust, and also creates a bridge between in-house and our distributed team. Being onsite also gives opportunities to talk to other stakeholders such as editors, who had numerous opportunities to provide feedback on the edit interface and make feature requests.
Alasdair coached the internal team.
Working effectively onsite isn't a given. We've heard lots of anecdotes about freelancers sitting around for days waiting for basics like network logons. At Wellcome it worked partly because the digital team were really committed to learning Drupal, but also because there was project management in place to ensure staff had time. Wellcome were interested in working according to Agile-scrum methodology and provided a dedicated scrum master, Angie Vanhegan. There's no doubt that having a competent scrum master at the client end makes a massive difference to organising a team that consists of agency and in-house members.
Interestingly, when reviewing the project with Angie, we both queried how genuinely Agile the project model had been. We started with a fairly fixed specification and had a fixed time budget for delivery. Certainly we worked in sprints and did introduce some new homepage features but on the whole this was fixed-price. To be honest, we're not too bothered about whether we've ticked all the Agile boxes; in the end, projects work where you've got realistic goals, good resourcing and rigorous communication. We had weekly management meetings throughout the project and used shared documentation in google docs. Regular meeting and consistent documentation of those really cuts down the risk of people jumping to the wrong conclusions.
Another variation on classic Agile that we both noticed was that the scrum master was actually much more of a project manager. Angie could participate in discussions and scrums as a representative of the product owner(s) rather than being a mere facilitator. That was important because there were actually two projects within Mosaic – one to create an online science publication and another to research the use of Drupal. Without a project manager able to make judgements, that could be a recipe for confusion.
One final reflection on the mentoring model is that it isn't a one-way street. The team at Wellcome have adopted techniques we use such as developers having scrum diaries and deployment being zero-touch, but we also acquired ideas from them. Wellcome introduced us to a simple rolling agenda and minutes document for meetings that we are using across every project – just one example of an seemingly minor improvement that actually makes a big difference.
Angie Vanhegan managed the project for Wellcome Trust.
Design up front
Another apparently non-Agile aspect of the project was that there was a comprehensive html prototype in place before we even started. In fact, the prototype was built by Clear Left Design using user-centred design principles and a firm commitment to mobile-first design without any reference to Drupal.
Everyone we talked to agreed that having a prototype in place ahead of development makes life much quicker for developers. It cuts out lots of time working out acceptance tests for user stories because the design team have already done that. It also cuts out dilemmas about how to achieve some tasks because you know what the end product has to be. It's also great for accessibility and device testing because again the designers have done the heavy lifting.
In fact, all you have to do is get rid of Drupal's very verbose markup and then inject the markup patterns provided in the prototype. That's easier said than done. We manage it using Panels as the fundamental container for page components, and we then use semantic panels and views to strip out Drupal markup before inserting the required markup identifiers via the user interface. As Panels and Views can be exported into code we then have everything captured into version control and we've cut out that horrible theming phase in Drupal where you spend your time writing endless identifiers to target things like blocks. Add some SASS into the mix to improve efficiency and that's all there is to it.
There are some downsides with prototyping such as how to accommodate change. In this project the homepage changed significantly late on in the project and that involved some rethinking and code refactoring. However, the approach of providing specific design patterns for components rather than the outmoded obsession with complete 'pages' should mean that change can be handled.
The user-centred approach doesn't stop with prototyping. The Wellcome UX specialist also plans a programme of user-testing finding out how users experience the website now that it has a decent amount of content. That will involve analyzing user journeys, working out how far down the page people are reading and any frustrations they have.
The end result
Naturally we're really interested in the technical and client-relationship aspects of any project but as we said at the start, this project has a content dimension that makes it stand out from a purely technical exercise. With that in mind, we asked the editorial team how they felt it was working, three months in. The big story has been the cascade aspect of syndicating content. So far stories have been picked up by the BBC, the Independent, the Guardian, Huffington Post, CNN and others. The site goes out of its way to encourage this by providing a copy and paste tool to grab text content. Apparently, some blogging sites have even contacted Wellcome to double-check that they really can use this stuff. Another dimension of syndication is that it addresses a potential risk with a health and science site. The chances are that people who might be very interested in multiple sclerosis might not be that interested in a feature on malaria. But if you can just let other publishers use the material it gets to the right audience. For example, a story on menstruation got recycled on the jezebel blog and got 330,000 reads. The same happened with a story on asbestos with the version on Hacker news getting far more reads than the 'original' on Mosaic.