App handling is too restrictive

[somas95]

AFAIK currently the app handling works as follows: Each session config has a hardcoded sequence of apps, in which apps cannot be repeated. At any time during the experiment there is an upcoming_apps dict which has the remaining apps (but not the ones already played/skipped). It is possible to skip to an app by using app_after_this_page.

This works for many situations but it is restrictive for many others. For example, it is not possible to aleatorize the app sequence per participant without creating extra rooms with the overhead that implies, or to run an experiment with an ABA structure where an app is run again after some task.

It would be highly beneficial with no other drawback to change from upcoming_apps to something like available_apps, where it would be just a dict with all apps in app_sequence, allowing app_after_this_page to jump to any of it without restriction

[oTree-org]

Thank you for the suggestion. I agree this would be useful for some experimental designs, but it goes against the grain of how oTree is designed as a multiplayer platform. For example, WaitPages keep track of who has arrived and who hasn't. If each player is jumping through apps on the fly, how do we determine who has arrived and who hasn't? It's impossible to define who is ahead and who is behind, when everyone is going through a different sequence.

When you create a session, creating_session is run to set up each app, so you can do e.g.:

def creating_session(subsession):
  for p in subsession.get_players():
    # randomize, etc....

This makes it simple to do things like make balanced treatment groups, etc. But with the dynamic design, this whole system wouldn't work. When would creating_session get run? It can't be ahead of time as it is now, because we don't know what the app sequence will be. The alternative would be to run it when a single player gets directed to an app. But creating_session is a subsession function that affects other players. It doesn't make sense to trigger it for a single player.

From an implementation perspective, this is also something that would introduce a lot of complexity internally. Currently the page sequence is fixed. It makes it easier for me to reason about, and to make performance optimizations. So internally I can determine exactly how many pages are in a session, where a player is in the sequence, what the status is of each WaitPage, etc.

By the way there is a sample app "sandwich design" in otree-snippets that implements the ABA design.

[oTree-org]

Also consider other functionality like "Advance slowest participants". That wouldn't work either, if we consider each player to have an individually dynamic app sequence.

I think the fixed app sequence is a simplifying assumption both for implementation and for users to understand how oTree works.