The Test Team helps manage testing and triage across the WordPress ecosystem. They focus on user testing of the editing experience and WordPress dashboard, replicating and documenting bug reports, and supporting a culture of review and triage across the project.
This post is a summary of the ninth call for testing for the experimental FSE outreach program. During this call for testing, we surpassed 400 members in the channel! I love an excuse to celebrate so please pat yourselves on the back, treat yourself to a favorite dessert, listen to your favorite song, etc to celebrate this neat milestone of community contributions. While we reached this milestone, I do want to note that contributions were lower for this last round than usual so, if you’re sitting back thinking that others have it covered, please instead jump into the next round if you can!
Here’s what a few folks had to say about the overall experience that can help frame the following detail oriented feedback. Across all of the feedback, the desire for a lighter navigation experience as well as more advanced tools around spacing, bulk adding items, etc. stood out.
I didn’t run into too many issues getting the headerHeaderThe header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. to display decently, but I also know a bunch of tricks to get the editor to do what I need it to do. The end result is ok — but the experience getting there needs a lot of refining yet.
Using the Navigation 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. still seems the most troublesome area of site editing. I know how much work the development team has put behind the user experience for this feature but cannot help but wonder if there is a point where users can opt into managing its content (the links) via the traditional Nav Menus screen in WordPress. The site editor works fine for the design aspect, but I have yet to feel comfortable using it to manage links.
After delving deeply into the ins and outs of the navbar – the primary issues all revolve around responsiveness. The coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. issue came down to the navigation bar operating as a separate element (which makes sense for a block) than the rest of what you’d normally consider a complete header. This means that in order to properly size and place the navbar, you have to use a container block like group or columns – which is where alignment starts to get into trouble.
Thanks to clear patterns in feedback due to a larger focus on the navigation block, this is a dedication section to just bugs that were found or confirmed in this test. Those that have been resolved thanks to a release mid-test have been noted below.
At the core of this test, the feedback centered around a combination of small, specific issues and larger problems with the overall settings of different blocks. This made the experience feel less refined and intuitive leading to general confusion when trying to accomplish sometimes simple things, like changing the width of the Search block. In some cases, work is underway actively to address these concerns, as is the case with adding a gap block feature to make it easier to manage the spacing between navigation block items. Some were repeat items and are noted as such below.
I am not able to see any visual difference between Wide width or Full width. Because my browser screen is not wide enough to see the difference. When I widen the browser window then I am able to see the difference. Should the Wide width alignment be response in relation to the browser size window? So the user will be able to see a visual difference in the backend when testing Wide or Full width.
For example, adding search to the navbar, and then wanting the search bar to display differently (larger, smaller) with a potentially different background doesn’t work. Individual menu items can’t easily change the background color of a link (e.g. an active color) to align properly with the container element and there are no hover effects (extremely common use cases) without diving into CSSCSSCSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. code.
When the first block is extremely near to the editor header, some parts of the block content gets hidden, while the viewport adjusts automatically on both left and right side, the top part remains fixed.
AccessibilityAccessibilityAccessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) feedback
Thanks to some folks focusing in on what could be done with this test using just keyboard controls, there’s a lovely list of accessibility focused items: