You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recall, each playlist will be assigned a chatMode in the database which will determine which UI users see (and which experimental condition they are under). This variable can be changed manually if we want to reassign experimental condition halfway through the study, for example. It would be nice to randomly assign the chatMode initially, but then we don't get control over how many playlists get each condition (we'd probably want an equal split). But manual assignment is difficult since the backend currently creates a document in the database when the playlist is first requested and initializes chatMode then. The solution is:
Create an additional little database for manually adding records of which playlist id should have which chatMode. When a playlist is first requested and a corresponding document is added to the main database, the backend will check this manual database for how to initialize chatMode (randomly if not found in the manual database).
There's still the question of: if we want to change the assignment during the study, do we change the smaller database and make the backend update the larger database accordingly, or do we update the larger database and use the smaller database only for the initial data?
The text was updated successfully, but these errors were encountered:
To allow users to use new playlists without having to share the id with us, make the little database track the mode for each user, not playlist. When a new playlist is requested it gets assigned whatever mode is listed for the owner user's id.
There's still the question of how updating should work, as explained above.
Also make this database a simpler csv file where each line is just userid,mode for easier updating.
Recall, each playlist will be assigned a chatMode in the database which will determine which UI users see (and which experimental condition they are under). This variable can be changed manually if we want to reassign experimental condition halfway through the study, for example. It would be nice to randomly assign the chatMode initially, but then we don't get control over how many playlists get each condition (we'd probably want an equal split). But manual assignment is difficult since the backend currently creates a document in the database when the playlist is first requested and initializes chatMode then. The solution is:
Create an additional little database for manually adding records of which playlist id should have which chatMode. When a playlist is first requested and a corresponding document is added to the main database, the backend will check this manual database for how to initialize chatMode (randomly if not found in the manual database).
There's still the question of: if we want to change the assignment during the study, do we change the smaller database and make the backend update the larger database accordingly, or do we update the larger database and use the smaller database only for the initial data?
The text was updated successfully, but these errors were encountered: