Description field missing in menu settings on node form

Right now the only way to manage menu item descriptions is from admin/build/menu-customize/ etc.

Furthermore Drupal automatically uses the description as a tooltip on menu items, thus when creating menu items from the node form you cannot suppress the creation of tooltips/descriptions bu leaving the form empty. You are forced to go to admin/build/menu and remove the descriptions manually if you don't want the infernal tooltips (that just repeat the node title, which probably not that helpful in any case).

I have searched around looking for similar issues but this is the closest old issue I could find.

Here's the way I see this:

1) allow menu descriptions to be added from the node form
2) if no description is set, it should be left empty and not do any trickery like using the node title as a tooltip etc.

I agree with 1), and from a usability perspective, this is a bug.

This should be a simple patch. Just add a description textfield to the widget/fieldset exposed for the menu link.

+1 for 1) in comment #1

Sub.

For anyone looking for a D6 solution to this, http://drupal.org/project/unique_link_title re-adds the description (in addition to letting you batch remove any link descriptions that were automatically generated by Drupal from the link title). Could use some testing.

here's a patch, I just copied and pasted the description form element from the admin form to the node form and changed the description. I left the fall back behavior to the node title.

Thanks! I hope that mcrittenden can also help to review this technically.

+++ modules/menu/menu.module	18 Jul 2010 03:46:30 -0000
@@ -637,6 +640,14 @@ function menu_form_alter(&$form, $form_s
+    $form['menu']['link']['description'] = array(
+      '#type' => 'textarea',
+      '#title' => t('Description'),
...
+      '#rows' => 1,

This should be a textfield. Not sure why it's a textarea elsewhere, but I suspect that's just straight another bug.

Powered by Dreditor.

ok, I changed both form items to text fields.

Patch looks good, except that I'm with #1 in that, if the description is left empty, the title attribute should just not be set (rather than using the node's title). Seems like that would be as easy as replacing this:

+      elseif (empty($link['options']['attributes']['title']) && !$link['customized']) {
         $link['options']['attributes']['title'] = trim($node->title);
       }

...with this:

+      elseif (empty($link['options']['attributes']['title']) && !$link['customized']) {
         unset($link['options']['attributes']['title']);
       }

Also, I'm not quite convinced that these should not be textareas. There are a few use cases I can think of (such as using them for fancy jQuery-ized tooltips, or using them for little hidden gems of information) where you'd want more than just a little bit of text. But it's not a huge deal, so if it's just me, then so be it.

Great work folks!

+1 for leaving the title attribute empty if the person creating the node doesn't specifically set it. I've read some usability blog posts on this (not Drupal related) and the strong recommendation is that you only should use the title attribute of an anchor tag when the link text isn't fully able to communicate what will happen when the user clicks on the link. Following that advice, the title attribute should never = the link text. If folks want me to look up those posts for more backup, I'd be happy to.

Regarding whether the form uses text textarea, I personally vote for textarea. Tooltips can do cool stuff with longer texts. But I think we should use whatever is used when you create/edit menu items via menu administration. I think that consistency is important.

Shai

ok, let's remove that totally hidden auto-node-title-to-link-description feature baked in here, and, also revert to a textarea (sorry!) -- I agree that consistency is required here, and, to fix/change it, both (or rather all) locations in core would have to be changed accordingly.

ok, I went back to textareas, and removed the behavior of automaticaly setting the description to the node title.

This looks good to me. Anybody else care to RTBC?

+++ modules/menu/menu.module	18 Jul 2010 21:54:43 -0000
@@ -508,9 +508,11 @@ function menu_node_save($node) {
+      else {
+        unset($link['options']['attributes']['title']);
       }

This unset() needs a comment explaining why it is here or needs to be removed.

Powered by Dreditor.

ok, I added a comment.

If that's all sun's got, then RTBC it is.

+++ modules/menu/menu.module	19 Jul 2010 12:05:02 -0000
@@ -508,9 +508,13 @@ function menu_node_save($node) {
+      if (trim($link['description'])) {
+        $link['options']['attributes']['title'] = trim($link['description']);
+      }
+      else {
+        // If the description field was left empty, remove the title attribute
+        // from the menu link.
+        unset($link['options']['attributes']['title']);
       }

Sorry, we need to extend on the why here. I don't understand why options][attributes][title should be set if the description field was left empty, or, why the menu link is altered, or, ?

Perhaps the logic is simple, perhaps we should move the comment above the entire if/else condition, so as to explain the situation for new menu settings in nodes and existing links retrieved for the node, possibly edited in the node form (or not), which are updated here.

+++ modules/menu/menu.module	19 Jul 2010 12:05:02 -0000
@@ -637,6 +641,14 @@ function menu_form_alter(&$form, $form_s
+      '#description' => t('The description displayed when hovering over a menu link. If this is left blank, the content title will be used.'),

Second sentence is outdated. Also, is it possible that this can be shortened?

"Displayed when hovering over a menu link."

EDIT: UX team input would be great to have for this description.

46 critical left. Go review some!

The flow on this is somewhat weird. "The description displayed when hovering over a menu link. If this is left blank, the content title will be used." We are basically stopping mid-sentence into a boolean construct. What about just?

"Shown when hovering over a menu link".

Not sure if its really necessary to display that the content title will be used. What is a content title anyway?

Not sure if its really necessary to display that the content title will be used. What is a content title anyway?

As sun said in #18, that part is outdated since we're removing this "feature" here. So yes, let's go with "Shown when hovering over a menu link."

sun, I am not sure how I can more clearly describe it. I think the comment there right now is perfectly clear. "If the description field was left empty, remove the title attribute from the menu link." that clearly, effectively, and efficiently communicates what this code does; that is to say, if the description field is left empty, this code removes the title attribute from the menu link. I am unsure what your objection to this is. can you be more specific in your critique, please?

in the meantime I have removed the no longer applicable notice about defaulting to the node title.

Looks ready to fly for me.

The last patch says "The description displayed when hovering over a menu link." rather then "Shown when hovering over a menu link." - not sure but I feel the last is more concise.

+1 for the language of the current patch. I think it is rtbc.

Agreed with #23. Saying "the description" on a form field called Description is redundant.

this is just the same description as displayed on the admin form item. I think we should keep it the same for consistency.

@glipay core is probally wrong.

"displayed" or "shown" - cuts this down to people who can see perhaps?

Both focus on behavior (displayed, shown, hover etc) - is this preferable to saying what it actually does, such as:

"The description is used in the title attribute (tooltip)."

I agree with @Jeff_Burnz. But I fear his suggestion raises some deep philosophical issues about the UI which I think are really too late to deal with this late in the dev process for D7. There will definitely be people who strongly disagree. I like what Jeff says because it is the most descriptive. But in order to understand it you need to know what the "title attribute" is and what a "tooltip" is. The node/add form is one of the most common backend forms used by end users who don't have technical knowledge.

So though I agree with @Jeff_Burnz that "shown" and "displayed" are both visual metaphors in a realm that we are trying to make as accessible as possible for screen readers etc... I think we should try to fix that language in D8 on both the menu admin form and the node/add form. I think they should be addressed in the same issue.

@Bojhan. As @Jeff_Burnz points out, "shown" is really no better than "displayed." And "displayed" is consistent with menu admin. Let's start an issue for D8 now to address the issue in both places, but not get picky here so that all of us can get on to the next issue so we can get D7 out the door.

Shai

Whatever. Totally over thinking it - this suggestion has nothing to do with accessibility, completely unnecessary to pull that into the discussion.

Right now it says "The description displayed when hovering over a menu link." - my suggestion "Shown when hovering over a menu link." is better. Its more actionable, starts with the trigger word rather then with stating the obvious.

There is no reason to be consistent with something bad.

But I honestly feel nothing for discussing this, off to RTBC.

Why don't we just change it to "Shown when hovering..." in both places, so we can be consistent and good at the same time.

fine, here's a patch with the changed text in both places.

Two things:

1 - Any notion of being displayed is wrong (titles are not always displayed).
2 - Use the indefinite article is grammatically wrong ("a" link - which would that be, this one, another one?).

Action is not good because you can never predict what that action might be - you can make a pretty good assumption, but technically its wrong. If I have no notion of what "shown" or "displayed" is how can I possibly understand what that might mean? If it tells me its going to be the content of the title attribute I can know exactly what it is.

@Bohjan - You have made your suggestion and it is appreciated, but unfortunately its pretty bad on this occasion, despite your assertion that it is better, I argue wholeheartedly that it is a very poor description indeed.

@Jeff I just don't get it why is stating the obvious at the beginning of the sentence better than stating the result? I may not be the best at creating these sentences but I do not understand the argument at all.

Saying things like "If it tells me its going to be the content of the title attribute I can know exactly what it is." I think you are completely misunderstanding our target audience, they do not know what a title attribute is. I am sad to say, but technical arguments are not at stake here - we are communicating this to humans, thus we should keep them first, before any technical arguments come into play - with them in mind the word "displayed" and "shown" both trigger a visual concept which to my knowledge would never be confusing - followed by the recognizable "when hovering over a menu link.".

Sub

+++ modules/menu/menu.admin.inc	20 Jul 2010 22:57:03 -0000
@@ -308,7 +308,7 @@ function menu_edit_item($form, &$form_st
-    '#description' => t('The description displayed when hovering over a menu link.'),
+    '#description' => t('Shown when hovering over a menu link.'),

I agree with 2) of Jeff, we're talking about the menu link the user is currently entering/editing. Thus, let's replace "a" with "the":

"Shown when hovering over the menu link."

+ be done with it, please.

Thanks, glipay, for constantly re-rolling with all of these considerations! You rock :)

Powered by Dreditor.

Any notion of being displayed is wrong (titles are not always displayed).

Yes, but 99% of the time they are.

Also, we're not suggesting "displayed", we're suggesting "shown", and to me, "shown" doesn't imply a visual as much as "displayed" does, so it could still apply fine to screen reader users.

Let's go with sun's #36 and be done with this. And yes, thanks glipay for hanging in there.

ok, I changed a to the.

Thanks!

I don't think we need a picture etc, looks good to go!

I would very much like a before and after screenshot please.

yoroy, I do not understand why you have reset the status. if you want to see how drupal looks before and after, why didn't you just try out the patch, and reset the status if you have any useful feedback?

here are the screenshots you requested. can we set the status back to reviewed & tested by the community, then?

Yes, we can.

Thanks, glipay!

Glipay, not everybody is able to apply patches. Especially with patches that alter the user interface it is good practice to attach before and after screenshots so that usability folk can review too. So thanks for posting them.

And I'm not convinced this is needed at all, it adds cognitive load to what should be a simple task. Creating a menu item already consists of 3 sub tasks (title, target menu, weight), and adding another one up-front is not an improvement. Especially since the description can be added after the fact through editing the menu item.

Creating menu items was one of the tasks people had the most trouble with in the usability lab tests of Drupal 6. Which means Adding options to the interface for doing it is *not* a way to fix that. Getting people to a completed task as quickly as possible is much more important than being feature-complete up front. Again, especially since the description can be added afterwards.

To me this is a won't fix, it adds cruft to the user interface without a clear benefit.

yoroy, see http://drupal.org/patch/apply for how to apply patches.

as for your "cognitive load" concern, I believe it is unfounded. what confuses new users about the menu settings is "what is a menu link?" and "what is the 'parent item' selector?" no one is confused by what a description is. the description field may even make users feel more comfortable with the menu settings, because at least they feel like they know what that is for. the usability problem with the menu settings is in no way worsened by adding a 'description' field. just because the current interface is hard to comprehend does not mean that all changes to the interface should be rejected because they don't improve the interface. in addition, this patch solves a much bigger usability problem; namely, there's no way to edit a menu link description for a node without going all the way to the administration menu settings. you seem to discard the notion that this field is necessary on the node form because 'he description can be added after the fact through editing the menu item', but in fact, many user will not know how to do this, and it is a lot of trouble for the users that do know how to do this.

so I don't agree with your statement that this patch "adds cruft to the user interface without a clear benefit." on the contrary, I do not think this adds cruft to the user interface, and I think there is a clear benefit to adding this.

Yoroy and all,

I'm someone who mostly loathes the description attribute of an anchor tag, but I still support this patch because it so easily maps the functionality of a hyperlink to a simple form, thereby making Drupal more usable, even if the form is longer.

I think we need to do a better job, in general, in communicating to users what designates a "required field" and that people should feel just fine leaving non-required fields blank. I agree it makes the form longer, but requiring people to go to menu admin (which that person may not have permission to do) is a huge stumbling block.

I would support putting the description attribute textarea in a fieldset which is "collapsed" by default.

Note that another important feature of this patch is that it changes D6 behavior by NOT auto-populating the description attribute with the node title. With this patch, it leaves the title attribute blank by default. That is a huge usability improvement.

Shai

Ahh, this is not actually a bug.

I am somewhat agreeing with yoroy here, that we are sneaking in a feature request with not clear usability improvement, having accessibility to a particular piece of functionality does not equal a usability improvement. But in this case might even make less sense, is there any reason this can't be handled by contrib? I never seen a high demand for this feature.

@glipay We are all simply assuming what is and what isn't confusing. Basing of the usability tests that where done on this, the confusing part is indeed the hard to understand concepts of parent item and weight. However on the subject of "descriptions" sadly Drupal does a very poor job communicating where its displayed, in this case we might have found a better labeling for this - it does not deny the fact that this feature is not asked for a lot and does bloat the interface, after all we are adding a patch that adds 40% more height and visual load to this screen.

I understand its somewhat buried in the administration, but to be quit frank its because we made it that way. Because its not important, the create content screen is an important page we should guard with our life for any possible bloat. This late in the process I am really not liking any patch that tries to add something not absolutely necessary to the create content page.

The way I see it this is actually less cognitive load - whats the alternative if we take the field away - we'll have a new usability issue to deal with (how do I add/remove a title?).

I like this mainly because the patch fixes the automagic node title as title attribute travesty of Drupal 6 and gives me control over the title attribute at the point at which I am creating the link.

To add a title or not is another decision to be made, I understand this, but really, is that big a deal? If we were suddenly adding token support for title attributes I would be getting worried, but this new field is not a lot of mental taxation in lieu of some very real benefits.

Unintended change of category.

This is a bug, because the description field is missing in the node form.

It's as simple as this: Your user, which all of you presume "can edit the menu link afterwards", exactly that user:

1) may not have the permission to edit menu links at all

2) will be kidding about Drupal's UX, if you consider it a good experience to do half of the job in one interface and having to go to a completely different location (if possible at all) to do the second half.

In this case, if you ever tried to work with this user interface in the real world, then you would know that this is simply a bug.

Bojhan, you said "having accessibility to a particular piece of functionality does not equal a usability improvement." the definition of usability is "the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use." therefore I have to disagree and point out that having accessibility to a particular piece of functionality means that users can more effectively, efficiently, and satisfactorily achieve their goals. I don't know where you're coming from when you say it's not a usability improvement.

Bojhan, you said "after all we are adding a patch that adds 40% more height and visual load to this screen." that is simply not true. firstly, even if we just count the vertical tab box, it is only increasing the height by a little over 30%. secondly, when we consider the whole page, this figure declines drastically. thirdly, the extra height is only visible when the vertical tab is selected and the check box is checked (it's unchecked by default). to claim that this adds "40% more visual load" is surely hyperbole.

furthermore, in addition to the usability improvements, this patch introduces some missing consistency between the admin interface and the node form. consistency is important for any application that wishes to be usable, and drupal is no exception.

cross posted, sorry sun.

Sorry, upon reading my follow-up again, it may sound a bit harsh, but wasn't intended that way.

However, also agreeing with the accessibility arguments. That's actually where I'm coming from: my content authoring and publishing users very well know that a link "title" attribute is important for accessibility, as well as SEO, but no, they won't get the permissions to alter the entire site's menu. Entering a meaningful link description is the job of the content author/editor, not the site administrator.

@sun You are right, and I am not arguing its the best user experience. I am just arguing that adding this will add clutter, thats probably unnecessary for such an unimportant feature. You and some others might think its critically important, but then again every discussion in Drupal someone finds it critically important - so I hope you understand I am not trying to defend a bad user experience, but merely adding clutter for the sake of a less used feature. Because at the end of the day, all those little bits add up - especially on something like the create content screen. I find your content editor argument very solid and more a reason for this to go in, not sure how representative the audience that creates tooltips for SEO/Accesiblity purposes realistically is.

@jeff And that is what worries me to, now we are adding something that kind of "needs" to be filled out to get something to show up. I am not really sure adding such a step is necessary, and automating it (making it more usable) would mean adding more elemtents to this.

@glipsy Sorry, but there is a large difference between perceived efficiency by bringing functionality closer and actual efficiency by bringing to much functionality closer, its a thin line but very important distinction. We are arguing on opposites sides of that line.

I am feeling somewhat attacked by you, I am going to ignore the definition statements and referals to consistency - its important in opensource to assume someone understands the topic at hand, makes for a far more intelligent discussion. I am obviously not stating that its not a usablity improvement I am merely stating that its not equal. There might be some improvement, but there are also quite some usability trade offs. One of them is the visual load - which is about it adding a very significant elements; textarea + extend textarea bar, and a description - especially it being a textarea adds a lot of visual load, because the first affordance is to enter multiple lines of text. Your literal assessment of my 40% height is somewhat foolish, sorry - obviously I didnt talk about the whole page or calculate the exact height.

To conclude is improving usability? Yes
Is it adding clutter? Yes.
Is it a feature that is highly needed? No.

Committed to CVS HEAD. More clutter! :)

We are doing two things here:

1) Removing the automagical link description added for menu links attached to nodes. Due to D7's new JavaScript to auto-populate the link text/title, this invisibly auto-populated description is total duplication. Invisible for sighted users, but most probably totally annoying for users with disabilities.

