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.
Attendance: Carolina Nymark, Daisy Olsen, Manuel Esposito, Rich Tabor, Herb Miller, Ellen Baeur, Ana Segota, Evan Mullins, Damon Cook, David Bowman, Jessica Lyschik, Ed Beck, Courtney Roberston, Amy L, Rita Best.
Apologies for the lack of timestamps – this conversation was vast and deep, making it hard to separate out into specific sections.
- Pain points with blockBlock Block 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. themes, including naming conventions for color palettes/mapping colors, managing updates to the theme, oddities with switching between style variations/losing styles, and keeping up with all the various changes to CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..
- Pain points from users including “how can I change fonts”, using the navigation block, and confusion around the split between the post editor vs site editor (ie have to go into the site editor to manage styles).
- Theme switching and the UXUX UX 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. around picking/choosing parts of Styles from a theme, which ties into this prior exploration.
- Discussion around “Who are our users?” and how there’s a spectrum of use cases to cover from those who want a ready made theme to those who want to dig into the details. How do you build for each or all?
- Discussion around having a pattern library/pool as a way to speed up development for themes with a note around how there are so many ways to build smarter for block themes and how much more accessible it is for designers compared to classic themes.
- Discussion around custom blocks, when to build them, and why they are often times preferable due to the ability to completely manage updates rather than chasing after changes to Core. This led to a conversation around why themes aren’t able to require custom blocks (it breaks a users site when they switch away).
- A follow up idea was shared after the hangout from Damon Cook to consider: “It would be super helpful to have a single Figma file with all blocks, colors, and properties that could go in a
theme.json. It would undoubtedly be high maintenance and would have to be under active updates alongside new GutenbergGutenberg The 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/ features being merged into core, but it could also have a webpage equivalent to markup/output. A WordPress theme Style Guide: Figma file with the equivalent of block output on a site for users to copy/paste the code into their theme and see everything on a page… kinda deal.”
Overall, while there is both excitement and interest in what block themes unlock, it’s also clear that there are a build up of pain points to address, whether through clearer resources or changes to Gutenberg itself. These conversations are just one way to start surfacing these themes (get it) and to begin finding ways forward.