Create Task Wizard for better UX around maintaining task configuration

[jkuester]

Is your feature request related to a problem? Please describe.

From: medic/cht-roadmap#121

It's difficult to test task rules without deploying them on production
It's difficult to find and make sense of errors when setting up the CHT

Describe the solution you'd like

App developers can easily visualize and quantify the impact of a change to config tasks

The proposal is to create a new desktop application that essentially functions as a front-end for cht-conf. The MVP of this app should include support for creating a new task configuration

Describe alternatives you've considered

Other places we considered locating this task wizard include:

• The admin app in cht-core
• A rewrite/replacement of the admin app in cht-core
• A TUI wizard included directly in cht-conf

Ultimately the Admin app seemed like a poor fit for a couple reasons. Its focus is more on the mutable state of a particular CHT instance (e.g. users, message queues, etc) and less on the static config that can be maintained via cht-conf. Additionally, while app developers commonly use cht-conf, they are less frequent users of the Admin app as part of their development workflows.

A TUI in cht-conf would limit the long-term UX benefits that might be available to a graphical application used for configuring a CHT instance.

[jkuester]

Design Overview

Requirements

• Cross-platform (macOS, Windows, Linux)
• HTML/CSS/JS(TS) stack
  • Probably not hard "requirement", but should have a good reason for introducing new technology
• Can directly consume cht-conf
  • Actual functionality of the application should not extend beyond what can be done with cht-conf
  • Do not re-invent the wheel when it comes to deploying configuration to CHT instance
• Reads/writes configuration from files that can still be managed via SCM tool (git)

Architecture options

1. From scratch application built with cross-platform framework
   • React Native (JS)
   • Flutter (Dart)
2. From scratch web-app style application wrapped with browser-backed desktop app framework
   • Electron
     • Strong guarantees of cross-platform functionality since webview is bundled - particularly important for old/outdated OSs
     • Large executable size
   • Tauri
     • Uses system webview, so small executable size
   • See this comparison for more options
3. Build on top of an existing IDE framework
   • Theia
     • Basically allows for building a fully customized white-labeled VSCode (comparison with VSCode)
   • RCP 🤣 - We should not use this, but it was the only other framework I could think of in this category besides Theia...
4. Build extension for existing IDE such as VSCode

[jkuester]

Here are my personal thoughts, so far, on the above overview:

• The main problem for any app trying to be a GUI version of cht-conf is going to be dealing with cht-conf's dependencies.
  • Currently, managing forms with cht-conf requires:
    • xsltproc
    • python
    • pyxform
• As much as I hate to say it, currently I am leaning towards #4 because of these pros/cons (absolutely open to being persuaded otherwise):
  • Pros:
    • Quickest to develop (minimal amount of code to maintain)
    • Fits well into current app development workflows. Many devs already use VSCode and so this will not be "yet another application to open".
    • Keeps the wizard "close" to the config files themselves. One danger of using a graphical app to configure your CHT instance is that you forget to actually commit the changes you made to the config files themselves (and push them to your SCM). Having your config files open in your VSCode workspace and then using an extension to help maintain them helps take the bad "magic" out of a helpful wizard.
    • The dependency problems mentioned above can be managed via using the existing cht-app-ide DevContainer
  • Cons:
    • Opinionated with regards to IDE (not everyone uses VSCode). This is probably the most significant downside.
      • Using the new wizard is not required. So, developers with other workflows can still leverage cht-conf directly.
      • Not everyone uses VSCode, but it is probably a pretty high percentage.
      • Also, from the perspective of a non-VSCode user, is there much difference between having to switch to VSCode to run a config wizard vs having to switch to some other sort of stand-alone application?
      • Ideally, the extension could be architected in such a way that would make it easy to port to a different IDE if needed
    • Probably the lowest level of abstraction from the actual config files. I listed this as a Pro, but I think it also could be considered a Con because at a certain level, devs will still have to carry the mental weight of these files and their contents.
      • I think the benefits outweigh the downsides here, though.
    • Might limit future functionality in unforeseen ways (usecases that could be handled in a stand-alone app, but not an extension)
      • Something like project-explorer may not work as an extension

[garethbowen]

@jkuester Thanks for that fantastic analysis.

My main concern with the VSCode solution is if we start to target this app at less technical users, not just app devs. I think working their way around an IDE would be a significant hurdle if you've never seen one before. If instead there was a single command which spawned a docker container for the server (which takes care of the dependencies you listed), and then launched either option 1 or 2 I think this would be more accessible for a wider range of users.

I'm making a couple of assumptions here...

1. that we want to make configuration accessible to less technical users, and
2. that we want to extend this app later with additional features that are desirable for those users (for example, a GUI xform builder for service designers).