HTML Email Editors: A Design Case Study

Applications that allow creation of stunning responsive emails are everywhere yet it's rare to find any that appeal to users of all experience levels.

As a professional, writing a responsive website is an easy process. Take a dash of HTML, mix with JavaScript and CSS, finally sprinkle with a bundle of experience and we end up with something pretty amazing.

But even for professional designers, repeating the same tasks within an HTML email is exponentially harder, mixing techniques from years gone by and modern practices in order to provide an optimal experience for all email clients.

This previous article discusses the complexity of Responsive HTML email design and the difficulties that can arise for the most experienced of us. With this in mind, how do we go about producing an editor that's perfect, or at least as close to perfect as we can get.

User Profiles and Experience

There are lots of applications that allow experienced users to produce stunning responsive emails. There are also countless apps that allow inexperienced users to produce equally stunning emails. However, it's rare to come across an HTML email editor that appeals to both groups of users.

The reason for this is simple to understand once you consider the level of knowledge possessed by the two user profiles. The difference comes down to the relationship between senior and junior roles.

At the novice level, users might have an idea of what they want a mailing to look like but not the experience to produce it quickly; they need help to build something to allow them to concentrate more on the content than layout and behaviour.

At the expert level our users are more likely to have a well-defined idea of what their mailing should look like and how it should be laid out, but often find that the restrictions of the editor prevent their vision from being fully realised.

More often than not, what we end up with is an app that provides the building blocks but often requires consultants or even paid developers in order that vision to make it to a users' inbox. All this comes with a hefty expense for clients.

So what HTML Email editors are out there, do they achieve a balance between the two approaches or do they just provide simple editors and force their clients to pay hundreds if not thousands for something more bespoke?

User Expectation

Before we consider how a responsive email application ought to work, we must first determine what users expect to see and how established practices mould that expectation. Providing something familiar helps break down the walls between our novice & expert user groups, it offers a starting point with which everyone is familiar allowing us to tag on extra features that users discover as they become more intimate with the processes we'll put in place.

Until a few years ago, the common denominator for all users would have been something like Microsoft Outlook. This is still common for business users, however with cloud computing and mobile devices becoming more common, simplified email clients like Gmail mean that users don't necessarily all have the same level of experience.

So our lowest common denominators range between the simplistic UI provided by Gmail/Outlook.com and the text editors such as Microsoft Word that allow creation of more advanced layouts. But; we're not producing a PDF document here, we're looking at something that can be displayed in varying sizes, on varying devices and that's before we even consider DPI and device text size options.

Existing HTML Email Editors

Email HTML editors come in all shapes & sizes, but they can be broadly split into two categories - Text editors and layout designers.

Users are familiar with the former, embodied in the likes of Outlook and Gmail. There are other options, but the restrictions of HTML in general and specifically in email make it harder to achieve a design guaranteed to work on every device.

There are many, many existing HTML email designers out there, but for the sake of simplicity we'll narrow it down to some of the common ones.

MailChimp MailChimp comes closest to mimicking a traditional email interface, the initial screen is split nicely into sender, recipient, subject and content areas. While there are a few oddities it provides a decent, if somewhat limited editor. Perfect for users who want to produce something quickly without any fuss.

Campaign Monitor Campaign Monitor ups the game a little. It doesn't provide quite the same traditional email interface, opting to hide recipient selection until the entire mail has been designed; a common approach among marketers but not suitable for every situation. Its editor is a little more advanced than MailChimp, and provides a few nice extra touches like image cropping. Extra brownie points for its collection of ready-to-go layouts.

BeeFree (or Pro) What BeeFree provides is far more of an email editor rather than a fully-fledged mailing system. It provides a more than generous selection of pre-configured layouts but generated content then has to be download for use in a separate mail client. This editor is far more refined than its counterparts, providing a well defined section editor and drag/drop interface, and options for padding, line height, hexadecimal colour codes alongside a brilliant image editor. The editor receives extra kudos for its ability to show or hide elements in desktop/mobile mode. Now, you might argue that hiding items in mobile mode is the wrong approach, and in most circumstances you'd be right, but without deeper knowledge of HTML then there really isn't any other option here.

Mosaico Mosaico takes a similar approach to the Bee editor, ignoring traditional mailing elements and producing pure downloadable HTML content. The editor provides preconfigured, draggable sections. Editing of section layout is limited, however it does provide a range of stylings that can be applied to individual content items and full HTML editing of certain areas. The Mosaico editors' handling of colour schemes is where it shines, providing the ability to swap the colour scheme on any particular section at the click of a button. There may only be two colour schemes available in the default view but the editor hints at the ability to add further schemes.

