Expected a realistic preview of changes.

This is something that has bugged me for a while.

I worked early on, on the development of SubHub Lite, which is a hosted content publishing service based on Drupal 7. Their content preview works really well, opening up in a new tab / window. I have attached a screenshot of how this appears.

It would be great to see how something like this tests.

The node preview functionality is something I would really like to help out with for D8.

Well, I'd say get to work! :) Seems like the solution here is pretty clear, we might discuss somewhat how it gets opened - but other than that - we want a preview.

There are three real options of how it gets opened. Each have their pros and cons.

1) Open in a new tab / window
Pros - Displays the page as it would be to the end user, keeps the node form page untouched.
Cons - Different reactions for different browsers (tab or window), user may loose the preview or node form page

2) Open in modal window / lightbox / overlay
Pros - clear where the content preview is and where the node form is, known action from the rest of the drupal admin interface
Cons - content will not look the same as it will on the live site mainly due to a different viewport, could cause an overlay over an overlay.

3) Open in current tab / window
Pros - Displays the page as it would be to the end user, obvious where the user is, browser back button would work
Cons - User could feel they have lost the node form page, and feel they have lost their content.

These are all worth discussing and testing.

Personally I would say 3 is my first choice, then 1, then 2, but an experienced UXer or Designer, may disagree.

Just posting a question to try and understand this a bit better - do you think users see "preview" as a workflow state - a sort of "saved but not published" interim step to being fully published?

No, I think preview is just a "check everything looks alright in the front end theme, formatting of text, formatting of images, how it fits with the rest of the site blocks and menus.

I think Drupal 8 should also remove the "save" button, replacing it with a "Publish" and a "Save as draft" button.

Wordpress does it by opening a new tab. It does not provide any hint that this is not yet published nor does it provide a means to get back to your edit form. This would be hard anyway in a new tab since it is browser-dependent and i guess you cannot implement a secure way changing to another browser tab. But if we go for a new tab, we could implement an info message, so it is clear to the user he is seeing a preview:

From the instinct, i would tend to use an overlay over the overlay, and maybe limit the height and rather include a scrollbar and as well limit the width with say 85% of the overlay itself. But it is true this is not an easy one and every solution has got its drawback. But I would see two main factors to be kept in mind to help find the best solution (apart from the preview being a real and complete preview):

1. How can I get back easily and safely to my edit page? No data loss nor fear of data loss.
2. Am I clear that this is a preview I am looking at? Even if I clicked a "Preview" button I might be insecure and suspect I have clicked the wrong button, or fear I have broken something or inadvertedly saved when I only wanted to preview.

If it was an overlay over the overlay, it could look like this:

I'd say option 3, open in current window while clearly stating it's a preview page and displaying a back-to-edit link in the upper-left (right for rtl) corner. This is what we do for demonstrating block regions right now.

Should be possible as we can store edit's form state. The back-to-edit link could hold the form state ID, while using browser's back-button should already work (Except for IE: #153313: ckeditor input is lost when using the browser's back button and #655388: Many ways to lose data on form input in the overlay).

An issue might be that users click on links (on the preview page) that don't return to the edit form, resulting in loss of their input. We might be able to render all links with an empty href or a target attribute. Or add some Javascript preventing links to work.

And in case overlay is enabled (the edit form would then be inside the overlay) temporarily close the overlay. Like block region demo.

I really don't like the idea of the preview in an overlay. I don't think it gives a clear enough indication of how the page will look.

One thought is if previews should use revisions and actually save the content. Currently Drupal has a published or unpublished state, what if it has an editing state too. So when you are creating content, it could periodically save the content with the editing state, when clicking preview it will also save a copy of the content in the editing state, but display it, using revisions it would be possible to edit, save and preview a new version of some existing content. Also if the browser were to crash, it would also have stored an editing version of the content as a revision to go back to.

This is a lot more complex solution, but saving the content to the database, as a revision or not, seems to be a sensible option for previews, rather than using sessions.

@timmillwood this is sort of what I was driving at before when I asked about workflows, to just save the node when the user clicks preview and pop them though to the front end - this could be a bit clunky though, having to click Edit again to to keep working and could be confusing (is my node saved, is it published etc etc).

In the overlay is a bit mad, there's no way of knowing if it will even fit, if its in the right context (if its not saved, how can we know this), it introduces a tonne of theming issues because Overlay and the admin theme both have CSS that cast a heavy influence.

Jeff,

I think it could be made not so clunky by changing the Drupal save / publish / preview / edit.

When clicking preview I think it should save the node, but not as published or as unpublished, but a third state. Then when the user is taken to the front end to view the page it needs to be clear that "this is a preview, here's how you get back to the form". I'm not even sure the view / edit tabs should even show on the preview.

Another interesting concept is things like block and menus, how will they show in the preview, and will the menus show links to the content you are previewing with the correct active state, and will relevant blocks show the data from the content you are previewing.

Regarding the 3 preview options, I'd put out there that using an IFRAME is a 4th option, which is what Page preview module does. That avoids the "overlay on top of overlay" confusion and the "Hey, where's my edit form?" problem.

The viewport size would still be an issue. When developing Page preview, I decided that the higher priority was to avoid adding new interaction patterns to the content creation workflow, whether it's new window/tabs or intermediate preview pages.

All options provide many ways to throw people off. That's why we'll design and build and test it :)
You want the preview ux to be as 'real' as possible, so option 3 is the guiding principle for any variations we explore.

It would really help if #3 was specked out a bit more, its not very clear what the concept is or how it would work, what it would look like etc.

Maybe it'd be worth me doing a story board of how option three would work.

Watch this space!

Also: #1164756: With short content, two seemingly-identical previews are presented. which should work towards having only 1 preview style visible at the time.

timmillwood, did you ever get around to sketching some stuff out here?

Related issue (and possible duplicate): #1510544: Allow to preview content in an actual live environment

Marking as duplicate