Widget Editor: Reconstruct Widgets Screen to use the Customize API #26012
Comments
annezazu
added
[Feature] Widgets Screen
|
This is a great proposal @celloexpressions, where are things at and how can people support you moving it forward? |
|
This should be on hold pending the outcome of blocks in the customizer (#26900, now #27343). If that experience is similar enough to the widgets screen, or significantly better, then it may be best to merge the widgets screen into the customizer. If the widget screen stays, then this proposal applies. The goal is to enable the things that the customize API does -- notably preview and changesets (drafts, scheduling, etc). Hopefully the blocks-in-customizer work will make this easier to integrate. I could see this as a detailed integration as described above or more minimally integrating blocks with customize settings to make this happen. |
noisysocks
added
[Feature] Widgets Customizer
|
As noted pending: #27343 |
noisysocks
added
Needs Decision
|
I forgot to thank you @celloexpressions for this really well thought out issue. It definitely influenced the way I think about this project and it has inspired a lot of the work that @kevin940726 and I done. There is now experimental support for block widgets in the Customizer. Check it out if you haven't already by enabling the flag in Gutenberg → Experiments. I think that these three points are now sufficiently addressed:
The remaining points you raised are still relevant today:
The third point can be addressed by adding Preview functionality to the Widgets screen. This would be implemented using Customizer APIs. It is not clear whether we could/should do this for v1. I think that the fundamental question, which I'd like to discuss, at the core of these three points is: What value does the Widgets screen have for users over the Customizer? Should we maintain both screens now and into the future? cc. @shaunandrews @critterverse @kevin940726 @talldan @tellthemachines @draganescu @TimothyBJacobs |
|
Hi all, very new to the project but just wanted to offer my top-level thoughts and congratulations on how far the work has come to revolutionize the experience of editing Widgets already.
As a designer, the instinct to simplify/streamline is strong, and I am hopeful that the standalone screen can go away.. eventually… in due time… 😂 From a user perspective — and maybe this goes without saying — it’s very confusing to see the two different screens accessible within the same site. After chatting with @draganescu and @shaunandrews about this, I can appreciate that this is anything but straightforward and that the standalone screen does need to stay around to support existing user flows. But I’m supportive of plans to try to merge these screens into a single experience in the future.
This approach proposed by @celloexpressions sounds really powerful to me. If we were able to do something like this eventually, one alternative to keeping the existing link in the Appearance menu permanently could be to leave it there temporarily to provide a user education moment during a timed phaseout — I can imagine having a note/link somewhere saying, “Widgets have a new home. They’ve been fully integrated into the Customizer where you can now schedule changes, save draft changes, and even share a public link to navigate through the site with a preview of changes 🎉“ While these changes would alter the existing flow for users who know and use the standalone screen, I think ultimately it would make for a cleaner, more simplified user experience overall. Anyway, these are just my early thoughts on where things might go in the future, and apologies if I’m glazing over some important technical concerns. This project is even more impressive after learning about some of the technical hurdles that have already been overcome, and I'm excited that it's positioned to have such a huge impact. Well done all! 🚀 |
What existing flows does a block-based Appearance → Widgets screen support? Because the block-based Appearance → Widgets screen is a completely new screen, many plugins that use the old Appearance → Widgets screen will need to be updated. As one example, this plugin which allows users to add custom sidebars will need significant changes if it wishes to support the new screen. In other words, if we are going to consolidate Appearance → Widgets and Appearance → Customize → Widgets, now is probably the time to do it since third parties will need to make changes one way or the other. |
|
I think we should seriously consider consolidating the two screens. Right now, the block-based Appearance → Customize → Widgets screen already has several advantages over Appearance → Widgets:
The block-based Appearance → Widgets screen does have a few advantages over Appearance → Customize → Widgets, but I think that they are less compelling:
If the above improvements are made to the block-based Appearance → Customize → Widgets screen, consolidation could be quite straightforward. We could delete the block-based Appearance → Widgets screen, make Appearance → Widgets link directly to the relevant part of the Customizer, and maintain the old
|
|
I have been strongly in favor of merging the two interfaces for a long time. The "manage with live preview" link, and various other link adjustments were initial steps in that direction. The separate widgets screen generally still exists because some people are accustomed to it and there are potential backwards compatibility issues with removing it. The same goes for the menus screen (and my proposals to consolidate that date back to the original menu customizer merge proposal for WordPress 4.3). It would also be critical to confirm that block-widgets in the customizer are accessible enough to lose the widgets screen "accessibility mode." The present block-ification of the widgets screen seems like a great opportunity to "flip the switch" on this. The screen is drastically changing, which will prompt the potential breakage and re-learning that would also happen by consolidating with the customizer. This idea likely warrants broader discussion (via a Make/Core post next?) to validate this idea and work toward a final decision. Consolidating to one widget editor should enable the team to address the few present advantages of the standalone screen in the customizer for better feature parity. And would generally allow everyone to focus on polishing, extending, and learning how to edit block widgets in one canonical place. |
|
My main concern with deprecating the standalone editor is that we may be boxing ourselves in, while also possibly miss out on the options open by upgrading widget areas with blocks support. Widgets living alongside blocks are a great opportunity to build upon. What today is sidebars, next year could become block areas, or block templates. Upgrading "sidebars" to "block templates" that are immediately editable and require no migration, no setup or opt-in, should have a great value for classic themes (including financial value). This is still possible after removing the stand alone screen, but cramped by the compromises we need to make in the Customizer. While the live preview is a great feature to have, the block editor is really, simply, much better when expanded, as we struggled with this from the very start of Gutenberg: all the screen or just the editor? All the screen "won" for a reason. While we do have an idea to expand the sidebar and bolt a full page editor in, it is not the same thing, and to make it the same thing we need to invent new UX/UI on top of the block editor’s already invented UX/UI. The editor in the Customizer's sidebar is not behaving like the other editors. It requires special treatment. If we opt to go on this route alone, we also should strap ourselves to always have to invent ways to do things in the “Customizer block editor” whenever the editor evolves, while the stand alone editor inherits, not only functionality but new UX paradigms as well. In a future with block templates for classic themes, working on them in isolation, in a block editor that will match the front end 100%, is a far more productive and intuitive experience. The long term striving should be that we make the editor be faithful of the frontend, not rely on a refreshing preview. Removing the stand alone editor "removes" this idea and possibility. Obviously you can bring it back, but we're not supposed to "move fast and break things". There are other things to be said about the widgets screen:
As a final note, there is a whole conceptual problem on whether using, creating and setting up widgets is an action of customization or of content management. On what basis do we decide the chrome around the content cannot hold content? If it weren't content maybe we wouldn't hear requests to add classic block support. If it is content then it mandates its own particular stand alone approach. Considering all the above, I am not against removing the screen. I do however find that the reason of "it's a good time to do it" is not a wise one, and the solution we end up with does not seem to capture everything we'll be missing out on. This decision needs two things:
|
|
The widget-block editor in the customizer needs to be equivalent to or better than the standalone screen as a prerequisite to considering consolidation. It's not there yet, but the vision could be there. Making a decision along the way would also allow focus on making one interface great. I'm not convinced that the block editor belongs in a sidebar UI. In fact, I think a modal overlay or inline-preview approach would better relate to the current post editor and reflect the idea that the block editor provides an inline live preview. A full-screen widget/block editor located in the customizer has the advantage of offering high-fidelity contextual previews in addition to the inline live previews. The "unexplored" ideas in #27343 should be revisited, as the sidebar block editor doesn't work well in practice. Widget editing made more sense in a sidebar because the options were highly abstracted. That's not the case with blocks. We don't need to compromise the customizer experience to work around a sidebar/preview UI. The customizer is more of a wrapper - its individual features can and should adapt the UI where appropriate. See the theme browser for example - it doesn't need the preview window, so it hides it. Block-based widgets can hide part or all of the preview while editing, and keep the preview handy for review before publishing (and with benefits like not having to open another tab).
My long-term hopes for the customizer are to consolidate most aspects of wp-admin into it and to improve its relationship to the frontend (improving contextual editing/customization). I outlined some specific next steps in the introduction to this issue:
Editing posts in the customizer wouldn't replace the standalone editor for most cases, but would make it easier to edit page contents alongside templates. This would be particularly useful for things like homepages. It streamlines the flow between editing different parts of a site with a unified focus on the frontend preview. The idea is to click "Customize" in the toolbar from a page on the frontend and go straight to the interface where you can edit any part of that frontend page. Step 3 on my list might happen with step 1 depending on approach. Step 4 could be its own project, or potentially be the landing place for the site editor (specifically template editing). See #30496 "Approach 2" for a potential strategy there. |
noisysocks
added
[Type] Discussion
|
While this has served everyone well by providing great insight and exploration paths, given the current implementation I think it's safe to close this. |
There are several fundamental problems with the current approach to the widgets screen. This issue outlines an alternative approach that leverages existing WordPress core functionality to improve user experience and minimize reinventing the wheel. It streamlines the process of bringing blocks to the widgets screen and to the customizer.
Much of the current implementation could remain as-is, but the underlying technical foundation will be reworked. The user interface could be refined as a result and the user experience benefits significantly. The design could be similar to what is currently proposed or evolve as desired.
Why Now? (Before First Release of the Widget Blocks Screen, Proposed WordPress 5.6)
The Gutenberg plugin currently supports a new widgets screen with blocks. But there is no support for block-widgets in the customizer. This introduces several challenges:
Generally, the current approach creates several disruptions to user flow. In contrast, reconstructing the widgets screen to leverage the customize API has several benefits:
Any change to the existing widgets screen will disrupt existing user flows. A vocal group of users expressed this concern when widgets and menus were originally added to the customizer. Let’s take the time to make sure the new experience is better, and to go through this disruption only once.
Why the Customize API?
The customizer is a framework for live-previewing changes to a site. It is not, necessarily, the specific interface that most of us are familiar with at
wp-admin/customize.php. The power of the customizer is its API and its contextual live preview – the ability to instantly see edits as they apply on the frontend of the site. Users can navigate to different pages on the site within the preview; for widgets, this makes it easier to understand how dynamic and conditionally-visible widgets work across a site.Most importantly, the customizer allows users to schedule changes, save draft changes, and even share a public link to navigate through the site with a preview of changes. The widgets screen has long suffered from a "change and surprise" publishing experience. The Gutenberg plugin’s new widgets screen currently has only a publish button with none of the other features.
We can leverage the customizer API outside of
wp-admin/customize.phpto bring this enhanced publishing experience to the standalone widgets screen (specifically, this is the customize changesets API). We can also offer a "preview" button that opens a standalone customizer preview of the frontend of the site reflecting changes to widgets.Previewing Widgets
Once widgets are managed with the customize API, we enable previews of widget options using existing core functionality. There are several ways to show these previews:
The preview under option 3 could open in a new tab similar to the editor preview. But, because we're using the customize API, we could also open it as a full-screen or modal overlay. The editor/preview toggle could be similar to the mobile interface that the customizer currently uses. This is contextual, but not live, preview. Exceptionally large (desktop) monitors might show a live preview next to the editor (option 4). Blocks already do inline preview (option 1), but traditional widgets are not as successful in this format.
Contextual preview (via options 3 or 4) is critical to widgets because they aren’t consistent across all pages on a site. Some widgets include dynamic content based on the current view. Others may have conditional visibility. Most frequently, a given widget area may not be shown in all views. Without contextual preview, widgets and blocks in widget areas cannot be reliably tested and reviewed before being published to the live site.
Technical Approach
How can we leverage the customize API for the widgets screen? Here are a few steps aligned with the customizer object structure:
WP_Widget_Form_Customize_Control). There could be different control classes for blocks vs. legacy widgets as appropriate.WP_Customize_Settingand/or primarily work in JS. There could be different setting classes or types for blocks vs. legacy widgets as appropriate.WP_Customize_Sidebar_Section, which controls the order and interaction between blocks.WP_Customize_Widgets_Panel, extendingWP_Customize_Panel. SeeWP_Customize_Nav_Menus_PanelandWP_Customize_Themes_Panelfor examples. This is the “screen” that holds all of the widget areas. It includes the widget inserter and block areas/block settings sidebar. And it’s responsible for the overall screen layout (“taking over” the customizer preview for the customizer version).wp-admin/widgets.php. This instance will only load the widgets panel and associated controls. See https://core.trac.wordpress.org/ticket/29071 for some background and links to examples.wp-admin/customize.php. Includes design decisions on how to handle previews.postMessage.All of this could be built in the plugin first by selectively extending and replacing elements (customize
remove_*functions, dequeuing scripts) of the current customize-widgets infrastructure. The customizer PHP API is more stable and fully-featured that the JS API. This could be a great opportunity to improve the JS side and coordinate with the approach that Gutenberg takes with JavaScript. All of the object references above apply to both the PHP and the JS aspects of the API.A Path toward Integrating Gutenberg with the Customizer
If the goal of the standalone widgets screen is to provide a full-screen experience for editing widgets, then it shouldn't use the same interface that widgets in the customizer currently use. But with block editing incorporated into widget editing, maybe customizer widgets should also offer a more-full-screen editing interface.
Customizer panels (widgets, menus, etc.) can take any form that's appropriate for the feature. The theme browser takes over the customize preview to offer a full-screen.) Why not do the same for widgets? With this approach, the widgets screen and widgets in the customizer can use exactly the same interface with exactly the same technical implementation as a customizer
panel.Do we need to offer the same interface in two different places? At that point, we can unify to a single full-screen widget editor that is powered by the customizer behind the scenes. We can keep links to the widgets screen as links that go directly to the full-screen widgets panel in the customizer. And users can also get to the widgets screen from directly within the customizer, without leaving the site customization scope. Or we can keep separate screens but use the same infrastructure and interface in both places. Either way, this general strategy brings Gutenberg into the customizer and demonstrates a path forward for integrating other parts of Gutenberg with the customizer.
Longer term, there becomes a clear path forward:
Note: full site editing as currently conceived is a new feature set introduced to core that individually benefits from the customizer’s contextual live preview. It does not replace the role or functionality of the customizer. Step 4 outlined above would be a good opportunity to implement site structure editing with post and other content area editing and other features in the customizer to create a unified site management experience that prioritizes contextual live preview.
Conclusion
The widgets screen in the Gutenberg plugin currently feels very "alpha". From accessibility to publishing flow there is work to do. We have an opportunity to significantly improve the experience and reduce technical debt by leveraging the customize API in the technical implementation. And we can bridge the gap between the editor, Gutenberg, the widgets screen, and the customizer in the process.
This may not be achievable in time for WordPress 5.6. But it is a better approach than the current separate implementations. Focusing on a single implementation, we can focus on critical needs such as accessibility. And we can create a better editing experience for all users.
The text was updated successfully, but these errors were encountered: