Customizer Menus: improve the "no results found" message

[designsimply]

New users often try to create menus before they create content. To help them out, let's add a notice if they do a search and it returns no results and in menu item areas that have no published content.

Here's how it currently looks if no search results are found:

^{Tested with WP 4.3-alpha-32629 and ​Menu Customizer plugin 0.4 (51d2682) with Firefox 38.0.1 on Mac OSX 10.10.3.}

Example scenario where someone has added content but it's all unpublished drafts or set as private: ​31s

And here's one where someone is a new user and hasn't added any content at all yet: ​57s

Current:

No results found.

Proposed:

No results found.

You must create and publish content before you can add it as a menu item, or you can add a link to an external site by clicking on Links below.

Moved from ​https://github.com/voldemortensen/menu-customizer/issues/53

[celloexpressions]

Add help text to the no results text.

[celloexpressions]

I tweaked the text slightly in the patch, making it input-type-agnostic and slightly more positive:

You must create and publish content before you can add it as a menu item. You can also add links to external sites in the Links section below.

[designsimply]

I tested 32710.diffand it looks good:

^{Seen at ​http://src.wordpress-develop.dev/wp-admin/customize.php with WordPress 4.3-alpha-32280-src using Firefox 38.0.5 on Mac OS X 10.10.3.}

I tried to shorten it even more:

You must publish content before you can add it as a menu item or you can add external links using the Links section below.

You should also check out #32720. :)

[afercia]

Side note: wouldn't be better to say "Custom Links" instead of just "Links"? (in the h4 heading too)

[paulwilde]

Replying to afercia:

Side note: wouldn't be better to say "Custom Links" instead of just "Links"? (in the h4 heading too)

Agreed. That's how it's phrased in nav-menus.php, so in order to be consistent it should be Custom Link(s).

I'll make a separate ticket with a patch that changes the phrasing.

[paulwilde]

Refreshed the patch with the assumption that "Links" is renamed to "Custom Links" (See #32732).

[celloexpressions]

32710.1.diff​ should be ready for commit. The text here illustrates clearly why "Links" makes more sense that "Custom Links", and we'll be changing it back in #32826 anyway.

[helen]

Marking as bug, because it is. We definitely need a better message here - incidentally, I find that this illustrates why "custom link" is better language. "External site" is not necessarily accurate - for instance, if you're linking to content on another site on the same network, it may conceptually be the same site to you, not "external". As far as the proposed string goes, we should not use the word "must" when it comes to an optional action (publishing content is not truly required) and the user hasn't tried any editing actions, only search. Perhaps "You don’t have any content to add to menus yet. You can add custom links using the custom link section below." Truly empty installs are also relatively rare - there is typically one post, one page, and one category in a new install.

However, I think we can and should go farther than the messaging. A lot of these interactions are a waste of the user's time - expanding boxes only to find them empty, running a search against nothing. There are a couple things we could do, which should be user tested - one would be to not display boxes that are empty, and the other would be to show them but disable the toggle and show some kind of message in that space (yes, I know it means variable length strings in a limited space). The latter may actually be the better route so that users can see what will become available to them once they add content. We should also disable the search box when there's nothing to search (except the Uncategorized category?), but not remove it. Also expand the custom link box when nothing else is available. Again, truly content-less installs are uncommon, but we can at least remove interactions that are a waste of time.

The above likely applies to the admin screen as well, but let's get this right in the customizer first, since it has the search message.

[valendesigns]

@helen So do you want this issue to pivot and solve the bigger picture or should we adjust the string and open a new enhancement ticket to track the other changes you mentioned?

[ocean90]

Replying to helen:

There are a couple things we could do, which should be user tested - one would be to not display boxes that are empty, and the other would be to show them but disable the toggle and show some kind of message in that space

Related: #32810

[designsimply]

Truly empty installs are also relatively rare - there is typically one post, one page, and one category in a new install.

It sounds like you're only thinking of empty content sections, not empty search results. This is probably my fault for including some more edge-case-ish things in the example screencasts (i.e. no published content at all). The empty content areas are really a separate case from empty search results. Here is a more up-to-date screenshot:

And here is a better example scenario: someone sets up a site, the first thing they want to do is add a menu, they create a new menu and search for "contact" because they want that in their menu bar, but no search results appear because they haven't published a contact page yet. In this scenario, neither the search nor the Custom Links are right for them yet—they need to be directed to create content before creating a menu and it might even be better to de-emphasize Custom Links all together for this flow.

I like your suggestion to not display boxes that are empty in the rare case there is no content for a section. That combined with a clear "not found" message for search results will help people who happen to get stuck trying to create menus for content that doesn't exist on their site yet.

Trying again for a "not found" message for the search:

No results found for "search term." Make sure you have published content you would like to add to the menu or use the Custom Links section to add a link to pre-existing content.

Or even shorter:

No results found for "search term." You can add content to a menu if it has been created and published first.

I left Custom Links out of the 2nd proposal because if someone does get stuck at this point, what they most likely need to know is that they should create and publish content before they can add it to a menu.

[helen]

I'm thinking of both - the proposed message from a screenshot up above makes it sound like there's no content whatsoever when there typically are at least a couple of things. It also highlights just how little guidance we give users to do things that are actually useful and meaningful (e.g. not having them click on sections or run a search only to find they're empty). What I think this does expose to me that the search input and the message below are not very well connected visually, though. I don't know what we should/could do here for 4.3 beyond the message; disabling empty sections is realistically a separate issue, and I don't know what would make the input and message look better connected.

[celloexpressions]

#32810 handles empty sections. So let's focus this ticket on how the search section should be handled. I think regardless of how much content exists on the site, if the secondary paragraph of an empty search result message explains that links can be added by url below and that content must be published before being added to menus, that would be useful information for both new users and users that may not have used menus in a while and could use a reminder of how things work.

[obenland]

@designsimply, would you want to take another stab at creating a patch for this?

[kirasong]

Refresh and combine of both previous patches.

[kirasong]

Attached 32710.3.diff, which refreshes/combines 32710.1.diff and 32710.2.diff.

This leaves @designsimply's initial wording intact, and includes @paulwilde's fix for displaying the HTML within the patch.

[valendesigns]

In a recent patch the No results found. string was changed in a few different places to No menu items found. for clarity and to standardize the string as there were two different variations floating around in the source. I think it should remain No menu items found. in your patch or you'll need to update the unit tests, because they'll no longer pass.

[kirasong]

@valendesigns: You are correct, thanks, if we change or add to this wording, the test needs to be updated as well. I'll upload another patch shortly.

It seemed like the question here was whether this information passed back is enough/appropriate or not, although I can certainly update it to have the "No menu items found." still returned, but with the additional verbiage as well.

[kirasong]

Fix unit test.

[kirasong]

Updated test in 32710.4.diff, and shift verbiage to note Custom Links, but including the current "No menu items found" for now.

I tend to think that "no menu items found" is confusing, since as a user, you're searching for content to add *as* a menu item, and not for existing menu items, but any additional context/explanation here helps.

[helen]

I agree that "No menu items found" is confusing. "No results found." would be preferable, and then the further explaining paragraph below.

Thinking further on how the message is visually confusing because it's unclear which section it's connected to - I think the other sections should be hidden when viewing search results. We would need to add a way to easily clear the search field beyond emptying the input, noting that search inputs with a clear button are browser-specific and that as discovered in 4.2, search inputs can lead to missed click events in iOS, as fixed in [32127].

[celloexpressions]

Please don't hide the other sections when search results are shown on a hunch. That would be hiding all of the UI that lets you get to other ways of adding items besides search, and it sounds like a visual UI issue that's influencing a massive UX change. Clearing the search field to get those sections back is not intuitive, and potentially not something users would do - if they don't see any UI but the search box and the no results message, they'll probably try a different search with similar terms, potentially never clearing it fully. Because the available menu items panel's state is generally persisted when it's closed and reopened, this could cause frustrated users to lose access to the navigation to menu item types until they close and reopen the Customizer.

If such a change were to be made it would need extensive user testing and analysis before being made. It's probably way too late in this cycle to make this sort of a change, which could have major unexpected consequences based on how things have gone with this area so far in terms of UX. I'd strongly recommend sticking to the simpler approach of improved help text for 4.3, then we can re-evaluate, run further user tests, and continue iterating on the experience in the future when we have more time to make fully-considered and tested changes. Also note that this ticket has been focused on improving the no results found string from the beginning, and this issue seems out of that scope.

I'm fine with No results found. and then whatever the agreed-upon expanded explanation paragraph is.

[jorbin]

The solution isn't clear (see the above chat). Helen is going to run with some ideas and come up with a solution that works for the issues.

[wonderboymusic]

I like the idea of a search overlay instead of shoving the other items down, hard to tell what the context is

[helen]

32710.5.diff​ experiments with better messaging and hiding the sections of available items when running a search. It is by no means a production-ready patch - I'm looking for gut reactions here.

Does the following:

• When running a search, hide the available items sections.
• Search section always has a gray background to help visually separate it.
• Removes the click handler for searching - unclear to me why it's there, easy to restore.
• Shuffles some order of cases in the JS search function and fixes a usage of this.searchTerm that appears to need to be event.target.value instead.

There are a few things that are not polished. There definitely needs to be at least one explicit way to clear search results / get back to the sections of all available items. The fade out/in is just a basic one, could likely use fine tuning in terms of timing and specific animation (if any) if we go this route. I'm also not sure infinite scroll works for search results given the height change.

[afercia]

Please consider the patch adds some HTML (paragraphs) to the data.message that's used also for wp.a11y.speak() which in turn uses jQuery text() so the HTML gets encoded and the final results is screen readers will read out encoded HTML tags:

The string inside the live region is actually:

<p>No results found.</p><p>You must create ... Links section.</p>

and gets read out this way :)

pee No results found. pee pee You must create ... pee

[helen]

@afercia: Yep, that will definitely have to change, I don't like having to use .html() if we can help it anyway.

Screencasts of ​before and ​after.

[helen]

In 33511:

Menu customizer: More clearly separate search results from available items.

Available items now fade from view while you're searching, and there is an explicit way to clear search results. No results gives a better message, though still brief this time around.

props valendesigns, designsimply, DH-Shredder, helen.
fixes #32710.

[helen]

A couple of things here - I removed the longer second paragraph because of the .html() issue as well as still being unsure about the first part regarding adding content, and the need to get this done for RC. I think it's valuable to provide more information, but we need more time than we have for 4.3 to come up with the right messaging. Let's definitely revisit. I'll also be opening another ticket tomorrow to change the clear results span to a button.

[helen]

In 33515:

Remove debug cruft from [33511].

see #32710.