Economist/Drupal Publishing Tools – Sprint One Update!

Sprint Planning

I’m in the midst of our first sprint on the ‘publishing tools’ project at the Economist, wherein we’re defining interface designs for the ongoing migration of economist.com over to Drupal 6. hurrah!

There is no sprint zero in this project and no time to consider the overall environment design, we’re going to be approaching this incrementally throughout the project, so instead we’re ploughing headlong into proper interface design, and the first few sprints are dedicated to designing publishing tools to allow a group of editors to update what are known as the Channel Index Pages (experimental versions can be seen on economist.com now here and here for example). They’re not much to look at just yet but designers in the New York office are hard at work wireframing and designing up much richer and more exciting!

So, Sprint One dives straight into research and interaction design, I work three days a week on the one week sprints and the format we’re using goes a little like this:

Day One: Research

This week I spent the day talking to Channel Index Editors (who update the website pages) and Section Editors (who edit the print version of The Economist). The interviews were a mixture of me getting to know who is who and what they do, understanding the way The Economist as an organisation works, the publishing processes, perceptions and concerns re: web vs print content production and quality, and getting walkthroughs of some of the current software in use for both web and print production.

There’s no time in the schedule for formal research analysis so it ends up as a page of scribbled notes at the end of the day that, as it turns out, is already serving as a really useful reference point. Some of the scribbled bullet points included:

  • the channel index admin interface is working pretty well at the moment no critical usability issues
  • however, one of the key tasks on this page (news package creation, where the editors group together related content) is currently a very ‘human’ task, relying a lot of the memory of the individual editors and a little on Google searches – there is an opportunity to support this task
  • the biggest usability issues are around the content creation tasks which uses the infamous ‘tree’ system and wastes vast quantities of editorial time due to it’s inefficiencies – improving this interface as we port the system to Drupal will free up significant time for journalists and editors to do what they do best and what they really want to do. As one participant so poignantly shared: ‘what I want to be doing is spending my time writing and at the moment I spend half my time writing and the rest of my time fighting the content management system’
  • people are using the print publication software (known as CCI) for much of the web production process to take advantage of its visible workflow/approval infrastructure (which is basically all about getting the right sets of initials on your content) – we need to find a way to support this process in the Drupal system
  • unlike many CMS implementations I’ve worked on, workflow is not really a ‘top down’ imposition but actually considered desirable – writers *want* people further up the editorial food chain to review their work and for this review to be evident. is this significant for the way we design workflow/reviews?

Day Two: Planning, Designing & More Research

My second day on this sprint kicked off with a Scrum Sprint Planning Meeting – much standing up, reviewing backlog, breaking down stories into tasks and guessing hours.

It’s always a kind of tricky process for design work (and probably for other kinds of work too) because the tasks seem to be so mixed up and messy in a lot of cases – what I say I’m going to do (theoretically) and the way they actually happen aren’t necessarily the same – but it seems to work pretty well here, mostly because the team are pretty flexible and very interested in making design work in a Scrum environment.

Then it was onto some design work – lots of sketching, some prototype building, rinse & repeat until I had to head out for another user research interview.

Day Three: Design, and setting up next week’s research


Day three was all about building my ‘demos’ for next week – demos are a requirement for the Scrum methodology and we have to have something to show at the ‘demo’ session each week and, of course, they’re also what I’ll use in my next round of research, which is day one of the next sprint and which I set up with a few of the people I’d met earlier in the week.

At the moment I’m building my prototypes in Omnigraffle – mostly because I’m using a mix of wireframes and screengrabs and it’s the fastest, easiest way I’ve found to do it – and then just throwing it into ‘presentation’ view makes a great format for use in user research sessions.

One of the big issues I’ve been dealing with this week has been the environment for the content management to take place. The project team I’ve come into have a strong preference for ‘in place’ editing, and I’ve been pretty cautious about taking this approach because it can be difficult to manage complex editing tasks in this environment and because there’s been no indication from user research that it is necessary or beneficial.

At the end of day three I’ve got two prototypes ready for Monday – one is a traditional ‘Admin System’ interface with some simple ‘in place’ editing on Preview and the other is almost entirely ‘in place’ editing. We’ll see how they go in testing on Monday and what we see there will guide the decision making going forward.

Unlike the D7UX project, the technical team here are not at all daunted by the prospect of trying to make Drupal do some pretty serious in-place editing (it’s a different story of course when you don’t have to worry about Core!). Time will tell whether they’re just an overly optimistic bunch or not :)

And now, to the weekend! :)

