Set Group_by_arrival_time to True... but not first in page sequence

104 views
Skip to first unread message

Seyit Hocuk

unread,
May 16, 2022, 12:27:06 PM5/16/22
to oTree help & discussion
Hi Everyone,

I have a specific problem, which I have not seen asked/answered before (if so, I apologize).

I want to create a wait page after some introduction pages where the participants will be matched. I call this "Waitforgroup". I face problems here, because I have to choose one of two methods with each having a different downside. I am hoping to find a solution to one of them or at least a workaround.

If I make two seperate apps, which are then put in sequence, I can have my group_by_arrival_time set to True in the second app where I want to match participants. This helps in the option of creating a room where participants are matched irrespective of their order, i.e., whoever comes next is matched with the incomplete group of three. We will have over 100 partcipants (in groups of three), where the final three may be the only incomplete group in this manner.

The downside of this is that between the app sequences, in the Waitforgroup page there is the infinite wait scenario, because the information is not sent from the earlier app to the next app if one participants leaves, times out, or does not consent. I have seen that other people in this Google groups are trying, perhaps successfully, to create a timer on these waiting pages. The small upside is that this is a less likely scenario.

If, on the other hand, I make only one app, I cannot put the Waitforgroup page later on in the page sequence and still set group_by_arrival_time to True. The code complains immediately that it must be placed first in page_sequence. But we need to have some intro pages before we want to match.

Setting group_by_arrival_time to False does not allow for the option (of creating rooms or otherwise) that the next player will be matched to an incomplete team of three. Every player has a preset order and therefore a predetermined group. This means that there can be potentially a lot of incomplete groups of three (instead of just one at the end ), if there is some reasonable fraction of dropouts in the case of 100+ participants. This is pretty unfavorable.

The only solution I can think of now is not very elegant, which is to utilize general links and put some pages with which we can still identify the participants somehow. Long story short, each participant will be awarded in some way (some small incentive is given). But this is very inelegant, prone to identification mistakes, and also has some potential privacy concerns. As stated earlier, the other solution is to somehow put a timer on the matching pages to avoid infinite waits (which is also relatively inelegant).

I hope that my explanation is clear, and that there is a simple solution to all of this.

With kind regards,
Seyit




Seyit Hocuk

unread,
May 24, 2022, 5:25:11 AM5/24/22
to oTree help & discussion
I guess, there is no easy solution.
Reply all
Reply to author
Forward
0 new messages