07-12-2018 11:47 PM
I will attempt and experiment with uploading custom HTML templates tomorrow. I will share my results afterwards.
I am presently in the middle of analyzing the code generated by the template tool, I am astonished by several things I see in it, from the use of divs as an alternative to paragraph tags to actually including a stylesheet- Nearly all e-mail marketing campaign services have warnings in their support section that says that including a stylesheet instead of inline css is a big no-no for how incompatible it is with some mail clients. For clarification, we are using one of your responsive templates.
I have not even gotten us to using multiple senders yet, when we send the test e-mail the template tool always takes our Times New Roman and randomizes it between Times New Roman and at least three other fonts.
This stands out to me: (Cleaned up a little because of it being a single omniline)
(From stylesheet section:
font-size: 1em !important;
font-size: 1.375em !important;
font-size: 1.500em !important;
font-size: 1.083em !important;
font-size: 1.333em !important;
font-size: 2em !important;
(from HTML section)
style="margin: 0px; padding: 0px; text-align: left !important; color: rgb(0, 0, 0); line-height: 120%; font-family: TimesNewRoman,; font-size: 18px; text-size-adjust: 100%;"> <span class="sp_h4"
style="color: rgb(0, 0, 0); line-height: 120%; font-family: TimesNewRoman,;"
=""> <span class="sp_h6"
style="line-height: 120%; font-size: 18px;"> <span style="font-family: TimesNewRoman, Times New Roman, Times, Baskerville, Georgia, serif;">
<br>(contents of paragraph 1)</span></span></span></div> <div align="left"
style="margin: 0px; padding: 0px; text-align: left !important; color: rgb(0, 0, 0); line-height: 120%; font-family: TimesNewRoman,; font-size: 18px; text-size-adjust: 100%;"><span style="color: rgb(0, 0, 0); font-family: TimesNewRoman,;"
(Contents of Paragraph 3)</span></div>
Result: First paragraph is Times New Roman, pt 14, third paragraph is some san serif font at point 18.
So... All of this began life as a single page highlighted and set to Times New Roman, point 18. The first paragraph refused to take the font size, so it was applied twice, hence first paragraph is wrapped in... three elements? So far, so weird. Now it should all be set to Times New Roman, point 18, right? Wrong. As you can see in the code, a number of them are set to "TimesNewRoman", not "Times New Roman". There is no "TimesNewRoman" font, which results in an error followed by substituting a mail client default font such as Arial, Courier New, Lucida Sans Unicode, etc. (Also note you have a per element line height, which I have been told this tool does not support.)
Now, you'll notice a few things to do with font sizes: You have nested elements with the font size measured in EMs (a relative unit) and !important set, to ensure it overrides it's container rules. This creates a weird situation where the child ems are supposed to be bigger than their parents, but depending on how something handles the collision of relative sizes, it will simply randomly allocate font size based on the order of operations in that browser/mail client. Then, insult to injury, you have inline font settings, because of the !important flag those will always be ignored. Is this specific to your Mobile friendly template?
The sp_h6 style is actually very odd in itself- nowhere in the editor is there a place to set heading text, only font size. If I can't specify something is a paragraph or an H1 or H2, why is there an sp_h1 style? This makes no sense and feels like something that you removed from the menu and forgot to remove from the code.
Next up, can someone explain why there is a parameterless argument at the end of over half the tags in that source? In case you missed it, repeat for emphasis:
<span class="sp_h4" style="color: rgb(0, 0, 0); line-height: 120%; font-family: TimesNewRoman,;" ="">
That ="" before the end of the tag. Where's the rest of that? Malformed parameters like that should not be generated under any circumstance.
For reference, this is what I expect to be generated when I have 3 paragraphs and I select Times new Roman, point 18.
<p style="font-family: 'Times New Roman', Times; font-size: 18pt">Contents of First Paragraph</p> <p style="font-family: 'Times New Roman', Times; font-size: 18pt">Contents of Second Paragraph</p> <p style="font-family: 'Times New Roman', Times; font-size: 18pt">Contents of Third Paragraph</p>
I could see an argument for including margin: 10px, but that starts to get into the art side of things. I think that demonstrates the difference between what your tool is generating and what it should be generating.
Carl, I hope that didn't come off as condescending. These are just frustratingly obvious flaws in the editor and my client is very angry at having paid money for this service last month only to miss the deadline for sending out his July newsletter by two weeks because these bugs keep turning his newsletter into a childish looking mess. He pays me to make sure these things don't go wrong, and now I'm looking at a problem I can't fix because it is specifically caused by flaws in the template editor. Additionally, we are both very angry at the moment as another Carl (You?) at tech support told him that he was manually setting some of the paragraphs to Lucida Sans Unicode and that he shouldn't expect fonts to display uniformly if he is changing them. I believe I demonstrated above that this is NOT the case.
As a random aside, there is an annoyance with the editor in that the editor toolbar appears to be attached to the top of whatever template area is currently selected. I would suggest changing this from Position: Absolute to Position: Sticky. This would allow it to follow the top of the window down the page in the event that your template region is taller than the visible window. Minor annoyance in the grand scheme of things, but when you have to scroll up and down to format things like italicizing quotes, it amplifies the frustration.
07-13-2018 12:10 AM
Do I ever feel your pain and that of your client!!!
Quite honestly, my frustration comes from the things we have both seen ... without doubt; but beyond that ... I have used many versions of ACT over the years with no complaints. SO making an upgrade to a version that would allow us to keep our data on our machine(s) and drop Constant Contact at the same time, it seemed like a no-brainer.
Then, as with you folks, the pain set in. I thought I had the best answer possible from a conceptual view; but whoever implemented this sorry mess clearly had no in-depth talent and the tech support knows less than we do about "HOW" the features should work!
You clearly understand the "code"behind the templates and I would be surprised to learn you do not now the specific differences between using blocks and rows; but I have to ask ... solely because it made a HUGE difference in the control of nearly everything I was trying to layout originally because I had not paid attention to the "differences."
Just curious and aching for you ... greatly,
07-13-2018 01:09 AM - edited 07-13-2018 01:15 AM
I haven't inspected the nuts and bolts of how this tool handles Rows and Blocks, but there are multiple ways they could be executed as they are loosely based on html tables. It seems to me like they started with that as their foundation, then someone wisely recognized the need to simplify as even the best of us can easily lose control and have a hard time understanding Tables- the average person has little to no chance. Generally speaking, you end up with some combination of the following... I'll try to simplify it a little using bullets, I'm not sure how familiar you are with HTML, so I'll spare you the pseudocode. (I can provide it if it'd help! Also, this is sort of a "minimum needed" graph, the template editor tends to use multiple things it doesn't need, so it likely is several orders of magnitude deeper without any actual gain.)
When we added some of our formatting with Date and Sender up, we ended up needing to split a row into two to separate the Date from Sender data. To do that, I ended up adding a Row that had an image Block (1/3rd width) and a text block (2/3rds width), to do that I ended up adding one of their prebuilt rows with an image block and a text block, and then selecting the image block, adding a text block, then deleting the image block. As far as I could tell, right before deleting the image block, we ended up with...
There's a couple ways it could be structured in code, but based on how it collapsed, that's my best guess. I would have to E-mail it and then look at the source of the e-mail. In all likelihood, it is a convoluted mess of nested elements where each of those is at least three objects with nothing else inside... and it could generate differently if we started with a different template.
Does that line up with your observations? I didn't find them that confusing, but I also spent more time than I probably should have mastering the weird quirks of tables back in the early 90's.
Edit: Thinking about it, probably one of the reasons they seem confusing is that while they act like tables, they're actually divs, so technically it's all just blocks nested in blocks with the template editor pretending to treat them differently.
07-13-2018 07:41 AM
It looks (reads) like we have traveled some similar paths in our past. :-)
Your observations on Blocks and Rows is quite accurate and the understanding you have of the code "beneath" the template is definitely way beyond the average user!
My discovery, thanks to the VP who was once willing to help and educate me, was simply that the ability to control spacing and margins was much more accurate - and uniform - with Blocks rather than Rows.
I can also imagine that your technical knowledge re HTML, Tables and Divs both enables and infuriates you as you look at the "design" (if there is one) that supports a template.
I gotta take my four-legged baby to the vet. Her end is nigh and she needs some drugs to quell body-wrenching, traumatic coughing (bronchitis?) I must run.
I wish we had someone with technical skills AT/IN Swiftpage, who could actually make things happen AS WE KNOW THEY SHOULD. Alas, I feel we are stuck with workarounds because I have not seen or heard from anyone like that! :-(
My best to you, today, Shawn ... and have a great weekend - in spite of this aggravating mess.