WordPress.org

Make WordPress Core

Opened 17 months ago

Last modified 6 months ago

#39389 new enhancement

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

Reported by: westonruter Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Customize Keywords: ux-feedback needs-patch
Focuses: ui Cc:

Description

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 17 months ago.
scroll widget into view upon control expansion.mov (6.9 MB) - added by westonruter 16 months ago.

Change History (28)

#1 @westonruter
17 months ago

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

#2 @westonruter
17 months 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
17 months ago

Implemented as part of the JS Widgets plugin in https://github.com/xwp/wp-js-widgets/pull/22

#4 @celloexpressions
17 months 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
17 months 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
17 months 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
16 months 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
16 months 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
16 months 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 16 months ago by karmatosed (previous) (diff)

#10 @westonruter
16 months ago

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

#11 @karmatosed
16 months 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
16 months ago

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

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


15 months ago

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


15 months ago

#15 @JoshuaWold
13 months 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.

Thoughts?

#16 @JoshuaWold
13 months ago

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

Video link: https://cloudup.com/iA3-V3OpvxH Interactive prototype: https://xd.adobe.com/view/087b3ec3-ff1f-4165-b8ef-0812725c6271/

#17 @westonruter
13 months 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
13 months ago

@westonruter good points. Agreed.

So something like this? https://cloudup.com/itu_raOioM9 (except that it'd scroll into view instead of fading)

#19 @westonruter
13 months 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
13 months 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.


13 months ago

#22 @jbpaul17
13 months ago

  • Milestone changed from 4.8 to 4.8.1

Punting to 4.8.1 per bug scrub earlier this week.

#23 @westonruter
12 months ago

  • Milestone changed from 4.8.1 to 4.9

#25 @westonruter
8 months ago

  • Milestone changed from 4.9 to Future Release

#26 @westonruter
6 months ago

I just found out that browsers now support smooth scrolling natively: https://twitter.com/LeaVerou/status/908521224074129408

Note: See TracTickets for help on using tickets.