disambiguity

Economist/Drupal – Complex Editing 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!

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!

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 Economist.com 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)

‘But is expanded choice good or bad?’, from The Paradox of Choice by Barry Schwartz

I use this study as an example with *so* many projects these days that I thought it might be useful to share the original source with you here. Schwartz is sharing the findings from a series of studies titled ‘When Choice is Demotivating’…

One study was set in a gourmet food store in an upscale community where, on weekends, the owners commonly set up sample tables of new items. When researchers set up a display featuring a line of exotic, high-quality james, customers who came by could taste samples, and they were given a coupon for a dollar off if they bought a jar.

In one condition of the study, 6 varieties of the jam were available for tasting. In another, 24 varieties were available. In either case, the entire set of 24 varieties was available for purchase.

The large array of jams attracted more people to the table than the small array, thought in both cases people tasted about the same amount of jams on average.

When it came to buying however, a huge difference became evident.

Thirty percent of the people exposed to the small array of jams actually bought a jar; only 3% of those exposed to the large array of jams did so

For the detailed answer(s) to ‘why is it so’ you should buy the book (and I strongly recommend it, as I said, I reference it *all* the time). For the short answer – people don’t do well with a lot of choice. Be a good designer and help them by guiding them towards good decisions, even if not the perfect one. A decision made can be remade and refined, which is much better than not seeing your customers for dust.

Matt Webb on design & scope at Reboot 11

I had the pleasure of speaking at Reboot11 recently and one of the best things about it was seeing this inspiring talk from Matt Webb which you should watch immediately and share with any other designers you know.

Design In the Open Community for Open Source User Experience Design

Just a very quick post to let you that I recently created a Ning community to allow designers and user experience people who are working in (or interested in working in) Open Source and Free Software communities to share their experiences, their projects, their questions and their mental health breakdowns!

If this sounds like something you might be interested in, come join us here: http://www.designintheopen.org/

[Participate in Research] Are you on the market for a new phone, insurance or breakdown cover?

Are you currently looking at purchasing a new mobile phone, switching your insurance provider or getting breakdown cover for your car?

We’re looking for people who are not so technically savvy who might be available to help us with a small research project in London on 6-7 July. We’re after everyone from students to grandparents, so if this is not you, perhaps it would suit someone you know – feel free to pass this onto them!

You’ll get £40 for an hour of your time, we’ll come and meet you at a location that is mutually convenient (in and around Central London), and it is really very easy – we’re interested in your experience and feedback, that’s all! Actually most people find these sessions pretty fun!

UX London – Designing for Content Rich Sites Workshop

Here’s a dump of tweets i sent during Jared’s workshop.

