[Ncomeau]

Was able to fix this and the replaying during feedback collection issue with your advice, thank you so much again Jeremy!

[Ncomeau]

When I go to edit the penncontroller.js file it only shows a view icon, and when I try to upload a new item to controllers it says “you do not have permission to upload to this location”…

[Ncomeau]

I sent a link to the admin@pcibex.net email. Let me know if you have any trouble with it!

[Ncomeau]

Hi again Jeremy,

I’m just about ready to publish my experiment on prolific, but while running some sanity checks today I noticed that in turning the debugger off I’ve somehow broken the quit trial (sends results and displays a canvas telling the participant to return to prolific). With the debugger on, the message displays properly but when I turn it off the experiment hangs on a black screen with the quit button still present where it’s position on any given trial. Any ideas why this may be the case?

Nickolas

[Ncomeau]

Works like a charm, thanks again Jeremy!
Just a heads up for anyone else trying to use this, I had Send_results() in my sequence before the “end” trial and that seemed to break this method. Moving the call to right at the beginning of the end trial fixed it.

[Ncomeau]

Hi again Jeremy,

I have successfully been using code similar to that detailed in #5684 to allow the participant to quit via a button that’s present in any given trial. I’ve since added a section to the success of the getScale(“quit”) that allows the participant to provide feedback via a newTextInput element, just before a Send_Results() function call. The logging seems to work fine with the same code at the end of my experiment (I have a separate trial for feedback before sending results), but the same code in the header does not seem to log correctly. This makes me think that properly logging an item must be tied to the header/trial actually completing in full, as currently if they quit the last bit of code in my header just waits indefinitely on a text telling them to return to the Prolific window they came from. Do you have any idea how I might prompt an addition of their feedback to the results file mid header?

Thanks,

Nickolas

• This reply was modified 3 years, 9 months ago by Ncomeau.

[Ncomeau]

Code that properly exits fullscreen for me (for some reason adding .documentElement breaks it):

newFunction( ()=> {
if (document.exitFullscreen)
document.exitFullscreen();
else if (document.mozCancelFullScreen) /* Firefox */
document.mozCancelFullScreen();
else if (document.webkitExitFullscreen) /* Chrome, Safari and Opera */
document.webkitExitFullscreen();
else if (document.msExitFullscreen) /* IE/Edge */
document.msExitFullscreen();
}).call()

[Ncomeau]

Jeremy,

Is there a way to pause (rather than stopping) a timer element? I am trying to do this currently by stopping the timeout timer I have for each trial (created in the header) when the user clicks the quit button, and start it back up if they select no. This works as intended if they click quit prior to the timer.wait() call at the end of the main and catch trials, but if they click after it just goes onto the next trial due to the wait being resolved. The other potential solution would be to reset the timer to a significantly higher value while they are on the yes/no quitting canvas, but I’m not sure if that’s possible either. I’m using calls to end(), .stop(), and clear() to handle when they say yes to quitting, so having a way to pause would make things less hacky in that I wouldn’t need to end the trial first.

Nickolas

[Ncomeau]

Hi Jeremy,

Going along with the question I had above regarding changing the sendingResultsMessage: Is there a way to change/remove the text that appears during a checkpreload function call? It would be like changing things from “Please wait while the resources are preloading. This may take up to 30s.” to “Loading, please wait”. A little nit-picky but I mostly want to avoid jargon / participants feeling like they missed something.

Thanks again,

Nickolas

[Ncomeau]

No worries, I think a solid workaround for now would be housing the headphone check in a separate eligibility/screener experiment that gets linked to from prolific, and then linking to our main experiment from there based on a url parameter. That would at least impose that there be no reason to refresh in the main experiment. I’d be interested in hearing more about what’s going on under the hood once you’ve done some testing.

Thanks again,

Nickolas

[Ncomeau]

Jeremy,

Using the clear removes everything so long as all of the elements have been loaded in for the next trial. I have my two choice buttons show up first, then one pops up for replaying the audio. If I use the stop button prior to the replay showing up, it will still appear. Also, the clear does not seem to handle the timer issue as the next trial still appears. When I try to do something like getTimer(“timewindow”).stop() just before SendResults(), it says “Attempted to get an element of an invalid type (Timer);timewindow” in my error log even if I’ve waited long enough for it to start. Perhaps this is due to having added the code to the header? I will try setting a variable “quit” to true and then testing to see if that’s the case after my timeout timer is defined in the main/catch trials.

[Ncomeau]

Jeremy,

I am using the method above to allow for exiting and sending results early. I am having some trouble getting the elements associated with my main trials to stop appearing over top of the canvas, and I also can’t seem to pause the timer that I use for a timeout of the main trials (so currently the next trial appears despite having clicked the quit button). Also, just a small thing with the method above: newScale(“quit”, “Yes”, “No”).button() does not seem to add a space between the Yes and No options when they appear on the canvas.

[Ncomeau]

Hi again Jeremy,

I think there was an issue with sending my experiment links from my wisc.edu email or my gmail to support@pcibex.net and admin@pcibex.net. It said they were not deliverable due to being unverified addresses? I think we are going to handle group assignment with separate prolific experiments anyways now, but something I noticed about the withsquare URL parameter is that it works no matter what if I append “ExperimentName/server.py?withsquare=0”, but sometimes breaks if I only use “ExperimentName/experiment.html?withsquare=0” and the counter is not deleted beforehand.

Some other miscellaneous questions I’ve had in finishing up the experiment are:
Is it possible to append a tag to every line of the log on the final trial (and send_results function call) of my experiment? I am sending results on every trial in an effort to retain information should the participant quit early, but I still haven’t found a great way to indicate the relevant final chunk of logged items in my results file.

Also, is there a way to make the progress bar larger / move its position on screen, and adjust or remove the “Sending results to server…” text?

[Ncomeau]

Of course, I will send the link to the support email.

[Ncomeau]

Jeremy,

The SepWithN function seems to work a lot better, so I’ve gone ahead and removed my changes to the definition of the modifyRunOrder function.

Regarding the table / counter interaction, I am using my groups to assign one of eight mutually exclusive sets of stimuli (housed in different zip files on AWS) to participants so while the name differs across groups, I was not having any issue with preloading prior to setting up these functions to insert break/catch trials. Up until now, I’ve been forcing a particular group number by running my experiment with “?withsquare=0”. If my understanding is correct, this will load “subject_0.zip” from my AWS location, and the filenames in that zip file correspond to all of the lines of my CSV where the group field is 1. When the counter has been freshly deleted, the preloading of each individual file works as expected.

Some things that I noticed today however were:
For withsquare=1 (group->2), the debugger tells me that my subject_1.zip downloads fine, but there are not any lines in the debugger saying the individual files were successfully preloaded (and the experiment hangs on preloading). This is the same thing that happens when I don’t delete the counter for an attempt of withsquare=0. Is it possible that the counter is overriding my explicit selection of a group with withsquare?

Another strange thing that I noticed is that rather than increasing upon every run of the experiment, my counter is increasing every trial. Is that due to sending results every trial perhaps? If so, I can just manually reset the counter to whatever its value was at the beginning of the script. The more that I think about it, doing my group assignment with counter rather than withsquare in the URL might be easier in the end as I would like to allow for the user to continue on to another set of data. This could be hard to do if they were initially assigned the last group with withsquare=7 and I would then somehow need to bring that back down to 0 again as opposed to just incrementing to 8.

I hope this makes sense, and I appreciate your patience given that some of my design choices go against the grain for existing penncontroller functionality.

Nickolas

[Author]

Posts