WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 5 weeks ago

Last modified 3 weeks ago

#27403 closed enhancement (fixed)

Improve UI for linking areas of Customizer preview to corresponding controls (desktop and mobile)

Reported by: westonruter Owned by: westonruter
Milestone: 4.7 Priority: high
Severity: normal Version: 3.9
Component: Customize Keywords: has-patch
Focuses: ui, accessibility, javascript Cc:

Description (last modified by westonruter)

Right now you may Shift+Click on a widget in the customizer preview and the corresponding widget area customizer section will expand, along with the corresponding widget control, and focus on the first field in that widget control. This is also available for nav menu items (#32681), and for any elements that are using selective refresh (#27355).

https://cldup.com/r9cTBdwm2b.png

(Props @afercia for image from #33251.)

While there is a tooltip that appears when hovering over a widget, this can be difficult for a user to discover. An alternative would be for there to be an Edit button that appears when hovering over a widget within the preview. The challenge with this, however, is that it may be difficult to universally style this button so that it can appear properly in all themes. The tooltip and Shift+Click requires no UI. A simple click (without a modifier key) was problematic because it prevents common mouse-based interactions with widgets.

Originally reported in: https://github.com/x-team/wp-widget-customizer/issues/78

For some alternative designs, see https://github.com/xwp/wp-widget-customizer/pull/16

Some experimentation has been done on WordPress.com in the Customizer for adding Edit buttons alongside widgets.

Additionally, there is a fundamental issue with the shift+click feature: it is not mobile friendly since there is no ability to do this on a touch screen. The immediate equivalent feature for mobile I think would be a long press. On mobile, the preview fills the screen so if a widget, nav menu item, or other partial was long-pressed it could then flip over to the controls pane where the relevant control would be focused. The problem with shift-click on desktop is similar to the problem with long-press on mobile: there is no indication which elements can be edited so the user doesn't know where to try.

And @afercia notes from duplicate ticket #33251:

By the way, the point is this feature is really hidden. The only chance users have to be informed about this is when by accident they hover on a widget and notice the title attribute. Not to mention touch devices, as far as I know, won't ever show this. There are no instructions or Help text that mention this, as far as I know.

Considering also #24766 I'd recommend to don't rely on title attributes alone to convey such important information. It would be a nice, interesting, challenge trying to find a new design/UI pattern to be used instead of a title attribute. Call for designers :)

Also, from an accessibility point of view, this UI control is not focusable and hardly usable for keyboard users and screen reader users.

For more discussion, see:

Attachments (16)

direct-manipulation.png (2.4 MB) - added by melchoyce 10 months ago.
27403.diff (5.5 KB) - added by sirbrillig 2 months ago.
Basic implementation of direct manipulation icons using partials
27403.2.diff (3.9 KB) - added by sirbrillig 8 weeks ago.
Updated implementation with button icons, element-paired icons, and menu support
27403.3.diff (4.0 KB) - added by sirbrillig 8 weeks ago.
Updated patch to include icon removal
dm-core-buttons-primary.jpg (256.1 KB) - added by melchoyce 8 weeks ago.
dm-core-buttons-secondary.jpg (247.7 KB) - added by melchoyce 8 weeks ago.
27403.4.diff (7.8 KB) - added by sirbrillig 8 weeks ago.
Updated patch to include translations and added widgets
27403.5.diff (9.3 KB) - added by sirbrillig 7 weeks ago.
Updated patch to handle absolute positioned targets
27403.6.diff (9.9 KB) - added by sirbrillig 7 weeks ago.
Update patch to hide icons when sidebar is collapsed (needs work since non-clicks can collapse sidebar)
cdm-with-and-without-float-labeled.png (73.0 KB) - added by sirbrillig 7 weeks ago.
Floated icon problems
27403.7.diff (10.6 KB) - added by sirbrillig 7 weeks ago.
Updated patch with before positioned icons
27403.8.diff (10.3 KB) - added by sirbrillig 7 weeks ago.
Updated patch with left-margin position safeguards
27403.9.diff (11.6 KB) - added by westonruter 7 weeks ago.
https://github.com/xwp/wordpress-develop/pull/179/commits/a0c1cd0d4bba9d946e7315e77bd2414f8c856101
27403.gif (2.4 MB) - added by celloexpressions 6 weeks ago.
Demo of latest patch with Twenty Fifteen.
27403-persistent-shortcuts.diff (4.2 KB) - added by westonruter 5 weeks ago.
27403-persistent-shortcuts.2.diff (5.1 KB) - added by westonruter 5 weeks ago.

Change History (140)

#1 @ocean90
2 years ago

Shilft+Click is currently half-broken, see #29529.

#2 @chriscct7
12 months ago

  • Keywords needs-patch added

#3 @westonruter
12 months ago

  • Description modified (diff)

#4 @westonruter
10 months ago

  • Description modified (diff)
  • Milestone changed from Awaiting Review to Future Release
  • Summary changed from Widget Customizer: Improve discoverability of widget editing in preview to Improve UI for linking areas of Customizer preview to corresponding controls (desktop and mobile)

#5 @westonruter
10 months ago

  • Description modified (diff)

#6 @westonruter
10 months ago

#33251 was marked as a duplicate.

#7 @westonruter
10 months ago

  • Description modified (diff)
  • Focuses accessibility added
  • Priority changed from low to normal

#8 @westonruter
10 months ago

  • Description modified (diff)

#9 follow-up: @westonruter
10 months ago

@melchoyce is the WordPress.com feature plugin for the Customizer extensions available yet on GitHub? It would be great to start iterating on that as a feature plugin for core.

#10 in reply to: ↑ 9 @melchoyce
10 months ago

Replying to westonruter:

@melchoyce is the WordPress.com feature plugin for the Customizer extensions available yet on GitHub? It would be great to start iterating on that as a feature plugin for core.

We're currently working on another iteration. We should be ready to open up the project repo in about a month.

#11 @melchoyce
10 months ago

FWIW, direct-manipulation.png is what we're building right now.

#12 @westonruter
10 months ago

In the current Selective Refresh framework, each placement for a partial gets the same tooltip:

Shift-click to edit this element.

For widgets, actually, there is an additional tooltip which is added at the initial document ready event:

Shift-click to edit this widget.

However, after the first time the user edits a widget, the widget-specific tooltip gets replaced with the generic one.

I realized that it might be good to introduce a new parameter to WP_Customize_Partial, like $inline_edit_tooltip, which could allow the message to be customized for the specific type of partial being shown in the preview (e.g. blogname vs widget vs nav menu). But then this one message wouldn't be applicable to touch screens or keyboard interaction (both of which aren't even possible right now).

But knowing that this ticket exists to improve the UI for contextual links from regions on the page to their corresponding controls, I suppose that it wouldn't be a good idea to introduce WP_Customize_Partial::$inline_edit_tooltip now prematurely if it will be deprecated in the next release.

Agreed?

#13 follow-up: @sirbrillig
8 months ago

@westonruter FYI if it's helpful we've open-sourced the click-to-edit customizer plugin that we're using on WP.com here: https://github.com/Automattic/customize-direct-manipulation

#14 @celloexpressions
8 months ago

We should definitely utilize fields in partials for this, but I'd actually be in favor of using something like "title". If we also had an "icon" (which would be a dashicon id) field, we could then do something like @melchoyce mocked up fairly easily in terms of API. Should probably avoid any API that is specific to title attributes for now.

Last edited 7 months ago by celloexpressions (previous) (diff)

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


7 months ago

#16 in reply to: ↑ 13 @westonruter
3 months ago

Replying to sirbrillig:

@westonruter FYI if it's helpful we've open-sourced the click-to-edit customizer plugin that we're using on WP.com here: https://github.com/Automattic/customize-direct-manipulation

@sirbrillig @melchoyce sorry, somehow I missed this! Thanks for sharing. I've given the plugin a spin and opened a few GitHub issues for discussion, in particular:

Cheers!

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


3 months ago

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


3 months ago

#19 @westonruter
3 months ago

In 38492:

Customize: Introduce paneVisible state and ensure pane is visible when a construct is expanded (or focused).

Fixes issue whereby a user would see nothing happen if the pane is collapsed while they shift-click to edit an element in the preview.

Props curdin, celloexpressions, westonruter.
See #27403.
Fixes #36678.

#20 @paaljoachim
3 months ago

Manipulating areas in the preview screen.
What about checking out various page builders to see how they accomplish this task?

  • Some have some kind of edit button. Click it to go into edit mode. Then hover over various areas that can be manipulated and thin frames/borders are seen around the content. One can then click inside these frames/borders and some builders can adjust the content directly there. Other builders will have another area of the page where the content can be changed.
  • Having extra visual content (edit buttons etc) that does not belong to the page inside a preview page creates visual clutter.

It would be good to throughly go through various UI options and perhaps also run some user tests.

#21 @sirbrillig
3 months ago

Some have some kind of edit button. Click it to go into edit mode.

I've been thinking about this for a while, and in my opinion the Customizer *is* "edit mode". The button you describe is the "collapse" button on the sidebar, which toggles out of "edit mode" and back to "preview mode".

We took this approach with the customize-direct-manipulation plugin: if you collapse the sidebar, the edit buttons in the preview disappear.

#22 @folletto
3 months ago

I've been thinking about this for a while, and in my opinion the Customizer *is* "edit mode".

Agreed. This meaning is also reinforced by the actual action on the buttons to get there ("Customize"). Having the sidebar visible with the editing controls, as the desktop editors do, is also a further reinforcement that the content on the side is editable right there.

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


3 months ago

#24 follow-up: @celloexpressions
3 months ago

Unfortunately, while the customizer is "edit mode", it also serves the critical role of providing the live preview. There needs to be an obvious way to see this live preview without any obstructions. The collapse sidebar button could serve that role but it almost certainly isn't obvious enough. Perhaps we need a separate toggle somewhere? We'll need user testing regardless.

#25 in reply to: ↑ 24 @paaljoachim
3 months ago

Replying to celloexpressions:

Unfortunately, while the customizer is "edit mode", it also serves the critical role of providing the live preview. There needs to be an obvious way to see this live preview without any obstructions. The collapse sidebar button could serve that role but it almost certainly isn't obvious enough. Perhaps we need a separate toggle somewhere? We'll need user testing regardless.

I agree!

Down the road...
the customizer will also be available on the frontend. Having an edit toogle both places (in the backend customizer and frontend) will keep a clear differentiation of seeing the page at it is and then going into edit mode to click elements and do the inline adjustments needed.

Last edited 3 months ago by paaljoachim (previous) (diff)

#26 @celloexpressions
3 months ago

  • Component changed from Widgets to Customize
  • Severity changed from minor to normal

#38080 is a prerequisite. We need to make sure that all proposals on this ticket also address the mobile experience.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


2 months ago

#28 @rianrietveld
2 months ago

  • Focuses accessibility removed

Removing the accessibility focus just to take this ticket out from the a11y report, will follow anyways.

This ticket was mentioned in Slack in #core-themes by davidakennedy. View the logs.


2 months ago

#30 @sirbrillig
2 months ago

ok, so... thinking a little out loud here, the steps to bringing the CDM plugin into core (if that's what we decide to do) would probably look like this:

  1. We would need to convert all the javascript from ES2015 to ES5, because AFAIK including transpiled javascript is not really a core thing.
  2. We'd need to find a good place to enqueue the javascript. I'm not sure where right now.
  3. Most of the plugin is JS, and mostly in the preview pane. However, there's also a piece for the admin side (the sidebar) that adds an API to focus certain things that were not otherwise focusable and to create the "bounce" effect on the appropriate input element. We would need to decide where to put those API pieces and the "bounce" highlight.
  4. We'd need to do a little work to make some theme elements more discoverable (like menus) which is PHP code that's currently in the plugin file. This is maybe the most challenging part of the plugin: how can JS be used to find things in the preview for different themes?

There's also the idea of adding awareness of partials for discoverability, which Weston pointed out here: https://github.com/Automattic/customize-direct-manipulation/issues/23

A note on the "bounce" effect: we did that because it wasn't always obvious when you click an element that the sidebar just became focused (eg: if the relevant sidebar pane is already visible), or what part of the sidebar was relevant to the click. In our user tests the little bounce made a big difference in discoverability.

#31 @celloexpressions
2 months ago

Partials should definitely be the mechanism for associating elements of the preview with settings/controls and linking them together. We can add properties to WP_Customize_Partial for things like icon and/or label once we finalize the UI.

If done properly, themes should be able to implement this fully within the PHP API, with all of the JS happening internally/automatically, similarly to how selective refresh works. The partial's selective refresh response could potentially pre/append the markup needed for the buttons automatically, although that part should probably be off by default with a flag set when registering the partial. Core add-theme-supports (menus, widgets, custom logo, possibly others) would support it out of the box for any theme (although themes would need to ensure the CSS is compatible, but if possible we should make every effort to give all themes some support as the customizer does in general).

@sirbrillig
2 months ago

Basic implementation of direct manipulation icons using partials

#32 @sirbrillig
2 months ago

I uploaded a fairly naive patch with a lot of rough edges that adds the CDM icons found in the WP.com plugin to core. It uses the selective refresh partials for its data so it will only work for theme elements that render partials.

Here is a video of it in use on twentyfifteen: https://cloudup.com/cUy5oFSjuw9

Things it needs (assuming this is a direction everyone wants to go):

  • Maybe move all the icon methods to their own file
  • Improve the detection of DOM changes in which to reposition icons
  • Improve the positioning of icons for certain elements to prevent overlapping those elements
  • Add (translated) hover text to the icons
  • Hide/show icons when sidebar is shown/hidden
  • Add bounce effect (or some other animation) to make it clear what a clicked icon did
  • Testing on themes with absolutely positioned elements
  • Testing on themes with hamburger menus
  • Testing to see if there are memory leaks

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


2 months ago

#34 @folletto
2 months ago

Some design questions that were raised in the chat (see link above), and brief answers. :)

what's the best experience for showing edit icons when you need them and hiding them when you don't

In simple terms, this should be added to the collapse icon. While that has some drawbacks (mobile will require something still), it's still a fairly acceptable way everything considered, and avoids further clutter.

the design of the edit icons

The current design has been iterated already multiple times on WordPress·com, and it's currently live. While I think everything can be improved, I feel this is already a solid design, thanks in large measure to @melchoyce.

each widget/menu item gets an icon or only the associated area

  • Widgets should be individually referred to. They are big and it also helps differentiating them on themes where it might not be very clear.
  • Menus are instead too small to do it, so they should have just one icon for the entire menu area.

should themes be able to specify a custom icon for a given partial, or does the edit icon always work?

While providing a way to change icon is possible, it shouldn't be up to the theme but to Core (widgets, menus, etc) and maybe Customizer Plugins. Then the theme uses these features, thus getting the icon, but it's not set explicitly by the theme.

However, there's also a solid argument in keeping always the same icon. It's simple. It's intuitive. And the user easily associates the icon to edit.

do we need tooltips of some sort? Is there a good way to make that accessible with touch, etc?

On mobile it's not possible, as there's no hover and tap would open the panel. But even so, the point of direct manipulation is that you are seeing what you're editing, and then by clicking you get the full explanation. A tooltip there feels redundant.

I hope it helps. :)

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


