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.

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:

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

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.

Another thing I came across, which I thought was a bug, but was told by support is just something that's not available yet:

You can not send segmented emails to the proper segment using the Send Sample email function in preview mode. For example, we segment our emails based on language. To test these in Editor 1.0, I open up a preview of the email, change the language segmentation to view each language and send a sample of each to a targeted list of email addresses internally so they may review the email. In Editor 2.0 in preview mode you can only send a sample of the default segmentation. If you want to send samples of the segmentation, you have to find/create a lead who meets the criteria of the segmentation and then send the email using a flow step in a campaign. This is going to add a lot of time to our email testing/review process. Support said they do not have an estimate of when this feature will be enabled for Editor 2.0.

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?

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.

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 )

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.

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?

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.

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.

I would enjoy a string field option that only allows numbers/letters or encodes spaces and punctuation. This would be useful for making variables that may be used in URLs. What I am hoping to do is prevent unnecessary errors by non-technical users using spaces or other invalid characters in UTM tracking. I'm currently using variables and tokens embedded in the URL to let the user use the marketo email builder interface as a UTM link generator as well. Thoughts?

Commenting first because I don't know if this is technically doable in today's product or there's already an idea out there:

One of the big advantages of modules is that you can greatly simplify editable areas. However, when combining modules and dynamic content, there's a snag. As an example, if you're making a newsletter and you only want to show a module to 3 out of 4 segments, you can't just hide the whole module.

Technically, you can get around this by making a dynamic snippet, but that requires the end user to edit HTML if there are multiple defined areas on the module. What I'd ideally like to see is conditional viewing of the module itself.

In fact, if the whole module could be dynamic as described in this idea (including variables and the possibility to completely hide of swap it per segment), it would be both much more powerful and simpler to use.