How/when should widgets in the preview window (and in the customizer) be scrolled to if they are not in view when being highlighted?

If we do an animated scroll, we'll have to make sure we scroll all scrolling parent containers. For example, what if a widget itself appears in a sidebar that is scrollable, but the preview window is also scrolled out of view? See #13 (comment)

Should the highlight be persistent instead of going away after 500ms?

My concern with it being persistent is that it could get in the way of the user attempting to visualize how the widget will actually appear on the site. Maybe some users would get annoyed that the highlight is stuck on. /cc @shaunandrews

Sounds like something worth testing. My guess is that a persistent highlight will help more than it would hurt.

Shaun

On Sep 24, 2013, at 1:10 AM, Weston Ruter notifications@github.com wrote:

Should the highlight be persistent instead of going away after 500ms?

My concern with it being persistent is that it could get in the way of the user attempting to visualize how the widget will actually appear on the site. Maybe some users would get annoyed that the highlight is stuck on. /cc @shaunandrews

—
Reply to this email directly or view it on GitHub.

Might seem a little bit corny, but I think an arrow pointing to the widget would be even better than a border change. Also think persistent is good, although a magnifying glass icon might work well to reduce the area that would cause the arrow to come up.

A few quick ideas for highlighting:

@shaunandrews it would be interesting to survey the different ways that widgets are oriented and rendered in a page. For example, sidebars can be oriented horizontally instead of vertically. The top row probably wouldn't work with a horizontal orientation.

@westonruter Very good point. What if we move the "edit flag" inside the widget, and make it slightly transparent:

@shaunandrews yes, that would work very well. The main problem then is figuring how when the edit flag should appear? If it persists then it would cover up the widget and would annoy someone trying to preview its contents, unless it is a very transparent (like opacity:0.1) which then becomes more opaque if you hover over it?

+1 to the edit flag or the "Custom Menu" flag with triangle.

If you want the edit buttons to be persistent, how about a toggle in the Widget Customizer group allowing show/hide of widget edit overlays?

@shaunandrews proposes that we fade out the page outside of the review:

@shaunandrews I've applied your patch regarding the canvas widget highlighting to a separate branch, and I've turned this branch into a pull request for this issue. Further commits for the widget highlighting improvements can be done to this issue-16-highlighting branch.

Regarding the previous commit, see Skype convo from @shaunandrews:

[12/7/13, 11:13:25 AM] Shaun: https://cloudup.com/cz5cgZ43EzM
[12/7/13, 11:13:35 AM] Shaun: That diff includes the working prototype for the canvas overlay.
[12/7/13, 11:13:53 AM] Shaun: I haven't had time to work on it to get it to recalculate on scroll — maybe thats something you can help with Weston?

Mentioned at http://make.wordpress.org/core/2014/01/28/widget-customizer-feature-as-plugin-merge-proposal/#comment-12745

From Nacin in IRC:

the usability of red outlines (needs a better design and they also sometimes light up when the corresponding control section is collapsed),