11 Responses to “Economist/Drupal Publishing Tools – Sprint One Update!”

  1. tylor July 17, 2009 at 7:39 pm #

    Thanks for this outline, it’s really interesting to learn about the process you are taking with this project. More please! :)

  2. Francis Norton July 18, 2009 at 12:12 am #

    I’m very interested in how interaction design fits in with Agile, and Scrum in particular – please keep the updates coming, and could you say a bit about whether design sprints are going to precede implementation sprints, overlap with them or a bit of both?

    • Leisa Reichelt July 20, 2009 at 3:25 pm #

      good question. The sprints I’m working on at the moment are design/ux only (actually, in Economist parlance I expect they are ‘UX only’ as I’m not doing any graphics work and that’s what they seem to call ‘design’ here), but the developers are at work on the Drupal implementation so I am hoping that by the time I get further into the project we’ll be able to start seeing some of the wireframes getting into the development phase, and then things should get really interesting!

  3. Laura July 18, 2009 at 6:10 pm #

    I hope they are “worrying about core”! Otherwise they’re forking their own complex CMS, taking on all the maintenance of code security updates, etc. themselves, and losing one of the biggest benefits of open source: reduced cost of ownership by sharing from the commons.

    Besides, inline editing doesn’t take any core hacking. I imagine the only “daunting” thing about doing it for #D7UX is that, in that case, people are working for free in their spare time. The world’s a different place when people pay you to do the work, isn’t it?

    • Leisa Reichelt July 20, 2009 at 3:28 pm #

      Laura, I think I expressed that poorly – it’s not really that they’re not worrying about core, and more that they don’t have the same concerns as you need to have when you are designing for core (as in, breaking Drupal for everyone) if that makes sense. Thanks for calling me on that, it felt a little wrong when I was writing it.

      Everyone at The Economist is really very interested in sharing back as much as possible with the Drupal community, whether in the form of code/modules (as is more traditional) or in more unusual ways (as we’re doing here!)

      But yes, it is a different world when everyone is getting paid to do the work :)

  4. Laura July 18, 2009 at 6:12 pm #

    PS – In reacting to the last part, I neglected to say what I came here to say: Thanks for posting about your process at The Economist! Very interesting and illuminating reading!

  5. Benjamin Birkenhake July 19, 2009 at 10:07 am #

    After working several years with at least two larger editorial offices, I am really not sure, if there is a chance at all, to never again hear that sentence: ‘what I want to be doing is spending my time writing and at the moment I spend half my time writing and the rest of my time fighting the content management system’.

    Of course, there are bad CMSes and there are even worse CMSes and a few great ones. But my experience is, that editors – by some kinde of principle – always tend to work against the limitations of a CMS. I’m sure, they do not do it no purpose. They somehow have a talent for finding the limits.

    And as soon, as you try to make your CMS more powerfull, to allow the editors to go beyond the limitation, it becomes more complex.

    I was really shocked, when I read, that Mercedes Bunz said, that she thinks, that the biggest challange Online Editors face, are their CMSes. They seem to her as “strenuously hand crafted baroque works of art“.

    I still have no clue, wether this problem can be solved at all. But I am very curious about your aproaches, and I think that it’s a great stept forward for online journalism to make the progress as transparent as you do here. Thanks a lot.

    • Leisa Reichelt July 20, 2009 at 3:36 pm #

      Benjamin, I’m going to have to defer to your more extensive experience on working with journalists and online editors… I can honestly say that so far I am amazed at how patient the journalists & editors have been with the truly horrid content management system (known as ‘The Tree’) that they have to use.

      Perhaps that accounts for why, so far, they have been very focussed on just getting the simple tasks to be simple, and not getting too carried away with the bells and whistles and things that we could do. Stay tuned to say ‘I told you so’ later in the project tho’!

      • Benjamin Birkenhake July 21, 2009 at 12:00 pm #

        Oh. Don’t get me wrong. Almost all Editors I’ve worked with were very kind and patient, almost humble.

        The problem is, that the tools they are supposed to work with almost never fit to their needs. Their relationship to their CMSes is almost always a tragical one. Let me try to explain ist with the opposite.

        A friend of mine is Carpenter and he has been looking for great Saws for a long time an finaly found some japanese saws. They support the way he works with wood. And he is really happy with them.

        Or myself. I am really happy with textmate and with drupal. Both support the way I work. I know exactly what I have to do, to achieve a certain goal with them. I have a feeling of controling, mastering these tools, although I’m definetly NOT a master of Textmate and Drupal.

        Most Editors I’ve met don’t have this kind of feeling with the CMSes they use. Their relation to their CMS is more like mine to MS Office … you know what I mean, these “Why did it do that?” and “How on earth can I do this simple little thing?” kind of relations.

        For me and Office, this is fine, because it is not my job to use MS-Office. But for Editors it’s a tradegy. It’s their job to manage content and to create great web experiences. Creating Tools, that makes them feel as Masters of their Sites, is a central challange for the whole CMS-Industry. I sure, you’re going to make some great advancements in this project and thanks to your transparency for all of us.

        As soon as our own CMS Improvements are done, later this Summer, I’ll try to publish them.

      • Leisa Reichelt July 21, 2009 at 12:06 pm #

        ah, ok, now I understand.

        Yes, we’ll that’s exactly the reason we’re doing this project – to wrangle the out of the box Drupal user experience so that it does actually support the tasks that the journalists and editors do on a day to day basis, and that’s also why I’m spending so much time talking to them and showing them my work from it’s very early, sketchy stages. Hopefully we can craft them some very fine and customised tools that will allow them to get on with their own crafting!

        thanks again for your interest and I look forward to seeing what you’ve been working on!