[wp-trac] [WordPress Trac] #11817: Better Site Menu Management

[WordPress Trac]

#11817: Better Site Menu Management
----------------------------+-----------------------------------------------
 Reporter:  scribu          |        Owner:          
     Type:  task (blessed)  |       Status:  reopened
 Priority:  normal          |    Milestone:  3.0     
Component:  General         |      Version:          
 Severity:  normal          |   Resolution:          
 Keywords:  has-patch       |  
----------------------------+-----------------------------------------------

Comment(by ptahdunbar):

 Replying to [comment:259 carlhancock]:
 > Why is the "Save All Changes" button right justified and the "Delete
 Menu" link left justified? My eyes keep going to the Delete Menu link and
 NOT the save link which isn't a good thing from a UI perspective.

 Taken from [http://wpdevel.wordpress.com/2010/02/25/menus-ux-manifesto/
 Menu Manifesto]:
 > Buttons. The Save button should use the primary button class (blue). It
 should also be furthest to the right. Delete should not be a button, but a
 red link, and to the left.

 Perhaps we could go with carl's approach as we didn't switch the columns.
 If anyone is against his way, comment now or else it's going in the next
 patch sprint.

 > Also, why is the button called "Save All Changes" instead of simply
 "Save Changes"?

 Valid argument. I didn't touch it yet as my thinking was that since the
 user can do a lot of changes (e.g. create links, and/remove items, and
 edit items), it made sense that the button reads: "Save all changes". If
 anyone is for leaving it how it is, comment now, the next patch will
 change it to "Save/Update Menu" so it's consistent with WP's UI
 conventions.

 > Since there is no "Trash" for Menus, it might be a good idea to prompt
 an approval dialog box when a user clicks on the Delete link.

 Done. I already started on the trash feature, but I need to consult Jane
 on the UI part.

 Replying to [comment:261 demetris]:
 > I am not happy that the TITLE attribute defaults to the anchor text.
 WordPress should stop doing that.

 Done.


 Replying to [comment:264 mrmist]:
 > Then I guess it's that that makes no sense. It shouldn't be falling back
 *and* creating a Menu 1. It should be doing one or t'other.

 Very true. Removing the functionality that creates a default menu. WP
 already defaults to wp_page_menu() as a fallback. Plus, it could get
 confusing when you have custom menus in your theme (basically anything pre
 3.0) but it's not using the new wp_nav_menu() API. Users can get confused
 that the default menu being shown in the backend isn't what's appearing in
 the frontend.

 > Confirmed. With a full "Menu 1" none of the menu edit/delete options are
 working (In IE6.)

 Keyword: '''IE6'''. No testing has been done on this ''9yr old'' browser.
 Perhaps it will during the accessibility pass, but don't take my word on
 it.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/11817#comment:267>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software