Plan for 2.1

Allow Drupal's preview button to appear again, have that trigger the reveal of the same page preview if permitted to appear & collapsed.

I really like this idea, thought I do have two reservations:

• In any admin theme except Gin, the Preview button is at the bottom of the form, and offering authors the option to see a live preview after they've populated all the fields would seriously diminish the value. Is there a way it could only rely on the existing button if it is in a fixed position container?
• I think it's worth discussion if "Preview" is still the most appropriate label given the altered functionality. For example, would "Live Preview" better communicate what a content author should expect?

Also, it hasn't been as explicitly mentioned here, but I believe that in one of the Slack threads there was mention that the setting of the localStorage preference about whether or not to use the preview pane by default would be moved to the gear icon. My personal view is that this would be a mistake. I think we should be careful not to assume that users will use the gear icon at all.

Personally I would favour using localStorage to treat every user choice as persistent, and then use the options within the gear icon as a way to expose less obvious options, and maybe a more explicit way to manage the stored preferences.

Some links that I think are relevant to this discussion:

https://www.wired.com/2015/12/simplicity-is-overrated-in-ux-design/

https://www.eleken.co/blog-posts/why-simplicity-is-overrated-in-ux

https://uxplanet.org/why-most-designers-think-simplicity-is-key-and-why-...

> In any admin theme except Gin, the Preview button is at the bottom of the form, and offering authors the option to see a live preview after they've populated all the fields would seriously diminish the value. Is there a way it could only rely on the existing button if it is in a fixed position container?

In early iterations we had altered the node edit form to ensure the preview button was at the top. In fact, I think we may have displayed it at both the top and bottom. We could consider something similar with this change.

Maybe a stretch goal, but I believe we also discussed trying to address https://www.drupal.org/project/same_page_preview/issues/3345096 📌 Add a grabber to the left border of the dialog Postponed (making it clearer that the preview panel can be dragged) as part of this as well.

The intent of the module remains to have the preview on/open by default. In that context, we can understand that clicking the preview button to open the preview is limited for the case when the user has chosen to turn the live preview off and only wants to see it when they choose to.

All of that considered, it is understandable that having a singular preview button at the bottom of the page would be fine

Personally I would favour using localStorage to treat every user choice as persistent, and then use the options within the gear icon as a way to expose less obvious options, and maybe a more explicit way to manage the stored preferences

It sounds like you only object to having the on by default setting available in the "advanced settings" menu option that is planned in the gear issue. The gear's intent is to make it easier to customize the preview experience. These quick feature toggles all feel like they belong together. It would feel weird to exclude on by default while keeping toggles for the UI elements.

We also have received feedback that the entire decision of including local settings might be contentious when including this feature into Core. I think rolling all these customizations into one feature helps us make a strong argument for its inclusion.

Looks good

Keeping the issue open for future conversations / considerations about finishing 2.1

2.1 was delivered.

Automatically closed - issue fixed for 2 weeks with no activity.