Make WordPress Core

Opened 8 years ago

Last modified 2 years ago

#37417 new enhancement

Customize Nav Menus: more visible way to navigate the preview to a menu item object

Reported by: celloexpressions's profile celloexpressions Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 4.3
Component: Customize Keywords: good-first-bug needs-design-feedback has-patch
Focuses: ui Cc:

Description

Nav menus in the customizer have the benefit of live preview. One of the more hidden aspects of this experience is the ability to view a menu item's object in the preview with the "original" link in the menu item options. Unfortunately, being hidden in the item properties dropdown, this feature is little-known.

Can we add a link for this to the menu item handle somehow? I've create a preliminary (fully-functional) patch for this, and while I like the UX I think the UI could use work (feels cluttered). This helps to reinforce the connection between menus and content, as well as making it easier to see what an item is linking to when the current menu isn't shown in the preview. It also helps users that may not know that you can navigate links within the preview.

Attachments (5)

37417.9.diff (2.5 KB) - added by celloexpressions 8 years ago.
37417.13.gif (2.6 MB) - added by celloexpressions 8 years ago.
view-page.jpg (45.4 KB) - added by melchoyce 8 years ago.
menu-item-original-view.png (13.5 KB) - added by melchoyce 5 years ago.
customizer_menu_spinner.PNG (9.2 KB) - added by rahatbaksh 2 years ago.
There is a spinner

Change History (26)

#1 @westonruter
8 years ago

  • Keywords ui-feedback ux-feedback added

#2 @karmatosed
8 years ago

I would -1 the implementation done with the eye icon being the point of clicking. It is assuming a lot of meaning that icon just may not have in this case. I know this may not be suitable, but why can't we have it just work on click? Yes it's less obviously discoverable, but I'm not sure and eye icon is as discoverable as may be assumed.

To that point, it does feel really cluttered and I am concerned about other languages to English in longer strings.

#3 @melchoyce
8 years ago

I'd also -1 an eye icon — we've already used it to mean visibility in the admin. To me, showing an eye here means "this item is visible in this menu." Clicking it would signal to me "hide this item from the menu." Introducing a secondary meaning (preview) is counter-intuitive. I'd only use the eye to maintain the visible/invisible or show/hide meaning.

#4 @celloexpressions
8 years ago

Yeah, the eye is not a great solution. I'm concerned that navigating on click could cause issues because clicking on the header currently expands the menu item options, and you also need to click to then drag and reorder items, so inadvertent clicking could become an issue. Any other ideas?

#5 @melchoyce
8 years ago

Maybe adding "View" or "View Page" to the open menu item? (Attaching an image to show what I mean).

Otherwise, I'm not sure this even needs a UI. If it's in your menu, you can click the menu item itself to view the page. This feature doesn't seem super necessary.

@melchoyce
8 years ago

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


7 years ago

#7 @celloexpressions
7 years ago

Note that the "original" link ("home" in the above screenshot) is where the view behavior currently lives. Maybe we should consider moving that to align opposite the remove button and say "View [post type label]" instead? I don't think the "original" link functionality is used (or noticed) frequently; that change could be a better balance between functionality and clutter.

#8 @melchoyce
7 years ago

I honestly had no idea that's what that link did. It would be worth being more explicit here, since I don't think that link is entirely clear.

#9 @celloexpressions
7 years ago

  • Keywords needs-patch added

The other purpose of that existing link is to note what the original title of the menu item object is. Since that's also likely unclear and not particularly necessary, I'd support removing the "original link" functionality in favor of a visible "view {post type/taxonomy label}" link.

This ticket was mentioned in Slack in #design by boemedia. View the logs.


6 years ago

#11 @wesselvandenberg
6 years ago

Isn't it a option to directly show the page on the right side when the user clicks on a menu item in the customiser? So they can instantly see what they are doing in the customiser?

#12 @Hendrik57
6 years ago

I'd suggest to change the text 'original' in 'Show page'.
The eye us commonly used for hidden text. I would not use this to show a page. Just clicking in the menu item on the currently shown page in the right window would do in my opinion.

#13 @harmwinnemuller
6 years ago

Today at the WordCamp Nijmegen meetup we opened the longest pending ticket in addition to design.

I also do not see the necessity of showing the original title of the menu item object. I like Wessels' idea to automatically load the page/ menu item which is being edited. I'd suggest removing the "Original: {menu item title}" completely.

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


5 years ago

#15 @melchoyce
5 years ago

Isn't it a option to directly show the page on the right side when the user clicks on a menu item in the customiser? So they can instantly see what they are doing in the customiser?

Clicking on the title opens the accordion, which is a standard interaction across WordPress — I don't think we should change this interaction in just one place.

We should definitely separate previewing from the "original" label, since they're two different concepts. Instead, we could move "original" to live underneath the navigation label field, and only show it if you've changed the page label to something custom.

Then, we can pull "View Page" out as it's own link.

#16 @celloexpressions
4 years ago

  • Keywords good-first-bug added; ui-feedback ux-feedback removed

The latest design from @melchoyce is ready to be implemented. This should be relatively straightforward to implement.

The nav menu item control markup lives in wp-includes/customize/class-wp-customize-nav-menu-item-control.php. The markup should be reorganized to locate the original label directly below the editable label, without a link. The link can be relocated and renamed to "view data.item_type_label".

The JavaScript likely hooks into the class="link-to-original"; testing will verify whether any JavaScript adjustments are required. We may need some minor CSS adjustments to achieve the styling per the design. This can go in wp-admin/css/customize-nav-menus.css.

@rahatbaksh
2 years ago

There is a spinner

#17 @rahatbaksh
2 years ago

Hello, @melchoyce @celloexpressions I would like to work on this ticket as my first bug. I have already made some progress following @celloexpressions directions. But there is a spinner at the end of this row where the new design suggests the view page link to be. where should I place the spinner if I am to make the changes?

thank you.

This ticket was mentioned in Slack in #core by rahatbaksh. View the logs.


2 years ago

#19 @costdev
2 years ago

  • Keywords needs-design-feedback added

This ticket was mentioned in Slack in #design by rahatbaksh. View the logs.


2 years ago

This ticket was mentioned in PR #2721 on WordPress/wordpress-develop by rahat1994.


2 years ago
#21

  • Keywords has-patch added; needs-patch removed

have changed the block from PHP to HTML. But the element selectors like class remains the the same as you can see on line number 150. If that needs to be changed. I can do that no problem.

Trac ticket: https://core.trac.wordpress.org/ticket/37417

Note: See TracTickets for help on using tickets.