Drag and Drop UI standards
All- 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, 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)? - Ken Rickard agentrickard
Op 24-jan-2007, om 19:44 heeft Ken Rickard het volgende geschreven:
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, and have a two simple questions: I think - when you're going to make use of interface - you should make this a contrib module, or only use and port the wrapper functions into some separate .js file.. I do almost know for sure, drupal core will _never_ ship with the jQuery Interface library..
1) Do we have any best-practice guidelines on using drag-and-drop? No, but perhaps that is because we do not have any drag-and-drop yet.. ;-)
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)? I think this is a matter of personal opinion.. But, I personally like automatic (on-drop) saving more than with the extra interaction (using a button perhaps)..
Steef
On 1/24/07, Stefan Nagtegaal <development@istyledthis.nl> wrote:
I think - when you're going to make use of interface - you should make this a contrib module, or only use and port the wrapper functions into some separate .js file.. I do almost know for sure, drupal core will _never_ ship with the jQuery Interface library..
Is that because it is just one solution among many, or because there is a better alternative in view? Steef
Op 24-jan-2007, om 23:55 heeft Victor Kane het volgende geschreven:
On 1/24/07, Stefan Nagtegaal <development@istyledthis.nl> wrote:
I think - when you're going to make use of interface - you should make this a contrib module, or only use and port the wrapper functions into some separate .js file.. I do almost know for sure, drupal core will _never_ ship with the jQuery Interface library..
Is that because it is just one solution among many, or because there is a better alternative in view? To be honoust, I have no idea..
What I *do* know is that the .js files of the Interface library are quite big. So I encourage you to build a patch for core based on the js-functions of interface which are quite good/stable imo.. For people who would like to see some demo's of jQuery Interface plugin in action, have a look here: - draggables demo: http://interface.eyecon.ro/demos/drag.html - sortables demo: http://interface.eyecon.ro/demos/sort.html I must say, i love them both... :-) I'm looking forward to test your patches and follow the work you are going to be doing on this! If your in need of help, let me know.. Maybe I can be of any help.. Steef
One of my current projects will definitely make use of the interface library, if I run into any difficulties I will let you know, and when we make progress (next few weeks) we will make a contrib module). We will be using the gui list ordering and of course drag and drop, at least. Victor On 1/24/07, Stefan Nagtegaal <development@istyledthis.nl> wrote:
Op 24-jan-2007, om 23:55 heeft Victor Kane het volgende geschreven:
On 1/24/07, Stefan Nagtegaal <development@istyledthis.nl> wrote:
I think - when you're going to make use of interface - you should make this a contrib module, or only use and port the wrapper functions into some separate .js file.. I do almost know for sure, drupal core will _never_ ship with the jQuery Interface library..
Is that because it is just one solution among many, or because there is a better alternative in view?
To be honoust, I have no idea..
What I *do* know is that the .js files of the Interface library are quite big. So I encourage you to build a patch for core based on the js-functions of interface which are quite good/stable imo..
For people who would like to see some demo's of jQuery Interface plugin in action, have a look here: - draggables demo: http://interface.eyecon.ro/demos/drag.html - sortables demo: http://interface.eyecon.ro/demos/sort.html
I must say, i love them both... :-)
I'm looking forward to test your patches and follow the work you are going to be doing on this! If your in need of help, let me know.. Maybe I can be of any help..
Steef
Victor Kane wrote:
One of my current projects will definitely make use of the interface library, if I run into any difficulties I will let you know, and when we make progress (next few weeks) we will make a contrib module). We will be using the gui list ordering and of course drag and drop, at least.
Your contribution module would be very appreciated by this developer. i don't have any time to commit to the project next month but would be very interested in its progress both personally and professionally. Thank you for sharing your work. -- Michael Favia michael@favias.org tel. 512.585.5650 http://michael.favias.org
On Wednesday 24 January 2007 18:17, Stefan Nagtegaal wrote:
For people who would like to see some demo's of jQuery Interface plugin in action, have a look here: - draggables demo: http://interface.eyecon.ro/demos/drag.html
This one works in Konqueror, but has some odd behaviors like moving objects other than the one selected, and sometimes things don't stay where they are dropped (and I mean that happens in places other than where it is supposed to).
- sortables demo: http://interface.eyecon.ro/demos/sort.html
This works in Konqueror if you wait about 30 seconds for it to initialize. Konqueror warns about a tight loop in JS, but if you tell it to ignore the first and second warnings, eventually the demo appears on the page. Once that happens, it works flawlessly.
I must say, i love them both... :-)
I do, too, in concept, but the point I'm making is that they are not fully browser-independent yet. Before I would want to see something like this in Drupal core, I would want it to work correctly with all the browsers used by significant numbers of Drupal users: Firefox, Konqueror, Safari, Opera, and (unfortunately) Internet Exploder. The Drupal core team has done an outstanding job so far of achieving cross- browser compatibility. I regularly use three different browsers to access Drupal sites, and find that the current JavaScript features in Drupal work fine with all of the browsers I use. I hope that will continue if we decide to add DnD to the Drupal feature set. That being said, I'm all in favor of the addition of this tool. There are some things, like ordering items in a list, that just cry out for DnD functionality as the most intuitive way for the user to indicate his or her wishes. Scott -- ------------------------------------------------------------------------------- Syscrusher (Scott Courtney) Drupal page: http://drupal.org/user/9184 syscrusher at 4th dot com Home page: http://4th.com/
Syscrusher wrote:
Drupal core,
This is currently discusses as a contrib module.
I would want it to work correctly with all the browsers used by significant numbers of Drupal users: Firefox, Konqueror, Safari, Opera, and (unfortunately) Internet Exploder.
Here are the drupal.org browserstats of the current month: Firefox 58.2 % IE 25.1 % Safari 3.9 % Opera 3.7 % Mozilla 3.2 % Unknown 2.8 % Konqueror 0.9 % So, the relevance of Konqueror could be argued against. Cheers, Gerhard
On Thursday 25 January 2007 10:55, Gerhard Killesreiter wrote:
Drupal core,
This is currently discusses as a contrib module.
I misunderstood, then. I thought the intent was that it was a contrib module with an eye toward eventually being part of core. I apologize if I misunderstood the intent. Scott -- ------------------------------------------------------------------------------- Syscrusher (Scott Courtney) Drupal page: http://drupal.org/user/9184 syscrusher at 4th dot com Home page: http://4th.com/
On Thursday 25 January 2007 9:55 am, Gerhard Killesreiter wrote:
Syscrusher wrote:
Drupal core,
This is currently discusses as a contrib module.
I would want it to work correctly with all the browsers used by significant numbers of Drupal users: Firefox, Konqueror, Safari, Opera, and (unfortunately) Internet Exploder.
Here are the drupal.org browserstats of the current month:
Firefox 58.2 % IE 25.1 % Safari 3.9 % Opera 3.7 % Mozilla 3.2 % Unknown 2.8 % Konqueror 0.9 %
So, the relevance of Konqueror could be argued against.
Cheers, Gerhard
I don't know about their numbers, but jQuery does not consider Konqueror a target browser because its market is so small and none of the core developers use it. Safari is, but not Konqueror. That said, I've found most stuff does work in Konqueror just fine with a few exceptions (like those listed here). I am biased since I use Konqueror myself at home, but a "jqinterface" module that provided a wrapper for the jQuery Interface library would, ideally, fix any outstanding Konqueror bugs. Those fixes would be send back upstream to the jQuery folks. I would be surprised if they didn't accept them, unless they broke something else. (Note: I don't know what the licensing issues there would be with doing that, since Drupal is GPL and jQuery/Interface is MIT/GPL. I'm just pointing out a place where the projects could benefit from each other's slightly different focuses.) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On Thursday, 25. January 2007 16:36, Syscrusher wrote:
I do, too, in concept, but the point I'm making is that they are not fully browser-independent yet.
I'm a heavy Konqueror user, but I would argue against waiting for Konqueror compatibility, as long as it works at least well enough to be usable at all, or degrades gracefully. If it's standards-compliant JavaScript, the bug is up to the Konqueror developers to fix, it's not the web developers' responsibility. (...and the Konqueror devs have explicitely said so.) Don't work around Konqueror bugs, rather write up a bug report on bugs.kde.org and wait for it to be fixed. That's better for the web, and better for Konqueror as well.
On 1/25/07, Jakob Petsovits <jpetso@gmx.at> wrote:
On Thursday, 25. January 2007 16:36, Syscrusher wrote:
I do, too, in concept, but the point I'm making is that they are not fully browser-independent yet.
I'm a heavy Konqueror user, but I would argue against waiting for Konqueror compatibility, as long as it works at least well enough to be usable at all, or degrades gracefully.
I also use Konqueror a lot, and like it a lot. In some cases, it is better than FireFox. However, being pragmatic, I realize that its market share is too low and can be ignored completely due to that.
On Thursday 25 January 2007 11:27, Jakob Petsovits wrote:
If it's standards-compliant JavaScript, the bug is up to the Konqueror developers to fix, it's not the web developers' responsibility. (...and the Konqueror devs have explicitely said so.) Don't work around Konqueror bugs, rather write up a bug report on bugs.kde.org and wait for it to be fixed.
That's better for the web, and better for Konqueror as well.
I agree with this, but have found that most standards-compliant JS works fine with newer versions of Konqueror. I didn't mean to ask that anyone specifically target working around Konqueror bugs, only that we ensure that the JS code is truly standards- compliant, rather than "nonstandard but works on Firefox and IE". I haven't examined the DnD example code, so I don't kow which category defines it. If the former, then I agree it's Konqueror's problem not Drupal's. Scott -- ------------------------------------------------------------------------------- Syscrusher (Scott Courtney) Drupal page: http://drupal.org/user/9184 syscrusher at 4th dot com Home page: http://4th.com/
On Wednesday 24 January 2007 18:17, Stefan Nagtegaal wrote:
What I *do* know is that the .js files of the Interface library are quite big. So I encourage you to build a patch for core based on the js-functions of interface which are quite good/stable imo..
This was what had me thinking that the target for this project was eventually core. :-) Again, sorry if I misunderstood Stefan's meaning. Scott -- ------------------------------------------------------------------------------- Syscrusher (Scott Courtney) Drupal page: http://drupal.org/user/9184 syscrusher at 4th dot com Home page: http://4th.com/
Op donderdag 25 januari 2007 00:17, schreef Stefan Nagtegaal:
- sortables demo: http://interface.eyecon.ro/demos/sort.html A note of caution: these hang both my firefox (making it deadslow, after a wile renicing to normal, in fact) and konqueror (causing konq to present a warning about possible ugly JS; asking the user to confirm killing the JS for that domain).
Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
For everyone's information: The jQuery interface demos at http://interface.eyecon.ro/demos work flawlessly in my installations of Firefox 2.0, with no performance downgrade, while working with many other windows open, including several with fckEditor. No problems with speed. I have the web developer plugin running also, as well as the tidy plugin. On Konqueror, it works also, with the error message limitations mentioned here earlier. Victor Kane http://awebfactory.com.ar On 1/25/07, Bèr Kessels <ber@webschuur.com> wrote:
Op donderdag 25 januari 2007 00:17, schreef Stefan Nagtegaal:
- sortables demo: http://interface.eyecon.ro/demos/sort.html A note of caution: these hang both my firefox (making it deadslow, after a wile renicing to normal, in fact) and konqueror (causing konq to present a warning about possible ugly JS; asking the user to confirm killing the JS for that domain).
Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
On Jan 24, 2007, at 11:44 AM, Ken Rickard wrote:
I've been working on one for my project, using the interface jQuery plug-in, 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)?
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
Ken Rickard wrote:
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)?
Well when developing the UI for WebFM (which has a drag and drop as well as right-click context menus triggering event) we asked ourselves (and the toronto drupal user's group) about when certain actions *should* be triggered. In the case of WebFM - when attaching a file to an existing node via a right click operation - we *could* have very easily attached the file (and updated the node) as soon as the action was taken (and in fact this was our first instinct). But the consensus was that users expected that the attach (or even an attachment re-order) operation should only happen when the node was saved by the user clicking on submit. The use case: User goes to edit a node User starts attaching new files (or re-arranging existing attached files) with the tool. User then decides - they don't actually want to change the node after all. User clicks away. User later discovers that even though they didn't click 'submit' - changes had been saved. Certainly an unexpected result. So I think any setting that *could* be changed via drag and drop should only be changed with an explicit 'submit'. andre
participants (12)
-
Andre Molnar -
Bèr Kessels -
Gerhard Killesreiter -
Jakob Petsovits -
Ken Rickard -
Khalid B -
Larry Garfield -
Laura Scott -
Michael Favia -
Stefan Nagtegaal -
Syscrusher -
Victor Kane