EXPERIMENT DESIGN: Stage 11: Research Program Development [37338]

NOTE: Some users may include copyright notices in their experiments. Be respectful of the constraints authors place on sharing script, and always give credit for script used.

Stage 11, Step 1: Modifying Experiments

When modifying experiments, it is important to maintain consistency as much as possible. This will aid not only in the understanding of the differences between versions of an experiment, but also in the merging of data files collected by different versions. Consistency should be maintained not only in the naming of the experiments themselves, but also in the naming of factors and attributes within the experiments. For example, it would be easiest to view the differences between files if objects performing similar duties were similarly named (e.g., the object presenting the stimulus should be consistently named Stimulus). Procedures running tasks at specific levels of the experiment are more easily understood if named to reflect the level (e.g., TrialProc, BlockProc).

When making modifications to an existing experiment, it is recommended that new conditions be added rather than deleting old conditions, making the new experiment a subset of the modified experiment. Detailed records should be kept to outline the differences between versions of an experiment. Another useful practice is to name versions of the same experiment using a consistent experiment name and a version number (e.g., ExpName-001.es3).

With the intention of merging data files, care should be taken to maintain consistency in the naming of variables (i.e., attributes and levels). For example, if an attribute is named “Stimulus” in the first version of an experiment, and “Stim” in the second version, the merging of the data files obtained by the two versions would result in two columns of data for what is essentially a single attribute. The values for half of each column would be set to NULL. The user would necessarily have to copy and paste information in order to relocate the appropriate information.

Consistency in naming of levels and attributes will avoid potential errors during the merging of data files. E-Merge will report problems if the same name is used to refer to an attribute in one data file and a level in another. Likewise, errors will be generated during a merge operation if a single name is used to refer to different levels in different data files (e.g., level 2 is called “Trial” in one data file and “SubTrial” in another). With the exception of the same name being used for both a variable and a level, the problems are not impossible to overcome, but are inconvenient and would require some manual editing.

Take care not to change the meaning of a variable across experiments that are to be combined for analysis (e.g., do not use Probe to refer to animals in one experiment, and fruits in another). If need be, add a new attribute or level, but avoid changing the experiment without modifying the logged variables.

Stage 11, Step 2: Sending Experiments to Colleagues

An E-Prime 3.0 license owner is free to distribute any files created by using the system. Files created by users include Experiment Specification files (.es3), E-Basic Script files (.ebs3), data files (.edat3, .emrg3), and analysis files (.ANL). However, according to the license agreement, users are not permitted to distribute any part of the E-Prime 3.0 system, including the runtime application.

Licenses

The full E-Prime 3.0 license permits use of each of the applications available within the E-Prime 3.0 suite of applications. The full license permits the development of new experiments (E-Studio), collection of data (E-Run), merging of data files (E-Merge), and data editing and export (E-DataAid). The full license includes installation options to permit the installation of the full system, installation of only the runtime components for data collection, and a custom installation option to install only a portion of the full system. E-Prime 3.0 must be installed in some manner on any machine on which E-Prime 3.0 is to be used. For development, the full installation is required. For data collection, the Run-Time Only Installation is necessary. The custom installation is most useful for adding components to a previous installation.

Hints for distributing experiments

The following is a list of suggestions and considerations when sharing or distributing experiments:

• Include clear and thorough instructions for running the experiment - Many times the instructions for tasks or response keys are not indicated in the actual experiment instructions. To facilitate the running of an experiment by someone other than the programmer, it is suggested that thorough instructions concerning the task and the response keys be included as a display at the beginning of the experiment.
• Include design notes - It may not be obvious to the person receiving an experiment why certain values were used, why certain procedures were created, or what certain variables were recording. Notes field on the Common tab of each object’s property page is the ideal place for adding comments concerning the parameters, variables, and organization of the experiment. If the recipient does not own a license including E-Studio, access to the Notes is not possible. Therefore, a text file would be more appropriate.
• Include a shortened version of the experiment in addition to the full version (for demonstration purposes) - It is often convenient for the person receiving an experiment from someone else to be able to get a preview of the experiment and the data being collected. A shortened version will allow the recipient to quickly view the task, and to collect a small data file for examination rather than working through hundreds of trials.

Determine the type of license the recipient owns
Determining which license the recipient owns will establish which files are necessary to run and modify an experiment, or to examine data files.

Stage 11, Step 3: Developing Functional Libraries
It is likely that many experiments and procedures will be used repeatedly. Therefore, it is beneficial to develop a library of experiments or subroutines that may be modified, inserted, or used as patterns for other experiments. When an experiment has been completed and tested, it is suggested that a copy of the experiment be placed into the library. This copy serves as a record of the experiment, a clean copy that may be retrieved if modifications are made to the original file, or as the basis for a different version of the same experiment.

Another suggestion is to create a package file for procedures used repetitively (e.g., criterion-based exit of a procedure, contingent branching). Package files from a library may be inserted into new experiments in order to avoid wasted time regenerating existing script. Examples of package files might be the N-Back memory task item selection, psychophysical threshold procedures, or moving window text presentation. 

Next Article: EXPERIMENT DESIGN: Sample Experiments [23971]
Previous Article: EXPERIMENT DESIGN: Stage 10: Archiving Experiments and Results [37337]