New device preview UI feedback

[paaljoachim]

I am looking at the new device preview feature built by @tellthemachines
It is an awesome feature. That will be very useful.

As I am gradually starting to use the new drop down I am noticing the following which I believe we should talk more about.

1. The drop down showing Desktop, Tablet, Mobile and Preview externally stays open until it is on purpose closed.

2. Clicking Preview requires two button clicks. One to open the drop down and another to click the Preview button.

EDIT 13 March:
My suggestion would be to show Preview at the top instead of Desktop. Clicking Preview would then open the external preview. While clicking the other options seen in the top would open the drop down similar to clicking the drop down arrow.

Something like this:

A dot beside the preselected Desktop view.
Preview changes to View when a page is updated.
Preview externally on the bottom could just be removed.

Associated issue:
#20564

[folletto]

Yes please. I already raised this issue in #19750 but was closed (I think by misunderstanding the issue I raised there). Given this has popped out again independently, I feel there's even more of a need to fix it.

Which means that on top of what's mentioned there, we need to have:

1. both a "View" (if no changes happened) or "Preview" (it changes happened)
2. a fix: "View" shouldn't trigger a revision being created

[boemedia]

Would it be an idea to add the icons as seen in the customizer? Both to the editor and frontend preview? https://share.getcloudapp.com/o0uDepgd

[locksoft]

I agree. A way to select the preferred view in the popup menu and then having it as default will make everyone happy.
I think I understand why the new function is this way, the three views (desktop, tablets and mobile) are supposed to give an immediate preview in the back office itself but I guess the theme should support it. I'm using a personalized child of FolioPress and tablet and mobile don't show anything, while desktop is quite different, so I need an external preview, and two clicks (even if the menu stays open, even if above part of text) is not the best way to go.

[paaljoachim]

@mtias and @jasmussen
It would be good to bring the preview/view button back into a visible place.

It would be good to get some reasoning as why it looks the way it does today, and then discuss possible solutions on how we can adjust it.
I will also ping @mapk and @karmatosed

[boemedia]

Thanks @paaljoachim for letting me know my image link is broken. My idea was, to copy the pattern from the customizer. Here's a quick mockup to get the idea.

[paaljoachim]

Hey @boemedia

Interesting idea!
I took your mockup and adjusted it to add devices into their own drop down (to save toolbar space).
That means taking out the Preview/View button and keeping it separate from devices.

This way View/Preview will always be visible where we are used to having it.
Keeping it consistent for the user. Viewing/Previewing a page is a button often used.

[boemedia]

Actually my idea was, it not to be a dropdown, so you can see them at a glance.

[boemedia]

I don't think I really understand the difference between preview/view.

[paaljoachim]

Yeah. I just used your mockup to create an alternative. I added device icons into a drop down. To save space in the toolbar.

Preview - before saving an update.
View - a published/draft page/post.

I got a feeling that a change happened from icons to text in certain areas. This was one of them.

[boemedia]

Preview - before saving an update.
View - a published/draft page/post.

Can this not be one button with a changed text depending on whether the post/page is in draft or published?

[paaljoachim]

Yes. The button should say Preview or View.

[NewJenk]

The standalone preview button that opens a preview in a new tab (current WP behaviour) definitely needs to come back. Or, a filter needs to be added to allow sites to easily revert to the status quo.

Although I can see what is trying to be accomplished with the dropdown, there are an infinite amount of reasons why the edit screen may not replicate the front-end, and in these cases the preview button works just fine.

[karmatosed]

I think it's important to think how easy to understand those icons are, I don't think they are as easy as we think. I'm going to loop in @jasmussen here as know he was part of the original work done here, just to try and get that insight. I don't personally believe what we have now for the Customizer is better, so we can by iterating get a better solution here that even could roll out there.

[jasmussen]

Hey folks! Things have come together fast here, and we've rapidly tweaked and polished the UI, and will continue to do so. The following change by @shaunandrews I feel improves this a fair bit:

Huh ... for some reason I can't upload GIFs to Github today.

So go here: https://cloudup.com/cphxgwCi4gK

Honestly in my opinion that solves it entirely.

As for icons, I would suggest we carefully give each iteration a proper chance before we add any icons — it's possible to do so, but I'm not entirely sure they add a ton of value.

[jasmussen]

Although I can see what is trying to be accomplished with the dropdown, there are an infinite amount of reasons why the edit screen may not replicate the front-end, and in these cases the preview button works just fine.

