Closed Bug 770739 Opened 12 years ago Closed 10 years ago

Preview interface is confusing

Categories

(developer.mozilla.org Graveyard :: Wiki pages, defect, P2)

x86_64
Linux
defect

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: openjck, Unassigned)

Details

A user remarked that she was confused by the "Preview Changes" interface. She did not like that the button opened a preview in a new tab -- because of this, she became lost and had a hard time finding her way back to the page that she was editing.
What are your thoughts here, sheppy?
That's an interesting observation. I'm not sure how else to do it though. Could the preview be injected into the same page somehow, possibly collapsible to tuck it out of the way to get back at the editor?
Luke's original implementation was putting the rendered content underneath the editor.
Under the editor, you don't see it unless you know to scroll down.

Maybe actually hide the editor and replace it with the preview, but with a "close preview" button, and being sure to keep all the save buttons across the top?
The thing I don't like about that is if you see an issue, you have to hide the preview, look at your WYSIWYG content, say "Wait, where was that again?", click "Preview" again, and so on.  What I like about dual tabs (present implementation) is you can switch between the two tabs quickly, always able to check back.

Each "preview" action is an AJAX request to the server (to clean content, reformat stuff, etc).
FWIW, I really like the approach MediaWiki takes: The preview button updates the page such that the rendered preview appears at the top and the WYSIWYG appears directly below that. This makes it easy to compare the markup to the rendered output and re-preview as necessary. 

http://i.imgur.com/EgC8x.png

It could definitely get better, but I think it's a pretty solid approach for now. If nothing else, it's more conventional. Most Wikis I use do this, but only WordPress (AFAIK) uses the two-tab approach.
Priority: -- → P2
I think putting the content above the WYSIWYG counter-acts what sheppy said -- they user would go "where the heck did my editor go?"  What if we we made that interface look kinda like the translation interface, where you click "preview" and see the content side-by-side?
I'd rather lightbox the preview. It's not live-updating, so why display it and the editor both usable at the same time? Just dim the editor and put up a scrollable box with the preview with a "dismiss" button.
I wonder if our preview feature is as valuable as we think it is. The feature makes sense for MediaWiki -- they have a pretty obtuse formatting language, so there is no way for an author to know what an article will look like until it's rendered.

On the other hand, we have a fantastic WYSIWYG that provides a nearly pixel-perfect representation of the final result. Yes, certain things do not render in the WYSIWYG (like templates), but that's not to say they couldn't.

To put it another way, does Google Docs need a preview feature?

This might be something to talk to the user experience team about. There are many options -- what we have now, side-by-side, lightbox, improved WYSIWYG, and more. I would be interested in what ideas they have.
Preview feature is definitely needed because of templates
(In reply to John Karahalis [:openjck] from comment #9)
> I wonder if our preview feature is as valuable as we think it is. The
> feature makes sense for MediaWiki -- they have a pretty obtuse formatting
> language, so there is no way for an author to know what an article will look
> like until it's rendered.
> 
> On the other hand, we have a fantastic WYSIWYG that provides a nearly
> pixel-perfect representation of the final result. Yes, certain things do not
> render in the WYSIWYG (like templates), but that's not to say they couldn't.
> 
> To put it another way, does Google Docs need a preview feature?
> 
> This might be something to talk to the user experience team about. There are
> many options -- what we have now, side-by-side, lightbox, improved WYSIWYG,
> and more. I would be interested in what ideas they have.

We do absolutely need the preview feature. Just for templates, it's totally needed. It was one of the most-requested features back in the MindTouch days. Plus the CSS in the editor is not an exact match for the viewing mode.
Understood. But again, what if templates were rendered in the WYSIWYG? What if the style applied in the WYSIWYG was closer to the style applied to the final page. We actually have bug 782842 for the latter.

It seems redundant to have two preview features -- one that provides a nearly pixel-perfect representation of the final result (the WYSIWYG) and one that does the same thing but also renders templates and applies more accurate styles. Why not just do those things in the WYSIWYG?

I know this goes against the grain, but that's what I do. I don't think I have the final answer, but I love trying to solve problems by asking hard questions.
How could you possibly render the templates in the WYSIWYG when you have to type them unrendered? That's a really odd idea; I don't see how it could work.
Rendering templates in the WYSIWYG is not going to happen;  each keystroke would send a server request for template processing, slowing the entire editing process down immensely.
(In reply to Eric Shepherd [:sheppy] from comment #13)
> How could you possibly render the templates in the WYSIWYG when you have to
> type them unrendered? That's a really odd idea; I don't see how it could
> work.

There are a few different ways we could do this. For example, we could have authors write templates in source view but have those templates render in the display view.

I think we all agree on the key points: the edit button (and associated edit-preview-edit workflow) is the most sensible thing to continue for now, it would be valuable to have a true preview in the WYSIWYG, and it would be very difficult to have a true preview in the WYSWIYG.

I guess my difference of opinion is that I feel a true preview in the WYSIWYG could be possible, and that if we did have this we might not need the edit button. But like I said, that's more of a blue sky idea. Not something we need to or should do right now.
s/edit button/preview button/
Your idea of having to write templates in source view would kill their usefulness in one fell stroke. Non-starter. Sorry. :)
Version: Kuma → unspecified
Component: Website → Landing pages
I'd say either lightbox the preview or just leave it as-is.
Whiteboard: u= c= s= p=
This needs discussion. As we don't have a concrete plan here, I'll go ahead and close the bug.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.