Improving Gutenberg Preview option to match user expectations

[SNaushadS]

After upgrading to 5.5 and publishing a new post i had a disconnect in checking the preview.

Observation:

1. Expectation mismatch
   The "Preview" action indicates a different preview would open up and that doesn't happen now.

2. Change in interaction
   Previous experience had the expectation that clicking preview would open in a new tab, which doesn't happen now. This would take some time to get used to.

3. Preview is on by default.
   In Gutenberg the preview is on by default in Desktop size. Hence the action of "Preview" doesn't fit well.

4. Switching sizes
   When a user switches preview size from Desktop to Mobile Or Tablet, user may find it difficult to switch back to the other state as we are not showing the selected preview size.

Suggestion:

• Inform users that preview is on by default and in which screen size, allow user to change the options.

Mockup
I mocked up a proto for this to get a feel of how this could function.

Figma Prototype Link

Screenshots:
Option that i prefer considering the horizontal space up at the header.

Other option, this one is more explicit but takes up additional horizontal space on header.

[ACEkin]

Suggestion: Use three radio buttons to pick the desired display simulation and click on Preview. This should require a second click only when changing the simulated display. At other times, a single click on Preview will do the job.

It would also be nice to bring back the link to the post buried in the Title block. Searching for the post link on the sidebar, expanding options, etc. are fine only for the first couple of times. Then, they become annoying. '-)

[MichaelArestad]

CC @jasmussen since this is somewhat related to previous work where we explored device views, etc.

[mapk]

Also related to: #23328 (comment)

[joyously]

Previous experience had the expectation that clicking preview would open in a new tab, which doesn't happen now. This would take some time to get used to.

I think this is the most important. Loading the page as it will look on the front end is essential, since there are totally different environments and different scripts and CSS are loaded. This should still be available to the user.

[ACEkin]

The other view/edit modes do not work at all anyway, all I see is the width of the simulated device and a single line height of the edit/view area. The tablet and mobile modes are totally useless here.

[SNaushadS]

Previous experience had the expectation that clicking preview would open in a new tab, which doesn't happen now. This would take some time to get used to.

I think this is the most important. Loading the page as it will look on the front end is essential, since there are totally different environments and different scripts and CSS are loaded. This should still be available to the user.

Rightly said, the only True Preview is in the new tab.

it just popped in my mind while pondering over this, there can be another approach wherein

1. the Preview is truly single click, single CTA.
2. it opens a new tab
3. the screen size manipulation is provided in the new tab. I am imagining only a floating size change button in top. I'll mock it up.
4. users can go back to the post tab when they need to make a change.

P.S.: this appears to work well when users need to get a sense of how their content would look. For the layout (Full Site Editing) we may still want to have the preview sizes as here the users goal is to make an overall layout decision not precisely content.

[ACEkin]

Rightly said, the only True Preview is in the new tab.

it just popped in my mind while pondering over this, there can be another approach wherein

1. the Preview is truly single click, single CTA.

2. it opens a new tab

3. the screen size manipulation is provided in the new tab. I am imagining only a floating size change button in top. I'll mock it up.

4. users can go back to the post tab when they need to make a change.

P.S.: this appears to work well when users need to get a sense of how their content would look. For the layout (Full Site Editing) we may still want to have the preview sizes as here the users goal is to make an overall layout decision not precisely content.

There is already a model for this in the Customize display with the screen simulations being selectable with icons like below:

[talldan]

The other view/edit modes do not work at all anyway, all I see is the width of the simulated device and a single line height of the edit/view area. The tablet and mobile modes are totally useless here

@ACEkin If you have metaboxes enabled. This bug fix might solve that - #24478, it should now be in v8.8 of the Gutenberg plugin, and WordPress 5.5.1 when that comes out.

[ACEkin]

@talldan , thanks for the tip. I disabled them from the view and the edit previews are working now. Thanks, but is this really a preview of the post but how it would be to edit it on a tablet or a phone? Moving the screen-based previews to the actual preview in the new window is a better idea. But at least I can get a rough idea if I really need to.

[jasmussen]

There are a few goals of the preview dropdown, including the ability to edit blocks and their responsive settings, but also to enable plugin extensibility to preview other views such as emulated search results or RSS feed views. The customization aspects here are underway, but not fully there. I understand that until that customizability arrives, it's frustrating that the preview requires two clicks instead of one, and I would encourage efforts towards addressing that issue to keep in mind the other goal of the dropdown so we don't lose that. Could be as simple as a split button.

[ACEkin]

A split button will be welcome. A similar approach will make the insert media button which combines occasionally used options (at least for me) into the interface again, requiring two clicks to reach my media library. This version increased the necessary clicks and scrolls to a frustrating level, having access to the post URL is in the same group. I cannot wait until at lease an interim release comes out.

[jordesign]

@SNaushadS I'm just checking through older inactive issues - and wanted to see if the improvements that have taken place in the preview since this initial report resolve things for you?

[ACEkin]

Not really. It still takes multiple clicks to preview a post in a new window. The text has turned into an icon for the link.

[SNaushadS]

@jordesign for the moment, I my need is satisfied with the open in new tab, although it is a 2 click option, but its fine for now. Considering comments from @jasmussen on how this preview needs to support content and other plugin/block features.

We can get feedback from a few more users and then close it appropriately.

[SNaushadS]

Additinal note: I saw another UI Element with the Aria Label as "View Post"

I am not sure why this is showing up and is it any different than "Preview in New Tab"

[jasmussen]

My feeling is that since this issue was opened, the actual block editor itself, especially in the case of block themes, actually does represent an accurate preview of the end result. I'd lean towards closing and consolidating, keeping in mind that if a new issue emerges, it's always possible to open a new ticket, which will be all the more up to date.

The "View Post" link shows up when you've published a post, as a shortcut for seeing the final permalink after you've published.

[jordesign]

I'm inclined to agree - so I'll mark this as closed for now. If there are further reports or instances where the preview is problematic, we can always open it again.

[ACEkin]

So, does this mean that this issue is no longer under consideration? Why not remove the "preview" option altogether then? I do not agree that the blocks give a preview of the post at all.