Discuss/define the minimal UX for adding menu links to entities

At least major

Referencing some prior art. (Pun intended. :))

Updated the issue summary with some ideas that have been posted in the other issue(s). I'd like to keep the UI brainstorming centered here though.

With the entity:// scheme idea in #2407505: [meta] Finalize the menu links (and other user-entered paths) system this means we won't have DER in core.

That then means that the UI without this issue getting resolved would be the same text field we have now (but if you enter entity://node/1 it'll work). It's likely the initial patch will still support adding links from the node form similar to now.

I think that's OK as an interim state, but given we thought it was important to make the entity selection very prominent and de-emphasise manually adding paths in the menu UI too, that makes this issue more important than if we'd gone with the DER idea (which would have come with a working entity-centric interface if not the final one).

That then means that the UI without this issue getting resolved would be the same text field we have now (but if you enter entity://node/1 it'll work)...I think that's OK as an interim state

Another possible interim state is we make that textfield have D7 Menu UI behavior, but for entity paths only. In other words, if the user types about-us and that's the path of node 1, we store that as entity://node/1. Then if they edit the field later, display it as node/1 (or we can even choose to display it as the current path alias of node 1). I think every option in this issue's issue summary is better than that, but at least that would be an interim state that would not be a UX regression relative to D7 (i.e., would not expose entity:// in the UI), so any improvements to the UI beyond that could happen in post-upgrade-path betas, or even in 8.1.

Right, in my mind, the critical issue is to stick the path field on the form, and allow it to resolve entity:// paths (that's part of #2407505: [meta] Finalize the menu links (and other user-entered paths) system). This is a major issue to refine that UI further once the basic one is in place. If it happens before 8.0.0, great, but otherwise it could also happen in 8.1.0+

Another possible interim state is we make that textfield have D7 Menu UI behavior, but for entity paths only.

Well, while you could argue it, this would conflict entirely with #2346189: Denormalizing paths into route names/parameters is brittle / broken which got this started (see IS) again.

Re-scoping this based on Peter / Alex B / my sprint prep discussion earlier today, and increasing to critical as a result.

Basically, the situation is that without a way for users to select a particular entity for a menu link to point to, we introduce a regression from D6/D7 whereby a user who used to just have to type "about" now has to type "entity://node/1." That's quite a bit of cognitive load, especially considering that the people building out navigation are usually content authors and not hardcore developer types.

So rather than trying to find an "ideal" UX, we should instead be aiming for "the simplest thing that can possibly work" (which probably already eliminates a few of the options like #4), but bearing in mind that our target end user spends their days making "About us" pages and does not know what an entity is, what a route is, etc.

And one thing we discussed as an option was something along the lines of option #5, which hard-codes the entity type selector to content (since we already have that in entity reference), and a later (non-critical) iteration prior to RC or 8.1.0+ adjusts the widget to work for other entity types, which gives us some runway to discuss the optimal way to share that level of saugsage-making with content authors.

I am taking a look at this. I am traveling quite a bit, so hopefully I can be engaged enough.

The path this is taking seems to be away from what I considered as an acceptable UX. I am trying to understand why we can't provide users with the ability to select the direct link and entity link. Similar to option #2 but then more eloquently. The summary nicely outlines the solutions, but not restrictions and requirements - is it possible to give some context? I've shifted through all the other issues/google docs, but its quite a mess to extract the right and up-to-date information from that.

@webchick Could we please stay off the path, that we ever pursue "ideal" UX. I feel like that is biasing the discussion towards poor UX, to try and tackle design process or bikeshedding as its sometimes called :). We rarely actually pursue ideal UX. Similar to most occasions, what we do is to find the best compromise between UX and engineering effort, lets not fool ourselves into thinking at 8.1 we implement the ideal UX. We will still be battling the same compromise, hopefully on a slightly higher level.

We should find a UX here, that is acceptable and won't cause a major UX regression - just before release. The cognitive load described by @webchick will most likely render this unusable for content editors.

Wow, we came to the same thing :)

My screenshot from the 15th I proposed to @pwolanin

Re #12, I re-scoped the issue not because I don't think we shouldn't look for an ideal UX, but because we need something in the interim that gets D8 to a shippable state since there is an actual regression in behaviour, and "ideal" could never be critical. There's also a sprint happening on Thursday - Sunday with several front-end developers in attendance, and was hoping to get them a direction to work on before then. Thanks a lot for chiming in!

I'm not sure what specifically would help regarding "restrictions and requirements" but attempted to add more of the "why" information to the issue summary, in the hopes that this will help.

@webchick Sure, I think we are on the same line - I will share some of my thoughts around this on a later time.

@larowlan That's great, I am looking forward to feedback around this - as that seems to be the most straightforward design. Obviously we do need to tweak the text a bit. I like showing the entity's title for example.

OK so it sounds like #12 and #13 are effectively proposing a variation on option 1 in the issue summary? It's a "smart" autocomplete field that searches labels across all entity types (or locked to only nodes?) and in the drop-down offers the option to either do a "hard" link to node/1 or a "soft" link to /content/about-us. (Of the two, I find larowlan's a bit more clear in that respect, but it'd be great to borrow the light grey descriptions from Bojhan's.)

What if I want to literally enter the path "about"? Separate text field, or just be careful not to accidentally select from the drop-down?

Adding Lee and Bojhan's mocks to the issue summary.

Ahem. And fixing it. :P

My concern with #12 is that we would then be requiring content authors to choose what kind of link they want. I don't see a reason to make that choice so prominent. I think we would prefer them to be guided into the "content item" variant. Additionally, it doesn't cover the use case of linking to something that isn't a node or something on another website.

I like option #5 for addressing that. Except what I don't like about option #5 is the text in the path element that says "Type the path if you know it". Because ideally, even if you know that the path of something is "about-us", we would still prefer you to select it as a content item from the prior field. Instead, I suggest text that captures the following idea, but with better wording:

As the description of the ER autocomplete element: "If you are linking to content on this website, select it here."
As the description of the path textfield element: "If you are linking to a page on this website that isn't content, type its path here. Or, if you are linking to a page on another website, type its full URL here."

The above doesn't make clear that you can also type a path in that last element, even if it is to a node, in the use case that you currently have a placeholder node with that path alias but intend to later create the real node and move that path alias to the new node. Or, the use case that you want to build out your menu to point to nodes that don't exist yet, but that you'll add later (which is a variant of the former case, but without the placeholder node to start with, because you're ok with those links being broken in the meantime). But, those are advanced use cases, so I think it's okay to not make them prominent. People who want to do that kind of stuff will figure out that they can through experimentation.

So for #19, something like this? (Bearing in mind that that much help text would be too overwhelming, unless it's behind a "?" icon or something.)

#20 looks good to me. @Bojhan: what do you think?

I was expecting that this was the direction people wanted to go (from the call). However it's not the direction I wish to take this in, my concerns focus around two arguments:

1) It creates the cognitive burden before entering anything that you need to decide between two options. Interaction design wise you ease this burden by having them provide data, that you can provide helpful context and interaction around this.
2) OR interfaces often create significant usability issues. I've tested a few of them over the years and whenever you present two relatively close options, people struggle making the right choice. The OR interfaces are particularly troublesome because they tend to present the options as equals, without prominence. I don't think that this will be any different, I've shared the same concerns when I saw Kevin's designs.

