The resulting artifact is composed of a number of components - the METT module, the questionnaire module, run-time configuration, deployment scripts, and text assets. These components are replaceable with other components on an as-needed basis. I present a graphical representation of the module dependencies Figure \ref{fig:modules}. In the following sections, I will discuss the developed artifact discussed in detail.
The artifact developed does not use the object-oriented design paradigm; instead, I used a design based on modules containing functions. Where possible, I avoided, unnecessary state modifications. Indeed, outside of functions concerned with screen rendering, input management, and input and output, state is not modified. Additionally, inputs were read once and not mutated after creation; outputs written once, and screen rendering produced no alterations of state as visible to the main artifact. After configuration, the only state read is user input from the keyboard.
The Python modules expects configuration in the JavaScript Object Notation (JSON). These configuration artifacts consists of three separate files—one with overall configuration global applicable to each trial and question of the experiment. This file is stored with the filename \texttt{options.json}, and an example of its syntax in Listing \ref{lst:options}.
\begin{lstlisting}[caption={\texttt{options.json} configuration file},label={lst:options}] { “NameOfTheExperiment”: { “forward_mask_frames”: 40 “backward_mask_frames”: 40, “expression_frames”: 12, “intertrial_interval”: 2, } } \end{lstlisting}
The second file, \texttt{trials.json}, specifies paths to image files for masks and stimuli as well as correct responses for each individual trial of the METT paradigm. An example of the syntax used for this file is Listing \label{lst:trials}.
\begin{lstlisting}[caption={\texttt{trials.json} trials file},label={lst:trials}] { “NameOfTheExperiment”: [ {“stim”: “PathToStimulus.JPG”, “neu”: “PathToMask.png”, “correct”: 5}, // … ] } \end{lstlisting}
Finally, a third JSON file, \texttt{questions.json}, specifies the questions used, and the keybindings which code keypresses to responses, an example of this file is shown in listing \ref{lst:questions}.
\begin{lstlisting}[caption={\texttt{questions.json} question specification file},label={lst:questions}] { “NameOfTheExperiment”: [ { “question_id”: 25, “responses”: { “1”: “Option One”, // … }, “text”: “Question” } // .. ] } \end{lstlisting}
To simplify the configuration and use of the system, I developed a number of utility scripts, including scripts for generating RaFD subsets, starting the system in a given configuration state, and running a demonstration mode of the software. These scripts do not run in the normal operations of the appliation; however, they are useful in setting up a reusable environment.
To make the application localizable to different languages, a system for text assets was created. Text assets such as instructions, can be created as needed. These assets are used to programmatically translate the application.
The system’s initialization is responsible for initializing the system on load. The first task is to collect the subject identifier and experimenter initials. Once this is done, the current time and hostname are collected to help with diagnostics. The module then delegates to the configuration module which then proceeds to deserialize configuration files and load them into memory. After loading files it passes-on the trials to the METT module which performs the trials. When the METT module has performed its trials, the initialization module invokes the question module, passing on the questions. When both METT and questions have been completed, collected responses are written to CSV.
Before the experiment starts, the module shuffles the order of trials used in the experiment. This results in each participant experiencing the trials in a pseudo-random, nonsystematic order.
The trials are invoked in order; upon invocation, the trial handler loads the relevant images from disk, showing a blank screen while loading. Once the images have been loaded, the picture of the neutral expression is shown for a fixed but configurable number of frames. Once frames have rendered, the emotional picture is displayed, for a configurable number of frames. Then, finally the neutral image is shown.
Once the pictures have been displayed, the system displays a prompt and starts accepting keyboard input. Once it collects an answer, the screen is cleared. The flow of execution then halts for a configurable number of seconds before yielding control.
Once the trials are completed, the system takes the trial data and combines it with the response data. This results in a one-row-per-trial-data set, which is then serialize and saved to disk as a CSV file.
After the METT module has completed its work the questionarie module is initialized. Each question consists of three components, a \texttt{question-id} that is logged to the output, a text description for prompting the user, and a mapping, \texttt{keymap}, between keyboard key names and a text-string containing the answer text.
Each question is then presented in order. A question’s presentation is performed as follows: First, the question text and the response options are rendered to the screen as text. Keyboard input is read. If the input read matches a response alternative, the key and response time are stored in memory. This is repeated until each configured question has been performed. After the task is complete the results are saved to disk in the CSV format.
Both the questionnaire and METT modules write their results to disk in the CSV format with filenames generated using the current time and current hostname. The output was designed to be as simple as possible and usable in many statistical environments. An example of METT and questionnaire output can be found in Listings \ref{lst:resultmett} and \ref{lst:resultquestionnarie}, respectively.