Open BeritJanssen opened 2 years ago
I have some ideas about this:
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.
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.
I've made a subtask for the optional comment parameter in prepare results.
https://github.com/Amsterdam-Music-Lab/aml-experiments/pull/248
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.
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.