Amsterdam-Music-Lab / MUSCLE

An application to easily set up and run online listening experiments for music research.
https://www.amsterdammusiclab.nl/
MIT License
4 stars 1 forks source link

Reusable practice phase #92

Open BeritJanssen opened 2 years ago

BeritJanssen commented 2 years ago

In the rhythm experiments, some logic for letting the participant practice was introduced, but this may not generalize well for other kinds of experiments. Ideally, we should have some utility functions for a practice phase which can be reused for any experiment which needs practice rounds. This practice phase defines the number of rounds the participants gets to practice each time, and a pass condition (i.e., how many correct results are required) before the participant enters the experiment proper.

Evert-R commented 2 years ago

I have some ideas about this:

BeritJanssen commented 2 years ago

I personally think that the session.current_phase field might only make sense for a small portion of experiments, and will not add any information to the database that is interesting for users later -- they'll want to know which result is associated with which phase, and on session this field will be whatever value was set last. So I'm all for putting a phase field which is null=True, blank=True on the Result model. But if the comment field can be used for this for now, we might also just reuse this field, and perhaps give it a more descriptive name, e.g., "type"?

As far as I can see, all the reasoning will always go over the session.result_set anyway, or is there a direct advantage to knowing the session.current_phase which cannot be covered with the json_data? I know working with the json_data is unwieldy, but as far as I noticed, it's no bottle-neck to performance.

Again, if it's too inconvenient to work with existing fields (and I may be overlooking some problems!), go for it and add fields, but otherwise, I'd rather keep the models as lean and multi-purpose as possible.

Evert-R commented 2 years ago

I think you are right that we should only change this if it will make sense for a substantial number of future experiments. Working with the json_data as we do now does feel a bit counter intuitive, but indeed this doesn't seem to affect the performance, and does provide a lot of freedom to build whatever we want.

The comment field in the result is also fine as it is now, if we are not going to fill this with the current phase.

Maybe we can only make the comment field a bit easier to use then by adding it as an (optional) argument to prepare_result? And also show the comment in the result in the django admin, cause I noticed it's not there.

Evert-R commented 2 years ago

I've made a subtask for the optional comment parameter in prepare results.

https://github.com/Amsterdam-Music-Lab/aml-experiments/pull/248

BeritJanssen commented 1 month ago

I decided to still work on this issue. The rhythm experiments I originally implemented include some practice phase which has a lot of shared syntax, but the way it's implemented is pretty complex and depends on functions with a plethora of arguments: I'm afraid no-one will really know that the helper functions I implemented back then exist, or how to use them. I'm planning to move this to a dedicated practice.py rules file, from which experiments can inherit & perhaps piggy-back on some logic that's already been implemented.