Improve HTML Useability

Archived and Closed

This conversation is no longer open for comments or replies and is no longer visible to community members.
The community moderator provided the following reason for archiving:
EOL Clean up

Emma's features provide wonderful, simple abstractions, but sometimes we need access to the actual building blocks of an email: the HTML. When it comes to the fundamentals, the Emma platform makes it really difficult to do basic, useful operations.Three features would really help:

Allow custom-coded campaigns to be saved as templates in all account types the way you do for agency accounts.

Allow for simple toggling between the drag-and-drop/GUI view and the full HTML code. Incidentally, this feature would supersede and cannibalize the above because it would involve a new, far more obvious paradigm of a single editor with toggled views rather than the current one where editor types are silos and each campaign can only be created in a single type of editor. Then any campaign could be saved as a template after it was created using either drag-and-drop or HTML - or both! Having the HTML block would still be helpful for users who only want to use it for dynamic content. In fact, in a perfect world the toggle would only change the view of the main editor body while leaving the block list on the left column; then make the blocks functional within the HTML view as well - adding the raw code when inserted.

Allow for editing of the footer HTML. Even if a full editor toggle is not soon in coming, being able to access the code for the footer like we can for other block elements would be a significant improvement, as well as providing what should be really obvious functionality. Providing options for social share in a hard-coded footer is not acceptable for use-cases like private event invites where we do not want invitees to share an email on Facebook or Twitter, so we need to be able to remove that. We would also like to customize the language around Manage Preferences and Opt Out. Frustratingly, none of these things is possible currently.

Some of these intersect or override each other. The basic premise is: an email is ultimately an HTML document, so, while code abstractions in the form of drag-and-drop blocks are awesome and user-friendly, users should not be prevented from viewing and editing the ﻿entire﻿ email in its actual form when they need to do so.