Overview of the psiturk dashboard
The dashboard provides many useful configuration options, AMT account information, and tools for paying participants and exporting data.
By default, the psiTurk dashboard is unprotected, which is generally safe if you're running or testing an experiment locally. However, if you plan to run your experiment on a remote server, protect the dashboard using a username and password. This can be done by adding a username and password under the dashboard section of the config.txt file in psiTurk's base directory. Delete these fields to remove the login requirement.
The top bar contains central server and database features. The export data dropdown menu provides CSV snapshots of the database for trial data, event data, and questionnaire data. The experiment server toggle [turn off?/turn on?] launches/tears down the experiment server. Note, the experiment server must be on, indicated by a green light, to run and test experiments.
The first option along the left bar is the dashboard, which summaries your current account balance on AMT, currently available HITs, etc. The Live and Sandbox tabs display the current HITs posted on AMT and AMT Sandbox. The remaining options configure psiTurk, as described below.
Incidentally, the configuration options are also directly editable in plain text via the config.txt file which was created when you ran psiturk-setup-example. It is good practice to shutdown the dashboard by pressing cntl-c in the terminal before editing the config file to avoid conflicts.
AWS Info sets or changes your AWS credentials.
Database configures where psiTurk should store the data from your experiment. By default the system uses a local SQLite database. This will be written to a file in your current project directory called 'participants.db' (another option you can configure), which is created when you first run psiturk in the folder.
SQLite is a light-weight database solution and is fine for local testing but may not be ideal for running live on AMT. In particular, SQLite does not allow concurrent access to the database, so if the locks work properly, simultaneous access (say, from multiple users submitting their data at the same time) could destabilize your database. In the worst (unlikely) scenario, the database could become corrupted, resulting in data loss. Thus, we ultimately recommend recommend using a deployment-robust database solution such as MySQL or PostgreSQL. See Databases for more information.
For the purposes of this tutorial, however, the default SQLite database will be okay.
Server allows you to configure the Experiment server (see Types of Server Processes). This is the server that your participants will access when running the experiment. Here you can customize the port number and other various options about your experiment, including support for Internet Explorer. Note, if the Support IE box is unchecked, psiTurk will prevent IE users from accessing in your experiment.
HIT Config configures how your HIT will appear to participants when they are browsing possible jobs to perform. This includes the title of your task, a short description, keywords, the actual URL that you want to direct participants to (this should ultimately match what you configure under the "Server" options), as well as things like how long each HIT should be available for and what the worker requirements should be like.
Expt Info configures other options about your experiment. This includes the code version (a number that will be stored with your data file and may be helpful in remembering which version of your task the participants actually saw), the number of experimental conditions and counterbalancing conditions (taking advantage of psiTurk's built-in method of randomly assigning participants to conditions as well as if you want to provide a debriefing afterward.
Pay lists participants who have completed your task and are awaiting payment. Accept and reject buttons determine if the participant will be payed or not.
Server Log launches a log (console.app for Mac users) file containing psiTurk's server messages, which can be helpful for debugging.