Email Builder / client-specific defaults

nadworks

Active Member
We have a situation where some clients prefer to continue using their existing process of importing their own HTML each time, some want to keep re-using their previous campaign as a template starter, some are keen to start using the integrated Stripo plugin.

However, it seems as soon as we activate the Stripo Email Builder via the backend extensions, everyone is forced to only have that one option and all other legacy templates are basically bombed. That's obviously a nightmare to manage among all customers. With one stroke, many their existing processes are being killed off and there's no apparent option to disable Stripo for some customers or at least not make the Stripo the default wipe-out builder in the "template" step of the campaigns. There isn't even a plain HTML view anymore. However, the "New Drag & Drop Editor" is strangely present.

What's the solution? Have we missed something? How can we allow customers different builder experiences? I think that's really (!!!) important.
 
Afaik, if they enable Stripo on the template, then yes, Stripo will take over, but even with stripo enabled, if you don't toggle and use it, then it should not affect you at all. Right, @laurentiu ?
 
It's pretty much wipe-out everything once you hit that toggle button (even if accidentally or out of curiosity) with no way to recover what was there. I've only had Stripo switched on for a few hours to test it and had clients calling in distress because they assumed it would be worth trying and then lost hours of work.

It's the nature of it being immediately activated everywhere and on everybody's account and the lack of choice between customers.
There's also the lack of template support.

I'm not even sure I can build a template in Stripo and make it available to be used with the Stripo Editor, can I? Well, I cannot test it right now because as soon as I switch to Stripo in the backend, I might disgruntle another client who's currently happy to work in the old-fashioned way.
 
Afaik, if they enable Stripo on the template, then yes, Stripo will take over, but even with stripo enabled, if you don't toggle and use it, then it should not affect you at all. Right,
Yes, if don't toggle Stripo builder then your template will remain intact and you can use it. If you select one template and then toggle stripo then your template will be removed and will be replaced with stripo template. You cannot change/modify another template made with another builder, if template is made with stripo then in campaign step template you can choose that template and toggle stripo and edit it in this case will work.
 
Thanks, you're confirming the issue: When the prominent toggle is clicked, all is wiped. There is no "template" in Stripo. It's just an empty block skeleton. You're explaining this to me here in the Forum, but the point is that our clients are not aware of this.

The bottom line is that I don't think we cannot leave it like that. That toggle killing all that was on screen at that point is un-userfriend (user-unfriendly?). Don't you agree?

I would also like to hear if there are plans to make the builder selectable on the customer account level, instead of inflicting it globally. Can you address that point, please?
 
Having customers select the builder is not something on our todo list, I also don't think customers should have this power, they should work with whatever the admin decides for them.
But we can address the current pain by adding an alert when they toggle the editor, informing them about potential issues and alternatively giving them a way to reload their initial template. If that works for you, i'll get to it.
 
Sorry to slightly disagree here. When we're dealing with existing clients and legacy processes, the importance of managing change is vital. New clients are not the issue. But existing clients cannot be expected to just switch without any regard for their established way of working without at least giving them the option.
Not having their entire email wiped by hitting the Stripo toggle is absolutely essential
Getting back to the original template after disabling Stripo again immediately would be expected UX

If that can be implemented, no warning is needed.
 
Sorry to slightly disagree here. When we're dealing with existing clients and legacy processes, the importance of managing change is vital. New clients are not the issue. But existing clients cannot be expected to just switch without any regard for their established way of working without at least giving them the option.
Not having their entire email wiped by hitting the Stripo toggle is absolutely essential
Getting back to the original template after disabling Stripo again immediately would be expected UX

If that can be implemented, no warning is needed.

I also found the stripo integration unpolished.

I would suggest using unlayered you can buy the plugin from https://www.avangemail.com/
After activating you still have the option to use the HTML option. You can also enable it for the specific customer groups:

1725521975563.png

It will also wipe the template when the button is clicked, but at least you can decide who sees it and who does not.

1725522044557.png

If you open the drag and drop it will not overwrite the template immediately if the client closes it the original template will still be present.
 
No, Stripo is without doubt the absolute best and most advanced email builder. Period. We've tried soooo many products in the last 15 years - both integrated and standalone. Stripo is miles ahead. I have absolutely nothing bad to say about them.
However, we've had MailWizz clients for as many years, and they all work differently and have found different ways around its limitations. While many would be happy to start working with Stripo, half of them would prefer to keep working the way they have.
For me, it's all about choice and options, without compromise.
 
Last edited:
No, Stripo is without doubt the absolute best and most advanced email builder. Period. We've tried soooo many products in the last 15 years - both integrated and standalone. Stripo is miles ahead. I have absolutely nothing bad to say about them.
However, we've had MailWizz clients for as many years, and they all work differently and have found different ways around its limitations. While many would be happy to start working with Stripo, half of them would prefer to keep working the way they have.
For me, it's all about choice and options, without compromise.
I agree with you that Stripo is miles ahead it's just the implementation of the integration which is a bit wonky. If it was done with workflow in mind and the ability to enable per account it would work out better—especially an option to edit full screen rather than in the the page.
 
Yes. We've now requested feedback from our clients, and the unanimous decision was not to enable Stripo. That's purely based on the way it's implemented and the lack of even the resemblance of a coherent or intuitive workflow:
  • templates cannot be saved or imported (i.e. some of our clients have Stripo accounts and would like to import editable templates from the external Stripo builder to then exclusively use inside MailWizz: not supported
  • Many other clients had developed their own workflow making do with the tools available and cannot suddenly switch. The wipe-out nature of the way Stripo was implemented would therefore not work for them
  • The missing method of saving / pre-saving reusable templates or even content blocks is making Stripo inside MailWizz virtually useless. Nobody wants to start from absolute zero each time they build a new campaign.
This last point is obviously shared among all available builders inside MailWizz, btw. incl. 3rd party, apart from the raw editor.
Just to clarify: this is not a complaint, just voicing my own and our clients' dismay about a feature that's currently not solving a pre-existing problem.
 
We understand these limitation, but is not a matter of implementation only, but a matter of how that the Stripo Plugin works and its own limitations. I suppose, in the future they will improve their api plugin and we will try also to update our implementation to match their improvements.

Cosmin
 
Back
Top