• sitting up the back of @jmspool‘s workshop – Why Good Content Must Suck: Designing For The Scent of Information
• Jared is talking about the Scent of Information and why it is more effective than designing for navigation
• humans = informavours
• Jared says: the best websites have a lot of content
• conten sucks the user towards it (this is why your content has to suck… like a vaccuum cleaner)
• every link gives off ‘scent’ that users follow. As scent gets stronger, people are more confident they’re headed the right way
• we can only tell from users behaviour whether the scent is working or not. If you’re not watching users, you won’t know.
• “trigger words” are the words that cause users to act
• our eyes go straight to trigger words.
• @Suw no videos from #uxlondon as far as I know
• Jared says the 3 click rule is ‘complete bullshit’. Tell your boss.
• the only time users complain about clicks is when the information scent has gone
• good design is like air conditioning. You don’t notice it unless there’s something wrong.
• @Suw I’m in the process of posting dumps of my tweets session by session to my blog right now www.disambiguity.com
• when the user comes to the page they scan for trigger words, if they find one, they click on it. If they don’t, they go to search
• the search box is users creating their own links by inputting the trigger words they’re looking for
• most of the time BYOL (bring your own link) via search doesn’t work
• users don’t like to scroll ‘that’s complete bullshit too’ @jmspool
• iceberg syndrome: people assume the most important stuff is at the top. If ‘marketing fluff’ is at the top, don’t bother scrolling
• nobody goes to a website without a purpose. except web designers.
• information masking:when users look at a page they focus on only the portion of the page that has consistently given them good use
• navigation panels are often scentless. Scent is specific, navigation is often not.
• short links don’t emit scent
• the best links are 7-12 words in length
• @atownley 12 words is too long
• short pages reduce scent. The best pages are *really* long. ref: CNN, Yahoo, Amazon, NYT
• things that stop ppl from scrolling 2. Design elements that *look* like the bottom- white space, text that looks like a disclaimer
• cute/brand/marketing type links don’t work (mystery meat)
• homepages should look more like sitemaps in @jmspool‘s opinion. It’s not clutter. Link rich homepages do better than sparse pages
• @jmspool on baseball – it’s 15mins of excitement jammed into 2.5hrs
• the only people who care about what ‘section’ of a site something is in is people who manage the site. Users couldn’t care less.
• graphics for information = v useful. decorative graphics are less easy to correlate to good user outcomes
• the no.1 thing that users base the quality of their experience on is whether or not they complete their task
• Navigation Graphics communicate scent. Content Graphics convey information. Ornamental Graphics do something else #uxlondon PRT @Wandster
• yes, in case you’re wondering, I’m tweeting a @jmspool workshop at
• designing for scent – make sure every click makes the user more confident
• what makes users confident – ‘i know where this link is going to take me’
• on click show desired content OR even stronger scent = happy user
• if you’re not spending time watching people use your site there is no way you’re designing a good site #uxlondon ( )
• you need to know – why are users coming to your site? what are their trigger words?
• users look for blue & underlines. yes, it’s ugly and hard to see but we’ve trained users to look for that.
• Target Content Page = the page the user is looking for to solve their objective. The most important page on the site for that user
• you only have to worry about information scent if you have more than one page on your website
• Gallery Page = a list of links to content pages. Scent comes from the content page thru the links on the gallery page to the user
• @jmspool does research on ecommerce sites because they’re easy – easy to measure if users have achieved their goal.
• 3 scent failure predictors: use of the back button, pogo-sticking, use of search
• wireframing 2.0 #uxlondon goodies http://tr.im/uxlondongoodies (via @solle)
• the back button is the button of doom (repeat after @jmspool)
• pogosticking = when the user bounces between levels of the information hierarchy seeking their target content page
• when people pogo-stick we see a huge reduction in users achieving success on a site
• the more users pogo-stick the less likely they are to find the target content. When you see it it, tells you there’s a problem.
• you are *much* more likely to find what you’re looking for if you DON’T use search
• only if you have Uniquely Identified Content (like Amazon) do you get an exception to the searching = predictor of problems rule
• people type very generic terms into search – this is the main reason search fails (behaviour not technology)
• your users are telling you every day what trigger words they’re looking for and on what pages. Look at your search logs.
• users are telling you every day what is wrong with your site and what you need to do to fix it. Are you paying attention? @jmspool
• to stop people pogosticking, you need to put as much information on the gallery page as possible
• “Changes in the web don‚Äôt change the fundamentals of human behaviour” (@jmspool) #uxlondon (via @Paulseys)
• alphabetical order is the same as random order in 99% of cases @jmspool
• Department Pages = collections of gallery pages. Separates gallery pages into logical groups.
• Department pages are for winnowing, gallery pages are for selecting. Users get this.
• More on “pogosticking” on UIE: http://bit.ly/NuY6W #uxlondon (via @bashford)
• You can always have that much space for your gallery page because you have an infinite page length @jmspool
• people do NOT learn the structure of your site by using it. They have no sense of the organisation of your site, nor do they care
• When users comparison-shopped using pogosticking techniques:purchase = 11% . Compare to 55% when product lists used. #uxlondon PRT @Wandster
• seducible moments – at the end, once users have *achieved* their goal say ‘by the way, would you like to do this?’
• Store pages = groups of department pages. Helps users tell the system what they *don’t* want to see (eg. business or sports)
• people who choose a ‘Store’ page tend to never choose another ‘Store’ page in the same session.
• Do you need store pages? Look to your competitors. If they have them, you probably do. Use the same terms as they are (generic)
• Homepage purpose – to get people to other pages, usually to a category page. Divide real estate accordingly
• anyone who tells you that your homepage is for brand, to learn about your products/your business etc. They’re wrong @jmspool
• the best way to solve arguments is to have everyone watching users actually using the site @jmspool

UX London – Quick Sketching for Interaction Design Workshop – Mark Baskinger & William Bardel

Here is a dump of my live tweets during this excellent workshop at UX London. If you like it, you should buy their book when it comes out later this year.

