Campaigns UI

[joshuap]

1. I think that one of the more powerful aspects of Heya is the ability to add users to campaigns anywhere in the Rails app, in response to any event (bypassing the complex rules that must be created in traditional UIs).
2. For that to work, each campaign must be represented in the code via a unique class. Currently, the only way to create a campaign is by creating such a class, which is great.
3. I have been considering how we might allow users to also (optionally) create campaigns from a UI. The benefit of a UI would be that you could edit the campaigns without deploying the app.

Here's an idea that just occurred to me: we could require users to deploy the app when creating campaigns, but then allow them to manage messages and other features from the UI. For instance, instead of creating steps inside the campaign, you could declare that this campaign will be managed elsewhere:

class SignupFirstRunCampaign < Heya::Campaigns::UI
  # The step method will not work here. It will simply create the campaign. Messages must be added in the UI.
end

Campaigns created in this way could be paused by default, requiring you to activate them via the UI to start sending.

Campaigns that are managed in Ruby would likewise be locked from editing via the UI.

[chalmagean]

Wouldn't that make things even more confusing?

I think the big problem is having a big-picture view of the whole system (at least to me it is).

I'm currently struggling with the campaigns as well, but I think the solution is to move them to the db instead of having them as objects. There are two benefits I see by doing that:

1. You're not limited to one user. You can have multiple users creating campaigns.
2. You have a single place to manage campaigns (and the business logic is easier to manage).

What do you think?

[joshuap]

Wouldn't that make things even more confusing?

I think the big problem is having a big-picture view of the whole system (at least to me it is).

I'm currently struggling with the campaigns as well, but I think the solution is to move them to the db instead of having them as objects. There are two benefits I see by doing that:

1. You're not limited to one user. You can have multiple users creating campaigns.
2. You have a single place to manage campaigns (and the business logic is easier to manage).

What do you think?

Yeah, this is the direction I'm thinking too. I'm actually (slowly) working on #127, which would provide the basis for adding campaigns in the DB.

[chalmagean]

Oh nice, looking forward to see where you're going with it.

[chalmagean]

I've been thinking about this a bit, and I think an important aspect differentiates the two methods.

If the campaigns are in the code, you can write tests that describe the subscriber's journey through the automation. Which is super important (I think), and I'm not sure how you would achieve that in the UI.

I've used ConvertKit's automation UI, and it's super hard to have an overview of the user's flow through the many visual automations you create. I think tests are much more useful because you can read a bullet list of steps.

What are your thoughts on that?

[joshuap]

I've been thinking about this a bit, and I think an important aspect differentiates the two methods.

If the campaigns are in the code, you can write tests that describe the subscriber's journey through the automation. Which is super important (I think), and I'm not sure how you would achieve that in the UI.

I've used ConvertKit's automation UI, and it's super hard to have an overview of the user's flow through the many visual automations you create. I think tests are much more useful because you can read a bullet list of steps.

What are your thoughts on that?

I totally agree, and that's why I built the current campaigns UI as a Ruby, DSL basically. I think you should be able to test them. In the future I'd love to have an even more intuitive way to write tests for campaigns or automation logic, but it's a big problem to solve. 😁

In any case, I was thinking that if I do add a web UI for campaigns, it would not replace the current approach—it would just be an alternative. I honestly haven't thought about it too much, though.

[chalmagean]

Either way, I think testability (as in seeing the flows and making sure they work right) is an important feature.

Feel free to bounce ideas if you want ;)

[joshuap]

Either way, I think testability (as in seeing the flows and making sure they work right) is an important feature.

Feel free to bounce ideas if you want ;)

Thank you, likewise! (And I really appreciate the ideas you've already provided.)

I haven't had a ton of time to work on open source lately. I was thinking I might try to spend some time on Heya in December. It's definitely a fun project to hack on, things have just been busy here. :)