Of these well-known tools, there's no one clear best-of-breed option. They all offer good WYSIWYG editors, each with their own advantages. They're all brilliant tools in their own right, but in their desire to simplify the approach they miss out on the bigger picture and the pixel perfect designs that so many users are looking to achieve.

Features of the ideal HTML editor

We know what users are likely to expect, and for the purposes of a design review, we have an idea of what other editors can achieve (and more importantly, what they're missing out on). But we want a fully functioning HTML email editor, usable by all and that requires some more in-depth thought about how our editor should work.

• The most important thing (and something that should ordinarily go without saying) is that our editor needs to be as close to WYSIWYG as is possible.
  There will always be differences in the way that certain mail clients render our generated HTML, but users need to be able to make a change and see its immediate impact on the design while maintaining a high degree of certainty as to how it will look to the mail recipient.

  We should be assisting this further, with at a minimum, the ability to swap the editor mode between different screen sizes and view modes in order to simulate how a mailing may look on a smaller screen or in dark mode.

• A user won't necessarily know all details of a mailing at the point of creating it; as with product design, the details can be in flux right up until the final design is complete.

  With this in mind, we want users to be able to view sender, subject, recipients and the email design all at the same time and (perhaps even to include some additional fields like the preheader and send time etc). But we don't want this overshadowing the design view, ideally these basic fields should be visible alongside the mailing content.

• Pre-defined layouts look pretty and help to inspire users, but they can be restricting. So we'll want the choice to select between several layouts (or a blank layout), similar to how modern versions of Microsoft Word operates.

• To get past the restrictiveness of such layouts, we'll want to complement our functionality with draggable rows which can be positioned anywhere within existing content in order to provide responsive email elements. For example we might want a tri-column section which automatically stacks on smaller devices; we might want to allow content to be dragged into a very specific area, preventing changes to all other areas.

• In order to maintain compatibility with all mail clients, our sections will need to be table-based. In turn, this opens us up to the possibility of introducing another area that users of common office applications will be used to: the ability to split or merge cells in order to further redefine the layout.

  Splitting or combining sections will update the manner in which responsive email design will operate so an element of caution is required. Also many HTML emails tend to use multiple levels of nested tables, we'll need a method of separating those used for content from those added purely for layout purposes.

• With our layout in place, we'll need to provide the ability to add content components, making adding content as easy as possible at a minimum we'll need to provide text, image and buttons with the default mode being to add text.

  We'll want to give consideration to dividers, bullet points, social media and perhaps even content pulled from an RSS feed. Some mail clients support gifs and videos, so we may also want to consider this, but there are other implications around using these sort of features which would need to be considered.

  When dragging items we'll need to implicitly create a table structure around our objects to allow them to be positioned properly, this would also facilitate easier repositioning of components.

• To help users retain similar designs throughout multiple mailings users will want to re-use sub-sections of designs elsewhere in much the same way as adding an image or text area to a mailing. We can allow users to build collections of design elements for later use, even allowing importing of design elements from previous mailings.

• On selecting a section area or a content item we'll need to provide a list of common options available in most text and HTML editors.

  This will require separating standard text editor functions into a standard menu/ribbon, or perhaps inline editor while the HTML editing functions (which typically would require more screen space) are held elsewhere.

  At the very least we'll want to expose the standard font options, alignment, colour options (foreground, background & text highlight), padding options & table manipulation functions. But we'll want to keep it simple, with context-sensitive options.

• CSS is a huge part of HTML content, advanced clients tend to setup standard CSS styles for their emails, sometimes reusing stylesheets from other locations such as company websites.

  Most email clients require CSS in HTML email to be inlined; to simplify the lives of developers we'll need to provide the ability to add CSS (or even SCSS/LESS) directly to an email and automatically inline it at an appropriate time.

  Exceptions to this are media queries (usually produced to work alongside dark mode and responsive design) which will need to be handled separately. We can handle separation of media queries from the core CSS automatically, but users will need some method of editing these options.

• Full HTML access can be dangerous, but there are clients who will have their designs professionally built and will then want to import that content into an editor for easier manipulation. Equally there will be those who know exactly what they want and how to go about it.

  Most HTML email editors tend to concentrate on simpler functionality, but ours needs to be opened up to users of all levels in a safe manner.

Editor Layout

So here I am, typing into a Microsoft Word document with both the left and right-hand panels open alongside my document, and it occurs that when there is enough screen space to play with, this is the ideal layout for our HTML editor, not only because it's an interface which will be familiar to users, but because it allows us to better guide them through the creative process.

We start on the left, with our non-design items (subject, sender, etc) and drag/drop components, move to our full design and WYSIWYG editor and provide a final panel in which a selected component can be edited. This allows the users flow to move left-to-right with the items more likely to be used at the beginning on the left and everything else on the right.

There is of course, a bit of rearranging to be done for smaller screens, where the visibility of content should be prioritised; the nature of such devices means that it will always be easier to create an HTML email when using a larger screen.

In this screen design, we've placed a number of tabs on the left-hand side with the following options:

• Email - containing typical settings for email subject, recipients, sender, etc.

• Layout - containing draggable layout sections (single column, multiple columns, 60/40 split, etc).

• Design - containing draggable content items and user-defined snippets.

• CSS - for configuration of pre-inlined CSS to be applied to the entire mailing.

In earlier designs, this section contained a button to expand the section over the design area, however given that this area could well include the need for a scrollbar this could cause the user interface to appear cluttered. But with the possible length of fields such as the subject and sender name more screen space would be useful to users. We could achieve similar functionality by automatically expanding the area of the emails tab as soon as a user selects a field.

The right-hand area is displayed only when an item within the editor is selected:

• Containing CSS and HTML attributes appropriate to the item (those that will work within HTML email).

• Toward the bottom of the section we have options to swap between complexity modes, standard, advanced and expert - these may be better off being placed within the "View" tab of the main editor if usage can be expanded outside of this area. This would have the effect of making users search for advanced options and reduce the likelihood of making advanced changes to areas that they don't fully understand (particularly important for HTML emails).

Finally, the central area takes a more traditional word-processor approach, with a central defined content area and options to zoom in and out in order to view the content in its entirety.

A ribbon style menu at the top of the screen provides additional options:

• Edit - standard edit toolbar containing font options, alignment, text colour, paste formatting options, etc.

• View mode options, allowing users to swap between simulated design views for desktop & mobile views. Also provides functionality to view without CSS media queries to simulate appearance under desktop applications like Outlook.

• Send options - containing final send operations, validation, configuration of plain text, send time, etc.

In the examples of the left-hand panel here, the first tab shows our primary email options, required fields are pushed to the top (and will be identified with an appropriate icon) while less important items are further down. Expandable to any number of possible options, although given the plethora of CRM systems available, recipient selection may be better off being defined as a completely separate screen.

The simplistic drag and drop interface initiated from the second tab provides the ability to build the layout of the email design with built-in responsive design elements. While not displayed here, the appearance of the third tab is would follow a similar design approach with the exception that design elements need to be dragged into an existing layout element rather than directly onto the canvas.

As discussed above, the right-hand panel contains configuration options for all HTML attributes and CSS settings within stylised accordion settings. In smaller screen designs, this panel is repositioned to the left of the screen and in even smaller screens the left pane is collapsed entirely until required.

The complexity of these options will be driven by settings within the view tab. Standard mode provides most options but keeps the configuration simple (i.e. allowing padding to be set to a single value), advanced opens it up to the usual options (i.e. allowing top/bottom/left/right padding values to be set independently) while Expert mode allows users to set the padding values directly (i.e. users can type whatever they deem appropriate, including usage of CSS variables which will be inlined into HTML content as part of a separate process).

The design view is intended to operate in as close a manner to a standard text editor as possible, the key differences being that administrators are able to define sections that cannot be edited, this ensures that email designs will always be able to follow a set design pattern. HTML content is hidden except when running under Expert mode which provides full access to the underlying HTML of individual sections and components.

Finally, in addition to editing emails directly, the designer doubles as a template editor, giving expert users access to the entire HTML content and allowing them to define areas where layout areas can be added by standard users. This allows provision of functionality impossible in all HTML email editors where clients want to add double borders and other design elements around the entire content - something that the adding of layout sections can't deal with on its own, particularly where older email clients are concerned.

Conclusion

In conclusion, creating a pretty, responsive HTML emails has always been a complex task. Balancing behaviour so that users with all levels of experience can construct their own content will always be something of a tight-rope walk, but given enough consideration of the options we make available to our users anything is possible.

Comments

[Entony12]

Hi, Michael. Thanks for sharing. Did you know Stripo templates? You can also mention them in article or maybe you already know this builder and for some reason you didn't like it