Product Team

Over time, with changes made to different email builders, many of the created themes ended up being left behind, and so the number of themes available to a user interacting with the platform for the first time became very limited.

There are several ways in which we can see how themes, or the lack thereof, have been problematic for the adoption of Mautic as the marketing automation tool of choice for companies. The need for programming knowledge to achieve good design results is something that causes many users to simply abandon the platform.

The impact can be strongly seen in the Mautic Trials, when users send feedback talking about the frustrating experience they had when given a try for the first time. Example:

How would you rate the overall experience of the Mautic trial?: 1 - Very poor

Could you clarify this rating?: The truth is, the most frustrating part was the email design process. I had to struggle a lot with the tool, and in the end, it wasn’t possible to create a decent email design. That's why we won’t be using it.

Will you continue using Mautic?: No

What made you decide this?: I wasted many hours trying to make it work, especially with the email design interface, which lacks a lot of quality. You end up designing it in an external tool, copying and pasting the code, and it still doesn’t work.

This issue is bigger than just "oh, I as a random lead didn't like it". The adoption from customers is what makes the project keep alive: if people keep getting a fully problematic entry barrier, we know that they're going to choose another option and the Mautic partners keep losing sales. As you may know, all other tools are strong when it comes to making user's work easier.

What would your company do if you had to keep developing Mautic on your own? Not a great thing to discover. We need to evolve our way of thinking if growing this app and the community is necessary.

The feedback from the user makes us realise that the platform is very developer-centric, and even community members recognize this aspect through occasional comments across our communication channels.

So, I propose:

1. Revert the decision to use “Mautic team” as theme authors for Core themes
2. Allow companies and individuals to be recognized for contributing themes
3. Define standards and guidelines for integrating new themes into the product

Why?

We're lacking themes for a long time.

Ready-to-use great templates make Mautic more competitive among other tools.

Themes benefit all users.

This will make donating themes an interesting action from companies.

Companies pay employees to create those things, the minimum is to have authorship recognized.

The current decision regarding this topic conflicts with the marketplace, as there we can see authors.

Better adoption leads to community grow and it helps in project sustainability.

Proposed standards & guidelines

1. We can provide items such as placeholders for logo and other resources to incentivize quality in development
2. Themes cannot bear the visual identity of the company that is proposing, as this could lead to submissions for convenience
3. The content of the themes cannot be aimed at promoting the author, as making this feature valuable for users is the goal
4. Themes can contain custom fonts (pages) and images, as long as they are open source or have compatible licences for distribution
5. Mobile-first design should be mandatory, as many papers show how the amount of mobile users is bigger than compared to desktop users
6. Emails should be designed in MJML
7. They will be removed if they become incompatible across the release of major versions
8. No external resources allowed, such as importing things from external URLs or CDNs, to prevent potential security issues, improve privacy and compatibility with different clients
9. They must not depend heavily on images in a way that themes become unusable or useless when changing an image
10. All images must be culturally sensitive, have an alt attribute for accessibility and avoid text on top of them
11. Emails must have a designed unsubscribe page instead of the default blank screen with message

To foster the development, we can bring resources to support, help developers and designers know how to work with framework limitations (for example, the builder doesn't support responsive settings yet, even when the MJML framework seems to support).

Help me to refine this proposal. Leave a comment.