Users need to be able to select from list when adding menu items to a menu

subscribe

I'd suggest labeling the fieldset something along the lines of "Placement of link within the menu" (but probably shorter).

And also, leave the fieldset open, not collapsed - this isn't a concept people are likely to understand easily enough to know if they want to open a collapsed fieldset to configure it or not.

Mostly, I think this is great. Since this is filed as a D8 issue (as it should be), let me blue sky a little:

• The D6 module, Nodereference Explorer, implements a similar popup for CCK's nodereference field type.
• When creating a menu link, you may not yet have your content. You may come from a mental model of wanting to first add the menu link, then add your content. So, would be nice for the browse modal to allow you to make a new node, something also listed as a TODO goal for the Nodereference Explorer.
• The D7 module, Media, implements a modal for selecting a Media asset, either as a field value, or to inline into text. This modal does provide a UI with which to add a new media item (e.g., by uploading a file from your computer or entering a URL to some 3rd party media).
• There's a desire for D8 to fill in the remaining holes in the entity API, which among other things, should enable a uniform way for searching for and referencing any entity (not just nodes).
• So, I wonder if this can evolve into a generic and consistent UI for opening a modal to browse for any entity, or add a new one, and upon closing the modal, have a reference to it, that can be inserted into a menu link, into a wysiwyg, or into an entity reference field.

I'm not saying we need all of that solved before proceeding with this issue. This issue is awesome on its own. Just an idea for something I'd love to see happen some time during D8 development.

Early days and this looks great - would the intention be to use a modal even when overlay is disabled? How would this degrade without overlay?

In the browse dialog, I may not be able to recognize my content from just the title.
So I'd want a way to click on a piece of content and open the full page in a new window if I want to see it 1st.
Also I'd like to see a chunk (1 line) of the body in the grid. I think that is more important than the date. So I'd vote for 2 rows like the views listing and show:

Title Author, Updated, Operations
Body text (1st line)...

We could add a "View" link under operations to view it in a new window.

@Noyz: thanks for #7. Yeah, getting a fully unified UI that covers all use-cases will take time, so doing it in manageable steps makes sense, and keeping this issue to just dealing with selecting an existing node to build a menu link to, is a good scope. As long as we're aware of the larger goals, I think that's good enough for now.

I think my biggest concern with the design now is the auto-update and lazy load. Some sites can have 10K, 100K, or 1M+ nodes. Most of Drupal uses a pager for listings pages. The auto-update text filter is great in the Views UI for adding a field/filter/sort, but that's because it's very unlikely for any of those listings to be >1000. How do you envision this working for very large listings?

subscribe

Would love for screen-shots to have some form of description so that we can all play.

I have re-prioritized this to be critical, because any user that does not understand the concept of path will struggle with this issue and in addition to that the overlay adds something to the URL making it really hard for those who do understand the concept, to know which part of the path they need.

This issue was identified in both Baltimore 2009 and now again in Minesota 2011. It was identified as "Path fields as presented lead users to be unsure what to add.".

We had similar solutions proposed as in this issue.

Everett: Here's a textual description of the latest screenshots, so you can play, too. :)

#1: Add menu link screen (admin/structure/menu/manage/main-menu/add)

1. Most importantly, a new "Find content..." button is placed next to the "Path" textfield, so that users can browse for content rather than having to memorize node IDs. :)
2. "Main menu" as the page title gets renamed to "Add link"
3. "Menu link title" gets renamed to "Label"
4. "Path" help text gets shorter. Currently, it's:

   "The path for this menu link. This can be an internal Drupal path such as node/add or an external URL such as http://drupal.org. Enter to link to the front page."

   The proposed screenshot changes it to:
   "Find or enter the path to your content, e.g. node/1234 or http://drupal.org. For the sites [sic] front page, enter <front>"

5. "Parent link" and "Weight" both get grouped into a collapsed fieldset called "Order"

#2: The "browse" box you would get when you hit the "Find content..." button

