@Hugi, as we found our developer for this already, tell the Discourse Meta community that the call is closed?
No doubts about the quality of the plugin and its author … still I think it does not fit well into our software infrastructure. I will explain … but, first of all, hello and welcome from me 
I’m the guy in Edgeryders who has to try keeping all our IT infrastructure organized …
I’ll just list my reasons in no particular order and then let’s see if that persuades you:
-
Effort comparison. The Custom Wizard plugin would need the following extensions to work within our setup: (1) action type for user account creation at the end, as mentioned by Angus, (2) custom action implementation of that account creation action because we use SSO accounts so account creation has to be done remotely at the SSO provider side for which we now have a custom API endpoint. The custom wizard platform is a more generic solution, which is nice to have but also takes more effort to adapt (rule of thumb …). So the effort for both variants is comparable.
-
Core and periphery: what goes where. For this you need a bit of backstory: the previous (2012-2017) version of this web platform was built on, of all things, Drupal. When we made that decision, Discourse was not around yet, and we also initially liked the idea that admin users could adapt data types, forms, behavior and other aspects of the user interface using the admin interface, without having to do programming. That turned out to be a perfect recipe for a buggy mess of a software
and we’re now really staying away from “user configurable forms and data types” inside our core platform. The core data of Discourse is posts and users, with the occasional custom user record field – nice and clean! Discourse and other “new wave single purpose” applications are great because they do one thing very well, instead of trying to do everything and failing spectacularly (like Drupal).On a tangent: The failure of the “configuration over programming” approach taken by Drupal, at least as regards our use case, also means that I’m now much more inclined towards small, flexible software components that need programming for adaptations, rather than complex, generic components (like form builders) that supposedly need no programming but then always turn out to be just a bit too limited for a use case to really need no programming …
Now it certainly would not do harm to have one form builder plugin inside Discourse – it’s just that I try to establish this general architecture of keeping Discourse very close to its core function as a forum, while keeping peripheral data and features (forms, presentation websites, surveys etc.) to other independent web applications.
-
Stand-alone software or not? The Custom Wizard plugin has an unusual “semi-independent” software architecture: it is its own Ember application, but configurable from inside Discourse under the
/wizard/route. I understand where that comes from, as it’s a generalization of the Discourse setup wizard, which necessarily had to be a separate Ember application. (And we do a similar thing with our annotation system for Discourse by embedding a Rails engine into the Discourse interface under/annotator/.)However for this use case, we anticipate quite several (>10) future deployments based on this form software over the years, most of which will be in close connection with project-specific small custom websites that have nothing to do with Discourse and are made using Vue.js. With that in mind, I think for us it makes sense to go all the way to independence: the survey / form software would only talk to Discourse by API, not sharing a admin user login or data storage with the Discourse database. It’s just the usual “high cohesion, loose coupling” principle of object oriented design, applied to applications …
-
Standardization. As an internal standard, we have Ruby (with Rails) for backend and scripting work and JavaScript (with Vue.js) for frontend work. I’m a huge fan of standards in IT, even if just within one organization: it helps with interoperability of components, finding and keeping developers, the economics of learning new technology, re-usability of the hosting setup on our server etc… That would be a reason to keep with the Vue.js approach for this little project, esp. given that there is previous work inside our organization to combine it with for a joint effort.
Now if something makes sense to just add to Discourse Core or an existing Discourse plugin, we’ll gladly deviate from our standard and use the Ember framework. Because then it’s a one-off project for an external developer, it will live in the upstream code base and we create no future legacy for our organization. That can’t work though if we expect that piece of software to be something we’ll work on and constantly expand though, such as in this case of the form-building component.
To sum up, I propose to not use the Custom Wizard Plugin for this project but rather go with the original proposal for a small independent Vue.js application, connected to Discourse by API.
Anyway, thank you for bringing that plugin to our attention. It definitely has its uses, and we may consider it for what we consider core functionality of this platform. (For example we use a form to collect consent to data usage in research before a user posts for the first time. With an added “show before posting” action, the Custom Wizard Plugin would be a good candidate to replace our current implementation of that feature.)