Economist/Drupal – Complex Editing In Place

Edit In Place

Following on from our work in Sprint 1, I’ve been conducting some research today to establish whether or not we’re going to continue down essentially a traditional ‘admin’ system path or whether we’re going to pursue the altogether more challenging (read: scary & hard work!) route of trying to do as much of the content creation and editing ‘in place’ (which effectively means in as much of a WYSWIG environment as possible).

The research today involved some simple walk/talk throughs of two very basic prototypes that I had made using Omnigraffle and showed in the ‘Presentation’ view (probably the fastest way I’ve found to build relatively complex application interfaces using a mix of screengrabs and wireframes that you can click through). For those who are interested, those and this blog post are going to form my ‘demo’ materials for this Scrum sprint.

Predictably (although also happily) everyones main priority is for things to be ‘as simple as possible’, however there was a strong leaning towards the ‘in place’ solution which I found somewhat surprising, as previous research had almost indicated the opposite. (Yet another reason to research as iteratively as you design!)

So, for the next few days I’m going be working on more detailed interface designs for this ‘edit in place’ approach, and to that end, I wonder if you can help me… I’d *love* to see some good examples of relatively complex edit-in-place/WYSIWYG interfaces. Obviously Flickr is the poster child for fairly simple in-place interactions, but are there good examples of being able to add and create new content elements, move them around on page, maybe even manage a few versions of the page… relatively complicated stuff.

If you could point me to any examples, I’d be incredibly grateful!

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 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 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! :)

The Economist/Drupal Project – An introduction

Economist/Drupal – Intro to the Publishing Tools Project from Leisa on Vimeo.

Some of you may know that The Economist is in the process of moving their web content management over to Drupal and I am really excited to be joining the team working on the implementation of these publishing tools over the coming months – my mission is to wrangle the Drupal6 interface such that journalists will be able to spend more time doing what they love to do – chasing and writing stories – and less time doing what currently drives them mad – dealing with content publishing tools.

There are a few reasons that I’m excited about this project:

  1. it’s The Economist! – it’s a company full of clever people writing thoughtful, well researched material
  2. it’s Drupal! – also full of clever, thoughtful people
  3. it’s a really logical progression from all the work that we’ve been doing on d7ux throughout the year which has really been focused on transforming the Drupal admin interface to be more friendly to content producers
  4. it’s a big deal – getting this right is really important to The Economist being able to realise their potential and ambition in the online space
  5. it’s Agile – we’re doing SCRUM in 1 week iterations with an experienced scrum master and even a scrum master master! I am a big fan of well run agile and always looking for opportunities to experience design working well in Agile projects
  6. it’s end user focussed – each one week iteration includes user research/design evaluation (ah, the luxury of known and easily accessible end users)
  7. we’re sharing the process – when The Economist signed on with Drupal the community and open source philosophy was a big part of this decision. We think this is a great opportunity to contribute a case study and some more exposed design methodology back to the community, along the lines of what we’ve done with the D7UX project, so I’m going to be sharing our work on the project here in the coming weeks and months (if you’re interested!)

To kick off the sharing process, I asked Kerrie Lapworth, Production Manager, and Barney Southin, Managing Editor of to give you an introduction to the project in the video above, and I look forward to sharing more with you as we move forward!

Why Drupal needs a Design Community Manager

I’ve been working with the Drupal community on design projects for coming up to 12 months now – a splash in the ocean compared to many in the Drupal community but long enough to get a feel for how things work.

The ‘paid’ time I have left on the d7ux project is almost run out and I’m left feeling frustrated – not just by the work that I’d like to be able to continue to do on the Drupal 7 User Experience, but also by the great potential for building a critical mass of great designers and UX people in the Drupal community and the different types of activities that could spur this on, and the impact this could have on Drupal adoption and sustainability as an Open Source software project. So much opportunity, so little resource.

Despite the fact that I think there are probably a contingent within the Drupal community who are hoping that Mark & I are just going to go away once we stop getting paid for d7ux, the fact is that this is unlikely to happen any time soon. For various reasons and in various ways, I think we’re both kind of hooked on Drupal, or at least it’s amazing community.

Having said that, I know for myself it will be difficult to carve out any significant amount of time from the paid project work I’ll move onto and the demands joy of a family with a young child – I have long since given up on a social life!

At best, I hope to commit to spending a hour a day (or 5 hours a week) on Drupal post the official d7ux project. This is *far* less than others commit for ‘free’ each week but much more than many are able to consider committing.

(Having said that, have you seen that Matt Webb video I posted just before this post? What are you doing with your 100hrs?)

Here’s the thing… I really want to make those 5hrs a week count. At the moment, the logical place to spend those hours is bickering in the issue queue. Whilst some time does definitely need to be spent there, I think for the Design & UX community to spend too great a proportion of their time battling out grassfire by grassfire is not productive use of our time… but what can we do with just 5hrs?

I think the answer lies in crowdsourcing our time around big projects. Creating and managing projects that lots and lots of people can contribute an hour here and there to, and yet great and coherent value is created. I have some thoughts what kind of projects these might be:

  • creating/maintaining/applying an design pattern library
  • consulting with developers who are in the early stages of developing a module that has UI elements and providing them with assistance *before* they code a UI
  • concentrated work on known difficult interfaces that should be easier. (edited to delete unnecessary snarky remark at a specific module)
  • more microprojects!but my absolute favourite pet project is:
  • crowdsourced usability testing video library: create a library of video snippets of usability testing conducted by people around the world and tagged so that they can be used as a datasource to support design decision making AND to be pulled out over and over and over again to help maintain awareness of people-who-use-Drupal-who-are-not-us

Each of these projects (and I bet there are dozens more just as good or better!) provide:

  • ways for designers and UX people to contribute in a rewarding way to the Drupal community (contributing to the issue queue is v important yes, but can at times be incredibly frustrating and demoralising)
  • opportunities for new people to contribute to the community from their first interaction (rather than being smacked on the nose, told that everything has already been thought of and given a list of issues to read before proceeding),

Growing a vibrant design & UX community within the Drupal community in the long term and allowing Drupal to benefit from that (beyond finally starting to see some gorgeous looking sites that are Drupal-powered) is going to require some nuturing and creativity.

It needs someone to create and faciliate these ‘crowdsourced’ efforts and to promote them with in the Drupal community and within the broader Design/UX community.

But there is one big problem – in order to provide the framework for hundreds of people to start contributing their 5hrs a week, you need someone setting up and managing said framework. I think that this role is a Design Community Manager, I think it needs to be a paid role, and I think it should probably be about 2 days/wk.

So the three questions are:

  • this is something pretty different for the Drupal community… is this something we’re willing to try?
  • who’s going to sponsor this initiative, as in, put up the cash (and no doubt win the love and respect of both the Drupal and Design communities)
  • who is the guy/gal for the job (but let’s answer the first two before we get into this. Be assured there are some great candidates)