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.
If you’d like to help test Full Site Editing, please join the FSE Outreach Program. You can find current calls for testing for this program here and you can join the fun in #fse-outreach-experiment.
A working session was held today to discuss big picture goals and what to accomplish during the 5.9 cycle.
Consensus reached as to where e2e tests will live within each repository:
All recent major changes to Core with user facing functionalities are top priorities to receive e2e tests as part of WordPress 5.9. These areas are:
tl;dr:
Along with the previous areas to test, the following priority would be to port some Core tests that are currently implemented in Gutenberg (e2e-test-utils package). Concerned tests are those related to the login feature.
The next step after this would be to improve the login tests to make them more performant. This includes for instance cookie based authentication across all tests in Core and Gutenberg.
These items are not necessarily part of 5.9 Goals. However, these are part of the bigger picture Test Roadmap.
tl;dr:
e2e-test-utils package (maintained by Gutenberg)All agreed Playwright for e2e tests would indeed have a lot of advantages for both Core and Gutenberg. However, consideration must be given for breaking changes and impacts for extenders using the test utils. Kai noted the utils could be made compatible with both Puppeteer and Playwright, meaning no breaking changes.
Also, a migration plan will need to be discussed on developed once the test utils are ready for Playwright. Part of this plan is to figure out how to change Gutenberg and Core as well as how to upgrade existing, not yet committed patches/PRs. The how and when is yet to be determined.
As there is still work to do to prepare for Playwright, the team agreed to continue with the roadmap to build e2e tests in Core.
Props @hellofromTonya for peer review and proofreading.
This post is a summary of 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. theme switching exploration for the FSE outreach program. This was the first of its kind, enabling folks to share very early feedback on something that has yet to be robustly defined. Thank you to everyone who participated, whether through sharing feedback directly or sharing the exploration with others.
Shout out to @richtabor @elmastudio @anariel-design who officially got badges for responding, despite having engaged with surveys the program has done in the past.
Big thank you to @piermario for the Italian translation and @greenshady for the WP Tavern article, which both help bring the exploration to even more folks.
High level summary
Overall, the current experience proves to be frustrating and inconsistent, especially when taking into account custom block styles, keeping customized templates, etc. Thinking long term about what folks would want to be able to have across themes, there was mass consensus around being able to retain templates, template parts, and menus. There was somewhat mixed feedback around whether Global Styles should persist as some saw those as differentiating a theme. When it came to ideas for how to best manage the switching process, it quickly became clear that there’s a balance to strike between not adding too much friction to the process while also offering users options to pick and choose what can come with them when they switch. Ideally, there can be a simple and visual way to intuitively guide users and help them take advantage of the power of what block themes unlock without discouraging them with too many options.
On templates and template parts
There was mass agreement around the desire to keep customized templates and template parts across themes, with many expressing surprise and frustration at the current experience. This was previously documented and discussed here as part of an earlier call for testing.
I’m very surprised that any templates I’ve created are tied to the theme that was active when I created them. I’d expect that my custom templates should remain applied to pages when the new theme is active, instead of being disregarded. I’m not sure why templates are omitted when a theme is changed.
@richtabor in this comment.
I would like to be able to use templates and templates that I have created and saved, no matter which theme that is active. I know that I can view them under appearance templates/template parts, open them, copy the code and paste it into a new template, but I don’t think that is a good experience. It should be easier.
@poena in this comment.
On menus
Similar to templates and template parts, this was another area that folks inherently expected would persist across changing block themes.
An issue I’ve ran into now a few times when trying out different Full Site Editing themes is that losing menu data is frustrating. I think as a non-technical user it would be confusing, because you are prompted to “Add an existing menu”, which I would think would be my menu from the last theme I was using.
@timothyblynjacobs in this comment
I think it is important that navigation blocks that I have set up remains. The “Add existing menu” feature in the navigation block assumes that I have already created a menu in the navigation screen. If I only setup the navigation block as part of a headerHeader The 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. template part in the previous theme, then I can’t re-apply or reuse that navigation block. Perhaps navigation blocks should also work the other way around? I mean why can’t I select a name for my navigation block as I create it in the editor, save that in isolation like I can save the site blocks in isolation, and have that navigation menuNavigation Menu A theme feature introduced with Version 3.0. WordPress includes an easy to use mechanism for giving various control options to get users to click from one place to another on a site. present on the navigation screen?
@poena in this comment.
Keeping any menus created in the Site Editor available would be important, I think this is one of the biggest issues right now.
@elmastudio in this comment.
On Global Styles
Global Styles left folks a bit split with some seeing them as being theme dependent and others wanting the option to carry settings/styles across themes. There’s currently a discussion around what can and can’t be standardized which will impact how this could be implemented.
I see Global Styles tied to the theme, but it could be helpful if some common settings are taken from one theme to the next.
@elmastudio in this comment.
Understandably global styles settings would adapt when a theme is changed (just like the customizerCustomizer Tool 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.) – and I like how my custom GS settings persist when I change back to a theme (just like the customizer as well).
@richtabor in this comment.
When you export the demo and import it to the other installation, theme.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. file styles are not imported. As a theme developer, I would love to develop one theme with different demos for example. When I export the demo file I would love that global and block type styles are exported too and imported to other installations.
@anariel-design in this comment
Have the option to keep Global styles modifications. Perhaps a kind of dialog box that shows up when entering the Site Editor listing adjustments I made to the previous theme, asking if I wanted to keep these adjustments or to start anew.
@paaljoachim in this comment.
One question that keeps me up at night is how cross-theme compatibility will work on the content level. Default block output should translate from one theme to the next with little or no issues. However, custom block styles, font sizes, colors, and the full range of presets are already a problem area.
@greenshady in this WP Tavern article.
On ideas for how to manage the process
Outside of a desire for the experience to be overall easier and more seamless, the following ideas were shared with a split in terms of folks who wanted decisions upfront vs after switching:
I have experimented with one theme but figured out along the way that it does not have the patterns or finished templates or something else I had hoped for. Instead of creating the patterns and templates myself I switch themes. When I click to switch a theme I get a warning message saying that switching themes will remove the adjustments I made to the current active theme, but I have an option to save these adjustments in a kind of twilight zone between one theme and another. I select to save changes I made, and notice that these carry over to the new theme that I activate. I check and notice that the changes do carry over. I am relieved that I am able to create adjustments in one theme and have these with me to the next time…In the Site Editor I can check out what the new theme offers and when I feel ready for it I can either say yes to bringing over the changes or no because I notice that the new theme has what I need.
@paaljoachim in this comment.
I actually don’t want to be prompted with having to make several decisions as soon as I activate a new theme. I would find that stressful. I want to take my time. I want to understand what the differences are between the themes, and what changes I need to make. Perhaps there would be a side-by-side comparison of common page templates like page, single post, home? Like a revision?
@poena in this comment.
It needs to be easier for the users. They already needed to deal with the domain, hosting, choosing a theme etc.
@anariel-design in this comment
It could also be awesome to pull a color palette and drop it into an existing theme. Sort of like having a Colour Lovers directory to pick color schemes from but keep all the other bits. This could be fun for people who can recognize a palette that they like but would never be able to handpick all those colors. I’ve often seen color schemes that I’d love to use from other themes but didn’t like other things about them.
@greenshady in this WP Tavern article.
On reasons for switching and the experience
Of the various questions folks could answer, some touched on both reasons for switching and the current experience. I’ve listed each response below since only a few folks addressed this area specifically. I’m also including images from @greenshady’s post where he took a simple blog post with some custom block styles, gradient colors, and font sizes and compared the output across three different themes highlighting current problems with theme switching.
To see prebuilt template layouts (could be done in a template mosaic view to where I can choose various prebuilt layouts instead of switching themes). To have a base that I want to start from. A design that I would like to use and modify.
@paaljoachim in this comment.
I think the most common scenario is a missing functionality in one theme like WooCommerce support. Next would be outdated design and lack of updates and support from the theme author.
@elmastudio in this comment.
When I switched to the Quadrat I mostly lost everything that I set up in the Clove theme. That means, About page doesn’t look anything similar, colors, fonts are now from the Quadrat theme and button style too. From the user’s side, this is very confusing. If u ever used Elementor for example, and many are using it they are used to the similar overflow. If I create a template and change the look and styles and switch to any other theme this template will look the same and it will remain available.
@anariel-design in this comment
I am not one for switching themes. Since I learned how to design for WordPress well over a decade ago, I have never moved from one theme to the next. At least not in the same way that the average user would. Instead, every time I have added a new coat of paint on my websites, I have simply switched over the foundation to whatever I had been working on at the given moment. WordPress themes, for me, were always just an iteration upon the last project…The first thing I do when testing any theme is to load a demo post. Lately, this has been the “Welcome to the 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/ Editor” test post. The primary question: Can I read the content comfortably? If I do not get past this stage, I simply deactivate the theme.
@greenshady in this WP Tavern article.
What’s next?
@critterverse is exploring how to approach these flows from a design perspective and has been following along as feedback has come in. You can expect to see a more in depth design exploration shared soon enough with some of these pieces of feedback and ideas integrated in! I’ll flag this in the outreach program channel when the time comes and will see how we can explore these experiences in future calls for testing.
Date: 2021-09-16 16:00 UTC
Format: Zoom (recorded). A link will be shared in the #fse-outreach-experiment channel before the meeting time. Please join that channel if you’d like to participate!
Length: 45 – 60mins. This will not run longer than an hour.
Topic: This session will focus on adoption pathways with full site editing.
Facilitator(s): @mkaz @get_dave @annezazu
Goal: To have a broader discussion about adoption pathways, what’s working, what successes folks have had, what blockers people are running into, and what might help more folks participate. Beyond just the benefits of learning from each other, this information will ideally be used to help influence future resources and to give insights to the teams working on these items.
Intended Audience: Anyone who has adopted or is interested in adopting site editing related features (theme.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML., template editor, theme blocks, navigation editor, etc).
Agenda
This conversation is meant to casual, collaborative, and open ended rather than prescriptive about how one should approach adoption. With that in mind, we’ll start the session asking folks who are comfortable doing so to share what they’ve tried and how it’s gone. Once everyone who wants to go has done so, we’ll talk about successes, blockers, and what resources folks have used (along with what resources folks would like to see). We’ll see where the conversation takes us from there!
Two candidates were nominated during the open nomination period, both of whom accepted their nominations. The new Test Team Reps for 2021 (and beyond) are Piotr Boniu (@boniu91) and Tonya Mork (@hellofromtonya)!
Piotr is fascinated by WordPress since 8 years. Firstly, it was just a fun for him, later it became a way to live. He attends WordCamps whenever possible since WCEU 2017 in Paris. In 2019 in Brighton he was a speaker.
Within the project, he served as the 5.9 Test Lead.
In his career, he’s transitioning into technical product management for a WordPress performance product company, after having previously served as a QA Engineer and Technical Support Engineer.
On the personal side, Piotr is a resident of Canary Islands, previously lived in Madrid and Warsaw. He resides in a small town called Puerto de la Cruz with a girlfriend and his two cats. He’s obsessed with technology and gadgets that are making life easier, his free time is filled with hiking, sports and swimming in the ocean.
You can read more about him on his profile page.
Tonya is a leader, architect, engineer (software and electrical), educator, and learner. She became hooked on contributing during the 5.6 release cycle. She saw the impact the Test Team can and could have on the project. She brings her empowerment and transformational approach to help the team rebuild itself, help fuel continuous improvement, and help contributors get started, gain and grow their skills, and grow their impact.
Within the project, she served as the 5.6 and 5.7 Triage Lead, coached the 5.8 triage and test release squad, is a Build/Test Tooling co-maintainer, and is a full-time contributor (as of February).
Outside of the project, she’s likely best known as a developer educator. She’s been leading and advising multi-disciplined engineering teams for over 3 decades in the areas of architecture, quality, testing, performance, and operations.
On the personal side, Tonya lives in a small fishing village on the NW coast of Lake Michigan in the US with her spouse (celebrated their 35th anniversary this year), dog (who thinks he’s a cat), and cat (who thinks he’s a dog and ruler of the house).
You can read more about her journey on HeroPress and her profile page.
This is a summary of a Hallway Hangout that was wrangled in the #fse-outreach-experiment channel as part of the FSE Outreach Program. Thank you to everyone who joined the conversation!
Attendance: 10 Attendees in total
You can watch the recording of the call here:
Notable Topics Covered:
The call for testing will remain open for feedback until July 14th. Please feel free to check the test here.
#fse-hallway-hangout, #fse-outreach-program, #full-site-editing
To better expand the reach of the FSE Outreach Program, I am exploring creative ways to engage the wider community. In the #fse-outreach-experiment slackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel (join us!), I recently shared an idea to create better connections between the program’s work and local polyglot communities. Since then, I’ve had the chance to work with @mimi who is a part of the Japanese WordPress community. I wanted to share how our work is evolving so others can join in.
Here are a few ways that someone who is a part of a local polyglot community can help with the FSE Outreach Program:
If this seems like too much, try to find someone else in your local community to work with. For example, you could divide the work so one person translates the Calls for Testing, while another person translates the feedback that’s received to share on the official Call for Testing post.
If you’re interested in working on these ideas in your local community, please comment below or message me on slack (@annezazu).
I want to make this easier for anyone interested in any of the above ideas so let me know if this is an area you want to help with. Feedback is always welcome so please pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” me or share your thoughts in the #fse-outreach-experiment.
Finally, big props and thank you to @mimi who has kindly started helping here and has been giving me feedback along the way.
As part of leading the FSE Outreach Program, I’ve been building out resources to help further the overall mission of gathering feedback. While calls for testing are shared as frequently as possible, there are times when there isn’t an active call for testing. This shouldn’t be a blocker for anyone to explore FSE and give feedback!
To help empower everyone, I made the following guide:
Consider this just a start! Please let me know what else would be useful to include or update as you go through it. I’d love to help as many people as possible get excited about FSE and give feedback.
Currently, there are a few areas lined up for testing in the future for the FSE Outreach Program, but none are quite ready to be launched for a round of testing. Let’s use this time to dig into any general questions you all might have around Full Site Editing!
You are welcome to submit questions using the form below or to leave them as a comment on this post by February 15th:
Keep in mind that because this work is still heavily in progress, it’s likely that some answers might take the form of “people are working to figure this out and feedback is welcome here,” rather than a definitive answer.
Where will you share the answers?
I’ll share a recap post on this blog (Make Test). Questions will be grouped with corresponding answers for easy review. I will track down answers to every question and share my work as I go by creating a collaborative Google doc where people can help find answers or simply see how the work evolves.
While the main result will be a lovely list of answers, this collective effort will also be useful for future documentation updates and potential tutorials. Once the post is published, I will follow up via email with everyone who left their email and a question in the form. For anyone who leaves a question as a comment on this post, I will @ your username in the recap post so you don’t miss out too!
For more information about this experimental program, please review this FAQ for helpful details. To properly join the fun, please head to #fse-outreach-experiment in Make Slack for future testing announcements, helpful posts, and more will be shared there.
#fse-outreach-program #full-site-editing #gutenberg #core-editor #fse-testing-call
More calls for testing are on their way so join #fse-outreach-experiment in slack and/or subscribe to this Make blog to stay tuned.
This post is a summary of the first call for testing for the experimental FSE outreach program. Thank you to everyone who participated, whether through testing directly or sharing the call for testing with others. It all helps! While this call for testing is over, feedback is always needed and welcomed in GitHub.
Related feedback is grouped under high-level headings. As you read through it, please remember that feedback is welcome on the format of this post too as the program is still in the early stages of determining what works best.
Distinction between editing modes (template vs page/post)
The need for the distinction between modes appeared in a number of responses. Thankfully, this was already identified as an area to improve before this call for testing in open issues like this one that reveal just how similar the two modes currently, and the resulting confusion.
Have a clear defined area for post editing and well defined area for Full Site Editing. Do not mix Publish and saving. As they are very different things. One is for post editing and one for FSE editing.
– @paaljoachim in this comment.
I believe it was not clear enough how those changes could impact the site. If you don’t already know how templates, template parts, and global blocks like Site Title work, you might not understand how your editing will affect the rest of the site.
– @priethor in this comment.
The fact that I had to spend a considerable amount of time to understand the differences for a few arbitrary terms and what they mean in a UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. is going to be a significant barrier to migrating existing clients to FSE and training them to understand. It simply won’t be worth it.
– @pointydrip in this comment.
Switching between editing modes (template vs page/post)
The actual act of switching back and forth between modes brought up a few different issues. What does the cancel button do? Why does applying changes for a template take me from template editing back into post editing? Some of this overlaps with the previous section as well. Thanks to the feedback shared, multiple issues were opened related to this particular part of the experience:
Most feedback indicated that by increasing clarity in the interface (ie: a clearer, stickier notice) and making the switching process more predictable, the experience can be greatly improved from the current iteration.
Switching to Template Editing – Editing the template from the post, while logically I knew what that meant, felt surprising – the switch was kind of a jolt because a bunch of things changed on the screen yet the overall layout stayed the same – so it felt like “Whoa, what just happened?”. Felt disorienting.
– @brentjettgmailcom in this comment.
I found it confusing that clicking Save brought me out of the FSE template mode. I saved. I did not ask to go out of the FSE mode.
– @paaljoachim in this comment.
It took me a while to find how to get back to the original post. I eventually found the Cancel button.
– @bobbingwide in this comment.
Saving Process
Generally speaking, the saving experience was reliable technically and, at the highest level, intuitive enough. The main sticking points came when trying to dismiss changes, save changes as a draft, and understanding what each “sub” item to save meant. The following issues were created to address each piece of feedback:
I found this part to be kind of difficult. I think the labels on the different things being saved confused me. I didn’t really understand right away what was being saved for each checkmark…If I wanted to not save the template and left it unselected, but wanted to save the post, it would want to keep publishing the post.
– @geheren in this comment.
The saving process is intuitive, and it’s very helpful to clearly list what elements are going to be updated when saving. However, as said before, it might not be clear enough how each edited element will impact the rest of the site. It could be helpful to add a tooltip to the different elements that are going to be saved (post/site/template/template part) to provide users a quick, last-minute reference.
– @priethor in this comment.
Create a new template
While this call for testing didn’t focus on creating a new template, it feels like a natural extension to wonder how a new template could be created after making changes to a current one. While there isn’t currently a mapped-out plan for this experience, it is under discussion in this issue as there are quite a few scenarios to consider.
What if I want to Save As? To create a new single template. As I might want the original single template and just want to create a new template that modifies the original template. Kind of like a default template and a modified template.
– @paaljoachim in this comment.
How would I go about creating a new template for a selected post/page?
– @bobbingwide in this comment.
Preview changes
Previewing changes is a workflow people rely upon, and this showed up in testing. While explicitly including ways to preview content hasn’t yet been discussed, there is an open issue to explore how best to view the template while editing a post that touches on this experience. In response, a new issue was opened around offering the option to preview the template in the same way one can with the Site Editor.
My trust is always in the published page, and I’m looking everywhere in FSE for a preview page link while I’m editing to basically see if it worked. I feel like just being able to open the page in a new tab would give me confidence in what i’m doing in FSE. The other issue is that since you don’t see the headerHeader The 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. or footer in the post editing context, as soon as you do apply changes to a template and you land back on the post, you immediately think “Did it work?”.
– @brentjettgmailcom in this comment.
I found it confusing that clicking Save brought me out of the FSE template mode. I saved I did not ask to go out of the FSE mode. I want to see what it looks like on the frontend. Meaning clicking Save and then previewing the template on the frontend.
– @paaljoachim in this comment.
Undo/Revert Template Changes
This was originally brought up in this issue and is currently being worked on in this PR.
There’s no place that I have found within FSE to revert a template/part back to the theme’s default setup.
– @brentjettgmailcom in this comment.
Bug with template parts
As part of this testing, a few people (myself included) ran into a strange bug related to themes located in a sub-directory not properly loading template parts. This was reported and should help ensure future 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 work with this experience.
Where is template editing work headed?
While this post goes deep into the pain points of the current experience of switching between template and post editing, it’s important to show where this work is headed. Currently, the best place to follow along is in this organizational issue focused on the remaining interface and infrastructure issues. This includes everything from issues on how to better distinguish the editing experiences to a welcome guide to introduce people to template mode! Follow along there as the work continues.
#fse-outreach-program #full-site-editing #gutenberg #core-editor #fse-testing-summary
This is the first call for testing as part of the Full Site Editing Outreach Program. For more information about this experimental program, please review this FAQ for helpful details. To properly join the fun, please head to #fse-outreach-experiment in Make Slack for future testing announcements, helpful posts, and more will be shared there.
To help frame what we’re going to be testing (and ideally build some excitement!), I wanted to give a brief context on the feature at the center of this call for testing. With Full Site Editing, people are able to edit both an individual post’s content and, with the release of Gutenberg 9.6, the template that an individual post uses. This call for testing is designed to explore the interaction between the two editing experiences (post vs. template editing) to make sure it’s clear when you’re editing each, granular saving works properly, etc. Ultimately, being able to edit templates like index, single, or archive directly is a huge leap forward compared to what’s been possible in the past! Unlocking this level of customization gives you far more control to build the site you want and this call for testing is to help ensure it’s as intuitive as possible.
You can read more about the terms templates, template parts, and more here.
While there’s more information below to ensure you get everything setup properly, here are the key aspects to have in place with your testing environment:
Flow is the actual user experience, in many ways. If you like, you can think of flow as a really comprehensive set of user stories. When you think about user flow, you’re thinking about exactly how a user will perform the tasks allowed by your product.Flow and Context
Here’s a basic flow to follow when testing this specific feature. If anything doesn’t make sense, just comment below!
Important Note:
While this call for testing is focused on testing a specific feature, it’s extremely likely you’ll find other bugs in the process of testing with such a betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. feature! Please know any bugs you find are welcome in your report for testing, even if they aren’t directly applicable to the tested feature.
Setup Instructions:
Testing Instructions:
What to notice:
Please leave feedback in the comments of this post. If you’d prefer, you’re always welcome to create issues in this GitHub repo directly for Gutenberg and in this GitHub repo for TT1 Blocks Theme (formerly called Twenty Twenty-One Block Based Theme). If you leave feedback in GitHubGitHub GitHub is a website that offers online implementation of git repositories that can 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/, please do still comment below with the link. If you see that someone else has already reported a problem, please still note your experience with it below, as it’ll help give those working on this experience more well-rounded insight into what to improve.
#fse-outreach-program #full-site-editing #gutenberg #core-editor #fse-testing-call, #usability-testing
You must be logged in to post a comment.