Skip to content

XGov Form Builder

Jump to bottom
Daniel Burnley edited this page Jan 27, 2022 · 2 revisions

https://github.com/XGovFormBuilder/digital-form-builder

User based forms spike update

Spike wrapped up on 27/01/2022

PRs based on this spike:

Changes required

The PR goes into more detail, in short:

  • Add an external API for storing forms
    • Note: Whilst this isn't strictly required, it's a bit easier to manage user based forms via an authenticated API
  • Create a method for storing a token to authenticate against the API that also identifies which user
  • Create the code for persisting to this API in the XGov-Designer
  • Create the code for connecting the runner to the API, rather than depending on locally stored forms

Thoughts on adding user based forms to the XGov form builder

  • Not too difficult to do, adding the API layer and interactions is fairly simple for storing forms
    • (Aside: We should commit this API Persistence code back to the main repo as it would be useful for other people)
  • One thing missing is the publish workflow for the runner to interact with
    • This can be added separate to the xgov builder though, expanding the API to have a "publish" endpoint, as well as a PUT update for just the general form. As the designer doesn't currently have a clear concept of "publishing" vs "Saving" it leaves it to the API to implement as they want
  • The runner is solid, we'd want to figure out how forms with the same name may conflict across departments
    • This could be mitigated via other routes (e.g. Storing the form under an organisation and putting that organisation in the URL also)
  • The submission method is currently stored in the code of the runner, we could add another "API" submission method as a default and create a new submissions API

Initial recommendation going forward (Dan)

The XGov designer/runner are probably a fine base to get things in place during private beta - although (as things move forward) we're likely to replace at least one of them with our own from scratch as the users of our service differ, it can get us in good stead for private beta where we can support our users more if required.

The main outstanding question would be how to handle the authentication when we're connected with another service, until we have an authentication service to test this out we will need to wait to answer this.

At the moment I'd recommend that we consider the following approach:

  • Reuse the XGov Designer in the beginning of private beta
    • We could disable functionality we don't want in our version by just removing code (e.g. Integration with govuk pay)
  • Reuse the XGov Runner in the beginning of private beta
  • Adapt the two to use our newly created forms API (which can handle the publishing)
    • This could (and should where it makes sense to) involve committing some of our changes back upstream
      • API Persistence layer
      • API Connection for forms in the runner
      • (?) Proposing a solution for authentication, though our approach may wildly differ to what would be ideal from the XGov community
  • Build up the supporting apps separately using our chosen tech stack, E.g.
    • Form management frontend using Rails for the form/organisation management interface
    • Submitter API build using
  • Assess the urgency of replacing the designer, and begin to work towards it when it makes sense to

Trade offs to be aware of and considerate of reusing these (based on my experience changing things):

  • The format the forms are stored in will have to be using the existing XGov form model to begin with, and any iterations in the future may become complex as they're large JSON documents which makes them harder to change
  • The XGov Designer is designed for more DDaT specialists than our service is aimed at, we may need to give more support to the users in private beta
  • We did not build the XGov Form Builder, therefore working with it will require some level of onboarding/figuring things out if we do ever encounter any bugs with it that need fixing
  • The XGov Form Builder has not been accessibility tested (?), which means we need to be aware of the impact that may have on people with accessibility needs in the short term (- Other points can be listed here in the future if we think of any)

Dan's looked at it with a view to adding accounts/auth.

  • xgov forms is just an editor for json forms, which you then give to the runner
  • Does have a persistant layer (uses runner and s3 as persistance)
  • blob store doesn't work
  • we could use this as an editor, setting the persistance layer as an authenticated jwt layer
  • bounce the management of the auth to a separate service
  • discussion: should we use this? It's react, and maybe not accessible.
    • Keyboard navigation with tab is not possible
  • Could we change it? Maybe starting from scratch is better
  • Maybe we could plug in this as the forms designer for Alpha, rewrite it in the future
  • Publishing and preview could be done outside, as an api, keep it out of this builder

When you open a form in the form builder, it COPIES it?!

Go back Home

Clone this wiki locally