/admin/studies to add user to study

• Title, start, end, chat duration (default = 30 mins)
• Default study by url param
• Only for students with a tutor/chatbot

added To do label

changed the description

assigned to @bridubois

changed milestone to %0.2: Essential functions ready & corrective feedback

marked the checklist item Default study by url param as completed

marked the checklist item Title, start, end, chat duration (default = 30 mins) as completed

mentioned in commit b0c1deaa

I've done a first implementation of studies, but I have 2 questions before I can go further:

• As the study is part of the user, couldn't it be just possible to edit that field too in /admin, rather than a completely new page? Especially now that /admin allows to edit users attributes.
• Are tutors also assigned to studies?
• Should we have an admin page to create new studies? For now, it works using /docs.

added waiting + 1 deleted label and removed To do label

Good points. Rather:

• I'd implement the studies and users as 2 separate tables with a join table, if it's not too difficult. Even though if not frequently, a user may participate to multiple studies.
• Yes, I think tutors should be assigned to studies (same join table). For instance, users should only be able to select a tutor from the specific study pool.
• Ideally, yes, it would be great to have an admin page for new studies.
• If possible, the main way to assign users to a study could be via the registration URL ( /register/studyid, e.g., /register/19 ) or in a dropdown at registration, otherwise.
• Study influence the tests that are required at registration, the pre/post tests, the activation or non-activation of the feedback forms such as the weekly questionnaire, etc. (hopefully this doesn't complicate things too much; for now, as there will only be one study, it is not that important)

• If a student is part of multiple study, should he have a "in progress" one? How can we know which study's data to use for the tests/weekly surveys/...?
• Currently, a user can already join a study using /register?study=X. Should we use this only as a default for the dropdown, or should it be forced? Same for tutors?

Good questions.

1. No, I think both studies would be active, and all the log data would be included in both studies. StudyID would determine which tests/questions/surveys get sent to the participant/student, and hence would influence which data is collected, but if study1 and 2 both require VocabularyTest3, then VocabularyTest3 is opened and collected (once) for both studies.

2. I think it should be forced. Dropdown is then NOT shown. Yes, same for tutors.

Here is screenshots from the new registration process. The path is /register/[study_id], and the drop-down is disabled if a study_id is provided. If not, he can select one from the list.

The only thing is that, ideally, details of the study should influence the informed consent form (step 1), so if no study_id is provided, it should ideally be required BEFORE the first step of the registration rather than here (and hence, could be hidden here).

But it's already great!

The new workflow ask the study first, and skip that page if the study is in the URL.

If this workflow suits you, I would like to merge it to be able to develop other features based on this one, without diverging too much from the dev branch.

This is great, yes! Let's go with this.

mentioned in issue #49 (closed)

As said in #49 (closed), the study should also determine if a weekly survey should be shown, and how often.

removed 1 deleted label

removed waiting label

mentioned in issue #88 (closed)

changed milestone to %0.2: Essential functions ready & corrective feedback

added Studies & tests To do labels

Here is a preview of the current work on studies. The new frontend currently allows to create, see, update, delete and add/remove users to studies. Details in the frontend can obviously be improved (such as user management and session duration), but for now it's thought to be functional.

ll-studies

Is it what is expected for studies @sbibauw? If so, I will implement the adapted tests and registrations soon.

Sorry, I thought I had replied here. This is great.

Main thing missing, ideally: defining which tests to administer at registration (i.e. procedure/registration pipeline for participants) and at other moments, eventually.