search

UiL-OTS-labs / jspsych-spr-mw

A self paced reading with moving window experiment using jsPsych
GNU General Public License v2.0
6 stars 3 forks source link

Repeating the survey, lose all data or not #1

Closed maartenuni closed 3 years ago

maartenuni commented 3 years ago

Currently the following function runs at the end of the survey procedure.

    loop_function : function () {
//        if (repeat_survey) {
//            // clear data (this might clear to much)
//            jsPsych.data.reset();
//        }
        return repeat_survey;
    }

The lexical decisions experiments throw everything away at that point. This could potentially be harmful. Because everything before the survey is discarded as well.

maartenuni commented 3 years ago

Ik heb jullie even om hulp gevraagd. Ik heb de surveys overgenomen met een paar aanpassingen van de visual lexical descision experimenten. Als de survey op nieuw moet worden gedaan, dan wordt op dit moment alle bestaande data weggegooid. Dat is erg lastig. Helemaal als we bijvoorbeeld besluiten dat we de "declaration of consent" voor de survey doen; de survey is immers onbruikbaar als we geen declaration of consent krijgen. Het zou handig zijn als we op de een of andere manier wat preciezer de survey data wegdoen. Of de laatst gelogde gebruiken in geval dat de proefpersoon de survey opnieuw doet.

tymees commented 3 years ago

Ik heb destijds die code geschreven, en heb er toen wel goed over nagedacht.

Helaas is er niet een manier dat data van specieke trials kan verwijderen, ik heb het tenminste niet gevonden in zowel de documentatie als code. Aangezien destijds de survey de allereerste trial waar je daadwerkelijk data van wou hebben, leek mij dit een prima oplossing om niet meerdere keren de survey data te krijgen. (Elke keer dat ie loopt zorgt voor een extra entry).

Maar nu met consent is het inderdaad wel wat anders... Desiree is nog bij Joris de Graaff aan het navragen of je ook moet opslaan of je consent hebt (dit kwam ook op bij het babylab). Wij dachten namelijk dat het feit dat je geeneens de data kan versturen zonder dat vinkje aan te klikken al genoeg 'bewijs' is dat het vinkje is aangevinkt.

Het kan dus zijn dat we niet per se die consent moeten opslaan, alleen moet het dus wel 100% verplicht zijn dat de data alleen opgeslagen wordt als dat vinkje is toegepast.

Een workaround is de consent opslaan als algemene variable, maar dan krijg je die kolom wel bij elke row erbij.

irisopgithub commented 3 years ago

zou het helpen om de declaration of consent na het surveyblokje te doen? dan moet dus wel als iemand geen consent aanvinkt, de surveydata verwijderd worden (maar dat is geen probleem, als ik het goed begrijp).

irisopgithub commented 3 years ago

de laatst gelogde surveydata gebruiken lijkt me ook prima trouwens.

je moet sowieso de surveydata er met de hand uit gaan trekken als onderzoeker, omdat je die data (vaak) op elke regel zult willen hebben als je gaat analyseren. en zelfs als je dat niet wilt, wil je de surveydata allemaal lekker in 1 excelletje bij elkaar hebben zodat je bijvoorbeeld gemiddelde leeftijd makkelijk kunt uitrekenen.

dus enig handwerk ontkom je toch niet aan.

tymees commented 3 years ago

zou het helpen om de declaration of consent na het surveyblokje te doen? dan moet dus wel als iemand geen consent aanvinkt, de surveydata verwijderd worden (maar dat is geen probleem, als ik het goed begrijp).

Dit is GPDR technisch wel oke, de data wordt inderdaad toch pas helemaal aan het eind verzonden, maar het staat mij bij dat de UU graag deze consent altijd als eerste wil ontvangen. Dit weten Marijn of Desiree vast beter dan ik.

Ook lijkt het me heel raar om als participant eerst al mijn data in te moeten vullen en dan pas gevraagd te worden of ik het uberhaupt wel wil laten regristreren...

de laatst gelogde surveydata gebruiken lijkt me ook prima trouwens.

Dit lijkt me dan op korte termijn de makkelijkste oplossing. Gewoon er een opmerking over bijzetten bij de data documentatie en nooit data leeghalen.

omdat je die data (vaak) op elke regel zult willen hebben als je gaat analyseren.

Kunnen we dan niet op lange termijn kijken naar het niet als aparte regel op te slaan, maar juist toe te voegen als kolommen aan elke regel (zoals groep en pp nummer al gedaan wordt)? Als het toch op elke regel gezet gaat worden door de onderzoeker...

maartenuni commented 3 years ago

zou het helpen om de declaration of consent na het surveyblokje te doen? dan moet dus wel als iemand geen consent aanvinkt, de surveydata verwijderd worden (maar dat is geen probleem, als ik het goed begrijp).

Dit is GPDR technisch wel oke, de data wordt inderdaad toch pas helemaal aan het eind verzonden, maar het staat mij bij dat de UU graag deze consent altijd als eerste wil ontvangen. Dit weten Marijn of Desiree vast beter dan ik.

Ook lijkt het me heel raar om als participant eerst al mijn data in te moeten vullen en dan pas gevraagd te worden of ik het uberhaupt wel wil laten regristreren...

de laatst gelogde surveydata gebruiken lijkt me ook prima trouwens.

Dit lijkt me dan op korte termijn de makkelijkste oplossing. Gewoon er een opmerking over bijzetten bij de data documentatie en nooit data leeghalen.

Dit lijkt mij ook het makkelijkste

omdat je die data (vaak) op elke regel zult willen hebben als je gaat analyseren.

Kunnen we dan niet op lange termijn kijken naar het niet als aparte regel op te slaan, maar juist toe te voegen als kolommen aan elke regel (zoals groep en pp nummer al gedaan wordt)? Als het toch op elke regel gezet gaat worden door de onderzoeker...

Ik zit er ook wel eens over na te denken om alleen bij de relevante trials de relevante data in een aparte array op te slaan, en dan onze eigen kopie te json-ifyen en die op te sturen naar de server. De logging van jsPsych sucks bigtime.

maartenuni commented 3 years ago

Hmm, ik heb denk ik een snood plannetje om toch de laatste x aantal gelogde trials te verwijderen.

tymees commented 3 years ago

Do tell

maartenuni commented 3 years ago

jsPsych.data.get(), geeft een referentie aan de interne DataCollection(). DataColletion.values() geeft een referentie aan de javascript array trials. Die array heeft een lengte en dat is een beschrijfbare property of een array met side-effects :-)

collection =  jsPsych.data.get();
trials = jsPsych.values();
trials.length = trial.length - x;

Dit moet ik nog ff uitproberen, maar ik denk dat het moet werken omdat je een referentie krijgt en "x" kunnen we zelf een waarde geven :-).

tymees commented 3 years ago

Snood plannetje indeed. Ben benieuwd!

Edit: als je een referentie hebt aan de array, is het niet handiger om .pop() te doen? Array lengte aanpassen is mischien iets te hacky?

maartenuni commented 3 years ago

Tja, zo bekend met javascript ben ik dus niet. Ik kijk wel even waar het schip strand.

array.pop() verwijderd 1 element, de lengte aanpassen lijkt me beter dat bijvoorbeeld 3 maal pop te doen.

maartenuni commented 3 years ago

Ik denk dat deze code moet werken:

let survey_procedure = {
    timeline : [
        survey_1,
        survey_2,
        survey_review
    ],
    loop_function : function () {
        if (repeat_survey) {
            // clear last trials of the survey
            let collection = jsPsych.data.get();
            let trials = collection.values();
            trials.length = trials.length - this.timeline.length;
        }
        return repeat_survey;
    }
};

repeat_survey is een globale variabele die op false wordt gezet in de survey_review.

Edit: add this.timeline.length, timeline alone is not defined. Edit2: In de output kan je wel zien dat de trials verwijderd zijn doordat de trial_index die je van jsPsych krijgt van 0 naar 4 spring, ik haal namelijk 3 trials weg.

tymees commented 3 years ago

Hm, blijkbaar is deze methode een geaccepteerde methode om een array te vergroten/verkleiner. Had ik niet verwacht, het voelt verkeerd, maar het blijft JS.

Je kan proberen voor de trail_index om jspsych.global_trial_index te verlagen met this.timeline.length. Dat lijkt veilig te zijn.

Als dit inderdaad werkt kunnen we kijken of we dit in een PR kunnen zetten bij JSPsych, dit hoort eigenlijk gewoon in de API van JSPsych te zitten...

jcvanelst commented 3 years ago

