Menu name = node title upon node edit through user interface

I suggest the approach from http://drupal.org/node/195014#comment-1048978 implemented in Drupal.

Alright, here's my take on it:
I've added a checkbox to the node form titled "Create a menu item for this node", which additionally has "(Un-check to delete)" if there is already an item.
And the menu link title is optional, titled "Menu link title (defaults to node title)"
that's basically the gist -- I think this solution will be intuitive, and easier.

check out the attached screenshots for more info

Given that menu items are not intrinsically connected to nodes, and are in fact only created along side, I don't think it makes sense to tie them together too closely -- it would suffice to automatically fill in the menu title, when none is given. Once the menu item is created, there's no way of knowing whether you wanted it to match the node title.

I like the idea. Thanks for working on it, jabapyth!

I didn't test the patch but here's a short code review:

+    $form['menu']['create'] = array(
+      '#type' => 'checkbox',
+      '#title' => '<b>'.t('Create a menu item for this node.').(!!$item['mlid']?t(' (Un-check to delete)'):'').'</b>',
+      '#required' => FALSE,
+      '#default_value' => !!$item['mlid']

We don't use <b> tags in Drupal. Also, let's just drop the "Un-check to delete" part. It's quite clear that if you uncheck the "create a menu item" checkbox, the menu item is removed.
And there's a comma missing after #default_value.

+      '#title' => t('Menu link title (defaults to node title)'),

Instead of writing "defaults to node title", let's add a little bit of javascript that automatically updates the menu title field when the node title changes (but only if it was previously empty or identical to the node title). Much easier to grasp UI-wise. Fallback to using the node title if the field is empty is fine (so it also works when javascript is disabled).

Please use Drupal's code style througout the patch (e.g. add spaces before and after ? and : and before and after . when concatenating strings).

Now, that's a point for discussion. So far there's no direct link between node titles and menu link titles at all. This patch here doesn't add a real link either, it just makes it easier to create a menu link with the same title as the node, this being the most common scenario. I think it is fine to leave it at that for now. That means, just prefilling the menu link title field in the UI but not creating an actual connection between menu links and node links.

@Frando I agree with Aren, I don't think this should be handled by javascript -- it needs to be able to degrade. If we take out "defaults to node title" and the user has js turned off, there's no way for the user to know that it would default to the node title.

Some reasons for using Javascript to propose the menu name:
Your node title is:
The Assassination of Jesse James by the Coward Robert Ford
You want to delete a few words. The menu will be the shorter:
Assassination of Jesse James

You have several nodes with titles similar to:
The Life and Times of Jesse James
You want to organize the nodes as:
Jesse James childhood
Jesse James marriage
Jesse James death

If Javascript loads the menu name with the node title. you can then use those words as is or modify them slightly. I setup dozens of Web sites with the javascript mentioned in http://drupal.org/node/195014#comment-1048978 and most people create menu names of the following three categories:
a/ The node title unchanged. The Life and Times of Jesse James
b/ The node title with minor words deleted. Life of Jesse James
c/ The node title with major words moved to the front. Jesse James Life and Times

a is possible with PHP code and Javascript. b and c are possible with Javascript.

My bad, should have found this issue before, I basically came up with the very same mockups on my own as shown in #3. Good thing is: there is lot of similar thinking in Drupal community.

Background: http://sprint.drupalusability.org/content/populate-menu-item-node-title

What this proposal tries to solve:

1. Fix the problematic usage pattern: users focus on menu selection and forget to set the title, they submit the node with no errors and their set menu item "disappears"
2. It's not clear how to disable and enable the menu "feature" on node

The solution:

The solution is proposed in attached mockup.

- there is a checkbox control "Add this content item to a menu" (requires text review) in top of the menu settings form
- rest of the menu settings form items are disabled by default
- when user clicks on checkbox, two things happen:
-- menu setting form items turn enabled
-- if node title is entered, it's fetched from there and populated to "Menu link" field. There is no dynamic syncing of title field and menu title, it just a "js copy-paste", run once.
Existing interaction pattern in Drupal: site and user/1 e-mails in installer

Also note that Menu title is a required field, but it should not raise validation error on submit when "Add this content item to a menu" checkbox is off.

I would go further than disabling the other options, I would actually hide them altogether, until the checkbox is checked

also, the way it's used right now on the configure site page during the install is onblur, which wouldn't be desirable for a checkbox, since then it wouldn't fire untill the user clicks something else

so either we have to change the copyFieldValue behavior to take an argument of which type of event (onblur, onclick, onchange, ...) or we would have to make another (pretty much exactly the same) behavior for the checkbox

I would personally prefer making the behavior more generic and take an extra argument, because otherwise we will be in this position again and again untill we have a behavior for each event

ok, so reformatting the behavior wasn't that hard, I changed it so instead of using this:

drupal_add_js(array('copyFieldValue' => array('sourceFieldId' => array('targetFieldId'))), 'setting');

u now use

drupal_add_js(array('copyFieldValue' => array('sourceFieldId' => array('eventName' => array('targetFieldId')))), 'setting');

tested with 'blur', 'click', 'change'

'hover' will not work for obvious reasons, you will have to use 'mouseover' and 'mouseout'

it still needs work to be more generic, as now it only copies the field value when the target field is empty, and I can imagine that some things might wanna specify a conditional as to when to do it and when not to

for instance, if the target field would have a starting value of 'none', one should be able to specify 'none' as the empty value

but for now I'll try and see if I can use this same behavior for the menu name thing

ok, I just realised this is rather useless for the issue at hand, because in the issue, the element (the checkbox) the event is bound on, doesn't have the value that needs to be copied, whereas on the site configurations page during the install, the element (the site email address field) the event is bound on, does hold the value that needs to be copied

so for it to be really generic, we'd need to have 5 parameters: the eventElement (the element to which the event is bound), the event ('blur', 'click', ...), the sourceElement (the element that contains the value to be copied), the targetElement (the element where the value gets copied to), and I think it might also be interesting to be able to specify what the "empty" text is (like 'none' or w/e)

I don't think you should assume that the user (or whatever) always wants the menu title to update when the node title changes, but I do understand that this issue needs some pondering

Compared to the content type and taxonomy term machine readable name, I guess user should expect similar behaviour on node menu entries. So the menu entry title would be automatically copied from node title, while the menu entry title form is not expanded. As this works independently of insert or update in content types and terms at the moment, this behaviour should be used for the Menu entry too.

The currently in work #503816: Make form elements expandable may take some part of this issue.

I personally think that syncing the menu title and the node title on the backend is something for contrib.

Core never changes node titles without the front end, so if a module changes a node's title, it's the module's responsibility to sync the menu title if desired. I can't think of any way to have it sync it on the backend while allowing the user or module to override this behavior and prevent the menu title from being changed.

RE #20.
Number 3 is always precisely what I want and expect, not bizarre to me.

I've always seen this as a UI convenience. If js can help us, then when you enable a menu item the first time, it gets filled in with the node title. You then get to choose a shorter name by editing the menu title. This is a incredibly common scenario for me.

A page titled 'About Our Company' becomes 'About' in the menu.
A page titled 'Contact Us' becomes 'Contact' in the menu. etc..
So it's handy that the long version get filled in when it's being created. If you care, maybe you edit it shorter. If not, the default title is there. Just saves typing.

If you change the node title later - there is no expectation that the menu title needs to change. If you manage to put things out of sync badly though manual renamings... well it's no worse than the current behaviour.
I see no need for anything on the server side. This is simply a UI assist, not code logic.

Changing the menu mysteriously would be much more confusing than noticing that it simply hadn't been renamed when the title changed.

We do not auto-update menu title, it's purely one-way, triggered by [x] add this content item to a menu checkbox

Patch contains the desired implementation.

The delete menu item checkbox is replaced by the uncheck functionality of the 'Add this content item to a menu'

Tested, an edge case found:

1. User checks "[x] Add this content item to a menu"
2. Menu title is populated
3. User manually cleans menu title field
4. "Not in menu" is displayed in vertical tab summary <-- this is wrong, "[ ] Add this content item to a menu" should be in charge of changing vertical tab summary
5. When saved a node and reloading edit screen, the "[ ] Add this content item to a menu" have lost is checkbox

Suggested behaviour

1. User checks "[x] Add this content item to a menu"
2. Menu title is populated
3. User manually cleans menu title field
4. Nothing is displayed in vertical tab summary
5. When saving a node, the "[x] Add this content item to a menu" setting is preserved and node is saved with a node title as menu title.

Other feedback:

- Remove "Leave blank if you do not wish to add this post to the menu." from Menu link title description

- [ ] Add this content item to a menu. <-- remove "."

Screenshots added

Checking Drupal.checkPlain works fine but when submitting <&>; placed in the menu as a link <&>; but the title is only a semi-colon ; instead of the expected <&>;. Guess it's another bug.

I applied the suggestions. Removed the "blank..." text. And dot.

The Menu title is repopulated with the node title when the checkbox is checked and the menu title is emptied.

@Arem Cambre = Yes and Yes. And I think we decided not to adress those two edge cases - since then its a big ass 10% case patch and not solving it for 90% of the use cases.

I am guessing that it doesn't really confuse users - at least not worse as now.

some odd behavior I noticed on FF 3.0.11 on vista:

1. fill out 'something normal' as title
2. check the checkbox
3. the value of the menu title field will change, but the summary will keep saying "not in menu"
4. focus the menu title field and now the value will change
5. change the title
6. focus the menu title field, and it, nor the summary will change

and there was another issue:

1. fill out 'something normal' as the title
2. check the checkbox
3. change the tile
4. uncheck the checkbox, the menu title field won't change, and the summary changes to "not in menu"
5. check the checkbox, the menu title field will change, but the summary won't

after adding some console.log's I noticed the setSummary was called before the node title was copied to the menu title field, so the value the setSummary callback was getting wasn't updated yet

attached patch will produce following behavior:

1. fill out 'something normal' as title
2. check the checkbox
3. the value of the menu title field will change, and the summary will also change
4. change the title
5. focus the menu title field, and it, nor the summary will change
6. uncheck the checkbox, the menu title field won't change, and the summary changes to "not in menu"
7. check the checkbox, the menu title field will change but the summary won't, which is still an issue

I'm sure there's a way to trigger the summaryUpdate, but I can't manage it right now

also turned a tab into 2 spaces and changed the doit function name to changeFieldset

This functionality is a improvement. +1 based on the screenshots.

I'm wondering if we can do better on the interface text. "Add this content item to a menu" seems wordy and lacks context. "Content item" also could add confusion (user: "what's a content item?") Here's a few alternate options:

• "Add to a menu" - Short and sweet. Sidesteps "content item" by not mentioning the concept.
• "Add this content type to a menu" - Adds context
• "Add a menu entry for this item" - Slightly reworked.
• A better suggestion from you goes here...

"Add a menu entry for this item"
= Most accurate to me.

Maybe "Create a menu item for this content-type"

Not perfect, but only because the whole menu vs node dichotomy is slightly unintuative. No serious diff between add/create/(provide?), just a thought.

+1 for "Add a menu entry for this item"

mainly because the forms "Create a menu item for this [content-type]" and "Add this content type to a menu" create translation difficulties in some languages where the demonstrative (the "this" in "this page" or "this newsitem") would depend on the gender of [content-type]

-> http://en.wikipedia.org/wiki/Demonstrative#Demonstrative_series_in_other...

Off-topic ...

...translation difficulties in some languages where the demonstrative would depend on the gender of [content-type]

Is this very common? I'm familiar with a few gendered languages, but often there is an almost-acceptable generic/neuter or rule that can be used?

french:
this page -> cette page
this event -> cet événement
this product -> ce produit

german:
this page -> diese Seite
this event -> dieser Veranstaltung
this product -> dieses Produkt

spanish:
this page -> esta página
this event -> este caso
this product -> este producto

but I think this is more of a fundamental flaw in the way we use tokens in translations so not that related to this issue, but rather to translation formatting in general

Coming back from Utrecht I just occurred to me in the train that we have _almost_ similar interface in the core -- and spatially very near to menu setting vertical tab: book outline. Books as container of outlines are very similar to menus as container of outlines, "Book: " dropdown value reflects similar state as "[ ] Add this content to a menu", there is similar jquery magic going on, when selecing certain book: "Parent item" dropdown appears by slide animation etc.

I would hate to see two almost similar but different interaction patterns in core. I see two ways out:

a) model our menu settings tab interface to be similar to book outline settings: it's essentialy "book outline ui lite"
b) refactor book outline to be similar to our proposed menu settings