8 weeks ago

#36 @sirbrillig
8 weeks ago

Status update for the patch:

  • Trying to figure out how to get partial.showControl() to work with a menu (currently does nothing).
  • Also noticed a bug (actually noticed by @westonruter in the plugin repo https://github.com/Automattic/customize-direct-manipulation/issues/23#issuecomment-251543800 ) where partials do not call their ready() method when first added.
  • Experimenting with injecting the icons directly to the elements in the DOM (mostly working!).
  • Need to find/make an event that is triggered when a partial is removed so the associated icon can be removed.

Sorry for my slowness here. I'm not super-familiar with the selective refresh code and the panel focusing code. If anyone has any help to offer on the above, please let me know.

#37 @sirbrillig
8 weeks ago

When I call partial.showControl() on a menu, it sends the following event to the parent frame:

api.preview.send('focus-control-for-setting', 'nav_menu_instance[0e6e681bc81cb296f5497e1fe9fb9d23]')

It appears that 'nav_menu_instance[...] does not map to a panel in the sidebar. I notice that the panels I can focus with that event have a data-customize-setting-link property, but menu panels don't appear to have that anywhere I can see.

How does shift-clicking on a menu work?

api.preview.send( 'focus-nav-menu-item-control', menuItem );

In that case, menuItem is an integer for a specific menu item, but it looks like maybe there's no way to focus a menu itself.

If that's true (@celloexpressions ?) then I suppose there's a few options:

  • We could extend showControl() to notice when it's targeting a menu, try to find an integer for the menu's first item, and send that to the focus-nav-menu-item-control event. That seems like a hack, though.
  • We could modify the handler for focus-control-for-setting to accept menu hashes like the one above and somehow find the menu panel that the hash applies to. This is more sensible, but it's quite a lot of pieces I'm not familiar with.

#38 @celloexpressions
8 weeks ago

Hmm, @westonruter would know for sure, but that might be the case. It implements selective refresh internally, so we may need to make some adjustments to unify menus with other partials. That may be something for a future ticket, with a hack like those described above or no support for menus for now.

@sirbrillig
8 weeks ago

Updated implementation with button icons, element-paired icons, and menu support

#39 @sirbrillig
8 weeks ago

Thanks! Good advice; let me see how far I can get even with hacks.

I figured out one way to get a menu to focus without changing much other code is to replace nav_menu_instance[...] with nav_menu_locations[primary]. I'm not sure if it's ideal, but it works for the time being.

Still working on these issues:

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


8 weeks ago

#41 @celloexpressions
8 weeks ago

  • Milestone changed from Future Release to 4.7

Excellent work @sirbrillig! The small size of the patch is really great to see for unlocking so much functionality. Testing briefly, it works as advertised.

There are a few tweaks to go still, but I'm moving to 4.7 since this should be ready to go soon.

#42 @afercia
8 weeks ago

  • Focuses accessibility added
  • Milestone changed from 4.7 to Future Release

These new controls would need an accessibility review, at least for keyboard accessibility.

#43 @westonruter
8 weeks ago

I appreciate that the new functionality is added via methods on the Partial class, allowing the functionality to be overridden and extended based on the Partial.

#44 @paaljoachim
8 weeks ago

  • Focuses accessibility removed

Can someone post an animated gif so we can see what it looks like at this stage?

#45 @afercia
8 weeks ago

  • Focuses accessibility added
  • Milestone changed from Future Release to 4.7

Sorry, seems some simultaneous comments messed up the milestone and focus 😁

#46 @celloexpressions
8 weeks ago

A couple of additional comments with testing:

  • I'm back to thinking we need some sort of a toggle for another reason - if this causes layout issues on some themes (Twenty Seventeen's header menu currently is an example), that would mitigate the issues there without having to add theme support.
  • Is there a good way to show icons for empty widget areas? That's an important point for discoverability.
  • Focusing the menu location selector is a great approach for menus for now, since there's a link from there and the partial is more directly tied to that than the menu itself anyway.
  • Add type="button" for the button elements.
  • Add an aria-label to each button, if possible that includes the label of the associated control.
  • The buttons need a better focus style, with something other than color changes. Probably a blue outline/box-shadow as is used elsewhere in core.

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


