Summary: UI components and workflow interfaces

[SimonHeybrock]

Overview

I would like to summarize where we are after the widget hackathon (see #28), what key problems to be solved we have identified, etc. The goal is to decide on a course of action, e.g., when key features are essential and must be implemented, what can we defer or ignore.

Key open questions

• Workflow classes in technique packages: -> Keeping functions creating pipeline, interface for UI uses free helper functions
  • Should these subclass Pipeline, or wrap it, or simply create one? Before the hackathon it was the latter, which had significant advantages when directly interacting with the created workflows (pipelines) in a notebook. We have seen problems with both the subclassing and composition approach that would need to be resolved.
  • Another option to consider is separating the existing workflows (keeping them as they are) from the corresponding interfaces for the UI. This seems feasible since there is no state in workflows aside from the Pipeline object.
  • Users will still want to modify the workflows, e.g., by adding custom correction steps, which may also require new input parameters. The setup mechanism must be compatible with this.
• Dealing with map-reduce transformations of workflows (usually wrapped in helper functions). -> Using global registry for mappers. Maybe need to be refined to workflow-specific mappers in the future, but this works for now.
  • This must be linked to "mappable" parameters where users can input a list or table of values. We also need to ensure this is compatible with how results are computed, since keys will get duplicated (may need sciline.compute_mapped).
• How to embed or interact with Plopp? Plots will need to be interactive.
• How to define layouts for better UX?
• How to define param descriptions from docstrings? This currently does not work with types defined via NewType or for Generic instances.

Major features (not curated)

• Dump and load config, to avoid need to repeatedly re-enter same info into many widgets.
• Put workflow outputs into a registry, so they can be accessed programmatically, as well as displayed in a special UI component. This would open the doors to allowing plotting of selected outputs and much more.
• Pass objects from the global (or other) namespace as workflow inputs. For example, a user may have computed the DirectBeam or BeamCenter using workflow A (possibly using widget A), and now wants to set it as input to workflow B (in widget B).
• We probably want to make the workflow selector optional: In many cases a workflow is either pre-defined (user Python code) or fixed (one notebook per purpose). Split out into a separate widget?
• Generate Python code to set parameters.
• Run workflows on a table of files (independently, not necessarily using map-reduce) producing a table of outputs.

Architecture and design

• Should/can we use a standard pattern like MVP or MVC for the UI?