• wondering about the easiest way to export my tweets from yesterday and get them into chronological order
• sketching workshop kicking off, hooray! ‘and we’re going to get kind of sweaty’
• ‘how many of you guys are IxDs? And how many are UX Designers?’ Cue chaos
• showing people your sucky drawings is part of the growing process
• squeak squeak squeak, explain explain, squeak squeak (how many of you use a whiteboard?)
• why are we here (in this sketching workshop)? to become better communicators
• design drawing is useful in the planning process, can help to see the world differently, heightened awareness of how things work
• drawing can help you tell your story to others, its honesty can be v compelling
• why draw by hand when we have computers? Mice suck.
• why draw by hand – direct with the pencil is more direct, more expressive than via mouse
• thinking is a fast paced activity, the pencil is simple & immediate, a good, fast tool for capturing thought
• ‘Pencils Before Pixels’ – Mark Baskinger
• we’re going to start off with really simple things like straight lines …
• ‘i’d love to sit down and draw cubes with you after the workshop’
• we’re grabbing pencils and paper…
• starting with pencil holding technique. @ashdonaldson & @cennydd are getting some remedial tips
• if you can’t see the tip of your pencil you can’t draw. You need a v loose grip to avoid fatigue
• your bellybutton is very important for vertical lines. It’s like a visual landmark. Pull the lines toward it #uxlondon (seriously!)
• (feels like sketch pilates)
• @keeran of course I’m participating! my vertical lines are much better than my horizontal!
• correct each others squares. what do you see? either ‘my squares suck’ or ‘the person next to me is blind’
• you have to warm up before you can sketch properly.
• techniques for better hand drawn wireframes: use non-repro blue for underlay drawing (it disappears when copied)
• carry a sketchbook all the time. practice sketching all the time. practice straight lines, squares, using hatching for tone
• ‘it’s all about pulling some lines’
• use lines in various intervals, not scribble, for adding tone.
• being purposefully rough, like overlapping corners, makes sketching look more sketchy
• sketchiness = this is not a finished idea, I’m still thinking about this. Sketching holds the conversation back to the big picture
• avoid crosshatching in wireframes, starts to ‘pop’ too much. Use various weight of diagonal or vertical lines instead
• build your sketches up sequentially, add weight and tone onto the skeleton
• uh oh. perspective! (moving shapes in space)
• perspective – make sure your back vertical is a little shorter than your front vertical
• try to finish your line with the same weight as you start it
• if you can do curved planes, you can do arrows. (v pretty arrows, that is)
• @alexjamesmorris you might think all UX people draw, but unfortunately not true, and many of us would love to draw better!
• move the point of your arrow back just a tiny bit off centre and it will look better
• i can recommend Trio Scribli pens #uxlondon (via @solle)
• ‘these are all ‘ungood’ ways of drawing a circle’
• the only useful thing your pinky does is stablise your hand when you want to ‘drop in’ a pencil
• the trick to drawing a good circle is to do a few practice circles before you ‘drop in’ your circle (it works!)
• @freecloud agree that blog posts are like word sketches, but there’s nothing like drawn sketches to communicate some ideas
• @alexjamesmorris i agree. you can’t copy and paste sketched wireframes. I think that’s incredibly important.
• I’m realising that my biggest problem with sketching before is not visualising what I am trying to sketch before starting to draw
• realising sketching is a lot more deliberate than I thought. Resolving to *really* do the sketchbook thing from now on
• ‘sketching becomes a magic trick. I can draw this and you can’t. That’s a powerful thing’
• @alexjamesmorris absolutely – pencil before pixels as Mark said at the beginning
• ok. drawing people. If I can leave this workshop with people drawing skills I will be stoked.
• if you have an element in your sketch that is weak or less deliberate, it attracts attention & detracts from your entire sketch.
• notational sketching = the act of recording things that you see in the world. Mostly for your sketchbook, less so for sharing
• analysing visual input (what you see) and deciding what to record is a particular kind of drawing skill
• @leisa sketching is physical thought in my book #uxlondon (via @Snowbadger) > i agree
• notational sketching tips: fast & loose, use icons, images & symbols, portability is important (in context), date your pages
• more notational sketching tips: respect the borders (esp. the gutter), print neatly (annotations), white space is ok
• moving onto visualising functional relationships – communicating how things interact together so it makes sense to others
• Bill: I like using watercolour because it is less controlled, it forces you to work with mistakes
• if notation is aimed at recording, diagramming is aimed at explaining
• tips for explanatory mapping & diagramming: balance style and substance, think about how to direct attention where you want it
• The Don: ‘How do you draw a blur?’ Mark: ‘You lick your page’
• @jonbho this is an unusual glut of tweets due to #uxlondon. I can assure you I’m usually much quieter! Apologies for the noise.
• getting to the end of the sketching workshop. My sketching is still rubbish, but I have a v good idea of why and what to do
• sketching workshop wrapped up with a gentle critiquing session. Great workshop, recommend it.