Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Post Editor: Preview button was removed by a Site Editor change #44738

Closed
tomjn opened this issue Oct 6, 2022 · 10 comments
Closed

Post Editor: Preview button was removed by a Site Editor change #44738

tomjn opened this issue Oct 6, 2022 · 10 comments
Labels
General Interface Parts of the UI which don't fall neatly under other labels. Needs Decision Needs a decision to be actionable or relevant Needs Design Feedback Needs general design feedback.

Comments

@tomjn
Copy link
Contributor

tomjn commented Oct 6, 2022

Description

In #42331 the site editor was improved by changing the preview button to a view button. However this change wasn't just applied to the site editor, it was applied to all editors. I can understand why the change was made for the site editor, but it's a major regression for the post editor and other block interfaces.

This on its own will create tens of thousands of hours of support requests and problems.

It also heavily implies that you can no longer preview your changes, and that changes are applied immediately rather than on update.

Step-by-step reproduction instructions

  • Open a draft post
  • Make changes
  • Attempt to preview the changes
  • Notice that there is no preview button

( unless you are told that the view button can be used to preview the changes, how would you know? )

Screenshots, screen recording, code snippet

Screenshot 2022-10-06 at 13 47 38

Environment info

  • WordPress 6.0
  • Gutenberg 14.2.0

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

@dream-encode
Copy link

This one looks like it needs a fix before 6.1 RC.

CC @ndiego @ockham @c4rl0sbr4v0 @annezazu

@annezazu
Copy link
Contributor

annezazu commented Oct 6, 2022

cc @jameskoster / @jasmussen / @richtabor for a design point of view. I can see an argument that this creates consistency across the editors and I can see an argument for having nuance in each. In the original PR that implemented this, it seems like there wasn't necessarily certainty there either #42331 (comment)

For now, adding to the 6.1 board for consideration.

@annezazu annezazu added the General Interface Parts of the UI which don't fall neatly under other labels. label Oct 6, 2022
@annezazu annezazu added the Needs Design Feedback Needs general design feedback. label Oct 6, 2022
@jasmussen
Copy link
Contributor

Personal opinion: I like keeping it "View". The canvas itself is already a preview, and the View toggle offers query based sizes, and an option to view in a new tab.

@bobbingwide
Copy link
Contributor

My personal opinion. I don't use Preview. I much prefer to Update and View Post. WIBNI if the View menu actually included the option to actually view the post.

@tomjn
Copy link
Contributor Author

tomjn commented Oct 7, 2022

Personal opinion: I like keeping it "View". The canvas itself is already a preview, and the View toggle offers query based sizes, and an option to view in a new tab.

This is only true on well built block themes which make up a tiny slither of the current install base. The idea that the canvas is itself the preview is inaccurate on the majority of sites, as well as many of your own companies main offerings such as WooCommerce. Most custom and 3rd party blocks don't follow the WYSIWYG rule either. E.g. how would you preview an ACF interface.

It's also not possible to preview the canvas at breakpoints other than the 3 predefined desktop/tablet/mobile, as well as testing that the post behaves correctly with 3rd party scripts and assets that aren't loaded in the editor. For these preview is required, and removing the wording removes the feature for most users.

This will cause a large amount of support/customer/client confusion, removing the word "preview" is a regression.

@tomjn
Copy link
Contributor Author

tomjn commented Oct 7, 2022

Also the site editor doesn't behave the same way that the post editor behaves, in the site editor viewing the site doesn't trigger the preview functionality, it actually views the site. That's not the case for posts.

A user may make changes, click view expecting to see the unmodified site, see their changes, and think that their changes were saved and applied, only to be confused when they later visit and their changes are missing.

Users who don't use the preview feature can continue to not use the preview feature, but I can see the value of the preview button changing to a view button if the current document has no changes

E.g.

if post is saving
    disable button
else
  if post is dirty
      display preview
  else
      display view

@talldan talldan added the Needs Decision Needs a decision to be actionable or relevant label Oct 12, 2022
@getsource
Copy link
Member

A user may make changes, click view expecting to see the unmodified site, see their changes, and think that their changes were saved and applied, only to be confused when they later visit and their changes are missing.

Just thought I'd leave a note that I agree that it's confusing to change it globally to "View".

I like the solution suggested by @tomjn re: different state depending on the post's status.

@dlh01
Copy link
Contributor

dlh01 commented Oct 13, 2022

Please also note that there's already a link labeled "View" in the post editor, in the admin bar, which does something different than the button: It goes to the published post on the frontend.

Screen Shot 2022-10-13 at 2 04 30 PM

With this change, there are arguably two "View" links that do different things.

I'm sympathetic to the reasons for labeling the button "View" everywhere, but I hope that what @tomjn says takes precedence. This is going to be a disruption for many users and the teams that support them. If it's going to happen, then, IMO, it deserves to happen deliberately and to get attention in a dev note and the field guide. It's too significant to happen as a side effect of a change to the site editor, which is a feature that a small number of users will ever see relative to the number of users with the ability to publish content.

@annezazu
Copy link
Contributor

For context, this was initially done in the Site Editor (view) and ported over to the Post Editor. While I think it's good to have consistency, I can also understand where keeping preview makes sense, especially while previewing isn't possible: #28208 Since the functionality does exist in the Post Editor, it seems wise to have separation there and keep "preview" for now. In the future when there's more shared functionality, I could see having consistency between the two, especially when content is available in the site editor #44461

@annezazu annezazu moved this from Triage to Todo in WordPress 6.1 Editor Tasks Oct 17, 2022
@annezazu
Copy link
Contributor

Update for folks here. Thanks to everyone who chimed in, offered feedback, and shared context around this initial implementation. Based on what's been shared, a PR was completed to add back in the "Preview" button to the post editor: #45074 I'm working to ensure it's backported for 6.1 and am going to close this issue out for now!

Repository owner moved this from Todo to Done in WordPress 6.1 Editor Tasks Oct 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
General Interface Parts of the UI which don't fall neatly under other labels. Needs Decision Needs a decision to be actionable or relevant Needs Design Feedback Needs general design feedback.
Projects
No open projects
Development

No branches or pull requests

8 participants