Category: the economist

I’m going to stop referring to what we’re doing as ‘edit in place’ because actually what we’re attempting to do is what is charmingly known as ‘CRUD’ in Content Management System (CMS) lingo, being Creating, Reading, Updating and Deleting content.

I’ve spent this morning reviewing a whole host of existing examples of ‘CRUD-in-place’ (thanks to the great examples that you provided in response to my previous post). I have to say, although there are quite a few examples out there, not very many of them are particularly inspiring… at least for my purposes.

I’ve posted up some screenshots and a few comments on Flickr that you’re welcome to add your thoughts to. As a summary I think that for this project we can absolutely draw the most inspiration from Flickr & 37 Signals (eg. BaseCamp) implementation of edit in place – mostly for their simplicity, which is the entire point of this exercise.

Many of the other examples offered huge amounts of flexibility which is, frankly, the complete opposite to what I want to offer here – we want to offer flexibility within a template (or perhaps templates) certainly not the ability to create templates on the fly (we don’t want to make people whose skills are editorial suddenly have to try to make good design/user experience decisions!).

Two other pet peeves that I’ve developed since I’ve been reviewing these interfaces are the overly liberal use of buttons when a simple text link would suffice, and throwing up a great hunk of a form that was obviously intended for a back end interface when a much more elegant ‘in place’ solution could have been achieved.

Now that I am trying to apply my learnings and inspiration to my particular design challenge I’m finding myself coming up with some design principles that I will probably add to over time and hope to use consistently throughout the system design. I’m going to start posting them here so I can keep them together and you can give me some feedback as we go!

Design Principles for CRUD-in-place

1. Don’t map the interface to the technical architecture, map the interface to the tasks that users will want to perform. The user/interface shouldn’t have to care about the way that content is grouped in the back end. If I want to just edit the headline of a ‘news package’ I should be able to do that without having to see the form for the entire package. (Eg. fixing a typo in the headline, adjusting line length etc.)
2. Show as few controls as possible and try to show them only when required. Particularly on the ‘index’ type pages I’m working on at the moment there will be lots of ‘bits’ that will be editable. Showing all of them will result in a hideously scrappy looking page. I’m rather tempted to use the BaseCamp approach and show the appropriate controls on hover, however I’m also concerned that we design an accessible experience, so we’ll need to think more about what we need to do to achieve this principle without sacrificing the experience for people with visual/mobility impairment.
3. Where possible, choose a text link and not a button. See (2) above – text links are a much less intrusive element on the page and will help us to maintain a clean, simple interface. Obviously, there are some times where buttons are necessary, we won’t get silly with this.
4. Provide Editorial Tools not Design Tools. The purpose of this interface is to allow editorial staff (writers and editors) to do their jobs well – their job is to craft, curate and communicate content to readers. These people are not designers and should not be asked to make design decisions. The flexibility they require is about selecting, grouping and prioritising content. The design work should be done within the page template and within that framework we provide appropriate editorial tools.

More to follow I’m sure, I’m just getting started. Feedback welcome!

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!

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