I will try to come up with both mockups.

And yes, ultimate goal would me totally integrate user-created-menu and book concepts, those things are just way too similar. But baby steps first.

@41: the way this works in book is that it adds an extra submit button which works sorta like a preview (which is only visible when js is disabled) and part of the form is ajaxed in

when discussing this menu name functionality, I heard most ppl opting to show a grayed out form rather than nothing when the checkbox isn't checked

if we want it consistent with the way it happens in book, we can only copy the value when the checkbox is checked (as the form values are passed on to the AHAH handler), and the way the vertical tabs summary works, would make it rather hard since the field the summary is bound to wouldn't be on the form when the page loads

I'll try making some screenshots to clarify what I mean by all this

@41 : What do you mean by baby steps? ... do you want this to get committed or not? That's unclear to me.

@42 : I don't copy :p

if (@41.wish == commit) {
  @42.create( new issue)?
}

Hi, I stumbled upon this issue looking for requests fo UX improvements for menu handling. Here's my proposals on the issue, whose scope may be a bit larger than the original request :

- I'm 100% backing the "checkbox on the node form" approach. Then if the menu title is kept empty it will default to the node title. If one enters a custom menu title, the custom title will be used.
Bonus: Being able to use tokens in menu titles would be a huge plus, and a move towards consistency (indeed an empty menu title would default to [node-title])