8 weeks ago

#48 @paaljoachim
8 weeks ago

Regarding blue icons in the preview pane.

  1. It creates visual clutter. Previewing the page in the customizer should show it as it is.
  2. Removing the blue icons requires the user to minimize the left customizer pane. (Which I find too vague.)

Having an edit button.

  1. As more and more elements can be edited having a clear differentiation between preview and edit is more and more needed. Having an UI element to change between preview-edit will very much help.
  1. I find it much more forward thinking. As the preview/edit button could also down the road be used on the frontend of the site doing something similar as could be done in the backend customizer.

Please also post images/animated gifs so that people like myself can easily view what is going on directly in the trac ticket.
Thanks.

#49 @afercia
8 weeks ago

Current status of the buttons accessibility, no text or label that can be read out:

https://cldup.com/3IEC0v0CCr.png

Last edited 8 weeks ago by afercia (previous) (diff)

#50 @sirbrillig
8 weeks ago

As more and more elements can be edited having a clear differentiation between preview and edit is more and more needed. Having an UI element to change between preview-edit will very much help.

Agreed. This is an important design and UX issue. I still believe that this should be the sidebar collapse button, however. Why not move the sidebar collapse button to somewhere more distinct?

Is there a good way to show icons for empty widget areas? That's an important point for discoverability.

