🌟 Feedback Needed: Rebuilding the workflow editor experience

[scopsy]

Context

Recently, we have re-built our content and workflow execution engine by introducing the new Framework SDK, the goal was to establish a flexible and customizable foundation so that simple use cases can be done with a GUI, and advanced use cases can be done from code with great Developer Experience.

Right, we are looking to redesign the dashboard interface for the workflow editor and other pages based on the learnings we have so far to provide an even better no-code experience while still allowing the rest to extend with framework-based workflow definitions and run-time.

What's next?

The design and implementation of the new dashboard are currently in motion. We are trying to incorporate as much learning as we can into the new UX flow.

Also, we have partnered with Arik from Maily to create the best email editing experience that could've easily been extended with custom components and embed it into the new step editor experience. Check the Live Maily Playground.

How you can help?

As a comment to this issue, write any feedback you have with the current workflow management experience focusing on:

• No-Code and Code email editor experience
• Working with more complex content forms (Digest, etc..)
• Overall UX challenges you are facing with the existing design
• Anything else!

[gemueselasagne]

Great initiative! How will you be bringing variables and more complex data insertion procedures such as loops or array handling to the visual editor? (see https://postmarkapp.com/blog/why-were-nuts-about-mustachio for examples)

Also, which templating language / syntax will you be using for e mail generation?

[wh1337]

I like this idea. One question I do have is about the code vs no-code editor experience.

It would be nice to be able to create the workflow and outline the payload schema in code and then be able to edit the email utilizing the new editor. That way, as an engineer I can say "we are giving you x, y, and z fields on this workflow" and our non-technical members can then edit the email design. This would allow them to know exactly what payload fields are coming in without having to reference outside documents.

So kind of like a hybrid code / no-code environment.

Eager to see where this goes!

[cortopy]

One thing that I really like about React Email cli is the ability to switch between html and text email. This is particularly useful when sending emails that have to support both formats

[scopsy]

@gemueselasagne we are creating a few helper component such as For (You can see it at the mainly playground: https://maily.to/playground)

And for string based manipulation we are supporting Liquid syntax for things like capitalize, and etc...

Would love to hear your opinion on the For component implementation!

[scopsy]

One thing that I really like about React Email cli is the ability to switch between html and text email. This is particularly useful when sending emails that have to support both formats

That makes complete sense! cc. @SokratisVidros @twentyone24

[scopsy]

I like this idea. One question I do have is about the code vs no-code editor experience.

It would be nice to be able to create the workflow and outline the payload schema in code and then be able to edit the email utilizing the new editor. That way, as an engineer I can say "we are giving you x, y, and z fields on this workflow" and our non-technical members can then edit the email design. This would allow them to know exactly what payload fields are coming in without having to reference outside documents.

So kind of like a hybrid code / no-code environment.

Eager to see where this goes!

@wh1337 this is exactly what we are aiming for with the next releases. The engineers role is to establish advanced logic, rules, and reusable components. Offloading email editing and content updates to other team members.

[arikchakma]

Hello folks,

Arik here, creator of Maily. We're introducing many new features and enhancing existing ones. Let us know if you have any feedback!