response type as a single choice image

[jchough1]

So for the experimental design that I am working on, I want to run through and present a sequence of 300 images one by one under a set duration of time, and record if the user clicks the image (as well as the response time associated with it).  However, based on what I can see in the grammar reference page, as well as my own testing of the code, there is no response type that is suited for this purpose.  The closest option that I can think of would be to use the response type "choice", with the image that we wish to present as the response, but that would make the stimulus redundant, and the program forces me to have to create a second option besides the single image that I wish to present.  
Is there any way to achieve what I am looking to accomplish? 
Here is a link to the study we are referring to if there is still any confusion:
https://osf.io/preprints/africarxiv/q8k5w/

[Ting]

Hi! This is a great question. Please let us investigate if it makes sense to allow for only one choice option in the choice response. If that becomes possible, would it solve the problem?

[[email protected]]

Hi Ting - Replying alongside Jino, who is working with me.

Yes, I think having a 1-option choice would solve the problem. The actual design is just a visual statistical learning study (analogous to speech segmentation), so we need to rapidly present a sequence of single images. The catch is that we need the images to be click-able because the cover task is target detection (e.g., "click on the blue alien when he appears"), so that is why we're using the Choice response. Importantly, we need to log the initial click, and not require a secondary "Submit" step for the choice, since the presentation continues (800ms + 200ms ISI) regardless of user response. If there's already a better way to approach this problem, we're very open to ideas!
-Ben

[Ting]

Gotcha! It sounds like the easiest (and the conceptually cleanest) way is to make the choice response work with a single choice! We'll work on that right away next week! We should have a solution for you by early December. I will reply again to give you an interim update after Thanksgiving.

[[email protected]]

Thank you, Ting and FF team! Looking forward to trying it out!

[Ting]

Hi Jino and Ben,

We have made a few tweaks so that the choice response can be used with a single choice now, when the response is used in a "basic" trial template. If researchers use the choice response in an "AFC" trial template, it will still check whether at least two choices are defined. Hope this makes sense.

This new feature is currently only available on our testing site https://testing.findingfive.com - can you help us verify that it indeed works as expected? The testing site represents a "beta" version of FindingFive with slightly newer features, and shares the same underlying database with the production site (so you don't have to recreate your studies). Once you guys give the OK, we'll move the feature to the production site so you can use it in a real study!

Thanks again for this suggestion.

[[email protected]]

We'll test it out this week and let you know how things go. Thanks FF Dev Team, and thanks Ting!

[[email protected]]

The one-option choice is now working, presenting one clickable image on the screen at a time!
We do have a problem with the timing, though: It seems to have severe delays corresponding to the "Response received" animation that follows each Choice event. We ran a mock-up with 106 repetitions of 800ms stimulus + 200ms ISI. (That's a bit less than half the length of the real experiment). It should have taken 106 seconds to complete, but it took 365 seconds. The data output is here, showing only small timing errors for each event, hence my inference that the problem exists in transitions between events.
I tried turning off the "submission_point" feature to prevent the data upload from causing a network latency between trials (thanks for the tip, Ting!), but it does not seem to be actually disabling the feature. "Response received" still appears after each trial. Is this the correct code to define "familiarization_trial"?

Code:

"familiarization_trial": {
    "type": "basic",
    "delay": 0.2,
    "submission_point": false,
    "responses":["m1r","m2r","m3r",...]
}

[Ting]

Aha! You are correct that the response received message still popped up. That's not the intended behavior, and we'll fix it today.

[Ting]

Hi Ben and Jino, the "submission_point" bug should be fixed. Can you try again to see if the timing has improved?