Drag and drop menu structure

+1

AHAH reorder of weights under only one parent would be great (provided all the children come along, of course.)

Subscribing.

^{ben Agaric Design Collective}

Hi.
Perhaps http://interface.eyecon.ro/demos/drag_drop_tree.html would be a good starting point for moving a complete group.
Something like this:

table = $('#menu-overview');
$('tr', table.get(0)).each(
  function()
  {
    // select all <tr> that start with same class/id as the current <tr>
    subbranch = $('...');
    if (subbranch.size() > 0) {
      // add these "child" <tr> to the items that needs to be dragged and do all other magic...
    }
  }
);

I have to do some testing but it should be possible somehow.

Thanks for making this a form I am using this to patch http://drupal.org/node/178608 . But please note that you have removed the pager from the overview form -- this is not going to work, the menu links table can have hundreds of thousands of items in it for any given menu.

Then again, I am wrong, the pager_query is still there just the theme pager is not. Sorry.

Bah, didn't figure out immediately that I needed to rebuild my menu.

It works very nicely.

The same problem as for the blocks dnd applies: no auto-scroll at the top. Another concern is that you have to point below a valid parent to be able to drag a menu item or a tree of menu items to another location, i.e. for as long as no valid parent has been pointed at, you don't get much feedback about what exactly is happening. Ideally, you'd see the menu tree being dragged along. But I'm not sure that's possible.

Patch needs a re-roll and probably some simplification because of the blocks patch got committed..

Quicksketch, I'm looking forward to test this! :-)

subscribing.

Drag'n'drop for reordering of menu items is even more exciting than the block admin stuff. (subscribing)

Subscribing. Poke me when you need Konqueror testing and I'll see what I can do. :-)

OK, get this rolling! I think it is important to have consistent UI elements in Drupal, so it would be great to have table DND for menus. I am also looking forward of this patch fixing the UI issues I mentioned in http://drupal.org/node/178608 which are admittedly not critical, but make the page look ugly when wide.

Here's the re-roll!

This works as expected. Please test!

In firefox and IE7:

I have to click and hold on an item to drag it, then release and click again to drop it in place, otherwise it keeps dragging even though I've let go of the mouse button. This is different to the blocks implementation (and the blocks implementation seems right to me).

Also, do we still want manual weight settings in admin/build/menu/item/121/edit? Do we still want drop-down parent items there with the full menu tree? I'd expect weight to be hidden unless I had js disabled, and I'd expect parent items to be a select list of "Naviagation, Primary Links, Secondary Links" to swap items between menus. There may be good reasons for keeping them as they are though so those are minor complaints.

Subscribing. This will bring so much usability magic to D6!

Ok. Been putting this through the paces. Overall this looks *really* solid, which tells me we did a good job testing the original drag and drop patch. :)

Two minor issues. For testing purposes, I have the following hierarchy:

My account
  - Content Management
    - Content
      - Post settings

a) I can't move anything under "My account" above "My account" with the mouse. "My account is the first menu item in the list.
b) Using the keyboard shortcuts to move "Post settings" further up the page, it is staying indented at the same level, not outdenting appropriately as I move it up the tree. Ironically, it *will* let me move Post settings above "My account", though, with the keyboard. Weird.

One thing I also pointed out, though I'm not sure it's really a bug, is that it's kind of weird that checking checkboxes doesn't trigger the yellow "you changed this row" behaviour. I understand *why* it doesn't do that (it's not JS, and on all other forms you need to click the button to submit it), but it looked a little odd so I figured I'd mention it.

Oh, and the last thing was I added the "Log out" link under "Administer > Help." This effectively hid it from user 2's view. I talked to chx about it and he said the "bubbling" behaviour from Drupal 5 was not carried over to the new menu system, so this is by design, and has nothing to do with this patch.

Just wanted to send a pointer to Tao Starbow's Quick Admin Menu module that tries to address a number of usability issues.
Here is a very brief demo screencast that I did to show how he implemented hierarchical menu sorting: http://blip.tv/file/get/Kentbye_tech-QuickAdminMenuDemo680.mov
On the backend, he actually splits a table row into three sections to see if it should either go before, as a child, or after. He has some interesting hovering UI tricks to make which one your selecting more clear.
He also has some other icons for deleting, disabling & renaming menus. And also a dialog box interface for creating new menus.
He's said that some of his approaches don't degrade well without javascript & he's using some jQuery UI stuff, but it's probably worth checking out some of the work he's done on pushing the envelope on the menu sorting UI.

Great work taking this (and book!) on quicksketch. It all looks lovely, tested in the following browsers and found some issues though.