2) Allow users to enter a link description, if they want or need to, without requiring them to have administrative superuser menu permissions, which they currently need. And even if they have that permission, there's no meaningful way to get from the node to the corresponding administrative menu link edit page.

Both should be considered as bugs. Having personally experienced the lack of 2), and, trying to explain users how to get from the node they're editing to the administrative menu overview, drill down the target menu to the link in question, and edit that just to get that description in there (which many users also refer to as "hey, I want a tooltip when hovering!"), it's hard to understand how this improvement can be seen as problem.

In the end, i.e., speaking D8, we probably want to consider entities as entities, also consider a menu link as entity, and make that entire entity form for a menu link re-usable -- so as to be able to use it on its own, re-use it on node forms, other entity forms (taxonomy, user, etc), and finally: improve the user experience of that single, dedicated entity form on its own. Of course, nifty AJAX goodness and whatnot, but most importantly: consistency.

Lastly, although I've read and barely recall the previous input on that detailed question, I still think that the description field being a textarea is a bug on its own. We left it consistent in this patch, so as to not open another can of worms. We should open a separate issue to convert that textarea into a textfield (also in the admin).

Bojhan, I am sorry, I did not mean to attack you or anyone else in this issue. I was simply concerned with getting this patch committed, I did not mean to be condescending, I just wanted to reference some usability information in case anyone reading this issue lacked a background in usability and wanted to read up on it. in no way should this be taken as an attack, and again, apologies. I was also joking about the 40% height thing aside from the fact that it was hidden by default - bad joke, I guess.

resetting status to fixed, I do not think sun meant to reset status.

d'oh. :)

Someone up for that follow-up?

@sun beside that follow up, is there a D8 issue we can create here?

@glipay Its oke, no worries. Just for future reference I guess, really makes discussions more intelligent if one assumes such basic knowledge already exists.

Nope, what I mentioned with regard to D8+ will probably/hopefully be on the overall todo plan anyway. ;)

(informative only)

@Sun wrote:
However, also agreeing with the accessibility arguments. That's actually where I'm coming from: my content authoring and publishing users very well know that a link "title" attribute is important for accessibility

Actually most screen-readers will not read the title attribute of a link when there is also link text in the anchor. Also most keyboard only users will not get the content of the title attribute as it is usually only available to those with a pointing device.

This is why, for the Toolbar menu items, we duplicated the title attribute as hidden text (using .element-invisible) appended to the link text. This is not usually a good idea. Bottom line is that title is for non-important information, users must be able to determine the purpose of a link without using the content of the title attribute.