High level feedback from the FSE Program (March 2021)

After a few months and a few rounds of testing for the Full Site Editing Outreach Program, this post summarizes the top pieces of feedback of the current experience to help inform ongoing efforts for an MVPMinimum Viable Product "A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development." - WikiPedia. Keep in mind that this post is simply a snapshot in time and is inherently going to leave out aspects of the experience that haven’t been the subject of calls for testing yet, for example, Global Styles. If you want a more in-depth look at feedback across the testing calls and a full summary of all issues rather than a sampling, please review the summary posts. If you want to help give feedback, join the calls for testing or test whenever you’d like. 

Previewing content

Across both calls for testing, it quickly became clear that previewing changes is a workflow people rely upon and miss deeply in the current experience, whether it was a desire to preview changes to a template or to preview the entire site. A “Preview Site” option is currently under discussion, along with exploring a possible browsing mode allowing a user to browse around their site within the editor. 

Saving Process

While the saving experience was reliable technically and generally intuitive, it has left a lot to be desired and resulted in a fair bit of confusion around expected behavior. This is likely because multi-entity saving (saving multiple aspects at once) is a new WordPress concept and one that underpins every interaction in the Site Editor. Whether it was mentioning desired features, finding bugs, or confusion around how to accomplish a task, this proved to be a robust area of feedback. 

The distinction between editing the entire site vs. specific content

Similar to the saving process feedback, this is another area where features technically work but are difficult to distinguish across the experience. For example, one can edit a template directly, but it’s not always clear when one is editing a template or editing an item of content. Beyond just clarity in what one is editing, there needs to be the right amount of friction when switching between content that impacts the entire site vs. content on an individual post/page. This is an area of active iteration and exploration to get the right amount of friction in place, as you can see in open issues like this one around clarifying template vs. content editing, and this one around refining the experience of editing a template part in isolation.

Rethinking Width/Alignment

Currently, alignment in Full Site Editing works to optimize traditional themes that provide their own alignment styles. This approach has served the project well until this point, but it’s a key area to reconsider to ensure a true and reliable WYSIWYGWhat You See Is What You Get What You See Is What You Get. Most commonly used in relation to editors, where changes made in edit mode reflect exactly as they will translate to the published page. experience. Thankfully, work is already underway in an important PR by @youknowriad to reimagine how this dynamic should allow for more control over alignments/widths when using the Site Editor. 

General Usability Improvements

As this work moves into a place of refinement, there are numerous enhancements to consider to improve overall usability of the Site Editor. This is a “catch-all” categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. but an important one nonetheless, as it will help the Site Editor experience move from functional to delightful. What follows is a sampling of items both to get a sense of the kinds of issues raised and the spread: 

Improving Placeholders

Placeholders for some of the newer blocks in the site editing experience prove to be both a powerful way to guide people and a point of confusion. This feedback mainly came into play with blocks like the Query Block (including the 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. variations like Posts Lists), Social Icon Block, Featured Image Block, and the Navigation Block. Each currently gets users started in different ways. In the long run, it seems that users will benefit from a standardized, consistent way to interact with placeholder content across all blocks. This is particularly important when viewed through the context of editing a template where you might mostly see placeholder content. 

#core-editor, #fse-outreach-program, #full-site-editing, #gutenberg