http://www.opensourcery.com/blog/jonathan-hedstrom/creating-html-newsletter contains some hooks that allow users to preview the newsletter's email view on-site, which greatly improves the developer experience.

Needs to be ported to a module patch, currently is in the form of a sub-module.

Comments

miro_dietiker’s picture

Version: 6.x-1.0-rc6 » 6.x-2.x-dev

I'm very interested in improving the preview.
Note that there are still some inconsistencies between foreground and background (cron) send. See
#374222: Template files do not work when using admin theme

I'd like to see this task improved, so please complete this work and contribute!

simon georges’s picture

Status: Needs work » Needs review
StatusFileSize
new1.88 KB

Please find attached a patch implementing exactly what is in the article mentioned above :
- new button "Preview newsletter"
- new preview function using simplenews-newsletter-body.tpl.php

Should I add the footer template as well ?

miro_dietiker’s picture

Just from reading the patch:
How will the Preview show? I thought they where asking for a popup window preview.

We should build the preview anonymously (see the userswitch in send method) to hide admin html/css output

How will it display now? I thought we'll miss the actions to complete save/sending now on preview.... so workflows seem broken to me.

Am i missing something?

miro_dietiker’s picture

Status: Needs review » Needs work

Pls update

simon georges’s picture

Right, I see your point. I'll try to rework that a little bit. I'll get back to you.

miro_dietiker’s picture

Instead of cluttering the page more and more we could also think about this
#781708: Move simplenews node actions into Tab

This might split the process cleaner.
Create, edit, save, preview ... on the regular node page.

And send separately.

We can then provide a clean action "send" method that is completely decoupled from the nodeapi instead of identifying a save button in case of a regular form save...

(
Although test send is somehow related to preview... hmm...
I think we should stay open for better solutions here...
)

Just some quick thoughts ;-)

miro_dietiker’s picture

Simon: In case of a popup or overlay i'm perfectly fine with a preview that is missing any button -- just to be closed after review.

Technically what i'd expect is
- a callback handler for preview
- a popup or overlay/w/iframe to show the newsletter in its own design
-- if the button has a js action only, it should be created by js only. i don't know if we can implement a non-js workflow that works without breaking save process cleanly and displays correctly...
- as said, temporary anonymous user switch (there was an issue where i implemented this)

As simple this sounds, it opens a can of worms. ;-)

simon georges’s picture

Well, an overlay / javascript only action would break accessibility, so I'm not in favor of that.
We have to switch the user only for generating the preview, keep the user in session identified, so everything during the process of validating / saving the node goes smoothly.

Anyway, you're right, it needs some deeper thinking than my little patch above ;) Maybe for 7.x ? Or not for the first 6.x-2.x release, what do you think... ? Maybe make a poll above what user need, or consult with a UX expert ? You're right, it's a can of worms ;)

simon georges’s picture

StatusFileSize
new2.31 KB

New patch adding the anonymous user switch.

I'm still thinking about the overlay.

miro_dietiker’s picture

Note that overlays could be made accessible these days.

Referring to WCAG 2.0 // WAI Standard:
http://www.w3.org/WAI/

simon georges’s picture

Thanks for the input, I'll take a look when I have more time.

simon georges’s picture

Version: 6.x-2.x-dev » 7.x-1.x-dev

What about having that in 7.x-1.x?

Everett Zufelt’s picture

I know nothing about this issue or module. I will state that it is incredibly difficult, borderline impossible, to make overlays accessible, particularly if they are modal.

miro_dietiker’s picture

Still they're popular ... We could even open it in a separate window instead an overlay.

The patch above is not enough in my opinion.
A newsletter can have its own rendering and outer HTML design. It also can have an independent mail.css.
A real preview should show exactly the result that is finally presented to the mail application, not the node body/content only.

This needs some redefinition of rendering as currently the design wrapping is implemented by the module like mimemail and not simplenews itself.
I think simplenews should implement it consistently itself.

miro_dietiker’s picture

Version: 7.x-1.x-dev » 8.x-1.x-dev
Issue summary: View changes
Issue tags: +8.x release target

Promoting this to 8.x for a release target.

miro_dietiker’s picture

The recently started project Inmail introduces a parser for messages. The plan is also still to outsource its parser into a library at some point.

Unsure if previewing here is previewing just the body (plain web rendering) or if it's previewing the full rendered mail.
If it's the mail, then we would add inmail to parse the message.
Inmail is also supposed to offer a reusable mail display UI - at least we will start development there. (thus postponing this issue on it)
See issue in Collect: #2419209: Reusable email display UI