Design patterns for using the RAPID-MIX API

RAPID-MIX API users, as developers, would benefit from design patterns for macro or frequent use operations, that should be consistently implemented across examples.

Recommendations:

• Users would benefit from having the "record", "train" and "run" controls and modes made as visible and explicit as possible. A design pattern that unifies this kind of usage across examples, would provide a stronger scaffolding for understanding the RAPID-MIX workflow.

• Participants didn’t explore much feature selection in their process, sticking to what was given by default. Participants would benefit from a design pattern, or any scaffolding, that structures feature selection and the features meta-information across the examples.

• There aren’t many examples that save/load the “configuration data” (training data set or model). It would be useful to provide a design pattern for API examples that offers selection between pre-trained models (inputing stored training data, either from local or remote storage) and a new model to be trained from scratch, so that they can explore other features of the pipeline working with data, a feature selection and ML algorithms and parameters tuning.

• A design pattern that makes explicit the fast, realtime, and iterative nature of data streams, could benefit the users in understanding how to design with data. This could be achieved by rendering the feature vector or frame of data that is passed as input for training