search

WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10.39k stars 4.15k forks source link

Really confusing UX using site title block #33223

Open omarreiss opened 3 years ago

omarreiss commented 3 years ago

Description

When I was investigating a bugreport about compatibility between Yoast SEO and the new Site title block, it took me about a twenty minutes to understand how to use this block. I've created a screencasts with all the roadblocks I bumped into. Just wanted to drop this here since I don't think it would be wise to ship the block with WP 5.8 in its current form.

Step-by-step reproduction instructions

  1. Add a site title block
  2. Edit it
  3. Save as draft
  4. Navigate away.

Expected behaviour

I expect I can save a draft and navigate away. I expect the publish button serves the purpose of publishing only. I expect it to be made more clear in a site wide block that changing it has consequences in all places where this block / field is used.

Actual behaviour

I couldn't save as draft and go to another page without ignoring a confusing prompt. Publish button apparently can also be used to save site wide blocks. When saving those, it is not used to publish content. Even in the current flow I didn't realize I'm altering the site title. Especially in a hybrid theme situation where it's not used as a block, this could be confusing. (Sidenote: To me this feels like we are pushing the "everything is a block" ideal too early and too randomly. )

Screenshots or screen recording (includes sound)

https://user-images.githubusercontent.com/1488816/124618516-2699fd80-de78-11eb-988e-f9328bb8eecb.mov

Code snippet (optional)

WordPress information

Device information

paaljoachim commented 3 years ago

Thank you for adding this issue @omarreiss Omar! What you mention is part of the multi-entity saving confusion which can be seen in a few different places. @ockham Bernie will be looking into multi-entity saving process very soon.

I have made a separate issue which I called: Publish: The Pre-publish dot, edit and save overview https://github.com/WordPress/gutenberg/issues/32833 I have also linked in several other issues.

aristath commented 3 years ago

Related: https://github.com/WordPress/gutenberg/pull/33140

ockham commented 3 years ago

The stuff I'm currently working on (mainly #33140) is more on an implementation/bug level. AFAIU, @paaljoachim's #32833 is also more about visual consistency on a rather low level (presence of the dot indicator on the Save button, mainly).

@omarreiss's concerns, as expressed in the video, seem to be on a higher level of UX. To extract/paraphrase the way I read it:

  1. After clicking 'Save draft' for an unpublished post, the user expects to be able to navigate away from the editor (rather than being stopped by an "You have unsaved changes"-style box).
  2. After clicking 'Publish' for an unpublished post, the user would be able to configure a few settings in the Publish panel, and then finally publish by clicking that button again.
  3. After modifying a post, the user could click 'Update', and that would update the published post.

These were invariants prior to the arrival of multi-entity saving (though I'm not sure they're entirely new for Full-Site Editing related blocks; I'd think that modifying a reusable block inside of a post draft would lead to similar behavior). Now they aren't anymore: If the user modifies something that impacts a "non-post entity", they'll have to go through an extra saving step. It's not always evident to them that they've modified such a thing: The Site Title block arguably doesn't "feel" that different from any other block.

While users can change their behavior and expectations after being exposed to some of these changed flows if they easily map to a mental model, it's arguable that some of these flows don't do that. On first glance, I'd say in particular that the first invariant (the 'Save draft' one) makes a lot of sense, and that it's rather unintuitive to require the user to click 'Publish' to persist non-post changes even if they don't want to publish their post yet.

We can probably fix that part at engineering level by making the 'Save draft' button save those changes, but even that raises some UX questions: How does the user select which non-post entity changes to save? Do we just assume they want to save all of them? Or do we show the multi-entity save panel (that we're now showing upon pressing 'Publish')?

Calling out to our designers @mtias @jasmussen if they can think of an 'easy' solution to make things more intuitive and/or consistent, at this point into the release cycle 😅

cc/ing @ntsekouras @david-szabo97 @jeyip @youknowriad 'cause y'all have worked on FSE blocks, dirty state detection, and/or multi-entity saving.

jasmussen commented 3 years ago

The issue is real, but is not unique to the site title block. It's the same for template parts, reusable blocks, site tagline, and any other blocks that make changes global to the site itself. Getting this right is a key part of full site editing, and as outlined, we definitely have a ways to go.

There's some good thoughts about how to improve the multi entity saving flow, notably Jay's comments here: https://github.com/WordPress/gutenberg/issues/29577#issuecomment-791302392. I'm personally hesitant in making "Save draft" make changes to such site options: it may be obvious for us as developers what's up, but I could easily imagine a casual user inserting a Site Title block thinking it was a heading or otherwise title block, and making unintended changes without knowing it.