Email editor 2.0 is leaving room for a v2.1

Grégoire_Miche2 · ‎06-20-2016

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

Enable the Search (Ctrl-F) function on the code. See
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
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
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.
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:
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.
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 .
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
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
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 .
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 )
Restrict the List variables values to the list values. See
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
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

Enable the text editor to wrap text instead of horizontal scrolling. See
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
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
Editing the email code is not a right that should be given to anyone. See
Variables should display in the order set by the designer, as this order is usually more functionally logical.
Finding out which email is upgraded and which is not requires to browse each of them one by one. Not convenient. See
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:
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
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.
The support for Wistia in the mktoVideo elements. See (Thx c24e95309120f4c42f0a0d024f6c47467e75a070)
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
The possibility to crop / resize images on the fly from the editor:
The risk induced by some variable default behavior:
The possibility to specify where an image should be stored when loading it from the computer. See
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.
The possibility to generate HTML5 videos that would be played in clients that support it:
Make the module management in the editor much faster. See
And also:

-Greg