I am using NLS on an extranet for a corporate who's staff base is almost entirely on Microsoft Outlook 2016 for Windows.
I have a vanilla install of NLS (at v3.0.3) set up for them to test with no modifications and have built a simple test email using the NLS campaign composer UI. This seems to display well in browser and mobile based email clients and for me when receiving/rendering in Outlook for Mac however, numerous things render incorrectly when received/viewed in Outlook 2016 by the client and their staff, for example:
Images which are not manually downsized using the NLS image width
slider are displayed at sizes larger than their containing row/table
cell (presumably their actual size)
Whitespace/padding is seen
between each row of the email content
Some rows don't grow to the
standard (without 'Full width' checkbox applied) width if they don't
have enough content, so content which should be left/right aligned
ends up centred with the row and it's background not extending to the
edges of the standard content area
Having looked at the email.cshtml template and the generated/delivered HTML, I can see notable consideration is being given to MS Outlook via various IE/MSO conditional CSS and markup, so I assume that rendering well in Outlook is well on the NLS radar.
Any idea why I might be seeing issues with a standard install rendering in Outlook 2016? Is that an Outlook version that is explicitly not supported?
First of all, Outlook is the "internet explorer of emails" so getting things to look great in Outlook (especially older versions) means that one has to compromise with the appearance in all modern clients (responsiveness, use table layouts and so on).
Our approach here has been to try to make the experience in older Outlook versions acceptable but pixel perfection has never been the goal.
Some features (e.g full width rows and background images) are almost impossible to get perfect in Outlook, so if one targets Outlook I would recommend avoiding these features in the emails.
We test mainly on modern versions of Outlook (think versions shipped with Office 365) and the most popular email clients on the market. We don't have any official support for Outlook 2016 but it would be interesting to try to narrow this down and see if we can make your experience a little better. I will try to schedule some time to digg deeper into this. I would very much like to see exactly how your email look - would it be possible to send a screenshot to markus [at sign here] enkelmedia.se?
There is always the option to create a custom theme where you have control over the rendered HTML. This way you can override whatever part you like to make the email render good in the client that you're targeting. Maybe this is something that you can play with if this is something urgent on your side.
I think I have established that a number of these rendering issues were caused by copying an pasting content with additional hidden formatting from, for example, MS Word, into the RTE's in the email builder. This was adding extra classes and mark up that we weren't expecting.
The one outstanding Outlook 2016 issue I am trying to resolve is image sizing of images inserted via the NLS Image component.
From my testing, it seems that any image inserted in this way (even those at the perfect dimensions (e.g. 1 Col - 580px, 2 Col - 280px and 4 Col - 130px wide) display larger than this in Outlook 2016 when the image size slider is left at it's default of 'Full'. They display as expected when this slider is set to any fixed value e.g. 579px.
Image Displays As Expected in Outlook 2016
Image Too Big in Outlook 2016
(even if source image used is only 280px wide)
I can see from Views/Controls/Image.cshtml that the difference between these two settings is a fixed pixel based width being used for both CSS width and <img width="" /> (the prior) vs a percentage based (100%) width when the default of 'Full' is used (the latter):
var width = img.ImageIsMaxWidth ? "100%" : img.ImageWidth.ToString();
var styleWidth = img.ImageIsMaxWidth ? "100%" : img.ImageWidth + "px !important";
To attempt to resolve this for Outlook 2016, I was hoping to to overload Image.cshtml and if needed Email.cshtml in order to set the width to 580px, 280px or 130px (based on the no. of cols in the parent row) in scenarios where img.ImageIsMaxWidth was true
However, in Image.cshtml there is no context to determine whether this image is to be displayed in a column with a width of 100% (1 Col), 50% (2 Cols) or 25% (4 Cols).
I'm thinking it would therefore be necessary to pass this context into this template as part of the RenderPartial call in Email.cshtml passing in the parent rows column count either in the view model or as view data etc in the below:
However, I am unable to alter the defined structure of ControlWithEmailViewModel and the RenderPartial method is NLS specific, so unline the inbuilt Umbraco Partial() and CachedPartial() methods, doesn't seem to take additional params which include aViewDataDictionary option.
Do you have any thoughts on the ease/suitability of using one of these approaches, or any alternative solutions I might be able to employ to resolve this? Given our company IT enforced reliance on Outlook 2016, at the moment the only work around is to have the email creators manually adjust this slider to -1px off the full width to ensure a hardcoded px value is assigned instead of 100%.
Thanks for reporting this and for providing your findings! I'm wondering, will you only send to recipients with Outlook 2016 or do you need support for other clients as well? (Just so I know).
I've played around with rendering in Outlook 2016 (O16) for a couple of hours now. First of all, it seems like O16 does not like div-elements. We're using some of them but in some scenarios, O16 will let a div grow to 100% of its content no matter if it's inside a table with explicit width.
Here I removed the wrapping div, I'm quite sure that there is a reason why the div was there in the first place but this avoids the "100% of its content"-problem with the text blocks.
@if (Model.Model is NewsletterStudio.Core.Editor.Controls.Text.TextEmailControlViewModel model)
{
@Html.Raw(model.Html)
}
Another option to keep this for other clients could be
This is the file you are referring to. We're using a custom way to render cshtml since it also needs to work in background jobs or in background threads so it's not a "full-blown mvc"-razor. It would probably be possible (and a good idea) for us to pass down the current column to the view but the fact is that img.ImageWidth is set to the value that you're looking for.
So changing
var width = img.ImageIsMaxWidth ? "100%" : img.ImageWidth.ToString();
to
var width = img.ImageWidth.ToString();
Would output the number of pixels for the full-width version. At the moment I'm not sure why we used 100% but there is probably a reason =D I will need to perform some more testing in other clients before I know for sure.
If you still need access to the column information there is a hack that you could use until we find a way to pass this down with the view model.
This code inside any control-view could get the current column.
var allColumns = Model.Email.Rows.SelectMany(x=>x.Columns).ToList();
var thisColumn = allColumns.Where(x => x.Controls.Any(b => (object)b == Model.Model)).FirstOrDefault();
Another solution could be to create a class that inherits from ControlWithEmailViewModel, add a property for the column and pass this down to the control-view from the code you had in your screenshot. This would however also require you to override email.cshtml.
One thing that I've noticed during my testing and that is really strange is that Outlook 2016 will render the same email differently when I open and close the message a couple of times.
Here I'm opening the same message, the first time the content is a lot wider then the 600px it should be, the 2nd time it aligns correctly within the 600px boundary.
I'm hoping that this illustrates the challenge with trying to support this client. Please try the different approaches above and let me know how this works for you. Depending on your feedback I'll try to include some of the fixes in the package in upcoming releases if it does not have a negative impact on other more modern and popular clients.
I hadn't realised that img.ImageWidth would contain the appropriate max width giving consideration to the column layout the image was in already (I thought it would be the source image width), so that caters for what I was looking for.
I have duplicated Image.cshtml to create an overloaded version for my theme and changed the lines at the top to:
var width = img.ImageWidth.ToString();
var styleWidth = img.ImageWidth.ToString() + "px !important";
This solves the issue for me on Outlook 2016 (desktop layout).
The one slight downside, and the reason you'll have been using 100% in the first place (given it works fine for any compliant email client), is that the smaller images (those used in 2 or 4 column layouts) no longer expand to full width/their source image size when shown on mobiles with the row configured to 'Stack on smaller screens'. For example:
Original Outcome
Images grow when stacked on smaller screens
New Outcome
Images remain at their fixed size when stacked on smaller screens
This is entirely expected I and is less of an issue than the original issue we were looking to solve. Whilst we still have to support Outlook 2016 in my context, I will stick with this as a fix.
Outlook 2016 Rendering Issues in v3.0.3
I am using NLS on an extranet for a corporate who's staff base is almost entirely on Microsoft Outlook 2016 for Windows.
I have a vanilla install of NLS (at v3.0.3) set up for them to test with no modifications and have built a simple test email using the NLS campaign composer UI. This seems to display well in browser and mobile based email clients and for me when receiving/rendering in Outlook for Mac however, numerous things render incorrectly when received/viewed in Outlook 2016 by the client and their staff, for example:
Having looked at the email.cshtml template and the generated/delivered HTML, I can see notable consideration is being given to MS Outlook via various IE/MSO conditional CSS and markup, so I assume that rendering well in Outlook is well on the NLS radar.
Any idea why I might be seeing issues with a standard install rendering in Outlook 2016? Is that an Outlook version that is explicitly not supported?
Hi Joe!
First of all, Outlook is the "internet explorer of emails" so getting things to look great in Outlook (especially older versions) means that one has to compromise with the appearance in all modern clients (responsiveness, use table layouts and so on).
Our approach here has been to try to make the experience in older Outlook versions acceptable but pixel perfection has never been the goal.
Some features (e.g full width rows and background images) are almost impossible to get perfect in Outlook, so if one targets Outlook I would recommend avoiding these features in the emails.
We test mainly on modern versions of Outlook (think versions shipped with Office 365) and the most popular email clients on the market. We don't have any official support for Outlook 2016 but it would be interesting to try to narrow this down and see if we can make your experience a little better. I will try to schedule some time to digg deeper into this. I would very much like to see exactly how your email look - would it be possible to send a screenshot to markus [at sign here] enkelmedia.se?
There is always the option to create a custom theme where you have control over the rendered HTML. This way you can override whatever part you like to make the email render good in the client that you're targeting. Maybe this is something that you can play with if this is something urgent on your side.
Cheers!
Hi Markus,
I think I have established that a number of these rendering issues were caused by copying an pasting content with additional hidden formatting from, for example, MS Word, into the RTE's in the email builder. This was adding extra classes and mark up that we weren't expecting.
The one outstanding Outlook 2016 issue I am trying to resolve is image sizing of images inserted via the NLS Image component.
From my testing, it seems that any image inserted in this way (even those at the perfect dimensions (e.g. 1 Col - 580px, 2 Col - 280px and 4 Col - 130px wide) display larger than this in Outlook 2016 when the image size slider is left at it's default of 'Full'. They display as expected when this slider is set to any fixed value e.g. 579px.
Image Displays As Expected in Outlook 2016
Image Too Big in Outlook 2016 (even if source image used is only 280px wide)
I can see from
Views/Controls/Image.cshtmlthat the difference between these two settings is a fixed pixel based width being used for both CSS width and<img width="" />(the prior) vs a percentage based (100%) width when the default of 'Full' is used (the latter):To attempt to resolve this for Outlook 2016, I was hoping to to overload
Image.cshtmland if neededEmail.cshtmlin order to set the width to 580px, 280px or 130px (based on the no. of cols in the parent row) in scenarios whereimg.ImageIsMaxWidthwastrueHowever, in
Image.cshtmlthere is no context to determine whether this image is to be displayed in a column with a width of 100% (1 Col), 50% (2 Cols) or 25% (4 Cols).I'm thinking it would therefore be necessary to pass this context into this template as part of the
RenderPartialcall inEmail.cshtmlpassing in the parent rows column count either in the view model or as view data etc in the below:However, I am unable to alter the defined structure of
ControlWithEmailViewModeland theRenderPartialmethod is NLS specific, so unline the inbuilt UmbracoPartial()andCachedPartial()methods, doesn't seem to take additional params which include aViewDataDictionaryoption.Do you have any thoughts on the ease/suitability of using one of these approaches, or any alternative solutions I might be able to employ to resolve this? Given our company IT enforced reliance on Outlook 2016, at the moment the only work around is to have the email creators manually adjust this slider to -1px off the full width to ensure a hardcoded px value is assigned instead of 100%.
Hi!
Thanks for reporting this and for providing your findings! I'm wondering, will you only send to recipients with Outlook 2016 or do you need support for other clients as well? (Just so I know).
I've played around with rendering in Outlook 2016 (O16) for a couple of hours now. First of all, it seems like O16 does not like div-elements. We're using some of them but in some scenarios, O16 will let a div grow to 100% of its content no matter if it's inside a table with explicit width.
I tried a couple of things that made the experience better in O16. I'll outline the changes I've made here and paste my new code. As I think you know you can apply them by overriding views in a custom theme: https://www.newsletterstudio.org/documentation/package/4.0.0/concepts/themes/
Controls/Text.cshtml
Here I removed the wrapping div, I'm quite sure that there is a reason why the div was there in the first place but this avoids the "100% of its content"-problem with the text blocks.
Another option to keep this for other clients could be
Controls/Image.cshtml
This is the file you are referring to. We're using a custom way to render cshtml since it also needs to work in background jobs or in background threads so it's not a "full-blown mvc"-razor. It would probably be possible (and a good idea) for us to pass down the current column to the view but the fact is that
img.ImageWidthis set to the value that you're looking for.So changing
to
Would output the number of pixels for the full-width version. At the moment I'm not sure why we used 100% but there is probably a reason =D I will need to perform some more testing in other clients before I know for sure.
If you still need access to the column information there is a hack that you could use until we find a way to pass this down with the view model.
This code inside any control-view could get the current column.
Another solution could be to create a class that inherits from ControlWithEmailViewModel, add a property for the column and pass this down to the control-view from the code you had in your screenshot. This would however also require you to override
email.cshtml.One thing that I've noticed during my testing and that is really strange is that Outlook 2016 will render the same email differently when I open and close the message a couple of times.
Here I'm opening the same message, the first time the content is a lot wider then the 600px it should be, the 2nd time it aligns correctly within the 600px boundary.
I'm hoping that this illustrates the challenge with trying to support this client. Please try the different approaches above and let me know how this works for you. Depending on your feedback I'll try to include some of the fixes in the package in upcoming releases if it does not have a negative impact on other more modern and popular clients.
All the best!
Hi Markus,
Thanks for the above investigations and ideas.
I hadn't realised that
img.ImageWidthwould contain the appropriate max width giving consideration to the column layout the image was in already (I thought it would be the source image width), so that caters for what I was looking for.I have duplicated
Image.cshtmlto create an overloaded version for my theme and changed the lines at the top to:This solves the issue for me on Outlook 2016 (desktop layout).
The one slight downside, and the reason you'll have been using 100% in the first place (given it works fine for any compliant email client), is that the smaller images (those used in 2 or 4 column layouts) no longer expand to full width/their source image size when shown on mobiles with the row configured to 'Stack on smaller screens'. For example:
Original Outcome
Images grow when stacked on smaller screens
New Outcome
Images remain at their fixed size when stacked on smaller screens
This is entirely expected I and is less of an issue than the original issue we were looking to solve. Whilst we still have to support Outlook 2016 in my context, I will stick with this as a fix.
Cheers,
HARVS1789UK
is working on a reply...