XP:
Firefox: everything's lovely except a minor delay seeing the drag icons when the page loads, equates to a small layout shift when the page fully loads.
IE7: can't drag left or right - only up or down. However using key strokes it works.
IE6 (on win2000 fwiw): Same as IE7, plus some weird shadowing of the draggable icons (increase text size to largest to see this clearly, otherwise it's just a dot).
Opera: same as IE7 but I don't know how to tab to links.
Safari 3: see Opera.

Wow, this is really exciting work! Huge congratulations on getting drag & drop into D6 with the blocks patch.

The patch isn't applying cleanly against head this morning, conflicts in common.inc and system.css

Boy, now I am inspirited to see if I can get modal popups in.

I just wanted to follow onto starbow's comment of modal popups, which are demoed at the beginning of this screencast referenced above.

I asked on IRC about any previous discussions about jQueryUI getting into D6, and it looks like it doesn't have much of a chance just because it is such a moving target. The consensus seemed to be to wait until it matured a bit more to prevent having to have a required jQueryUI update module whenever the latest versions come out. jQuery namespacing features could possibly address this, and there'd have to be some pretty compelling UI functionality and wider support for it to happen.

But if modal popups could be achieved without requiring jQuery UI, then I'd say create another issue and see if others here could help support and get it in.

Patch fixes everything I spotted except this IE6 issue (only noticeable if you increase text size above medium). The duplicate images disappear when you mouseover, if that helps.

Sorry cross posted. Minor IE6 issue isn't important enough to stop this getting some more reviews.

I didn't find any bugs with Minefield 3.0b2pre except that there's no indentations when viewing a fresh page (i.e. when you haven't moved anything around). It feels a bit awkward moving an item up a tree since the "hotspot" seems to change depending on the amount of indentation, can this be improved in any way?

quicksketch: most of your explanations in #25 and #34 are invaluable. Move it to the code comments! It really helps one understand what is going on. The existing code comments are not bad, but they could be more verbose. I know it would help me.

I've tested this patch on Firefox and Safari. Spent 15 minutes playing with it. It blows my mind. I want.

I'll look at the code in more detail shortly.

Tested patch in #34.

Only outstanding issue found in Opera 9 where dragging left/right still doesn't work ("keying" works fine).
IE6 works but freezes for quite a while when dragged. All others (Safari 3, Firefox 2, IE7) works fine. Really cool!

Two UI ideas:
1. Might be useful to get a hint when trying to drag to a disallowed area. Attached an example where the background turns light red. When using keys this could be fired on keypress, and turned back to the previous bgcolor on keyup. And similar when dragging.

2. This idea is inspired by tab drag in IE7. IE is not using a "ghost" version of the tab (like Safari, which I prefer, but technically impossible (?) in our case). Instead an icon follows the cursor when dragging. The move cursor have the same intention (indication a drag) but this could possibly make it more obvious. Unlike block DnD where the row follows the cursor, menu DnD can have quite a distance where the row isn't following the cursor.

I looked at the code and it looks good to me. If this works on all browsers and if this degrades properly, it's RTBC.

Re-rolled to keep up with HEAD.

Also slightly tweaked CSS. This closes the small gap in Firefox for the the tree image. Adopted the same margin/padding for the handle, which also had a small gap on the menu page (strangely enough not on the block page, but this works there as well in my tests). Finally added height which makes the tree images display correctly in Bluemarine.

Tested in Opera, Safari, Firefox IE6/7 on Win.

- Patch in #48 has one hunk fail in menu.admin.inc line 31. It's just a typo change to add a space after an equals sign, so no biggie and trivial to fix.

- Tested in Konqueror. Everything appears to work correctly. I was able to move a menu item to be the parent of its current parent in one go, and it still worked. Assigning menu items to be the first in the page worked, too. If anything, it seems smoother here than it did on the block admin page. I'm assuming everyone else has already tested the hell out of it in other browsers. :-)

- With JS off it all still works, but the "parent" textfield column is very confusing. I don't know if it would be possible to hide it without breaking other things. I do like having weight on this page either way, as that's FAR more sensible and usable than doing it on each menu item edit screen.

Unless someone has a brilliant idea for how to hide the parent textfield from non-JS users, I'd say this is ready to go.

You could use the html.js switch to hide the textfield:

.menu-plid {display:none}
html.js .menu-plid {display:block}

The column would still be there though (doesn't have a class defined) and no menu.css to put it in. quicksketch?

testing the patch in #40 - am I missing something? In FF 2.0 and Safari under Mac OS 10.4 on the admin/build/menu-customize/navigation page, all the menu items are aligned to the left - the parent-child relationships are not reflected in the indenting.

I have created a patch that creates modal dialogs and put together some cool uses cases involving the new drag and drop blocks page. I would love to get your feedback.

http://drupal.org/node/193311

ps. This is my first core patch proposal, so please let me know if I made any rookie moves.

Hidden element sounds like the right approach, and I think it's the right move here. This is sort of an edge case, but as long as the parents are only numbers (and not titles for example) none will use it, and are better off hidden.

I just tested this again in Firefox 2 on Ubuntu and Minefield on Vista, and the menus are not indented at all when viewing a menu list. It indents correctly when dragging things around, but doesn't save. I cleared the cache to be sure, which had no effect.

Another thing, the 'Enabled' column should be switched with the 'Expanded' column, since enabled is more important than expanded.

playing with this more (after fixing the cache problem) - it's a really nice piece of work, but I think the UI is still going to be confusing. The parent-child relationships are not necessarily evident from just the indenting. I almost feel like the connecting lines that show when a parent and children are dragged should show most or all of the time.

I tested and liked very much what I see. When the connectin' lines are visible and the order of checkboxes can indeed be discussed as a followup.

FWIW, I had to disable Page compression to get the indenting to work correctly, it was enabled by default at Site configuration > Performance. It should be safe to turn it back on after the changes take effect.

Tested this patch extensively with all kinds of drag and drop operations, and the operation looks fine. Although I don't like the enable checkbox being on the right (instead on the left of the row), but I understand the drag handles need their attention there, so committed. Great work!