This is a tricky point. Not just for widgets, but also for things like header images and themes where site-title is hidden when empty. I think it can be done, but maybe this is a future feature?

Please also post images/animated gifs so that people like myself can easily view what is going on directly in the trac ticket.

Animated gif:

https://cldup.com/-CyAMAc5zc.gif

#51 @afercia
8 weeks ago

P.S. flexbox is tricky, there are browsers that still implement it differently. As you can see in the screenshot above (comment 49, Safari 10) the icon is not perfectly centered while on Chrome it is. I'd be curious to see how they look on Edge and all the IE versions that the Customizer currently supports. IE 9 is still supported, right? :) It is absolutely necessary to use flexbox here?

Last edited 8 weeks ago by afercia (previous) (diff)

#52 follow-up: @folletto
8 weeks ago

Having an edit button.

This is a new feature, so I understand we're still mostly working in the frame of mind of the customizer and in that perspective one can imagine to toggle this as being an extra feature layered on top of the existing. However, from a user perspective, they have already clicked on edit. They are already editing.

The "Customize" button on the admin bar is the edit button.


Current status of the buttons accessibility

A question on accessibility here: all the direct manipulation buttons are extra pointers to existing customizer controls. In practice, they provide a direct access to panels.

In terms of accessibility, does it even make sense to make them accessible, instead of hiding them entirely, given there's already another accessible way to do the same thing (as much as the customizer navigation is accessible)?
This is probably a meta-question, not strictly related to this scenario, so feel free to answer both in theory and in this specific case. :)

Last edited 8 weeks ago by folletto (previous) (diff)

#53 @afercia
8 weeks ago

The "Customize" button on the admin bar is the edit button.

I kindly disagree :) The Customizer is not editing territory and I really hope it will never be.

@sirbrillig
8 weeks ago

Updated patch to include icon removal

#54 @folletto
8 weeks ago

I kindly disagree :) The Customizer is not editing territory and I really hope it will never be.

I think we need to clarify what we need by "editing territory", which I think it's another can of worms and I'm not getting into that right now. ;)

All I'm saying is that the user reached that page because they expressed the intent to customize by clicking "customize" either in front-end or in the admin. Imagining to add another "edit" button after they have already expressed that desire by reaching that page is correct in terms of "customizer" as "Classic WordPress Implementation Of A Customization Tool With Preview", but that's us, that's the codebase, that's the history where we come from. The user intent? It has already spoken by the time they are seeing the customizer. And it can't be ignored.

#55 in reply to: ↑ 52 @afercia
8 weeks ago

Replying to folletto:

A question on accessibility here: all the direct manipulation buttons are extra pointers to existing customizer controls. In practice, they provide a direct access to panels.

In terms of accessibility, does it even make sense to make them accessible, instead of hiding them entirely, given there's already another accessible way to do the same thing (as much as the customizer navigation is accessible)?

If you provide a UI control, it should be usable by everyone. If it is not, maybe you should probably consider why you're adding that control in the first place. Additionally, an empty button is not just an accessibility issue, its a matter of web standards too and keeping it empty, I would say it's an incomplete development. The web is not an empty canvas, standards and specifications exist for a good reason.

#56 @folletto
8 weeks ago

If you provide a UI control, it should be usable by everyone.

Thank you for the clarification.
Sorry for derailing a bit the ticket with a wider question on accessibility. :)

#57 @sirbrillig
8 weeks ago

P.S. flexbox is tricky, there are browsers that still implement it differently.

This is a very good point. I'm sure we can make these icons better supported, but my CSS skills are limited. If anyone wants to take a crack at it, please do!

Another point only briefly touched on above is that with the icons added to the page, they:
A) can affect the page layout, and
B) don't hover over elements which are absolutely positioned.

Twentythirteen is a good example of a theme which has both issues. The menu icon causes the menu area to become twice as thick and the footer widgets are all positioned away from their icons.

https://cldup.com/nREXTndVC9.png

Making the icons absolutely positioned "solves" this by removing the icons from the document flow. Unfortunately this opens another can of worms. It requires very careful positioning to prevent the icon from completely covering its target, not falling off the page, not appearing to relate to another page element, etc. Also when certain DOM changes take place (eg: repositioning widgets in Twentythirteen) the icons do not automatically follow, so we must listen to all sorts of changes and perform manual repositions.

https://cldup.com/LWRuQNfF2d.png

The implementation on wp.com does all of these things to support the widest array of themes possible, and we're still tweaking it every so often. I was hoping to avoid the issue in core, but unless we disable this feature for certain themes, I'm starting to see us going down the same road.

https://cldup.com/-iIw6EMGvJ.png

Last edited 8 weeks ago by sirbrillig (previous) (diff)

#58 @paaljoachim
8 weeks ago

I think placing icons directly on the layout is a tricky thing to have as there are so many uncertainties as to how it ends up affecting the overall design.

We should consider various alternatives and look at advantages and disadvantages of each and have a broader discussion on various ways to edit elements through the customizer.

Btw clicking the customizer link in the top admin or in the backend opens up the environment for live editing and previewing. Where the user can see the live site and make changes seen in realtime. One expects to see the site as it is and then make the adjustments needed.

#59 @melchoyce
8 weeks ago

Uploaded some alternate button ideas, drawing from core button styles.

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


8 weeks ago

#61 @eherman24
8 weeks ago

I've forked the original plugin because I needed to extend it and add custom markers in custom locations.