While I understand the many use cases you intend to tackle, I believe the interaction proposed in #13 is optimised for content items (we make it the first option, we clearly note the other option is a hard link - larowlans design shows this). I believe that it is actually in line with effulgentsia goals here. Pursuing the option in #20 actually promotes an equal option, which is not what we want to do. I don't believe that the other use cases mentioned will be impossible with the design in #13, people will still be able to enter paths as long as the help text describes "Enter a page title or URL".

I will be around on IRC later today, if you wish to discuss.

One other possible variation on #5, bearing in mind that we do expect the "pick a piece of content" UI to be the 90% case:

Clicking the link would reveal the field/title shown in #20. Doesn't negate the concerns about presenting an "or" UI, but it does at least make it very clear which we expect you to choose.

It creates the cognitive burden before entering anything that you need to decide between two options.

Funny. That's exactly what I dislike about #12 and #13. I like how #23 addresses that though.

I don't believe that the other use cases mentioned will be impossible with the design in #13, people will still be able to enter paths as long as the help text describes "Enter a page title or URL".

Ah, I see. That can work, but then we shouldn't present 2 options per autocompleted title, since if they want the hard link, they can enter the path instead of using the autocomplete-by-title mode.

- when the user types something that starts with a '/' or the final string (probably copy-pasted) starts with 'http://', no autocompletion will be provided and just store what was typed - this is the path reference case
- when the user types something that doesn't start with a '/', provide (D)ER autocompletion for a list of entity types configurable at the widget level