I hear you. The editor is currently not as close to the frontend as it could/should be. There are numerous efforts underway (tagged "Lighter DOM" in the issues/PR list) that will make this possible, and the goal is to make it possible to load the theme stylesheet itself into the editor directly, making it true 1:1.

In the mean time, if a theme does not add an editor style (specifically, loads a CSS file using add_editor_style), the dropdown reverts to the Preview button.

[boemedia]

I think it's important to think how easy to understand those icons are, I don't think they are as easy as we think.

True. I'd never suggest using these as a substitute. I'm sorry if the quick mockup gave that impression.

[folletto]

I'd also want to re-quote my comment at the beginning to make sure it doesn't get lost in the shuffle:

we need to have:

• both a "View" (if no changes happened) or "Preview" (it changes happened)
• a fix: "View" shouldn't trigger a revision being created

I'm ok reopening the previous issue that got closed when this UI was implemented (#19750) if we feel it shouldn't be in this one, let's just not miss that.

[jasmussen]

@folletto It seems like it might be better to reopen that issue you created, and continue the discussion there. It seems to have context that's otherwise easily lost in this one.

Additionally it might allow us to close this one as fixed by the dropdown changes?

[jasmussen]

Closing this one so discussions around labelling/behavior can continue in #19750!

[mtias]

For reference, this is the latest iteration:

[paaljoachim]

Do you have a PR so that I can test it out in http://gutenberg.run/ ?
Thanks.

[jasmussen]

Matías screenshot is merged to master. I also have a GIF in https://cloudup.com/cphxgwCi4gK. Here's Shaun's PR: #20683

[paaljoachim]

Great! That looks good.
Thanks Joen!

[NewJenk]

In the mean time, if a theme does not add an editor style (specifically, loads a CSS file using add_editor_style), the dropdown reverts to the Preview button.

The dropdown is displaying for me whether add_editor_style is used or not.

[jasmussen]

The dropdown is displaying for me whether add_editor_style is used or not.

Perhaps you need to comment out both of these, then:

add_theme_support( 'editor-styles' );
add_editor_style( 'style-editor.css' );

Let me know if that works.

[NewJenk]

The dropdown is displaying for me whether add_editor_style is used or not.

Perhaps you need to comment out both of these, then:

add_theme_support( 'editor-styles' );
add_editor_style( 'style-editor.css' );

Let me know if that works.

Nope, that didn't work.

[jasmussen]

Which theme is this? Is it loading in an editor style using a different method? CC: @tellthemachines can you recall the specific heuristics we put in place to show the preview button when an editor style was not loaded?

[tellthemachines]

@jasmussen @NewJenk we didn't implement that distinction in the end. The reasoning was: we're not able to make the editor styles responsive because they are loaded inline, so in terms of the responsive preview it makes no difference whether there are editor styles or not. So we always show it. However, that problem looks like it might be solved with @ellatrix 's proposal in #20797.

Perhaps we could add a toggle to enable/disable the responsive preview, just like we have for fullscreen mode and suchlike?

[jasmussen]

Thanks for the clarification!

so in terms of the responsive preview it makes no difference whether there are editor styles or not.

I definitely think Ella's efforts can benefit us there, and it's definitely still the end goal. More importantly than that, though — the big differentiation is that if the editor has an editor style, it is more of an actual preview of the contents, than if it doesn't, so even if the responsive styles aren't 100% — I believe they will be eventually, especially if those iframe efforts pan out — you are still watching something closer to the frontend. Besides, most responsiveness happens in the blocks themselves, rather than from rules in the editor style.

I think it's definitely worth adding the behavior, so that if a theme registers an editor style using add_theme_support('editor-styles');, the dropdown shows up, and if it doesn't, you get the preview button.

[NewJenk]

My concern with adding this dropdown and not offering a filter to disable it is that you are essentially saying that Gutenberg should not be used for anything that isn't an exact visual representation of the front-end.

I thought that the eventual plan was to replace the classic editor with Gutenberg? But if that is the plan, then Gutenberg should cater for instances when the editor does not look like the front-end.

What comes to mind is plugins like WooCommerce (which is still using the Classic editor for products) and EDD etc, that are doing all kinds of stuff with meta boxes to manage products, and that is their primary aim - plugins that in-effect add CPTs that are more focused on manipulating data than achieving an exact replica of the front-end. In these instances a visual representation of the front-end is a nice to have, but is not essential.

But adding this dropdown makes it that bit harder for Gutenberg to be a full and proper replacement for the classic editor in those instances when an exact visual representation of the front-end is not the primary aim.