I would love to see an API put in place before this hits core to make it easy to extend and add custom markers, override links or add custom icons etc. This is a huge step forward for the customizer.

#62 follow-up: @sirbrillig
8 weeks ago

Btw clicking the customizer link in the top admin or in the backend opens up the environment for live editing and previewing. Where the user can see the live site and make changes seen in realtime. One expects to see the site as it is and then make the adjustments needed.

Just brainstorming, @paaljoachim, but what if immediately upon entering the Customizer the sidebar was collapsed, but we made the collapse/extend button big and bright (maybe even with an animation) so it's clear from the start how to hide/show the preview.

Uploaded some alternate button ideas, drawing from core button styles.

@melchoyce: thanks! I like the square gray ones a lot, but partly that may be because they match the gray background in that theme. I guess the advantage of bright icons is that they are more easily visible with different backgrounds. ¯\_(ツ)_/¯

I would love to see an API put in place before this hits core to make it easy to extend and add custom markers, override links or add custom icons etc.

I really like this idea, @eherman24! Do you have anything in mind for this API? For the icons themselves, we could store the svg in wp.customize... somewhere. For custom locations, this version varies from the plugin because while the plugin targets a specific list of elements, this version simply adds icons to selective refresh partials. So to add specific targets one would theoretically just need to add new partials. That said, maybe there are specific targets that would work differently. As it is right now it's possible to override Partial.showIconForElement or Partial.showControl to get a lot more options.

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


8 weeks ago

@sirbrillig
8 weeks ago

Updated patch to include translations and added widgets

#64 in reply to: ↑ 62 @westonruter
8 weeks ago

@sirbrillig:

Replying to sirbrillig:

Btw clicking the customizer link in the top admin or in the backend opens up the environment for live editing and previewing. Where the user can see the live site and make changes seen in realtime. One expects to see the site as it is and then make the adjustments needed.

Just brainstorming, @paaljoachim, but what if immediately upon entering the Customizer the sidebar was collapsed, but we made the collapse/extend button big and bright (maybe even with an animation) so it's clear from the start how to hide/show the preview.

I don't think opening the customizer with the pane collapsed would be well received because it would be yet another click to start getting to work. However, in the future when we can bootstrap the customizer on to the frontend, I definitely think this would be a great way to enter the customizer: the pane can be loaded and slide out on any frontend page and you could get to work right away without ever going to customize.php.

From my personal aesthetic point of view, having the edit icons persistently shown in the preview when the controls are expanded is very visually cluttered. I feel strongly that we should figure out a way to only show the icons contextually, either showing them momentarily when the preview first loads, or showing them when hovering over a partial's placement container, or a second or so after a scroll/mousedown/touch event. To access the buttons then, on desktop and mobile, a user would just have to scroll the preview or hover over or touch some inert element of the screen to get the icons to show up, particularly the icon in the partial's container (although all the other icons could also be revealed, but perhaps with half-opacity to indicate that they're not related to any container being touched).

Consider also mobile where there is no collapse button. You can show the preview or show the controls, not both. So when viewing the preview on mobile, the edit icons need to be shown intelligently but also not get in the way of the preview.

Consider also in #36678 we fixed an issue whereby shift-clicking on an element in the preview can automatically expand the controls pane if it was collapsed. So the edit icons should be still available in the preview when the controls are collapsed.

Uploaded some alternate button ideas, drawing from core button styles.

@melchoyce: thanks! I like the square gray ones a lot, but partly that may be because they match the gray background in that theme. I guess the advantage of bright icons is that they are more easily visible with different backgrounds. ¯\_(ツ)_/¯

I like the gray icons as well. The gray icons feel less visually-cluttered. But my concern about there being so many icons persistently all over the place remains.

#65 @celloexpressions
8 weeks ago

I think the solid-colored (blue) icons are probably better cross-theme and in terms of ensuring they're noticed. Themes can be encouraged to tweak this color as needed but keep the general style from core.

Per the design chat we're thinking about a click (anywhere on the page) to toggle the icons on and off approach. We'll probably also need a hidden toggle for keyboard users to trigger this with an actual button.

#66 @jorbin
7 weeks ago

  • Owner set to westonruter
  • Status changed from new to assigned

Trying to make sure this can get completed for 4.7, so giving this an owner.

#67 @celloexpressions
7 weeks ago

  • Owner changed from westonruter to sirbrilling

Let's assign to @sirbrillig for now since he's working on it, then I'll review and track before passing to @westonruter for commit to lighten his load a bit.

We need a final patch by the end of this week, I'd say.

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


7 weeks ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


7 weeks ago

@sirbrillig
7 weeks ago

Updated patch to handle absolute positioned targets

@sirbrillig
7 weeks ago

Update patch to hide icons when sidebar is collapsed (needs work since non-clicks can collapse sidebar)

@sirbrillig
7 weeks ago

Floated icon problems

#70 @sirbrillig
7 weeks ago

Floating icons may not be the best solution after all (see attached screenshots). It removes the icons from the flow, but it causes other elements to flow around them. This is bringing me back to considering absolute positioning again.

And of course if we use absolute positioning with icons that are inside other elements, the positioning calculations have to be based on the parent elements, which makes things a lot more complex. It also means it's hard to tell if an icon is off the screen (part of the original features).

So this brings me back to adding the icons directly to body and absolutely positioning them. This is the same train of thoughts I went through with the plugin, of course. 😭

Last edited 7 weeks ago by sirbrillig (previous) (diff)

#71 follow-up: @celloexpressions
7 weeks ago

I think the keyboard accessibility challenges with absolutely positioning everything relative to the body likely prevent that from being viable. What about putting the icons in a container, positioned as they currently are and adding float:left;, and adding position:relative, then positioning absolutely to the left of that?

And actually, if we switch to using dashicons, the button could be left-floated with 0 width and relative positioning and :before could be positioned absolutely relative to that, with a negative left.

#72 in reply to: ↑ 71 @afercia
7 weeks ago

Replying to celloexpressions:

I think the keyboard accessibility challenges with absolutely positioning everything relative to the body likely prevent that from being viable.

+1 yep, ideally icons need to be placed immediately before (or after) the customisable area for keyboard accessibility and to establish some logical context.

#73 @sirbrillig
7 weeks ago

And actually, if we switch to using dashicons, the button could be left-floated with 0 width and relative positioning and :before could be positioned absolutely relative to that, with a negative left.

Oh, that is clever! Thank you for providing a path out of my pit of confusion.

I'm attaching a patch that makes use of that technique, with two issues that I'm aware of:

  1. The positioning needs to be adjusted for some elements but not others. Some elements (eg: sidebar widgets) already have the icon to the far left, where others have the icon overlapping the content itself (eg: site title). If the icon moves left globally, it will be nicely positioned for the latter but the former will be off the screen. We probably just need a contextual check to be sure icons are not off-screen.
  2. I had to use Genericons rather than Dashicons because Dashicons doesn't seem to be available in the preview (?)

@sirbrillig
7 weeks ago

Updated patch with before positioned icons

@sirbrillig
7 weeks ago

Updated patch with left-margin position safeguards

#74 follow-up: @sirbrillig
7 weeks ago

Back to hiding/showing icons: there was a suggestion to toggle the icons when there is a click on the body of the page (defaulting to hidden, IIRC). I'm not really sure how to do this. The actual toggle is easy enough, but I'm not sure how to handle click events on the page body in such a way as to perform the toggling iff the click is not on a button, link, input element, or other page element with a click handler. Suggestions welcome.

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


7 weeks ago

#76 in reply to: ↑ 74 @westonruter
7 weeks ago

One approach is in 27403.9.diff. (See changes.) This is the first time I've used CSS animations, so there's probably a better way to toggle them. Also, should they get a wp-customize-preview prefix?

Replying to sirbrillig:

Back to hiding/showing icons: there was a suggestion to toggle the icons when there is a click on the body of the page (defaulting to hidden, IIRC). I'm not really sure how to do this. The actual toggle is easy enough, but I'm not sure how to handle click events on the page body in such a way as to perform the toggling iff the click is not on a button, link, input element, or other page element with a click handler. Suggestions welcome.

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


7 weeks ago

#78 @sirbrillig
7 weeks ago

One approach is in 27403.9.diff​.

Nice! Thank you! I think the animation-delay should be dropped down from 0.8s to 0.1s to make it feel more responsive when you click, but otherwise that works really well (history: that delay was there to give the user a chance to see the preview before the buttons appeared).

UX-wise I'm still not sure that this method of hiding/showing is very discoverable, but I'll leave that decision to the designers among us. Here's an animated gif of the current behavior in twentyfifteen. Note that my background clicks are hiding/showing the icons.

https://cldup.com/ItvHppCoBb.gif

#79 @melchoyce
7 weeks ago

Some thoughts...

  • How do you know you can click in the preview?
  • What happens if you try to highlight text in the preview? Will this activate?
  • What happens if your hand/mouse slips, and you click right next to the icon by accident?

#80 @sirbrillig
7 weeks ago

What happens if you try to highlight text in the preview? Will this activate?

I can answer that one: yes. The click to begin highlighting activates the toggle.

#81 @westonruter
7 weeks ago

Here's a fix for the text selection issue to prevent toggling the icons while dragging: https://github.com/xwp/wordpress-develop/pull/179/commits/dcd5ffeb65360d371fe0a7337b2cc6c50f6cdee5

To apply the patch, do grunt patch:https://github.com/xwp/wordpress-develop/pull/179

How do you know you can click in the preview?

Not sure the best way to advertise that clicking into the preview will cause the edit buttons to appear. Maybe they could be shown momentarily when the page first loads and then fade away.

What happens if your hand/mouse slips, and you click right next to the icon by accident?

Then the icons would currently be toggled off and you'd have to click/touch again to get them to re-appear.

#82 @celloexpressions
7 weeks ago

I think showing them by default will help, so it's more like click-to-hide. We can add an explanation of this behavior to the general customizer description (not that it's frequently referenced, but still). The ability to quickly re-toggle by clicking again is the most important part here I'd say.