That seems pretty subtle. That the way the user makes clear that the string they're typing is a path is that it starts with a / or has a ://, and otherwise, we guess that the string they're typing is intended as a title. I prefer how #23 doesn't require such guesswork (for example, #23 would allow the user to type in blog instead of /blog into the path field). But I'm ok with either option if we think that guesswork is more intuitive for a content author / site builder than #23's more explicit separation.

Here's a combination of both Bojhan and larowlan's that removes the explicit choice as suggested in #24 (extrapolated for both use cases):

So basically, autocomplete on either path or entity title? If so, "Cats rule" gets added to the list now because its path contains "about".

Incidentally, I could see #25 (or #12 or #13) being problematic with certain words. For example, imagine a Drupal developer blog that wrote a lot about Node.js. :P~ But that's the price to pay with eliminating the user decision, I guess. Unless you stick with "you must prefix / for a path" as suggested by amateescu, but I can't really envision succinct enough help text for that:

"Type the title of a piece of content such as "About us", or a path starting with"/" such as "/blog" or a URL such as https://www.drupal.org/ or..."

:P

Why couldn't the autocomplete be a system view that by default searches within title and path, but could be overridden by the end user to do whatever they need? Entityreference already essentially supports this (well, not via a system view, but you can have the valid set generated from a view). Or even a view-per-menu, so users could further refine things.

Before we get crazy here: I would suggest that we think about limitations of our ecosystem,
which is that we have a damn lot amount of entity types for example. Core has to provide a generic UI which works, not necessarily one which has the best UX
for some people.

we have a damn lot amount of entity types for example. Core has to provide a generic UI which works, not necessarily one which has the best UX
for some people.

Not necessarily. Why can't core provide a widget that only autocompletes-by-title for nodes? And let contrib provide widgets that work better for when you have multiple entity types you want to link to as an entity reference rather than explicit path?

I could think of a lot of modules that would be *very happy* with an autocomplete-entity-by-label functionality built into Drupal core, rather than each module having to invent it's own. Entity Embed in Drupal 8 could make use of it already.

For #25, is "Our stuff" a node? If not (e.g., if it's a View), I don't think we can provide the autocomplete on it. Furthermore, what if it's a View that hasn't been built yet, or isn't a View at all, but is a section of the site that's handled by Wordpress rather than Drupal? In which case, would we allow "blog" to still be typed and submitted as a string despite not matching anything? In which case would "Abou" also be allowed to be submitted and then treated as an unrouted path rather than a non-completed title?

@dawehner I understand your concerns, do consider the fact that this is largely already a compromise. I always feel a little sad when a very modest proposal is considered a attempt at "best UX" or "ideal UX". I already looking for a compromise.

@effulgentsia Are we expecting this to support referencing an entity, before having created it? I can understand path, but entity? I don't really follow.

I do think that prefixing by / is the most sensible thing to do (not the user, but the system feedback). I can't imagine it working without that? As a user I enter "About" and I get two options: 1) entity (if we find one that has this in it) and/or 2) the option "/about" a hard link.

@effulgentsia Are we expecting this to support referencing an entity, before having created it? I can understand path, but entity? I don't really follow.

