Make WordPress Core

Opened 7 years ago

Last modified 21 months ago

#39389 new enhancement

Customize: Make sure selective refreshed partial placement is scrolled into view

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


As of #36678 there are visible edit shortcuts in addition to the “shift-click to edit” behavior in the preview. This ensures that the corresponding control for a given element in the preview can be focused and discovered. However, there is no corresponding facility to quickly discover and jump to an element in the preview that corresponds to a given control. When making a change in a control any corresponding element (partial placement) in the preview should be scrolled into view. This is a key usability improvement.

Attachments (2)

39389.0.diff (2.6 KB) - added by westonruter 7 years ago.
scroll widget into view upon control (6.9 MB) - added by westonruter 7 years ago.

Change History (34)

7 years ago

#1 @westonruter
7 years ago

  • Keywords has-patch needs-testing ux-feedback added

#2 @westonruter
7 years ago

Or perhaps the scrolling-into-view should be done upon focusing on a control, not merely upon changing the control? Widgets implemented this to a degree whereby whenever you focus or hover on a widget control an outline will be added around the widget in the preview. For widgets perhaps the partial could be scrolled into view upon expansion of the widget control.

#3 @westonruter
7 years ago

Implemented as part of the JS Widgets plugin in

#4 @celloexpressions
7 years ago

  • Focuses ui added

I'd like to see partials scrolled into view both when the associated setting is changed and when an associated control is focus()ed. However, auto-scrolling shouldn't happen if a user manually navigates to a control and focuses its UI; the focus behavior should only happen on an autofocus. It might make sense to also skip it if the control is focused from the partial edit icon.

#5 @westonruter
7 years ago

I've been trying out the implementation in JS Widgets and it's been quite annoying for the scrolling to happen whenever the widget changes. Limiting it to just when the control is expanded is working better for me. I agree that the scrolling shouldn't be done if the user clicked the edit shortcut as well.

#6 @celloexpressions
7 years ago

Limiting to control expansion (largely limited to widgets and menu items) and .focus()es (from edit shortcuts or elsewhere programmatic) sounds okay to me; I'd definitely err on the side of less auto-scrolling.

#7 @karmatosed
7 years ago

For people to give ux-feedback (as it's tagged for that), could we have a video or gif to show what is being suggested?

#8 @westonruter
7 years ago

@karmatosed attached a video. Note in this example the scrolling in the preview is only done when a widget control is expanded… expanding the control acts like the inverse of the visual edit shortcut—perhaps this could be called a “preview shortcut”. For other controls that lack an expanding control, like Site Title, should this scrolling be done whenever a change is made to the setting? Should scrolling to the changed element in the preview be done in every case?

#9 @karmatosed
7 years ago

Thanks for attaching a video.

One really obvious thing that strikes me is the speed. It feels too fast and as a result it removes one of the experience benefits of scrolling on click - the journey. We of course don't want it too slow that it feels like a chore, but not seeing where it comes from and having it so fast is a very sudden experience for users. It's a little disconcerting being so fast for an experience.

Can we have some experimentation over showing more of a path and being less sudden for users? I totally can see the merit in having a click to where things are going on - that's one thing I very much see being useful. My point is really about the experience of that.

Last edited 7 years ago by karmatosed (previous) (diff)

#10 @westonruter
7 years ago

@karmatosed good points. So you're suggesting that it should add smooth scrolling?

#11 @karmatosed
7 years ago

I think it would be good for it to be smoother and I almost feel we could do something like have a CodePen (if that's suitable) or other way of seeing a few versions. It's going to be a balance to make it responsive enough but not a dramatic sudden experience.

#12 @westonruter
7 years ago

  • Keywords needs-patch added; has-patch needs-testing removed

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

7 years ago

This ticket was mentioned in Slack in #core-customize by melchoyce. View the logs.

7 years ago

#15 @JoshuaWold
7 years ago

@karmatosed and @westonruter following up on this conversation. Do you see any concerns with causing confusion for users if they are expanding controls and having the content constantly change on them?

Meaning, are there scenarios where I'd want to expand a control without the content view changing?

If so, it might make sense to make the scroll into view a manual process, or have a way to override it at least. Perhaps in the expanded control there's a button to scroll into view.


#16 @JoshuaWold
7 years ago

I figure it would help to show a prototype of what I was thinking. :)

Video link:
Interactive prototype:

#17 @westonruter
7 years ago

@JoshuaWold thanks for the prototypes. It's true that there could be some confusion for users if they focus on a control and the preview jumps around. I don't think that having a “Jump to section” link inside of the widget will work because this scrolling-into-view should also happen when focusing on a simple text control like for the Site Title which does not expand.

Here's an idea: what if there was no auto-jumping behavior, but that when a user focuses (and/or expands) on a control that is not currently shown in the preview, if a “Jump to element” button appears at the top or bottom of the preview window with an arrow pointing up or down, respectively, indicating that the element being modified is out of the current viewport? A user could then click that link to opt-in to the (smooth) scroll to bring that element into view. As soon as the element appears in the viewport, the jump link at the top or bottom of the preview would disappear.

/cc @karmatosed

#18 @JoshuaWold
7 years ago

@westonruter good points. Agreed.

So something like this? (except that it'd scroll into view instead of fading)

#19 @westonruter
7 years ago

@JoshuaWold yes, exactly! Maybe the button could animate into view with a bounce as well, so that it clearly catches the user's eye.

#20 @JoshuaWold
7 years ago

@westonruter agreed, I couldn't quite mimic the look with my prototyping software. But some kind of 0 > 100% opacity with a bounce would do it.

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

7 years ago

#22 @jbpaul17
7 years ago

  • Milestone changed from 4.8 to 4.8.1

Punting to 4.8.1 per bug scrub earlier this week.

#23 @westonruter
7 years ago

  • Milestone changed from 4.8.1 to 4.9

#25 @westonruter
7 years ago

  • Milestone changed from 4.9 to Future Release

#26 @westonruter
6 years ago

I just found out that browsers now support smooth scrolling natively:

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

6 years ago

#28 @JoshuaWold
6 years ago

We just discussed this in our design triage meeting, wanted to validate if the UI suggestion proposed previously still makes sense, or if we need to look at a new solution?


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

4 years ago

#30 @karmatosed
4 years ago

  • Keywords has-ux-feedback added; ux-feedback removed

Thanks for all the input here, it's been a little while and there has been design feedback. This came up again in design triage, so going to remove the keyword.

#31 @celloexpressions
3 years ago

  • Keywords good-first-bug added
  • Version set to 4.5

This needs a patch that implements the javascript Element.scrollIntoView({behavior: "smooth"}) behavior. The end of the selective refresh partial refresh method in wp-includes/js/customize-selective-refresh.js should trigger visibility of a button to initiate this behavior.

This has native support in most browsers and could be considered a progressive enhancement. Alternatively we could reuse the jQuery implementation from Twenty Seventeen (linked above) for improved browser compatibility.

Alternatively, a patch that implements the smooth scrolling without a button is worth exploring and testing given the smooth scrolling behavior and its use in Twenty Seventeen.

#32 @coquardcyr
21 months ago

Hi @celloexpressions,
I implemented a scroll to the element in the refresh method however that works only for new elements and not already existing ones.
Is this behavior intended?

If not I searched areas where to add this piece of code in the code. However as I am new on that code base I could find where to add it. Could you indicate it to me?

Thanks by advance.

Note: See TracTickets for help on using tickets.