Today is Demo Day at The Economist, where all the various SCRUM teams will show and tell what they’ve achieved in their latest iteration. I thought I might see if I can get into the habit of pre-recording my demo so I can share it with you here and ask for feedback & advice! So, here we go!
In the past two iterations (this project runs on 1 week iterations) we’ve done a combination of research, design and testing the publishing tools that the editorials staff will use to administer what is known as the ‘Channel Index Pages’ – these are pages that you’d land on if you clicked something in the navigation that said, say, Business & Finance, or Science & Technology, and their job is to pull the most interesting current content to the top so that readers can access it more easily.
These pages are made up of a range of elements, most importantly for this demo are News Packages (consisting of a lead story and related stories/media files) and what is known as the Bloggy Chunk (an editable text area that section editors can freely input their own content, it is still very much a work in progress and is variously used as an aggregator for recent interesting stories that The Economist isn’t covering in depth or to highlight interesting reader comments, it may in the future show content from an RSS feed).
Although working within the SCRUM methodology, I am trying to take a systemwide approach to the design as far as possible, so there has been a whole range of questions that I’ve had to consider that aren’t strictly in the ‘stories’ for our sprint (logging on, activating editing, for example), and similarly, I’ve tried to devise interaction approaches that will be reusable across the other parts of the system that we have yet to design rather than just customising the design approach to this individual problem set.
The design approach shown in this demo is still quite lo-fidelity and ‘broad brushstroke’, it will become much more precise over time, at the moment my priority is to try to work through and communicate the ideas as quickly as possible – giving me more time to explore a range of approaches, and to iterate approaches which has been very valuable.
So, if you have a moment and are so inclined, I’d really love to get your thoughts on the approach we’re taking so far. We’re also about to embark on starting some development work on this – to make sure we can build it in Drupal without too much difficulty – so if anyone has any guidance on how best to approach this, modules we should take a look at, anything else you think we might need to know, I’d love if you could share it here!
Look forward to hearing from you and thanks in advance!
(apologies to anyone who saw the first version of this blogpost with the screwy audio synching)
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
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.)
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.
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.
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 :)