Nope. I think you and I are on the same page here. The reference would be to the path. I was just pointing out that unlike #25's screenshot, /blog might not exist yet, so wondering how the autocomplete UI would work for that. But, I think you answered that in:

As a user I enter "About" and I get two options: 1) entity (if we find one that has this in it) and/or 2) the option "/about" a hard link.

Ah. So, are you suggesting something like the "Link to content" field from #23, but with a 3rd option presented in the autocomplete: Hard link: /abou? And then we would only update that to Hard link: /about after the user types that final "t"? In other words, the autocomplete shows all of the nodes matched by title (one entry per node) plus one additional entry (total, not per node) for making a hard link to exactly what the user typed (no guesses about how to complete it other than prefixing with "/")? I can get behind that.

K, attempting to capture #32/#33:

"Cats rule" no longer in the list, because we are only matching entity labels (MVP: only node titles), not paths. And no matter what they type, we offer a "hard link" option.

The thing I don't like about this from a UX POV (leaving to Peter, Daniel, etc. to talk about the technical challenges) is it takes something that's a ~10% use case (linking to something that's not a node or some other kind of entity like user/register) and making it as prominent as a 90% use case (linking to about us, legal, privacy, etc.). Possibly even more prominent, since it'll always be in the list. (Versus the "or" UI OTOH clearly tells you "this is the one you should pick most of the time" so I like it more from that respect.)

Also worth noting that since Drupal 6, Drupal attempts to validate your input here and spits out an error at you if you try and link to a path that doesn't exist. So in the first case, choosing the "Hard link: /abou" option would yield a validation error, unless we change that behaviour. (We could always put display of that option behind some checking to see if what they typed maps to a valid URL alias/system path, or they have the "bypass menu validation" permission, and only show the "Hard link" option in those cases. That'd help with the "making a 10% case too prominent" problem, but it's also starting to sound pretty complex.)

@webchick From my POV, exposing it as a "separate" option is much more prominent. Now it kind of blends in as an alternative. I do understand the popular opinion towards OR interfaces - its very straight forward and often seen in more technical interfaces. I have just rarely seen them work very well with end-users (because of that cognitive dissonance having to choose between seemingly similar options, before getting any context - showing two options and their result (direct link vs. a url) will help with this). Except views, we have successfully staid away from them in core I think.

I don't really follow your path argument, wasn't the whole point of the usecases that we will now allow paths that don't exist yet? As early as 2009 we already discovered (in the Baltimore user test) that people have two behaviours to menu building 1) creating it after the content/views etc. 2) creating it before creating the content/views. etc.

I don't really follow your path argument, wasn't the whole point of the usecases that we will now allow paths that don't exist yet? As early as 2009 we already discovered (in the Baltimore user test) that people have two behaviours to menu building 1) creating it after the content/views etc. 2) creating it before creating the content/views. etc.

I'm 3,000% in agreement, but have been sadly unsuccessful in convincing the menu team to allow for this, though I've tried very, very hard. ;) See #308263: Allow privileged users to bypass the validation of menu items for that. So at least in the short-term, I think we need to assume that it retains the "validate the path when you attempt to save" behaviour. :\

However, my main point regarding presenting the 90/10% split as the same was this:

In Drupal 7, any time you link to, say, "about" what it'll do behind the scenes is figure out "Oh, that maps to node 12. Let me go ahead and store node/12 on your behalf." This way, if you are running Pathauto module and you change the title from "About" to "About Us," thus accidentally changing your path from /about to /content/about-us, your menu link stays working. It's generally argued that this is behaviour that content authors are going to want in any case involving a specific node.

If instead you choose the "Hard link: about" option, then simply changing the title of your page in this scenario would break your menu link. And it's not clear from the phrase "hard link" that that's what that means. Also, literally the *only* time you want a hard link is when you're linking to some kind of "landing page" that might get swapped out later from, say, a node that says "coming soon" to a panel or view.

So it really is two different behaviours you're getting, that's why I prefer the "or" UI because it makes that explicit, and allows us to put some kind of help text that explains what's going to happen.

I'm not sure everyone is talking about the same thing.