#83 @celloexpressions
6 weeks ago

I think we need to try to place the icons inside the partial container. I'm seeing a lot of issues, for example, with widget areas with the widget containers being floated or using masonry layouts - this causes all of the edit icons to be on top of each other. If a partial container has children, we should be able to inject the icon within the container without impacting the layout; otherwise it should remain before the partial itself. This will also make it easier for themes to add their own styles if needed.

We have some color contrast issues here; I pushed a couple adjustments to the PR to improve that. I also added a visible focus style and an identical hover styling (so that there isn't a flash of distinct focus styling when clicking). I also updated the PR to show the icons by default and to restore using the click event to toggle the icons - the other way was always under the impression that there was a mousemove event when I clicked and there are a lot of things you could do to accidentally toggle the icons anyway, like double-clicking to select text. If someone has a solution that works better cross-browser, let's explore alternatives further.

Is there a way to show icons somewhere for empty partials? Not sure what the best approach would be, but it would be nice if you could get an icon for adding a logo before there's a logo set, for example.

Current patch in progress is now here for easier collaboration: https://github.com/xwp/wordpress-develop/pull/179.

#84 @celloexpressions
6 weeks ago

  • Priority changed from normal to high

This is the highest priority customize enhancement remaining for 4.7, and still needs more dev and design work as well as testing (especially with different themes). For anyone available to contribute here, please test with https://github.com/xwp/wordpress-develop/pull/179.diff, and comment here, in #core-customize on Slack, or on https://github.com/xwp/wordpress-develop/pull/179 with feedback or code/design iterations!

#85 @afercia
6 weeks ago

Quickly testing https://github.com/xwp/wordpress-develop/pull/179.diff, the edit buttons are not focusable using Safari. Seems to me it's because they have a width and height set to 0 and Safari usually ignores elements with no dimensions. Quickly tried to change the width and height to 1px and then all the buttons get focusable and are in the correct tab order.

@celloexpressions
6 weeks ago

Demo of latest patch with Twenty Fifteen.

#86 @celloexpressions
6 weeks ago

  • Keywords has-screenshots added

I pushed a commit to make the actual button elements 1px square so they're focusable on Safari; we'll have to live with 1px misalignments caused by the icons.

See above a demo of this with the latest patch on Twenty Fifteen. The icon placement works, but the theme could presumably add some adjustments to make it look better. Next steps for the patch:

  • Try putting the buttons within the partial container when possible (when it has children elements), and re-add after a selective refresh. Should help with alignment with themes with floated partials.
  • Look at possible approaches for icons for empty partials. Related: #38114.

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


6 weeks ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


6 weeks ago

#89 @celloexpressions
6 weeks ago

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

Reference the latest changes on https://github.com/xwp/wordpress-develop/pull/179 and the testing results discussed on Slack in #core-customize last night (and general discussion on this yesteday). Pending a few final tweaks on the PR this morning, this is ready for an initial commit. A Make/Core post has been drafted detailing the new feature's implementation and how to add support in themes, and can be published later today pending approval. See also #38513.

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


6 weeks ago

#91 @jbpaul17
6 weeks ago

  • Owner changed from sirbrilling to sirbrillig

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


6 weeks ago

#93 follow-up: @westonruter
6 weeks ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 38967:

Customize: Add edit shortcuts in customizer preview to visually expose editable elements and focus on the corresponding controls when clicked.

  • Edit shortcuts show initially for a moment and then fade away so as to not get in the way of the preview.
  • Visibility of edit shortcuts is toggled by clicking/touching anywhere inert in the document.
  • Implements UI for mobile and touch devices which do not support shift-click.
  • Adds editShortcutVisibility state.
  • Adds new methods to wp.customize.selectiveRefresh.Partial for managing edit shortcuts.

Incorporates aspects of the Customize Direct Manipulation feature plugin.

Props sirbrillig, mattwiebe, celloexpressions, melchoyce, westonruter, afercia.
Fixes #27403.

#94 @westonruter
6 weeks ago

In 38972:

Customize: Remove unnecessary code for edit shortcuts which is no longer required due to moving buttons inside of partial placement containers.

Props sirbrillig.
Amends [38967].
See #27403.

#95 @pento
6 weeks ago

  • Keywords has-patch commit removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

#96 @pento
6 weeks ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 38973:

Customize: Remove an unused variable.

The cleanup in [38972] missed a variable that is no longer being used.

Fixes #27403.

#97 @westonruter
5 weeks ago

In 39010:

Customize: Reveal controls pane when clicking on edit shortcuts in mobile preview.

Re-use paneVisible state to also manage whether the mobile preview-only class is applied to the overlay.

Props seancjones.
See #36678, #36678, #27403.
Fixes #38080.

#98 @westonruter
5 weeks ago

In 39018:

Customize: Prevent toggling edit shortcuts when doing shift-click or when clicking on a descendent of an interactive element.

See #38532, #27403.
Fixes #38554.

#99 in reply to: ↑ 93 @johnbillion
5 weeks ago

  • Keywords ux-feedback added; has-screenshots removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

Replying to westonruter:

  • Visibility of edit shortcuts is toggled by clicking/touching anywhere inert in the document.

I just opened the Customizer for the first time since this was implemented and I saw some edit buttons appear for a moment and then disappear. The discoverability of these is exceptionally low and I had to play around with mouse hovering and clicking before I figured out how they appear. This needs user testing.

#100 @sirbrillig
5 weeks ago

The discoverability of these is exceptionally low

I very much agree, but there seems to be no agreement about how to make them discoverable. We've tried having them always visible which may be the most discoverable (and this has been user tested on WP.com) but it does obscure the preview and there must be some obvious way to toggle them. The show-then-hide and background-click-toggle is the only compromise anyone has come up with so far. Other suggestions are extremely welcome @johnbillion!

#101 @paaljoachim
5 weeks ago

The difficult part here is see the design as it is vs see icons to where one can edit a section.

Having a toggle on/off by clicking inside the window well we were not able to think of another way of doing this.
I am a bit worried that a lot of people will think that the issue that John brought up "....I saw some edit buttons appear for a moment and then disappear." is a glitch in the customizer. That can create confusion.

We need to think further....

Ok the customizer will someday be a site editor where one can edit areas on the frontend. Will one then click an edit button and have icons all over the frontend? Then click the (pre)view button to view the site? We need to think of this aspect as well. How will the customizer interact with the site while on the frontend? What is the most natural ui for this?
If we can take some of these thoughts back to where the customizer edit vs design is right now I think we can find an even better solution. Something that can last even when people begin to instead edit their site directly on the frontend.

Btw here is one of Folletto's wireframes used for the theme switcher (so yes it is out of context): https://core.trac.wordpress.org/attachment/ticket/31289/customizer-themeswitcher-i2-structural.png I am sharing it because it shows a preview button. If that is the right approach for showing a preview I do not know.

Last edited 5 weeks ago by paaljoachim (previous) (diff)

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


5 weeks ago

#103 @folletto
5 weeks ago

Btw here is one of Folletto's wireframes used for the theme switcher (so yes it is out of context): https://core.trac.wordpress.org/attachment/ticket/31289/customizer-themeswitcher-i2-structural.png I am sharing it because it shows a preview button. If that is the right approach for showing a preview I do not know.

It's not: that is the existing Preview button for mobile. It toggles between the customizer sidebar and the preview. Overloading it with an extra meaning on desktop would be an issue.

I very much agree, but there seems to be no agreement about how to make them discoverable. We've tried having them always visible which may be the most discoverable (and this has been user tested on WP.com) but it does obscure the preview and there must be some obvious way to toggle them.

I still think we're circling around this for more historical and theoretical reasons than good usability and pragmatism:

  • Icons should be always visible because that's what the user is meant to do there: the user clicked "Customize".
  • There's already the toggle, which is the collapse icon.

I just opened the Customizer for the first time since this was implemented and I saw some edit buttons appear for a moment and then disappear. The discoverability of these is exceptionally low and I had to play around with mouse hovering and clicking before I figured out how they appear. This needs user testing.

The approach of having the icons always visible is working well on WordPress·com too, so it's not as if we don't have a track record proving its effectiveness. Millions of users are already using it, successfully. And if I'm not mistaken (I can ask for hard data tho) we had virtually zero complaints. Which is impressive, and happens very rarely for features of this size.

One thing we can consider is to relabel the "Collapse" icon. That's probably the clearest, most intuitive improvement we can do, as "collapse" doesn't really mean anything.

My advice:

  1. Restore the "always visible" behaviour.
  2. Change "Collapse" to something different.

Ideas for "Collapse" alternative labels:

  • "Full view"
  • "Show all"
  • other?

#104 @westonruter
5 weeks ago

@folletto if the collapse button is what is used to toggle the edit shortcuts then this would mean the edit shortcuts could not be shown in mobile preview, since clicking preview in mobile is the same as collapsing the sidebar. The edit shortcuts are especially important to show in mobile preview since “shift-click to edit” is not possible on touch.

#105 @folletto
5 weeks ago

if the collapse button is what is used to toggle the edit shortcuts then this would mean the edit shortcuts could not be shown in mobile preview, since clicking preview in mobile is the same as collapsing the sidebar. The edit shortcuts are especially important to show in mobile preview since “shift-click to edit” is not possible on touch.

I agree they are important. :)