- Can a cron run take care of synchronizing the menu title with the node title, if the node title was edited from outside the node form?

- For a better UX, a setting could be added to the content type form, where one could select if the "Add menu entry" checkbox would be checked or unchecked by default for this content type, thus choosing which content types we want to create a menu entry by default for.

- Currently, one can only choose, as a site-wide setting, under which menu new entries will be created by default. A select list option could be added to the content type form, so one could be able to choose, by content type, under which menu entry the current entry will be created by default. It doesn't really add complexity, and it saves users from having to remember each time where to put the menu entry (or at least it points them to the right direction). This kind of little things really help. Another benefit is that it can serves as a good starting point for people that want to hierarchize content.

@mdupont: See #351249: Finer control over the Parent Menu select box -- some of your ideas might be reflected here

@clemens: sorry for being confusing. I will upload new proposal for UI tomorrow, hold on until then.

@kika could you still upload that UI?

What is the status of this issue?

There are several existing issues and problems listed in drupalusability.org. Could some potentially be resolved through this? Are we reviewing #35 or does this need more work as kika suggests?

I made a video of patch #35 by seutje - this is so other people can respond to it without needing to apply the patch.

Menu name = node title
http://vimeo.com/6557401 (currently processing)

It demonstrates some concerns. Namely, if you change the menu name, save, then edit the item, it reverses your changes.

I tried this patch, and to me, it looks like it is introducing confusing and unwanted behavior.

Yup, we might have created an interaction that is too smart. I am not sure how this will test, but I am also worried about the effect it has for Verity her menu choosing?

one would still need a checkbox then, otherwise it would be impossible not to create a menu item for the node

As suggested here? :
#322703: Use on/off checkbox to enable node's menu item

Just in case anyone else comes across this article, there is now a module for D7 that does this...

https://www.drupal.org/project/auto_menutitle