3 of 3 people found this helpful
Full disclosure: I've never used Email 1.0, I started using Marketo the month that 2.0 was released. BUT I'm a bit obsessive about creating the ultimate template as I manage an instance with multiple brands and have worked to develop a single tokenised template that works for all of them. A few of my must-haves that made this possible:
- Hinted at already: tokens tokens tokens. How far you take this may depend on the exact use case - you may at least want to tokenise your copyright, unsubscribe, legal links etc. For me, managing multiple brands on a single template, I tokenise fonts, logos, colors, etc, and while it looks funky in the editor it is a very scalable & efficient way of controlling some of those details
- Local vs Global variables. A global variable will be set once and applied the same way to every occurrence of it in the email. A local variable will only set the value in that one instance of that one module. Very useful if you would like to allow/prevent things from being set at the module only level. Also important if you want to, say, use a variable to set the URL on a button within a module, and use that button module twice in an email. If it's a global variable, you'll be forced to have those buttons link to the same URL.
- Make it as flexible as possible. I've seen people with templates that have over 30 modules, and it can be really frustrating to use and maintain that many modules. Doing these things has been enormously helpful in this pursuit for me:
- Utilise clearable elements. Rather than having 2 col with image and text and button, 2 col with image and text no button, 2 col with image and button no text, etc etc etc, If each section is mktEditable, you can clear elements as you wish in use, so you can have one 2 col with image and text and button module, and just right click and clear the image element when you don't want the image to be present, ditto text and ditto button.
- Break down modules thoughtfully. Sometimes it's much more helpful to break down elements into individual modules - e.g. a heading module, a body text module, and a button module, rather than a single module with a heading and body and button. I have numerous use cases for body copy above and below a button, or body copy then heading text then body then button. Breaking each of these elements into individual modules gives me the flexibility to arrange them in a vast number of different ways.
- Make padding a local variable! Sometimes you need more padding. Sometimes you need less. Having the ability to control it is awesome.
- Make alignment a list variable! Sometimes I want things left aligned. Sometimes I want them right aligned. As suits, some of my modules are designed to allow this as a drop down. Great example is my header logo banner - I can change the background colour and the alignment of the logo as I see fit.
- Don't make everything a default module. You can choose whether a module appears in a newly created email by default or not. This can be helpful for visibility of available modules, but having to remove them all is painful. Generally, it's easier to set to default only those that are almost always used - for me, it's preheader, logo, body text, footer, and post-footer disclaimers/unsub links.
I hope that's helpful, but I suspect you'll also find Grégoire Michel's detailed posts on the subject helpful as you go through this process:
This is all GREAT advice, Grace. I appreciate your input! Tokens I had thought of. As well as padding as a local variable. Clearable elements, alignment variable, and "don't make everything a default module" are just the kind of GOLD I was looking for. And I have read, several times, Grégoire Michel's posts. This time around I plan on the Email 2.0 going much smoother than the first. Thanks again.
Hey Bonnie - glad it's helpful
The other thing I would add - especially relevant if you're building the new template into program templates or always-on campaigns - make sure that the template has been thoroughly tested internally for ease of usability and externally for client responsiveness before you do build it into those.
When you make changes to an email template, those changes are carried into emails based on that template via the creation of a new draft. If the changes affect a specific module, those changes don't always automatically apply - often you will need to delete and re-introduce that module from the email for those code changes to be present. I'm sure you can see how this would scale to a significant piece of work pretty quickly if you make a significant change to a frequently used module in a template that's used across all your program templates and always-on comms!
It's not always avoidable, esp. with mobile responsiveness which is constantly changing, but it's good to avoid the obvious ones where you can!