ChRIS UI: High-level conceptual design for ChRIS UI

Some notes from our meeting a couple of weeks ago that need some fleshing out:

# Notes

## User groups

Clinicians work at a feed level.

Researchers work at a project level. Are projects personal or not?

## Pipeline/tree (What to call this?)

A feed can be a tree, not just a linear pipeline. The feed starts with data, and all subsequent operations are applied to the data. The feed can be serial, or it can be branched.

There is value in putting together a pipeline/tree feed, running it against an image, then taking that ordered tree of plugins and rerunning on a different data set. Pipelines may just consist of a single step, but they could be valuable to be saved and shared and rerun to share the config parameters with other researchers / for other data sets / etc.

## Project sharing

This is a long-term idea. The current version of ChRIS is permissive but productive. PEople don't seem to do complex pipeline analysis, we suspect researchers are happy with workflows that are just one operation.

# User Interface Objects

These are the main object types we want to think about long-term for the ChRIS UI. They may or may not necessarily each have a user-friendly name below:

## Plugin

A containerized set of image processing software, akin to say a filter in Photoshop or the like, that can be applied to data to manipulate it. Plugins can be chained together to produce a tree / pipeline that outputs manipulated versions of the data.

## Node

A specific point within the feed pipeline / tree. Basically a specific plugin at a specific place within the feed tree.

## Feed

A feed is a *specific run* of a set of plugins in a tree-based pipeline. This may or may not be the best term to use for user-facing front ends. (But maybe it's fine.)

## Data

Data is the actual data that the feeds operate on / manipulate. (Do we need to go more granular on this?)

## Plugin pipeline

We need a better name for this object. The plugin pipeline is one or more plugins chained together plus a set of config for those plugins. (E.g., plugin A with X = .5 and Y = .99 + plugin B with X = .001 Y = .99 and Z = .4 could be an example pipeline.)

Unsure if the specific computing power configuration (e.g. how many / which processing resources in the cloud etc. are going to run the job) is part of the config here, but I suspect not.

## Project

(Doesn't exist right now) A composition of pipelines + data and maybe ACLs and metadata (notes, chats, labels, etc.) for collaboration.

# Other concepts

## ChRIS store

An app that helps manage the plugins that may be made available to ChRIS users to include in their feeds. The cube admin can pull plugins from the ChRIS store to register them to his ChRIS deployment and make them available for users.

(Will there be just one ChRIS store or can there be multiple?)

## Feed plugins

These are ChRIS plugins of a specific type that create a feed. The expect only one positional parameter: where data is out put. They can do processing, but have no input data. The PACS plugin is a feed plugin. You always have to start a feed with a feed plugin.

## Data plugin

These are ChRIS plugins that need two positional parameters - the plugin node that comes before it, and the plugin node that follows after it. DS == data synthesis == data synthesis plugin == data plugin

A think a TODO for this ticket would be:

- [ ] fact-check the above
- [ ] map some of these concepts out visually
- [ ] brainstorm on some better user-facing terms for those that are maybe too confusing to expose to users. E.g., 'plugin pipeline' needs a better name.

Fleshing some of this out a bit better I believe is going to help make the UI more intuitive because some of these concepts / objects are a bit muddy right now I think.