New implementations of real-effort tasks

[Qwigly Dee]

Hello.

I'm currently developing real-effort tasks for oTree.

The tasks being implemented so far:

- `captcha`: transcribing classic distorted text

- `arithmetics`: solving equations in form of "A + B ="

- `matrices`: counting 0 and 1 in matrices

- `symmatrices`: version of matrices with special symbols

- `colors`: guessing color names rendered with confusing color

Main features:

- live page with infinite iterations (micro-rounds) and timeout
- generating randomized puzzle on the fly
- creating images for each puzzle on the fly
- showing the images on the live page
- recording answer and outcome of each trial
- custom export of all recorded data
- some other anti-cheating checks

If you are interested in that kind of apps, please, try them out from here:

https://github.com/qwiglydee/otree-experiments

Feel free to post any feedback here or directly into 'issues' section on github.

Thanks.

--

Max

[Chris @ oTree]

Thank you Max! I'm looking forward to hearing people's feedback on these apps.

[Gian Luca Pasin]

Wow, thank you! These are really helpful!

What about the slider task originally introduced by Gill and Prowse (2012)? It shows participants a screen with 48 sliders, where each slider ranges from 0 to 100. Sliders are solved by moving the slider's marker (initially placed at 0) to the midpoint of 50. Participants are given 2 minutes to solve as many sliders as possible, with the participant's chosen effort given by the number of sliders correctly positioned at 50 by the end of the two minutes. Participants normally repeat the task 10 times and earn their accumulated earnings.

I have found the code here: 

https://github.com/chkgk/slider_task

but I have some troubles in coding it with oTree 5. Can you please help me? 

Thank you!

[Qwigly Dee]

I implemented the sliders task and added to the same repository https://github.com/qwiglydee/otree-experiments

That's kind of work in progress and I would like to know if the implementation is reasonable.

Being a software developer, I might miss some aspects and details important from research point of view.

One of goals of the work was to make apps cheater-proof and script-proof, and the strategy is to generate the tasks/puzzles as images and do not reveal any solution data into browser.
With sliders task that turned out to be quite challenging and the code might be too complicated.

This is how it works in current implementation:

- When the game page loads, the browser signals about it and requests sliders layout from server

- Server generates sliders layout:

  - a regular grid according to configured number of sliders and columns

  - sliders are placed within the grid with some random shift relative to center of cells

  - initial positions for each slider is chosen randomly

- All the setup is stored in database record (in an ExtraModel linked to the current session/round/player)

  - timestamp of generation is recorded

  - all positions of the sliders, offsets of their centers and initial or submitted values are stored as pixel coordinates

- An image is generated depicting all the sliders and visually indicating their positions and target points

  - no numbers are printed anywhere, everything is only visual

- The image is transferred to the browser along with the initial positions of handles

- Browser draws handles over the image (using JavaScript and Canvas API, no html involved)

  - the drawing script knows the grid layout, but doesn't know precise sliders'  positions (that's why it's possible to move knobs outside of slider range within grid cell)

- User grabs a handle, moves it and releases somewhere in slider

  - all the motion is going pixel-wise without any checking or snapping

  - only mouse down/move/release are handled, mouse wheel or keyboard are totally ignored

- When user releases a handle, a request is sent to server to check the new position

  - this request adds network latency time, so working time measurements are somewhat distorted

- Server receives the  request and checks it against stored setup

  - timestamp of the request is recorded

  - new value is stored in the record along with all other sliders' values

  - the value is also snapped to steps of the slider (so, a user doesn't need pixel-wise accuracy when moving handles)

  - the value is checked against actual position of the slider center

  - total number of correct sliders is recalculated and saved

- Server respond with results of the check:

  - if the value is correct

  - step-aligned value

  - if all the sliders are correctly positioned

- Browser redraws handle indicating if it's correct with color

  - the sliders'  handles are not locked, so a user can move them away from correct positions for no reason, or accidently

- When all sliders are positioned or timeout happens, browser completes the game and proceeds to results

- For the results

  - total number of correct sliders is available from the same database record

  - difference between timestamps of last submit and layout creation approximates work time

It's also possible to make sliders work the same way as other RETs:

with infinite or limited iterations of new sliders' setups (or separate single sliders) with or without timeout.

The code is basically there, just not activated.