Email editor 2.0 is leaving room for a v2.1

[Grégoire_Miche2]

This post is the last one of a 3 parts series, starting with this one: Testing the email editor 2.0: Great features, a few glitches and the strong need for a v2.1​ and this one: Upgrading to the new email editor 2.0: a recommended migration path

From the tests we have ran, we found out that some of the features where not complete and that some of the key use cases would not be possible yet. This part details the features that still need to be completed or that are yet missing and points to the various ideas to be voted for.

Again, the new editor is a huge progress compared to the previous one. The level of flexibility it now provides makes it an excellent tool that combine user effectiveness, adaptation to business needs and high level of compliance to technical standards.

Nevertheless, from our tests and the doc, we have detected a few additional features that would be welcome and the lack of which limits the usage of the new features. These missing capabilities establish, in our opinion, the basis for a v2.1 that will hopefully come soon after and make the product really complete.

Table of content

The strong misses (must have)

This first set of ideas are still limiting the usage or mitigating the user experience

1. Enable the Search (Ctrl-F) function on the code. See
2. Text version of the email do not support variables, this reduces the possibility to use a variable as a container for text parts of the emails, such as a title. See ​​
3. Content that belongs to template and not to editable zones only render in the HTML version. And yet, it might be necessary in the text version as well. See
4. The new module feature seems very promising, although we have not been able to test it because of a strange limitation: it can be implemented only on a limited set of HTML tags and not on <div>. Our templates use divs as this is the only way to have them support all email clients on all versions of android. ​
5. Manipulating images has made very significant progress. But using them together with tokens is still quite difficult. In fact it means that it is still impossible for the moment to set/change the images in an email with tokens only, without editing it. What a waste of time and a contradiction with the principle of tokens! See:
   • ​
   • ​
   • ​
6. It is impossible to make variables segmentable for dynamic content. In other words, if you use a variable to create a CTA, this CTA will have to be the same for all segments. 
7. As detailed above, it's easy to replace CTA with 2 variables and make it unerring, but it will not be compatible with the module features. Text CTAs would be preferable. See ​.
8. The fact that variables have only 1 global value makes them very limited when combined with clonable modules, as it drives 2 modules to have the same CTA value, the same background image, etc... We really need to have variables to be able to get 1 different value for each module. See ​
9. It is not possible in the 2.0 to have more than one container in a template. Therefore, it is not possible to control in which area of the email which module will go. See
10. Controlling the number of modules that can be inserted in a template would be interesting to control that the modular approach does not turn into a total fantasy. See .
11. In order to make sure that users comply to the corporate guidelines, we could also need to be able to restrict access to some of the functionalities of the Rich text editor toolbar: (Thx Alan Brown )
12. Restrict the List variables values to the list values. See
13. The need for some more advanced support of VML in order to be able to create templates that perform as well on Outlook as on any other client. See ​
14. Making a whole module dynamic in order to provide much more flexibility and reduce the risk for errors.

The features that would be welcome (should have)

This series of ideas would enable to push the usability and functional level a step further

1. Enable the text editor to wrap text instead of horizontal scrolling. See ​
2. Adding a token to a variable is still not convenient, as in LP's: you need to know the token syntax or copy and paste it from another part of Marketo ​
3. It is too easy to add an image which dimensions are not compliant with the way your responsive template is set up, which would cause some issues on some platform. You can force the image dimensions with some new attributes, but it is not a recommended way if you want it to adapt to really all email clients and devices ​
4. Editing the email code is not a right that should be given to anyone. See
5. Variables should display in the order set by the designer, as this order is usually more functionally logical. ​
6. Finding out which email is upgraded and which is not requires to browse each of them one by one. Not convenient. See ​
7. Activating the starter templates is currently an ON/OFF setting in the admin. So either every one can access it or no one. It would be much better to make it more granular through a permission role: ​
8. When setting a variable in a template, if this variable is a number or a string, the user may leave it empty, which would break some of the behaviors in the template. See
9. A series of needs posted elsewhere by Courtney Grimes​ :
   • Would it be possible to offer overriding image thumbs for modules? If not, can we please get modules thumbs to render better? I use a lot of webfonts with fallbacks for emails and it seems Marketo likes to fall back...on sans-serif. Which I know is going to freak a lot of people out.
   • When dropping a module into an email, can the drop hover box scale to fit the bounds of mktoContainer's width? I can see this becoming confusing quickly.
   • For the "mobile" preview, would it be possible to allow for custom width scaling? While I realize 360px is the most common mobile width, it'd be nice to do quick checks without having to run to another email platform.