I checked the code, and it seems to me they are (correctly) two different buttons:

  • "Collapse" is button.collapse-sidebar.button-secondary in #customizer-footer-actions
  • "Preview" is button.customize-controls-preview-toggle in #customize-header-actions

They are already separate. The change in "Collapse" function and meaning wouldn't have any impact on "Preview". Sure, we won't have a way to hide the buttons on mobile, but I think for this iteration it's something that we can manage.

WordPress·com does that too. So it's again already tested, shipped, working.

Unless of course I'm missing something or I misinterpreted your comment. :)

Last edited 5 weeks ago by folletto (previous) (diff)

#106 @westonruter
5 weeks ago

@folletto yes, what I meant is on mobile the “Preview” button is all that is displayed. There is no “Collapse” button on mobile. The “Preview” button serves as “Collapse” in mobile. So if the edit shortcuts were tied to the collapse button, then on mobile there would be no way to show the preview and have the edit shortcuts displayed.

Even so, if the buttons are persistently shown unless the user collapses the controls, then when they switch to a new theme to see how it looks, they're not going to see how it looks since the edit shortcuts would be cluttering up the view. They'd have to know to click Collapse, and in my experience very few users know about this.

#107 @celloexpressions
5 weeks ago

The most important role of the customizer is to provide the ability to live-preview changes to a site as their made. There are two critical components of this:

  • The preview must be an accurate representation of the site as it will appear when the changes are published, including the ability to navigate around the site
  • The preview is live - changes are shown immediately as an interaction happens with a control