Kunnen we even afstemmen via teams, morgenochtend bijvoorbeeld? Ik weet niet welk probleem ik nu precies moet oplossen en wat men wil. Zover als ik begreep is de consent pagina bedoeld als showstopper, als er geen vinkje komt, moet er niet door gegaan kunnen worden, maar misschien is dat beter anders vorm te geven dan met mijn minimale implementatie van een alert, maar moet er iets gedaan worden zoals in de init functie met Maarten's flow gebeurt qua mobile detection: (indien geen consent, breek alles af?).

tymees commented 3 years ago

Kunnen we even afstemmen via teams, morgenochtend bijvoorbeeld?

Ik lig dan waarschijnlijk te slapen, dus ik ben er niet

Zover als ik begreep is de consent pagina bedoeld als showstopper, als er geen vinkje komt, moet er niet door gegaan kunnen worden, maar misschien is dat beter anders vorm te geven dan met mijn minimale implementatie van een alert, maar moet er iets gedaan worden zoals in de init functie met Maarten's flow gebeurt qua mobile detection: (indien geen consent, breek alles af?).

Een alert lijkt me inderdaad niet de beste oplossing. Die werken niet betrouwbaar genoeg hiervoor. Het lijkt me inderdaad beter om af te breken en een simpele tekst te tonen.

Overigens ging deze issue niet over de consent zelf, maar over een gerelateerd issue dat de consent data misschien verwijderd wordt door de survey. (En of dat een probleem is of niet).

jcvanelst commented 3 years ago

okay, ik probeer er morgen iets van te bakken, thanks!

maartenuni commented 3 years ago

Hm, blijkbaar is deze methode een geaccepteerde methode om een array te vergroten/verkleiner. Had ik niet verwacht, het voelt verkeerd, maar het blijft JS. Zo werkt het ook bij properties in python. getters en setters in CSharp, Zo raar is het niet.

Je kan proberen voor de trail_index om jspsych.global_trial_index te verlagen met this.timeline.length. Dat lijkt veilig te zijn.

Ik vind het niet zo'n probleem om te zien dat er 3 trials missen, met die info kunnen we zien hoe vaak een pp die trials opnieuw heeft gedaan. Als dat te vaak is, zeg er missen 15 trials, kan je dat als criterium gebruiken om zo'n participant eruit te wippen. Ik wilde alleen iedereen er bewust van maken.

Als dit inderdaad werkt kunnen we kijken of we dit in een PR kunnen zetten bij JSPsych, dit hoort eigenlijk gewoon in de API van JSPsych te zitten...

100% mee eens!!! Dan mogen ze bij jsPscych ook nadenken wat ze willen met de trial index. Ook verkleinen of gelijk houden.

maartenuni commented 3 years ago

Kunnen we even afstemmen via teams, morgenochtend bijvoorbeeld? Ik weet niet welk probleem ik nu precies moet oplossen en wat men wil. Zover als ik begreep is de consent pagina bedoeld als showstopper, als er geen vinkje komt, moet er niet door gegaan kunnen worden, maar misschien is dat beter anders vorm te geven dan met mijn minimale implementatie van een alert, maar moet er iets gedaan worden zoals in de init functie met Maarten's flow gebeurt qua mobile detection: (indien geen consent, breek alles af?).

Je hoeft hierbij geen probleem op te lossen, er is geen feature request of bug report. Ik wilde even jullie input over wat er met de data moet gebeuren als iemand de survey opnieuw doet.

Ik was niet zo'n fan dat alle data er uit gemikt word. Daarbij voorzie ik scripts die stuk gaan omdat bijvoorbeeld de welkoms pagina niet meer in de output zit. etc. voor de spr-mw-boilerplate heb ik gekozen om de output van de laatste 3 trials (de survey) eruit te mikken.

jcvanelst commented 3 years ago

ik heb alleen nog 7 templates op mijn naam staan waar nog iets mee moet in deze. maar misschien is het okay om dit dan in januari nog even met hernieuwde energie door te spreken?

tymees commented 3 years ago

Ik wil het ook wel voor je doen Jacco, ik heb dit 'probleem' in je template gezet dus ik vind het wel fair als ik hem voor je corrigeer.

Ik vind het niet zo'n probleem om te zien dat er 3 trials missen, met die info kunnen we zien hoe vaak een pp die trials opnieuw heeft gedaan. Als dat te vaak is, zeg er missen 15 trials, kan je dat als criterium gebruiken om zo'n participant eruit te wippen. Ik wilde alleen iedereen er bewust van maken.

Hm, ja dat is eigenlijk best een goed punt