This screen, which appears in a D7 Views-style overlay, essentially looks like admin/content; a large table of available content showing columns of Title, Author, Updated, and Operations (in this case, "select" rather than "edit/delete"). There are also filters on the top, though slightly different than those currently at admin/content (presumably, we'd want to make them the same):

- Title or body: [textfield for keyword searching]
- Author
- Status
- Content type

The idea then would be that for users who like to create content and then build out their site structure, they could come to Structure >> Menus and start making their outline, and instead of having to go to a completely different screen to figure out what node/XXX they should put there, they could instead easily browse for existing content.

Hope that helps! (And also, subscribe ;))

From an accessibility perspective I'm not comfortable with any design that will rely on a dialog or overlay to present content to users.

If this design can leverage the D7 Overlay in some way, so that if a user or site has Overlay disabled then there will be a graceful degradation that would be great.

I should point out though, that this is only part of the battle.

A decent number of UMN participants, when presented with a site mockup, wanted to start with structure *first* (building out About, Events, etc.) *before* creating any content. This is how I used to build sites before Drupal, too.

So in addition to finding existing content, I think we also need the ability to add content here, and have the checkbox pre-populated. (Obviously as part of a separate issue, but not sure if it makes sense to factor such functionality into the mocks here.)

Re #21, see #3, #7, and #9.

#23:

Number 1 is an easy fix. I consider this critical. So much so that I wish we could patch D7.

#20:

From an accessibility perspective I'm not comfortable with any design that will rely on a dialog or overlay to present content to users.

This second statement is a major (though probably not the only) reason we won't be able to backport this to D7 core. But, if/when someone has development time to spend on this, it can be done as a D7 contrib module, which would allow for some iteration between D8UX thinking and real world feedback from D7 users, as well as working through some of the thorny issues like accessibility.

Within D7, I don't think we yet have a clear standard for dialogs. We have the dialogs presented in the D7 Views UI, which are based on jQuery UI dialogs. In #1139514: Overhaul the media browser code to not use an iframe, and be more understandable, maintainable, and extendable, we're currently working on porting Media's media browser to a similar style of dialog. However, there are definitely accessibility issues that still need to be worked through with these, and if we want this to become a UX pattern in D8 core, then we MUST solve the accessibility issues.

If this design can leverage the D7 Overlay in some way, so that if a user or site has Overlay disabled then there will be a graceful degradation that would be great.

I think there's a significant UX difference between the Overlay module overlay, and the kinds of modal dialogs needed in Views UI, Media browsing, and what is being recommended in this issue. The Overlay module is designed for an entire admin page overlayed on a regular site page, while modal dialogs are for focused and partial interaction (perhaps the UX folks here can explain this distinction better, or maybe I'm erroneously perceiving a distinction where there really isn't one). So, I think we have to keep evolving our work with modal dialogs separately from the Overlay module overlay, though we should make both as accessible as we can. If we want to, though, we can decide to automatically disable and degrade modal dialogs when the Overlay is disabled. Do we want to do this though? I'm pretty sure there's people who would want Overlay disabled, but modal dialogs enabled.

@effulgentsia Having gone through the process of trying to make the overlay accessible, I am very worried of any interaction that requires a modal dialog to function (to note; Drupal, currently does not). It's clear from that process, that it is not possible as of now to make a modal dialog completely accessible - this due to "old" screenreader technology not recognizing its existance propperly. When you are talking about gracefull degegration of modal dialogs? What does this mean?

@Noyz I agree, we should focus on 1. Do you have any ideas for this interaction to exist inline? (for example search, rather than browse).

I would love to have a more indepth discussions on the useage of modal dialogs, it seems like a very interesting pattern to use - but also one that is a shift from our current UX strategy to keep functionality inline as much as possible.

@Bojhan et al

#1175830: Update to jQuery UI 1.10.2

> 1. We're asking users to remember paths in order to connect a menu to a node. Most users will not even look at the path let alone remember it

Are we? You can just edit the node and create its menu item through the node edit form.

There's a nice little module in the git applications issue queue that has an improvement to the UI for this: http://drupal.org/node/1081128

Screenshot:

"You can just edit the node and create its menu item through the node edit form."

Yes, and that works, if:

1. They arrive at content first, before structure, which many don't (think Dreamweaver, etc. where you create your "sitemap" first before laying down content).
2. They actually see that checkbox on the node edit form at the time they're creating their content, which data shows about half the people do not.
3. They understand that checking that box adds it to the menu (or even what a menu is).

Jeff's mockups here are to support the people who didn't see / didn't know to check that box in the first place, and now have a bunch of pages they can't actually get to. This happens a lot, and has been verified over and over in testing across multiple Drupal versions. We call it the "node orphanage." :)

"Main menu" as the page title gets renamed to "Add link"

Is there a good reason for choosing the text "Add link"?

Why not "Add menu item"?

The word "link" to me suggests something that could appear anywhere in the text of the page, whereas this is only about the menu.

I could imagine an editor wanting to add a normal hyperlink in some content, and thinking that she should look for the "Add link" page she saw previously.

So if we want to support structure-led site building, how about this:

- remove the path validation from the menu item creation form
- instead, have this process:

1. user creates a menu item (+1 for calling them menu links, btw!)
2. path points to something which does not exist
3. user is redirected to a confirmation form which says: 'There is no content defined to be found at path 'foo/bar'. Do you want to create a basic page at this path?'

Obviously with better verbiage. But there is a concept that new users must acquire, which is that in Drupal things 'live' at a path, rather than they 'are' that path.

Something worth noting that we've had a few recent examples of is the confusion around putting an unpublished node into the menu and having it not show up.

Perhaps this is a help text improvement or maybe a validation warning or something else, but I'm sure this would also help usability.

I did some testing and found the same problem where new users did not know how to get the path while creating a menu item. This thread is certainly helping to inch forward. Link to the issue: http://drupal.org/node/1123662

Just wanted to mention that there is already a module implementing the structured menu creation through the node form.
It is just having a bit of trouble with an inconsistent (no draggable items) interface.

http://drupal.org/project/menuux

Maybe this can be of use as a source of inspiration.

Subscribe

Can someone please clarify the state of this ... is the agreed upon direction of this issue to

a) improve the menu edit form by allowing people to search for content (a la the orig post & #13)
b) allow people to create menu items (menu links ++) that point to non-existing content (and perhaps warning them about that and directing them to create something by "clicking here"
c) both
d) neither

I'd love to help here as this is something that I have personally struggled with since D5. I often end up creating my primary navigation menu by creating 10 links to http://www.google.com and then changing them later. In my opinion I think that #13 is an excellent suggestion but clearly it does not help the person who goes to create his/her menu first. That is the bigger WTF than "how do I figure out what content I can link to." I like the suggestion in #30 ... anyway, if someone can clarify or summarize I think that would be helpful.

Subscribe

@mgifford ... There is a miraculous new "follow" bottom at the top right of this issue. DEATH TO "subscribe"

Yikes, it's finally arrived! Thanks @bleen18

For that matter to be able to unfollow is pretty keen too. Thanks everyone who was involved in the upgrade. Nice changes to d.o lately!

@webchick I used to build Drupal 5 sites structure-first too. It wasn't until D6 that the path had to be *valid* before it could be added to the menu. see #1339364: Remove requirement that drupal path is valid when creating new menu item - Save and warn only. for a related issue on path field validation.

Also, the content browser looks awesome! But, it also looks like an over-overlay a-la views or panels. Do we have a way to tackle that in core yet? I want to help build this! :)

So is someone able to create a patch for this for D8? What's the next step to help this move along?

To implement the screenshot in #13 in core, we're still stuck on #1175830: Update to jQuery UI 1.10.2. So, possible next steps are:

1. Do this in a contrib module for now.
2. Find some way to solve the UX goal of this issue that doesn't rely on a modal (see #25).
3. Help resolve the accessibility issues in #1175830-54: Update to jQuery UI 1.10.2.

The above might not be a complete list, so if anyone has ideas on what else can be done, please share.

A very important part in Jeffs Mockup is the "find content" button. Hopefully autocompletes will be much faster in D8. I would put the find content first and make it autocomplete. Give it an "enter path manually" toggle and off we go.

Retitling for clarity.

Adding tag for sprint

I've been looking at this as part of the accessibility sprint. For my own purposes, I have summarized the main points below:

1. Goal: Make it easier to add menu items to a menu by allowing users to browse for paths.
2. It was suggested (comment #3) that:
   • content may not exist—you may wish to create the link before the content
   • this could become a browser for any sort of entity
3. In comment #8 it was suggested that a multi-line listing would be more usable. The second line shows node body.
4. Relying on a modal dialog or overlay presents accessibility problems (comment #20). Leveraging the D7 overlay and degrading gracefully would alleviate the accessibility problems.
5. Several pointed out that some users want to create structure first, then fill in the content later. D5 allowed entering menu links that don't yet exist. There is an issue to allow this again: http://drupal.org/node/1339364 Comment #30 looked at another way to do this.
6. There's no standard way to implement a dialog box (comment #24), but jQuery UI is used in some key contrib modules. Overlay doesn't seem to meet the same requirements.
7. There is an issue to investigate and implement accessible dialog boxes (http://drupal.org/node/1175830).
8. Not having an accessible dialog is a blocker to having this issue in core.

The dialog/overlay issue is something that needs to be solved. It seems like there may also be a need for a reusable browser UI component. In this case, it is browsing for path, but a node or entity browser will be useful (comment 3).

The accessible dialog issue needs to be solved for this to get to core. I think this would best proceed as a contrib module until that is worked out

Another issue I can think of is that we tend to assume a page is a node. My take on the layout initiative is that a page maps to a location which could be pulling in node(s) or other content sources. This would be a consideration for the browser, IE: you could be browsing a node with a title and body, but you could be browsing a "layout" of some sort that would be pulling in multiple entities. Even in D7 this could be an issue—for example, you might browse for the path "/news" which is actually a view without an author or body to display in the browser.

I don't think modal dialogs are necessarily a blocker for this issue. It should be possible to have the browser inline rather than in a separate dialog (e.g., something like how Entityreference Browser does it, perhaps).

The browser could be hidden until the appropriate "Browse" link is clicked, of course.

I like the idea of an inline browser. Looking at Media browser, if you tab off the browser, the focus moves to the obscured parts of the DOM. Once I did that, I never seemed to be able to get back to the browser. Also, I could not seem to tab to the "Cancel" link.

What is it going to take to get a patch we can start reviewing for this?

Hm I doubt this will happen. Too much other stuff in the pipeline and this one does not even have a solid conception. My bet is contrib for D8.

I think we can more properly categorize this as a task, rather than a feature. This trips up every single user in every single usability test ever. We should fix it.

So this isn't restricted by the feature freeze, but we still do need a patch to review.

Anyone able to take a look?

tagging.

Moving to D9. This is a feature request and we are past API freeze.

I don't see Content Menu mentioned in this issue at all. Here's how it does things...

Adding a menu item that links to existing content (other options include a plain URL/path, a "Dummy" no-content node, or New {content_type}):

Here's how you edit existing menu items content directly from the menu management form and how you link to a new page. All content types configured to allow menu items are added in the "Target" drop-down menu in the form of "New {content_type}" entries:

The little pencil icon next to each menu item label allows to edit it in place.

And here are the actual steps in creating a new menu item that links to a page and also creating that page:

@klonos

That module is very nice and does quit effectively address the problem. Is there a D8 branch?

Yep, it actually more or less implements what is proposed in the issue summary but for D7. Combined with Special Menu Items that allows inserting the special <nolink> or <separator> tokens as the menu item path it also addresses the need to create "empty"/placeholder menu items. So people can first easily create a scaffold of their menu structure before they start populating/linking to actual nodes.

Here's a couple of issues I've recently filed in it queue that'll make the module perfect (the maintainer currently has no time to implement these, hence postponed):

#2042227: Replace the node menu settings tab with a minimal instance of Content Menu.
#2039267: Support the Instant Filter module when installed (for searching content on the add_existing_content page).
#1597620: Support the special_menu_items module (if installed) for creating empty (<nolink>) & separator (<separator>) links.

There is no 8.x branch available that I know of: https://drupal.org/node/1549778/release?api_version[]=7234

Closing this in favour of #1123662: Participants did not know how to get the path while creating a menu link, which has a patch.