The Design Team provides experience, interface, and visual design expertise for the WordPress project.
Want to get involved? See our handbook and drop into #design once signed up for volunteer opportunities. Our vision is to be the go-to resource for design for other teams across the open sourceOpen SourceOpen Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. project.
As noted in an earlier Gutenberg design update, I wanted to communicate a proposed UXUXUX is an acronym for User Experience - the way the user uses the UI. Think ‘what they are doing’ and less about how they do it. flow for rolling out the widgets-to-blocks interface changes. It’s a proposal and still up for discussion along with further communication in the GithubGitHubGitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ PR, Add blocks in widget areas RFC.
Widgets are now blocks which require a new GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ interface to help people transition to this new paradigm. What is the best way to introduce the new widgetWidgetA WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user.-blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. screens to users? How can we do this with the least amount of development time, use existing patterns, and clearly communicate the gradual transition to blocks?
Diverging to explore solutions
I began by segmenting the use cases:
Users with existing widgets
Users without widgets
My initial work included using different menu items in wp-admin and the CustomizerCustomizerTool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. based on if the user had existing widgets in their site. A user with existing widgets would need more help transitioning to a new interface than a user without any prior widget paradigms.
After further investigation of this, I opted out. If the menu items segmented, it might cause more confusion because there would be some users with the new menu items while another may have the old. Documentation and internet tutorials could get difficult to follow at that point. I’d like to do this with the least amount of development time, and confusion on the user’s end.
Converging on a solution
To achieve a simple and non-confusing rollout, keeping the wp-admin menu items the same might be the best option. The user would still see “Widgets” under the “Appearance” menu item. When clicking that to view the widgets, the user would now get the new Gutenberg Widget Areas screen.
We’d need to make sure the proper messaging or tips are displayed on this page to help orient the user to the new layout.
This scenario would work similarly to the one above. When clicking into the Customizer, the user would still see “Widgets” as an option if the Theme provides it. This shouldn’t require any additional work on the part of the theme outside what is currently required. Once clicked the user sorts through the blocks and can add 3rd party unconverted widgets with the Legacy Widget block.
So that everyone’s aware, the discussions around why blocks are being introduced in the widget screens is already explained in the Github issues, and in comments on other sites. This is one of the 9 projects for 2019, and aims at helping everyone slowly make the transition to the block paradigm.
The feedback I’m looking for here is:
How do you feel about keeping the “Widgets” menu item through the transition even though these really aren’t widgets anymore?
Does it make sense to call these “Widget Areas” through this transition phase?
Is there anything I may have missed or not thought of?