One of the great challenges of Interaction Design these days is that we now have a plethora of new ways to design interaction on the web than we did just a few short years ago. Drag and drop is probably one of the best – creating a sense of empowerment over the interface that can sometimes result in an almost joyful user experience.
Despite the fact that we’ve been designing with drag and drop for a while now, it’s taken this long for me to have the opportunity to do some good solid user testing with users comparing drag and drop with more traditional interaction styles. That is … clicking :)
In the test that were we performing we were (amongst other things) examining the use of drag and drop and clicking to perform two types of tasks: to select objects and place them onto a stage, and to manipulate objects on a stage.
One interface used drag and drop for both tasks. One interface used click to select and drag and drop to manipulate.
When users were interacting with the prototype that used drag and drop for both functions it was common for them to make unsolicited comments about the interface – generally expressions of delight at the responsiveness of the interface and the novelty of the interaction method. Of course, drag and drop is not really so novel – many users are accustomed to this method, and we found that no users (of the 15 we tested) were unfamiliar with the drag and drop method or had any difficulties understanding how they were expected to achieve their task using drag and drop. (The interface did include a small instruction to drag and drop onto the stage).
Some of the tasks, such as removing objects from the stage and understanding how many objects could be dragged onto the stage were not immediately obvious, but through brief experimentation the users were rapidly able to achieve these tasks and exhibited no difficulty. In fact, in many cases they were saying ‘I wonder if I drag this back here will it delete the object’, as they performed the task and were pleased to discover that it worked exactly as they had expected it might.
When users were interacting with the ‘click to select’ interface, there were no such expressions of delight with the interaction, however they also had no difficulty achieving all of the tasks involved in the test.
Later, we asked the users to compare the two interaction experiences and talk about which they preferred and why. Without exception, we found that our test participants preferred the click to select interface over the drag and drop interface – despite the feedback they had given at the time of testing.
They agreed that drag and drop felt ‘fun’, and ‘creative’, but overwhelmingly stated that it was unnecessarily complicated, and that it was just as easy, or easier, to click. ‘Dragging was a drag’ was one of my favourite quotes. :)
On the other hand, users unanimously agreed that drag and drop was an ideal way to manipulate objects in relation to each other (particularly, to change the position of objects in relation to one another).
Based on the results of this testing, the logical findings seem to be that drag and drop is ideal for manipulating the position of objects on a stage, but that when ‘selecting’ objects, simply using click to select is preferable. Even considering that we may be wishing to create an interface that is fun and creative (which was why the full drag and drop approach was originally considered), the inefficiency of this method detracts from the user performing their task. Selecting the objects was considered a preliminary task, and the ‘fun’ part started when users got to manipulating the content.
When thinking of the best examples of drag and drop interfaces (and I think that moving around maps is a great example of this), it is once again the manipulation of objects on a stage and not object selection, that seems to be common.
Of course, it is also important to note that choosing a drag and drop interface also significantly compromises your ability to deliver an accessible interface. This should always be an important consideration when selecting an interaction method.
Designing a drag and drop interface? You could do much worse than refer to the Yahoo! Design Pattern Library where they’ve spent a lot of time thinking about all of the components of the interaction and what you’ll need to consider.
Have you done any testing with drag and drop interfaces? I’d be really interested to hear what you’ve found.
I have gotten some pushback on drag and drop from an accessibility standpoint – what to you make of that? Do you think UIs designed around drag-and-drop still lend themselves to accessible alternatives?
From my limited personal experience, I’d say that drag and drop meets the ‘neat’ or ‘cool’ requirement for a lot of products. However, as your users progress and adapt their usage of the product, and adapt the product to their usage, it can become limiting and annoying.
An example: In our product we have a list, in which you can either drag and drop to reorder, or use up and down buttons. The drag and drop always goes down well in a demo but when we did some testing six months after purchase, not one customer used it. It was too hit or miss for them, and lacked the precise control.
Anyhoo, just my tuppence.
Interesting and valuable study.
I suspect that the original idea of “drag and drop” is as much as about “fun-ness” and about “direct manipulation”. The latter is sometimes proposed as a design principle.
The new Yahoo! Photos allow the user to select photos by “drag and drop”. I wonder if this is similar to the “drop and drop” interface and task that was used in this study.
When selecting several photos that are adjacent to each other, “drag and drop” is probably more efficient to use than to click on several checkboxes. Time required to click on several checkboxes is governed by the Fitts’ Law.
Finally, I wonder if there are any studies on differences between user preferences after a short-term exposure to a UI design and after a long-term daily usage. Sometimes users may prefer a UI simply because they are more familiar with it.
Drag and drop makes sense when your users need to make an association between two things (one may be a location), each selected among more than one possibilities. Your users’ comments concerning dragging for selecting suggest that users are sensitive to the inefficiency associated with using drag and drop when one object is selected from only one possibility –the drag is a wasted step. I suspect they would be more enthusiastic about D&D if there were two or more that one stage to place the objects. One click is more efficient than D&D, when you can get away with it, but D&D is more efficient than two clicks.
Including D&D in web apps is a major advance. However, we should remember its limitations. Unlike a button, menu item, or link, D&D does not self-document: a user can’t tell from looking at the UI if D&D is available or what exactly it will do (e.g., will it copy, convert, or associate the dragged thing?). I’ve also noticed that users new to the mouse have trouble coordinating sliding the mouse while holding down a button. Thus, D&D has to be regarded as an expert shortcut backed up by a click-type means elsewhere in the UI. This also addresses the accessibility issues, if all else fails.
hey :) thanks for all the great comments!
Scott – re: accessibility. I think we really do need to be looking at providing accessible alternatives to the drag and drop interface… it doesn’t just cause problems for screen readers, but it also requires a mouse to operate which means that anyone with mobility issues will struggle with it. (As per Michael’s comment about re: difficulty coordinating the mouse).
I actually had a perfectly mobile user in the lab who had troubles with drag and drop because the mouse lead kept getting caught on the back of the desk and she couldn’t get enough free mouse lead to drag fluidly.
Unfortunately a lot of companies respond to the accessibility issue by simply saying ‘well. people with accessibility issues aren’t in our target audience anyway so it doesn’t matter’… that response is not going to cut it in the longer time – if for not other reason than legally.
Gordon & Shaun – interesting that you both touched on the same idea of use of drag and drop over time… I too would be interested to see whether it is something that people use less and less over time (as the novelty wears off and they switch to more efficient means of interaction).
I think that drag and drop gives the impression of efficiency where in fact, in many cases it is much less efficient and accurate that other modes.
It’s great to hear your thoughts/experiences :)
When I think about the times I drag and drop, I think about reorganising the tabs in my browser, moving windows about when they’re constantly in the way and quickly scrolling a web page. It’s always to do with re-arranging object relations, altering layout, organising. I find that often when you begin to introduce action events with drag and drop, that efficiency decreases and end up making mistakes. eg. dragging and droping files in a directory tree. I never do that anymore, I right-click or shortcut key copy & paste everything now. It’s too easy to run out of mouse or screen real estate, have a view scroll (or not scroll) when you least want it to, etc. An example being with the bloglines subscription manager often when I want to rearrange my feed order and I have more than I can display on screen. It annoys the hell out of me that it doesn’t scroll.
I find interactive style events are very important when I drag and drop. I need to know what will happen when I move something over another object. I see that often forgotten, an example is when dragging objects and having the user think they may be able to drop it somewhere, only to find when they release, they can’t. Cursor and the area around an object feedback is very important.
Something else I find is that dragging and dropping and just using the mouse in general often makes me lazy. My GUI becomes a PUI(Parked User Interface) and I sit there, dragging and dropping, playing about, falling into; “what can I drag and drop next,” mode of thought. As a result, I get little done other than the fun of exploring the relationships between objects and seeing that interaction live on screen.
hey Craig – they’re some really interesting self-observations and they tend to fall into line with what I found in my recent research :)
I also like the idea of PUI. The way you’ve described it here sounds kind of negative (and if you’re trying to design an efficient task-oriented interface, then it probably is). I bet there are situations when this might be exactly the kind of experience you’re trying to design… I’m thinking about more ‘reflective’ kind of interfaces – where people are trying to learn by observing relationships between objects…
hrm. interesting.
As said by Michael Zuschlag I think drag & drop appications are really useful when users need to make an association between two things (try to think a booking service when, for example, you’ve to select dates or take-off/landing places).
It introduce a interactive part in surfing and thereafter it can evolve the user-experience.
By my experience no problem with accessibility requirements; sometimes you’ve just to provide an alternative way to realize some task to respect who use keyboard to navigate or another navigation system (so users can select one item per times and proceed).
Quick update – just had a user request stating that the user guide mentions cut and paste as a method of moving files in our app (windows based document management software) but no mention is made of drag and drop.
Specifically, the request states that, as it’s not mentioned and not obvious in the UI, the “user can become confused as we have accidentally moved things without meaning to”.
Now, this is just basic Windows functionality that we pull through into our app, how the hell do we deal with that kind of lack of knowledge…
Customers. Sheesh! ;-)