Posted by agentrickard on January 24, 2007 at 8:10pm
(I posted this on the dev list, but I think this is it's proper home.)
Now that we have jQuery in Drupal, there are all sorts of drag-and-drop
interface possibilities.
Questions, too, by the look of http://drupal.org/search/node/drag+and+drop.
I've been working on one for my project, using the interface jQuery plug-in (http://drupal.org/node/101471),
and have a two simple questions:
1) Do we have any best-practice guidelines on using drag-and-drop?
2) Specifically, if the action requires saving the state change, should that
save be automatic (on-drop) or user initiated (extra button or link
on-click)?
It seems like a Good Idea (tm) to collaborate here on some guidelines or modules for drag-and-drop.
Comments
Reposting what I said on the list
My feeling from a UI perspective is that it could do either, but that it has to be clear.
For example, as soon as you start to drag an object, the screen might turn colors and a [save this layout] button might appear on the bottom right of the screen, along with a [cancel] button.
There should also be an undo ability, ideally with a button. If an undo is done, then a redo button should also be offered.
If, on the other hand, each move is saved, then there's the question of alerting the user that this new position is permanent unless undone.
In other words, the user should have positive feedback with clear next-step guidance, and error forgiveness.
imho....
Laura
pingVision, LLC
PINGV | Strategy • Design • Drupal Development
I disagree
I don't like the idea of Undo/Redo. Here's why:
The point to most Drag-and-Drop is that it becomes very easy to move things around, reconfigure, etc. Because of this ease, it isn't a huge burden to undo changes manually. Think, for example about moving a file in a desktop GUI. In you drag a file to a different folder, the OS doesn't ask you if you really meant to do that unless doing so causes a conflict (such as replacing an existing file of the same name).
To me, this applies whether we use Drop-and-Save or Click-to-Save.
--
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3
--
http://ken.therickards.com/
Forgiveness
Forgiveness is a very common and I believe essential part of usability. When I don't have an undo available, I find it extremely frustrating if I make a mistake. With layouts, placements, dropping things into folders, manually having to undo a mistake can be a real pain. (Using your desktop GUI as an example, OSX has undo for file moves.)
I don't see why undo would be a problem. Leaving it out may be a convenience for developing the drag-and-drop functionality, but that does not make it desirable for the end users. I think if there is no confirmation, then undo is an essential, otherwise you're providing no error forgiveness, which makes for diminished usability.
Laura
pingVision, LLC
PINGV | Strategy • Design • Drupal Development
Point taken
(Cool. I never realized you could Apple-Z a file move. But there are no GUI pointers that this is so. OS X only gives conflict warnings.)
Steef made this point on the dev list:
I would agree. In other UI areas, we have click-to-save. So I think that Drag-and-Drop-and-Click has to be the standard.
Are there any places where we have click-to-undo?
If not, Undo/Redo seems another line of usability. Especially for Blocks, where Undo would be very welcome.
I still think drag-and-drop ease of use mitigates the error forgiveness issue. But I will yield that point if I am in the minority there.
But, from a developer p.o.v., at least in my case, Undo would simply reload the page from the database, blowing away all unsaved changes. (That wouldn't allow for Redo, though. To do a Redo, you'd need to store a session or semi-permanent variable).
If you get into UNDO/REDO, then you also get into levels of such. I think that's beyond the scope here. Undo/Redo standards for all of Drupal can't be solved by contib UI standards, can they?
So, modest proposal:
This leaves out a REDO step, but keeps the UI consistent with most Drupal forms.
--
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3
--
http://ken.therickards.com/
That sounds good
Another thought had occurred to me earlier, which is that not having an explicit "save" step is only beneficial really for quickie and rapid iteration types of behavior. If you're doing action x a hundred times, having to confirm each time can be a royal pain. However, having to confirm something you may do only intermittently is not particularly onerous, so having the save/cancel option seems not only internally consistent but also probably appropriate given the circumstances.
Laura
pingVision, LLC
PINGV | Strategy • Design • Drupal Development
An idea
What if, instead of a having an undo button, there was something like the revert revisions. Each new layout would be saved as a new revision (with revisions over a week old being deleted by cron) and then it would simply be a matter of switching back to a previous layout, without the necessity of adding a click to drag and drop.
License
Just in case this is an issue, from http://interface.eyecon.ro/
Since Interface is dual MIT/GPL, it can be folded into releases on Drupal.org, right or wrong?
--
http://ken.therickards.com/
--
http://ken.therickards.com/
drag-and-drop ui
Well, I have taken a first pass at this. But I couldn't get the buttons to work, so I went with drag-drop-save.
http://drupal.org/node/101471#comment-203584
Patches welcome.
--
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3
--
http://ken.therickards.com/
It is my opinion that the
It is my opinion that the the standard should be save on drop. I think that you lose some of what makes this function neat if you have to confirm the save.
Also, have you looked at the jQuery Form Plugin?
Saving option
Im a little bit late for this comment but i think that you could consider my opinion for your futur work.
I agree with pyrello that we should save on drop but we can also add a text like
"the information will be saved in (5,4,3,2,1) seconds. Undo (<- as a like)"
so the information will always be saved on drop and we can also undo the action for the usability.