Position BPMN as the no-code solution for Drupal

@phenaproxima commented Jun 24, 2024 •

Those two issues seem like good ideas to me, @jurgenhaas.

As for bpmn_io -- we could add it as a dependency if there's some actual use for it. I don't think we should be adding modules that we're not immediately using to add something tangible and useful. What does that module do? Why would we want it? What is the usefulness?

@jurgenhaas commented Jun 24, 2024

The bpmn_io module is the graphical interface to edit existing ECA models or build new ones. In the context of this issue, this would be about modifying the notification behaviour that comes with this recipe.

I would expect the initial audience of Starshot to not use it on day 1, but most likely later on when they're more familiar with Drupal.

But I can see that project browser would be around to let such users download and install bpmn_io themselves.

@phenaproxima commented Jun 24, 2024

Yeah, I think I'd rather go that route. :)

@jurgenhaas commented Jun 24, 2024

That's OK. I've updated the ECA model to v3 which will be pulled from now on. And the bpmn UI is left to the project browser to make is discoverable there if users are searching for that functionality.

@gitressa commented Jun 24, 2024

@jurgenhaas: Perhaps it could be considered to do some restructuring in ECA, and consolidate the module a bit, as I suggested in ECA: Idea for project page to help with on-boarding?

Proposed resolution

Choose a single model (BPMN.iO?) and use that everywhere
[...]
Remaining tasks

Decide if the BPMN.iO modeller should be singled out as the default. The two alternatives can of course still be mentioned, but be positioned less prominently.

This would make it easier to get started with using ECA, it's hard enough already, with many moving parts. Also, it would allow Starshot users to immediately tweak the ECA model(s).

What would be the downside of making BPMN.iO an integral part of ECA, and the default modeller?

@jurgenhaas commented Jun 24, 2024

Perhaps it could be considered to do some restructuring in ECA, and consolidate the module a bit, as I suggested in ECA: Idea for project page to help with on-boarding?

That's about restructuring the project's main page, not the module itself. At least that's how I understood that. And yes, this is open for contribution, we certainly need to improve our marketing and the user support here.

What would be the downside of making BPMN.iO an integral part of ECA, and the default modeller?

Proper system architecture is a reason against that. ECA is a black box processor with a single dependency: Drupal core. And that is important, short term and long term.

Modellers like bpmn_io are optional, even if there were only one available.

However, making the UI discoverable for end users and more intuitive is our top priority now that ECA 2.0 has been released.

@gitressa commented Jun 24, 2024

Thanks for a fast answer, and yes you're right. The Drupal issue comment was about making choices for people, and giving the users a 1-2-3 ready! recipe of two commands (composer require + drush install) which downloads and installs everything required to start using ECA.

And true, I went a step further here, and suggested even packaging within ECA the BPMN.iO modeller, as a dependency of ECA. So this is what I propose should be the steps required to install ECA and BPMN.iO, to get started really quickly, and not having to figure out what a modeller even is, and choose the correct one (most everybody will probably use bpmn_io anyway):

composer require drupal/eca
drush in eca eca_base eca_ui bpmn_io

After that, ECA should be fully functional, with BPMN.iO as the modeller.

What would be the downside of making BPMN.iO an integral part of ECA, and the default modeller?

Proper system architecture is a reason against that. ECA is a black box processor with a single dependency: Drupal core. And that is important, short term and long term.

Modellers like bpmn_io are optional, even if there were only one available.

I very much agree.

It's a great idea to be modeller agnostic, and able to switch to any other modeller, other than BPMN.iO, if so desired. That's perfectly fine. However, as I see it, ECA should be opinionated out-of-the-box, and ship with a sane default modeller, to make on-boarding new users easier. With the current complexity, we are shooting ourselves in the foot, and creating a bigger barrier of entry, than it needs to be.

I agree, let's work on improving the UI and documentation. And once again, thanks for working on ECA, it has enormous potential.

@jurgenhaas commented Jun 24, 2024

ECA should be opinionated out-of-the-box, and ship with a sane default modeller, to make on-boarding new users easier. With the current complexity, we are shooting ourselves in the foot, and creating a bigger barrier of entry, than it needs to be.

We could turn this around. So far, the issue you're describing is because we put ECA in the centre of the "universe".

Putting ourselves into the shows of a non-Drupalist, shouldn't we push BPMN as a tool for them top be in control of what their Drupal site can do for them. That would then come with the integrated ECA, which for that audience is not that relevant. What matters to them, there is a great UI that let's them build applications without programming.

In other words, we may have to start positioning BPMN as the no-code solution for Drupal in its own right. And ECA just comes with it, but not on the front page.

Sorry, for discussing all this in this PR, where it's completely off-topic. We should have that discussion over in ECA's issue queue or Slack channel.

Update Issue Summary.