I have created a mockup of how, IMO, the menu administration can be improved without too much work.
First of all consistancy: We are dealing with hierarchy here, so we should stick as close as possible to the UI of that other heoerarchy: taxonomy.
Because my UI designer lacks easy ability of adding tables, I used an exact screendump of the taxonomy listing UI. You should replace (in your head) the words taxonomy with "menu container" and the word "term" with" menu item. The edit etc links are the same. Only the "edit menu container" links, show the exact same edit form as the "edit menu item" links.
Comment | File | Size | Author |
---|---|---|---|
#2 | menu_ui_annot_2.png | 50.37 KB | Bèr Kessels |
menu_ui_annot.png | 123.54 KB | Bèr Kessels |
Comments
Comment #1
jhriggs CreditAttribution: jhriggs commentedPersonally, I would rather go the other way. That is, I don't like the look of the taxonomy listing. I think it would look better as a table similar to the menu listing. I do agree, though, that consistency is important, so either way they should look similar.
Comment #2
Bèr Kessels CreditAttribution: Bèr Kessels commentedjhriggs is right about the listing. I will keep my hads off them for the time being.
JonBob had some good comments about the UI, this new mockup resebles these.
What i also did not mention yet, is that the menu types will contain a sensible selection. Not just any type can be chosen
what I will do, is find a sensible list of allowed types. So that the menu-types dropdown will, e.g. not contain MENU_CALLBACK, MENU_SUGGESTED_ITEM and MENU_NORMAL_ITEM
also, if you check the flag menu container, the select wisth the options will be ignored. The help text should explain this. Greying out would require javascript, or extra page-loads, which i think is not an option.
Comment #3
Richard Archer CreditAttribution: Richard Archer commentedI agree that more consistency is required, and that changing menu.module is the way to achieve it.
@see http://drupal.org/node/37328
Comment #4
Bèr Kessels CreditAttribution: Bèr Kessels commentedDo you need new mockups?
Comment #5
Richard Archer CreditAttribution: Richard Archer commentedBèr, the pictures you posted (nearly a year ago) still show how this could be improved. It's funny how some things in Drupal move so quickly yet others are so slow...
I think the admin/menu changes I have in mind are more extensive, but these two issues are related. In fact, I'll merge these two issues.
Comment #6
Richard Archer CreditAttribution: Richard Archer commentedI agree that the admin/menu page could be improved. It should follow the interface used in other admin pages that manage a hierarchy of elements. Such as admin/contact or admin/taxonomy.
When you load the admin menu page you would be shown a list of menus. The local task tabs would be 'list' (active), 'add new menu' and 'reset menus'. The body of the page would contain a list of menus with text links 'edit menu' and 'edit menu items'. No menu items would be shown.
'Edit menu items' would bring up a new page showing the hierarchy for that menu. Secondary local tasks would contain tabs for 'list' and 'add menu item'. The body of the page would allow existing menu items to be edited.
One gotcha that I can already see... on editing and saving an existing menu item, if you've changed the menu that contains that item, would you be returned to the edit menu page for the old menu or the new one?
A motivator for this change is that currently the "edit primary links' link points to admin/menu. Ideally this would point to admin/menu/edit/nn so that it is obvious what needs to be done to configure the primary links menu.
Drawbacks of this change include:
Comment #7
eaton CreditAttribution: eaton commentedI agree wholeheartedly. The hassle of extra clicks when moving an item from one menu to another is minimal compared to the confusion of seeing EVERY menu item in EVERY menu the moment you hit admin > menu.
Comment #8
LAsan CreditAttribution: LAsan commentedAny progress in this task?
Anyone to assign it?
Comment #9
sunComment #10
dcam CreditAttribution: dcam commentedClosing old issues. I'm pretty sure a UX discussion from 10 years ago isn't relevant anymore.