10. The support for Wistia in the mktoVideo elements. See (Thx c24e95309120f4c42f0a0d024f6c47467e75a070)
11. Better manager of the pre-header, especially in context where we need to make it dynamic. See   and ​ and the possibility to use tokens in the preheader. See
12. The possibility to crop / resize images on the fly from the editor: ​
13. The risk induced by some variable default behavior:
14. The possibility to specify where an image should be stored when loading it from the computer. See ​
15. When creating a template from a template, have the possibility to lock down variables so that future users of the new template cannot change them. ​
16. The possibility to generate HTML5 videos that would be played in clients that support it:​
17. Make the module management in the editor much faster. See
18. And also:
    • ​
    • ​

-Greg

[Frank_Breen2]

Grégoire Michel do you think it is better keeping text out of variables (point 2)? I'm also noticing links are not showing if declared this way too. I looked at the upcoming release and Marketo doesn't seem to be fixing. Should I risk deploying a template with text in variables, on the hope they will fix in a future release? What work arounds have you created?

[Grégoire_Miche2]

Hi Frank,

We are rolling out templates with lots of variables, including for CTA's (text and URL) and warn users that they will have to complete the text version of emails, until Marketo brings in the feature. The value that variables bring in securing the styling of CTA is huge and we do not want to overlook it.

We are also using variables for titles, but not for longer texts.

And we encourage all of them to vote for these ideas

-Greg

[Grégoire_Miche2]

As most of Europeans, we have had the summer'16 release slightly earlier Meaning that we have been able to tests some of the new features over the past hours.

So we have been testing the new features and fixes, and it's all good!

• Module level variables are really great. We can put variables on many places, which makes a huge difference for making sure that the users will not temper with CSS inline code or other tricky things. BTW, the syntax is (not in the doc )
  • For module level variables:

<meta class="mktoString" id="CTALink" mktoName="CTA Link URL" default="http://www.inficiences.com" mktoModuleScope ="True">

• For global variables:

<meta class="mktoColor " id="CTAColor" mktoName="CTA Color" default="#ffa500" mktoModuleScope ="False"> 

• The possibility to make modules optional, rather than always present by default in the template. This was in theory part of the previous release, but a bug was preventing it to work. This is also very cool as designers can now create defaults templates of a reasonable size and propose some options modules
• The control over Image dimensions and styling. Here also, the progress is significant. We can set height only or height and width, and make sure that the user will comply with it and the email won't break if the user uses images of different dimensions.

-Greg

[Anonymous]

mktoModuleScope doesn't seem to work. Is it implemented on the editor already or is it only working on some of the types of variables?

[Grégoire_Miche2]

Seems to be working on all variables for me.

Paste your variable definition code here, we will give a look.

-Greg

[Anonymous]

<meta class="mktoNumber" id="separatorSpacer" mktoName="Top Spacer" default="20" min="1" max="100" units="px" step="1" mktoModuleScope="True" />

The mktoAddByDefault for the modules don't seem to work for me either, unless I'm understanding its use incorrectly. Setting this to false makes the module only show up under the modules tab and not in the default email view, correct?

[Grégoire_Miche2]

Hi My,

I think your instance has simply not been upgraded to summer'16. Release date is the 23rd. EMEA pods are usually upgraded 24h earlier.

-Greg

[Anonymous]

I guess I didn't realize this wasn't released yet since it's in the documentation. It's still the 22nd for me in the US. I'll be patient for a day and see if it starts working

[Anonymous]

Now that I'm in there coding templates using E-mail 2.0, I have a couple of comments.

I'd love to see the option to make a module mandatory, but still allow the user to set a variable, or toggle a Boolean on that module. For instance, restricting the templates so that the e-mail must have a header module, but we can apply a Boolean variable to it to enable or disable a certain style, or a list variable to choose the color. That way, they have to have the heading, but they have some choice in what the appearance of that heading might be like.

Does this make sense to anyone else? I realize you can use the scope to define a variable as global, but that implies, at least from my perspective, that that variable applies to a number of modules/areas.

Also, I'd like to be able to use a single Boolean variable or pick list option to allow the user to apply a number of changes simultaneously so that they're "bound" together. For instance, a pick list variable that would change the colors on the entire template, so that you could have color sets. (So that if templates were virtually identical aside from the colors, that you could manage that aspect of design through these "sets" rather than by managing a number of different templates.)

Finally, I would prefer that the default "true_value" and "false_value" for a Boolean variable be blank rather than "true" or "false", which are values I can't envision applying in my code. There's already been a couple of situations where I've been coding the template and it made sense to make the variable that controlled a part of my template a toggle, but where I wanted one of the values to be blank.

Overall though, I'm pretty happy with how things work.

[Grégoire_Miche2]

Added this one:

-Greg