e6615dd679b5dd0c3e60c20085706f392a9af2cb

Email editor 2.0 is leaving room for a v2.1

Blog Post created by e6615dd679b5dd0c3e60c20085706f392a9af2cb Champion on Jun 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

  1. Enable the Search (Ctrl-F) function on the code. See Enable Search (Crtl-F) in the Email 2.0 code editor
  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 Email editor 2.0: variables in the text version
  3. 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. Email Templates 2.0: enable containers and modules on <div> tags, not only on table elements
  4. 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:
  5. 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.  Guided LP and email 2.0 templates: make variables segmentable for dynamic content
  6. 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 Text CTA Elements for email and LP templates.
  7. 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 Email editor 2.0: module level values for Variables
  8. 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. SeeEditor 2.0: Have more than one mktoContainer per email template
  9. 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 Controlling the number of modules in a container.
  10. 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: Restrict access to the Rich Text toolbar (Thx Alan Brown )
  11. Restrict the List variables values to the list values. See Email 2.0: List variables should only accept list values
  12. 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 Email editor 2.0: Enable branded link for vml buttons

 

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 New email editor 2.0: wrap template code
  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 Token picklists for Guided LP or email 2.0 template string variables
  3. Making a whole module dynamic in order to reduce the risk for errors. Email editor 2.0: Make whole modules dynamic content
  4. 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 Editor 2.0: Set Min and max dimensions for image elements and variables in Guided LP / email templates
  5. Editing the email code is not a right that should be given to anyone. SeeEmail "Edit Code" (a.k.a "Replace HTML") permission
  6. Variables should display in the order set by the designer, as this order is usually more functionally logical. Guided Landing Page or email 2.0 variables should display in the order set by designer
  7. Finding out which email is upgraded and which is not requires to browse each of them one by one. Not convenient. See Have the editor version to appear in the email list
  8. 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: Editor 2.0: access to the Starter Templates to be controlled through a role permission
  9. 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 Required attribute for guided page variables
  10. 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.
  11. The support for Wistia in the mktoVideo elements. See Email video element wisita support (Thx Matt Tunney)
  12. Better manager of the pre-header, especially in context where we need to make it dynamic. See Email editor 2.0: enable dynamic content in the preheader  and Email 2.0: enable to disable the preheader feature
  13. The possibility to crop / resize images on the fly from the editor: email 2.0: Crop/resize images on the fly
  14. And also:

 

 

-Greg

Outcomes