Warm hello to all Designers and designers by heart 
Yes, I am inviting us all, for discussions on Templates. Getting your opinions, firsthand, which can help us enhance the experience of working with templates in Design Studio. The discussion is two-fold (and sub-questions within) :
1. Email templates:
1.1 Were there issues when Email 2.0 was rolled out as default?
1.2 How is your experience in editing an email template today?
1.3 What does your template to email ratio look like? (do you have one template for 100s of email or is the template count more?)
1.4 How often do you use HTML to make changes?
2. Landing Page templates:
2.1 What's the nature of your frequent edits to your Landing Page templates?
2.2 If you've used Email 2.0 editors, What can we borrow from there?
2.3 Is your Design team adept in HTML to make changes?
Our discussion can certainly span beyond the questions mentioned above. I'd certainly benefit by learning from you, on your usage and getting to know your requirements on templates/Design Studio. I'd be more than happy to set up some time and discuss over a call.
Best Regards,
Vikram Ramesh | Product Owner | Adobe | vikram.ramesh@adobe.com
phone: +91 988 607 4356
Hey Vikram - I am really excited to see a discussion about this from the Adobe team. Here are my thoughts...happy to be a resource to discuss any of this further.
1.1 Were there issues when Email 2.0 was rolled out as default?
I didn't personally experience any issues with the rollout; however I just started using Marketo shortly before it got rolled out, so we hadn't invested too much in 1.0 emails at the time yet.
1.2 How is your experience in editing an email template today?
The email 2.0 works well for most needs. There are a couple of things, however that I could see as enhancements:
- The ability to override modules used in emails if they are ever updated. Currently, if I ever fix a code issue or make an update to a module, I have to go back into every email that uses that module and either update the code manually, or delete and re-drag that module back into the email. This can be very tedious. I understand the premise of preserving existing emails, but it would be nice if there was a way to force an override for specific modules if there are emails currently using that module.
- One thing I ran into at my last agency is that if you have hundreds/thousands of emails using the same template, Marketo could ultimately freeze when trying to make updates to that template itself. As a workaround, I have made it a practice to clone the template once per year so new emails are running off the new template.
- It would be nice to apply a different template to an existing email (the email would be erased and start from scratch). Currently, we have program templates with emails built in and in order to use a different template for whatever reason, I have to completely delete the email from all the campaign flows, delete the email itself, and then re-create the email and select the new template. This is less of an issue when using the master modular template, but still happens on occasion and is very tedious.
- I like how when creating a new template there are code examples that exist. It would be nice to expand that out a bit to include more contextual use cases to give developers more ideas on how to use the variables in creative ways. Additionally, it would be nice to "insert" new variables into the template using the UI, vs having to bookmark the documentation and scroll to the variable you want to use and copy/paste.
1.3 What does your template to email ratio look like? (do you have one template for 100s of email or is the template count more?)
We are currently using 1 master email template with several modules to build virtually all of our emails. It mostly works well and is appreciated by the production team because they have pretty much everything they need to build any type of email such as webinar invites, newsletters, etc.
1.4 How often do you use HTML to make changes?
As mentioned above, I use the code editor in an email to either apply HTML fixes to modules (without having to delete and re-drag the updated module), or if I very rarely need to make a one-off change for that email.
2.1 What's the nature of your frequent edits to your Landing Page templates?
Like emails, I try to keep my landing page templates to a minimum and have multiple options for various contexts of the landing pages. Unlike emails though, any "modules" I have created in the landing page are controlled by either showing or hiding the blog using CSS. This is a very messy way to deal with landing pages because it creates a lot of hidden and bloated code in the final pages. I do make updates to Landing page templates much more often though, usually to account for some new context for that given campaign.
2.2 If you've used Email 2.0 editors, What can we borrow from there?
Like many others have suggested, at least having the concept of modules would be a great step forward. Especially since it already exists in Email 2.0, it doesn't seem like it would be that huge of a stretch to migrate it over to Landing pages (especially after 4 or 5 years). Personally though, I feel like there could be a much better approach to building landing pages given what we know from other platforms that have been available for several years now. If landing pages are planning to undergo a rebuild, I would love to see a more modern builder that the user could drag-and-drop HTML elements onto the page such as containers, grids, text blocks, buttons, images, etc:
The template then, would allow for branding of these elements using a master CSS file, as well as make any pre-built blocks that can be used similar to email modules.
The challenge with landing pages is that there is almost always something unique that needs to happen to the LP based on the campaign so giving the user the tools to build/modify what they need on the fly is a must in my opinion.
2.3 Is your Design team adept in HTML to make changes?
Yes, I manage most HTML templates for our company, and we have a few others who are competent in HTML as well. When I was working at an agency prior to this though, many of our clients did not have internal HTML resources, so we had to build templates in a way that their internal team could execute various campaigns. If they ever needed something though for a new use case, they would have to come back to us to modify the template to allow for that. That is why I think having some user friendly building tools is so important so that end users can at least do a little more on their own without having to bring in a dev team for every little thing.
.png)