RAPID-MIX_API issueshttps://gitlab.doc.gold.ac.uk/rapid-mix/RAPID-MIX_API/-/issues2017-09-20T14:03:39Zhttps://gitlab.doc.gold.ac.uk/rapid-mix/RAPID-MIX_API/-/issues/36Writing examples as building blocks2017-09-20T14:03:39ZFrancisco BernardoWriting examples as building blocksExamples were considered “cool", “ea. one useful in its one way", “the whole set providing of building blocks” which can be “borrowed”.
Recommendation:
* Users will benefit from examples become building blocks that they can readily in...Examples were considered “cool", “ea. one useful in its one way", “the whole set providing of building blocks” which can be “borrowed”.
Recommendation:
* Users will benefit from examples become building blocks that they can readily integrate in their code (scaffolding for capturing data, either to local storage or to a service)
* Some of the external libraries like the MYO have hidden global values it makes it difficult to use. The building blocks (i.e., sensor bridges) should have the exposed methods and state carefully designed, just as the API.https://gitlab.doc.gold.ac.uk/rapid-mix/RAPID-MIX_API/-/issues/28Self-explanatory code and commenting practices2017-09-20T12:31:53ZFrancisco BernardoSelf-explanatory code and commenting practicesUsers considered code comments as important as documentation. Code comments compete with the main documentation, particularly for certain users who bypassed documentation completely, or who prefer to refer to it much later in the explora...Users considered code comments as important as documentation. Code comments compete with the main documentation, particularly for certain users who bypassed documentation completely, or who prefer to refer to it much later in the exploration and development workflow, for troubleshooting for instance.
Recommendations:
* Examples' code should be comprehensively commented in sections with “magic numbers” (e.g. number 5 in RapidStream, number of Gaussians, etc.)"
* Examples such as the RapidStream would benefit from adding the rationale and usefulness for each feature in the UI.https://gitlab.doc.gold.ac.uk/rapid-mix/RAPID-MIX_API/-/issues/35Make server-side technologies robust and resilient, and pack them for local i...2017-12-02T23:09:29ZFrancisco BernardoMake server-side technologies robust and resilient, and pack them for local installationAll technologies should be made cross-platform (windows & linux support), to prevent the risk of the RAPID-MIX API to miss out on a significant share of end-users. This happened recurrently across the many of the UCD sessions.
Recommend...All technologies should be made cross-platform (windows & linux support), to prevent the risk of the RAPID-MIX API to miss out on a significant share of end-users. This happened recurrently across the many of the UCD sessions.
Recommendation: Server-side technologies should be open-sourced, and made robust and resilient for quick set and local installation, specially during UCD and dissemination actions.https://gitlab.doc.gold.ac.uk/rapid-mix/RAPID-MIX_API/-/issues/52JUCE example buggy2017-12-13T14:23:03ZMichael ZbyszyńskiJUCE example buggySam has demonstrated on his machine that the JUCE example seems to be failing to record training data. When he goes through the steps of holding the space bar and moving the mouse, it complains that there isn't any data.
I'm not able to...Sam has demonstrated on his machine that the JUCE example seems to be failing to record training data. When he goes through the steps of holding the space bar and moving the mouse, it complains that there isn't any data.
I'm not able to reproduce this on my machine. He's using an older version of JUCE, and I'm using a tablet rather than the trackpad.https://gitlab.doc.gold.ac.uk/rapid-mix/RAPID-MIX_API/-/issues/30Design patterns for using the RAPID-MIX API2017-09-20T12:59:27ZFrancisco BernardoDesign patterns for using the RAPID-MIX APIRAPID-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"...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
https://gitlab.doc.gold.ac.uk/rapid-mix/RAPID-MIX_API/-/issues/34Communicating the Interactive Machine Learning workflow to users2017-09-20T13:35:28ZFrancisco BernardoCommunicating the Interactive Machine Learning workflow to usersThe interactive machine learning workflow is difficult to convey with static sources of descriptive knowledge, such as text (documentation, comments, etc.) and even code. This is because of of procedural nature that the workflow entails....The interactive machine learning workflow is difficult to convey with static sources of descriptive knowledge, such as text (documentation, comments, etc.) and even code. This is because of of procedural nature that the workflow entails. Live demonstrations have been working pretty well for us, but were not always there.
Recommendation: We should find way to complement the documentation with richer media. Richer media, such as video and animations, are more effective at communicating the procedural nature of the workflow and yield better adoption.https://gitlab.doc.gold.ac.uk/rapid-mix/RAPID-MIX_API/-/issues/33API documentation fragmentation2017-09-20T13:04:40ZFrancisco BernardoAPI documentation fragmentationUsers' feedback reports about how the documentation of the different components is fragmented: different sites; different content, design and user experiences, and potentially, different authors.
Recommendations:
* There should be a ...Users' feedback reports about how the documentation of the different components is fragmented: different sites; different content, design and user experiences, and potentially, different authors.
Recommendations:
* There should be a common medium, method and style for documentation, which will reduce the adoption friction.
* ORM for MySQL, Postgres, loadash, underscore, KNX, and Processing, were given as reference examples of good documentation.