The collapsed mode isn't intended to be the only way to preview the site exactly as it'll appear; it's a secondary and rarely-used option that has proven to not be discoverable. Behind the scenes, the separate preview button on mobile triggers the same thing that the collapse button does. There have been some experimentations around improving the collapsed mode in the past (see #29949), but those were ultimately dropped.

With the current UI, there is no established mechanism for toggling a mode where UI within the preview is toggled, since in-preview UI is a new concept. As part of the goal of the customizer, though, it must be possible to view changes to the site exactly as they'll appear, live as you edit them (this is not currently possible on mobile). As part of that, we can't show icons over the preview without a mechanism to turn them off that doesn't hide any out-of-preview controls. Realistically, we should probably wait to explore alternatives until the customizer UI is generally redesigned from the ground up, with a native concept of in-preview controls.

In short, I'd rather preserve the primary functionality of the customizer at the expense of the discoverability of this feature for now. I'm pretty confident that users will eventually discover the toggle mechanism (which is also explained in the customizer help text), and when they do, I expect the behavior to be learned without excessive difficulty. Visible edit shortcuts are an enhancement of the existing, more hidden feature (shift-click to edit, which existed for everything that now has visible shortcuts via the same internal mechanism), and having a visible approach at all is a good first step toward further improvements in a future release. The last thing that we should do with this change is to hamper the ability for the customizer to perform its central objective as a live preview of the site.

#108 @folletto
5 weeks ago

So if the edit shortcuts were tied to the collapse button, then on mobile there would be no way to show the preview and have the edit shortcuts displayed.

On mobile it would show the preview with the edit buttons displayed, since the Preview button isn't the Collapse button. :)
If we want to make possible to hide the edit buttons on mobile too, we can find a solution for that.

They'd have to know to click Collapse, and in my experience very few users know about this.

Sure. Again, fixable tho. :)

In short, I don't think neither of these two is a blocker.
They are minor, fixable details compared to a major benefit of having the edit buttons visible.

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


5 weeks ago

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


5 weeks ago

#111 follow-up: @helen
5 weeks ago

  • Keywords needs-patch added; ux-feedback removed

This was discussed in today's #design chat, with general (not complete) agreement with @folletto. Let's make these visible by default and relabel "Collapse" to "Hide Controls" (@melchoyce will make a separate ticket for that). I think the best route for small screens is to always show the shortcuts for now. Because of concerns around small screen and theme compat, we should continue to explore methods of hiding just the shortcuts as opposed to all controls, but I don't find that to be immediately necessary and would like for this to be more prominent in beta 2 for testing and reports against themes.

#112 @westonruter
5 weeks ago

  • Owner changed from sirbrillig to westonruter
  • Status changed from reopened to accepted

Working on patch…

#113 @westonruter
5 weeks ago

  • Keywords has-patch added; needs-patch removed

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


5 weeks ago

#115 @sirbrillig
5 weeks ago

@westonruter looks good to me. I think we can also remove the body.customize-partial-edit-shortcuts-flash rule and the call to body.toggleClass() in customize-selective-refresh.js that enables it if there's no longer going to be an initial state.

#116 in reply to: ↑ 111 @melchoyce
5 weeks ago

Replying to helen:

Let's make these visible by default and relabel "Collapse" to "Hide Controls" (@melchoyce will make a separate ticket for that).

#38647

#117 @westonruter
5 weeks ago

  • Resolution set to fixed
  • Status changed from accepted to closed

In 39131:

Customize: Let edit shortcuts be persistently visible when controls pane is expanded, hidden when collapsed, and always visible in mobile preview. Remove initial flash of edit shortcuts.

Props westonruter, sirbrillig.
Fixes #27403.

#118 @westonruter
4 weeks ago

In 39144:

Customize: Remove edit shortcut toggle button from preview since visibility is now linked with pane visibility.

Amends [39131].
Props westonruter, sirbrillig.
See #27403.
Fixes #38668.

#119 @adamsilverstein
4 weeks ago

Note: I added a fix for the edit icon positioning in RTL in #38706

#120 @westonruter
4 weeks ago

In 39186:

Customize: Eliminate use of flexbox for edit shortcuts.

Props sirbrillig.
See #27403.
Fixes #38660.

#121 @helen
4 weeks ago

In 39197:

Customize: Ensure RTL version of customize-preview.css is loaded.

props adamsilverstein.
see #27403, #38706.

#122 @westonruter
3 weeks ago

In 39202:

Customize: Remove left-margin guard from edit shortcuts and adjust for small screen sizes.

Removes the .customize-partial-edit-shortcut-left-margin class which was not effective on some themes, created a worse experience for other themes, and which did not recalculate when the preview was reflowed or resized. Now some small-width media queries are added to handle common cases while more dramatic issues can be handled by the theme. Also renames Partial.positionEditShortcut()to Partial.addEditShortcutToPlacement() which is a more accurate description of its function.

Props sirbrillig, sstoqnov.
See #38651, #27403.

#123 @westonruter
3 weeks ago

In 39218:

Customize: Remove root panel description text which notes that edit shortcuts can be toggled by clicking anywhere in the preview.

Amends [39131], in which this method of toggling edit shortcuts was removed.
Props presskopp.
See #27403.

#124 @westonruter
3 weeks ago

In 39270:

Customize: Prevent edit shortcut buttons from being inserted into container elements in the head or into elements which should not get interactive children.

See #27403, #38672.
Fixes #38830.

Note: See TracTickets for help on using tickets.