Code screenshot script/bot

[ianchadd]

This is very open-ended, so it will require a bit of documentation to make sure that whatever solution you create is easily used by myself and Dr. Aksoy. For example, the below description have everything framed as saved png files in some folder, but if you think of a solution with slideshows/PDFs/etc. that would also be fine (for the most part). The end goal is to have a record of the appearance of the interface, so as long as your solution meets that goal, we're likely to be fine with it.

For all experimental projects, we save screenshots of the interface for record-keeping, regulatory approval, pre-registration, publication, etc. We've been doing this manually, but obviously this is inefficient.

We need a script/bot/test (something, not sure what to call this) that will do the following:

1. For a given session configuration, navigate through each app and page
2. Takes a screenshot of the page
3. Saves the screenshot in a folder on the repo (is this the most efficient solution?) using a consistent naming convention (e.g. a screenshot could be saved like "{date}{Session config name}{app name}_{page name}.png"
4. If the page/app has any conditionality to it (e.g. the html displays something different for Participant A than for Participant B as in the Trust Game you've programmed already), we need a screenshot for each option (saved with an identifiable name)

@billuraksoy Anything else to add?

[ianchadd]

Now that I think about it a little more, in an ideal world, this script would be automated such that it ran automatically upon deploy. So I'm imagining a world in which the following sequence might happen:

1. Make edits to repo
2. "git push origin testing"
3. Script runs after successful deploy/Heroku build
4. We immediately have access to these screenshots (without running an experimental session, running a separate python module, etc.)
5. This does not overwrite old versions of the same screenshots

[mcdaij]

Just to clarify, you'd want the program to be able to traverse the application capturing the screen on each page of the application and possible view of that page? Do you want it to perform inputs on each page? If so, do you want those to be entered in at runtime, saved in a text file in the page design, etc.? If not, what about the pages where input is required to continue? How would you want it to handle the pages where it would have to wait for some criteria for it to display the page fully, as in the instruction pages in the example you gave where you have to wait 30 seconds for the "Next" button to appear?

[ianchadd]

1. Yes to traversing the application and capturing the screen on each page of the application. "Each possible view" is not absolutely necessary (since some screens have interactive elements, etc. that would make this difficult). But the program should capture "large" variations in screen appearance (if that makes sense). For example, if the only thing that is conditionally displayed on a screen is essentially a word or two (e.g. displaying Task 1 or Task 2, depending on the round of play), that does not need to be captured. But for some applications (like the Trust Game), a decision screen appears totally differently depending on the participant's role. So we would need screenshots of all "role" screens in that case.
2. It does not need to perform inputs on each page (i.e. this is not an automated bot to test data)
3. If input is required to continue, the program should "override" that requirement (otree has an option for an admin to "advance the slowest participant" by one page if need be, so there might be something there that helps with this) or just put a random (valid) input for the sake of moving on, whatever is easiest to code.
4. Code this to only work for session configs/apps where there are no such required delays at first. I have a longer term plan of editing that "delay" code so that it has no delay by default (so that this delay code shouldn't be an issue, really).

[ianchadd]

Now that I think on it a bit more, it might be best to work on this in stages. So perhaps prioritizing just having it so that we can capture screenshots used in the apps that you've worked on today (survey, pg, trust) would be best. We can then generalize from there.

I say this just because there is a system for automated bots for testing (tests.py in each app on oTree) that handles something similar for back-end data testing. Perhaps a long-run general solution might rely on these automated testing scripts? We need to think about this more (and continue to get input from you), but a version that works for the most basic apps you've coded will go a long way in helping us develop more specifics about what is needed.