If you have a single autocomplete, then you get a choice of entity link OR 'hard' link - that's an OR ui to a large extent - and you'll always need to make that choice, can't ignore it.

If you have an entity reference browser, then a less prominent textfield below it, then that's also an OR ui except it's easier to skip over making the choice.

Yes, that.

I posted a patch for a generic Form API entity autocomplete in #1959806-15: Provide a generic 'entity_autocomplete' Form API element. I think this is what @Dave Reid mentioned as being generally useful in #30, right?

Just like the current entity reference field in core, it is restricted to a single entity type per element, but I think that's ok as a MVP for whatever design is going to be agreed upon here.

If you have an entity reference browser, then a less prominent textfield below it, then that's also an OR ui except it's easier to skip over making the choice.

+1

That's exactly what I suggested during the call that resulted in #2407505: [meta] Finalize the menu links (and other user-entered paths) system. Basically, something like this (designing UIs in ASCII art! :D):

+------------------------------+
| Linking to [Content]         |
|                              |
| [Enter a Content title…]     |
+------------------------------+


    Or link by URL: [Enter URL]

So first a <fieldset>, second text followed by an inline input[type=text]. The fieldset is most prominent. The fieldset requires an entity type to be selected in a <select> (defaulting to "Content", which is the human-readable name for node), and then offers an input[type=text] with autocompletion based on the entity title.

#40: I totally think that is what Dave Reid meant! This (both this issue and the patch you linked to) would also benefit another prominent Drupal core UI directly: creating links in the WYSIWYG editor — see #2292159: EditorLinkDialog should validate URLs, and autocomplete like the Link widget.

Having two fields, one for searching for content and one for a url, is a situation we have now with modules like LinkIt. It does not work well with my users. They often get confused between the two boxes and try to put links in the search box, and vice versa. They don't see or care about the difference between trying to find an existing entity versus putting in an exact path.

I also don't think the "Hard link:" option in #35 is the best idea. It will confuse the heck out of people, so it would at least need a better label. I'm also wondering what would happen when the autocomplete has a lot of stuff in it. Does it get pushed too far down? I'm not sure of the default limit to that box.

Also adding relative urls (paths) that do not exist in the system is something I want to do all the time and cannot do it now. It is helpful for testing, building out menus, landing pages, for all kinds of other reasons that may be external to Drupal. I wouldn't have half the menu that way, but it happens often.

A single field that searches by title and also allows allows full or relative urls would be best. I think it is fine to have the search stop if it sees http or / and assume it's a path that needs to be stored, instead of a link to an entity. It may not be the most intuitive, but it is easy to explain and easy to do.

Ok, great. Looks like we have a direction. Marking RTBC and updating the issue summary.

Yay!
I have a number of clients using D7 with https://www.drupal.org/project/mpac
which is basically what #1 is, and they all seem to like it.

@webchick's addition to the issue summary in #44

- Fixes a long-standing UX issue where new Drupal users do not understand what a path is.
- Is fairly simple to implement.

and @pwolanin's comment in #34

Autocompleting title OR path in one box seems totally strange to me and a pain to build. It will be both slow and confusing.

just made my evening :)

Well. :) That was back when I had misunderstood what the autocomplete was doing. The new behaviour is basically either autocomplete on node titles or no autocomplete and just paths, which is a lot more straight-forward.

Adding a mock of what I believe the proposed resolution is.

Also created #2416987: Fix UI regression in the menu link form for the implementation. It's currently postponed on this one reaching "fixed" which is probably reasonable to do once Bojhan has had a look.

This looks great to me! Lets build this.

The very key part is that we take away the complexity of thinking in what "input" field should I be in to do my activity. I am happy David was able to chime in with some experience of an actual module, the user behaviour he describes sounds very recognisable. The path part might be a bit magical, but I am sure we can make that better with the help description.

Unpostponed #2416987: Fix UI regression in the menu link form. Looks like we can close this out.

Awesome! Thanks, all.

Were there specific child issues to implement what was decided on? I'm not sure if there still might be work to do it. (we should note them in the summary)