empiricaly / empirica Goto Github PK

Updating to to Meteor 1.7.0.3. breaks the outro steps:

Uncaught ReferenceError: stepNames is not defined
    at new ExitSteps (ExitSteps.jsx:28)
    at constructClassInstance (modules.js?hash=6733a8cd12786a21f27a7cc5ebfdca555242b2eb:48719)
    at updateClassComponent (modules.js?hash=6733a8cd12786a21f27a7cc5ebfdca555242b2eb:50203)
    at beginWork (modules.js?hash=6733a8cd12786a21f27a7cc5ebfdca555242b2eb:50589)
    at performUnitOfWork (modules.js?hash=6733a8cd12786a21f27a7cc5ebfdca555242b2eb:52588)
    at workLoop (modules.js?hash=6733a8cd12786a21f27a7cc5ebfdca555242b2eb:52652)
    at HTMLUnknownElement.callCallback (modules.js?hash=6733a8cd12786a21f27a7cc5ebfdca555242b2eb:42906)
    at Object.invokeGuardedCallbackDev (modules.js?hash=6733a8cd12786a21f27a7cc5ebfdca555242b2eb:42945)
    at invokeGuardedCallback (modules.js?hash=6733a8cd12786a21f27a7cc5ebfdca555242b2eb:42802)
    at renderRoot (modules.js?hash=6733a8cd12786a21f27a7cc5ebfdca555242b2eb:52730)
modules.js?hash=6733a8cd12786a21f27a7cc5ebfdca555242b2eb:52111 The above error occurred in the <ExitSteps> component:
    in ExitSteps (created by Game)
    in Game (created by ReactMeteorDataComponent)
    in ReactMeteorDataComponent (created by ReactMeteorDataComponent)
    in ReactMeteorDataComponent (created by Public)
    in main (created by Public)
    in div (created by Public)
    in Public (created by ReactMeteorDataComponent)
    in ReactMeteorDataComponent (created by Route)
    in Route (created by IdentifiedRouteInner)
    in IdentifiedRouteInner (created by ReactMeteorDataComponent)
    in ReactMeteorDataComponent
    in Switch
    in div
    in Router (created by BrowserRouter)
    in BrowserRouter

Consider adding an error boundary to your tree to customize error handling behavior.
Visit https://fb.me/react-error-boundaries to learn more about error boundaries.
logCapturedError @ modules.js?hash=6733a8cd12786a21f27a7cc5ebfdca555242b2eb:52111
meteor.js?hash=c8108d734cc548d91539b054e14b613d0c4512cc:1010 Exception from Tracker recompute function:
meteor.js?hash=c8108d734cc548d91539b054e14b613d0c4512cc:1010 ReferenceError: stepNames is not defined
    at new ExitSteps (ExitSteps.jsx:28)
    at constructClassInstance (modules.js?hash=6733a8cd12786a21f27a7cc5ebfdca555242b2eb:48719)
    at updateClassComponent (modules.js?hash=6733a8cd12786a21f27a7cc5ebfdca555242b2eb:50203)
    at beginWork (modules.js?hash=6733a8cd12786a21f27a7cc5ebfdca555242b2eb:50589)
    at performUnitOfWork (modules.js?hash=6733a8cd12786a21f27a7cc5ebfdca555242b2eb:52588)
    at workLoop (modules.js?hash=6733a8cd12786a21f27a7cc5ebfdca555242b2eb:52652)
    at HTMLUnknownElement.callCallback (modules.js?hash=6733a8cd12786a21f27a7cc5ebfdca555242b2eb:42906)
    at Object.invokeGuardedCallbackDev (modules.js?hash=6733a8cd12786a21f27a7cc5ebfdca555242b2eb:42945)
    at invokeGuardedCallback (modules.js?hash=6733a8cd12786a21f27a7cc5ebfdca555242b2eb:42802)
    at renderRoot (modules.js?hash=6733a8cd12786a21f27a7cc5ebfdca555242b2eb:52730)

At the moment, the player is unique per deployment (i.e., for the entire experiment), which is the common case in experiments (i.e., no repeated participation allowed). However, there are other possibilities:

• game level uniqueness: Participant is unique at the game level, such that the same participant can play multiple games (even within the same batch).
• batch level uniqueness: Participant can play only one game per batch.
• experiment level: what we currently have, which is a player can participate only once in the experiment (this holds true across batches).

When choosing a simple randomized assignment, stopping the batch from the admin UI doesn't really stop ongoing games.

For instance

export const onRoundStart = (game, round, players) => {
  console.log("Round ", round.index, " started");
  console.log("players are ", players);
};

will print an empty list of player [] when round.index is 0 and then it will populate the players fro round 1!

We need to put some demand on empirica and measure its response and scalability (i.e., simultaneous connections). It seems that the core can benefit from some performance optimization as well as we can provide tips and tricks for the experiments to improve performance.

It is weird that refreshing the page on the exit survey can break the browser (i.e., not responding) and feels really heavy and slow. The console shows Clock discrepancy detected. Attempting re-sync. which I don't know if related to this issue.

We want to be able to see if the player is online/offline, background/foreground (tab in background or not) and idle/active (user events: click, mouse movement, etc.).

The "Player" tab in the admin page (configuration tab) would include Authorization rules like:

• Unique participants? (true/false) Exclude those who have already played the experiment.
• Connection properties: reject incoming connections based on properties such as IP, browser type, PING (delay of communicating with the server), mobile devices (yes/no?), etc.
• Whitelisting participant: in case the experimenter wants to add a list of the participants who are allowed to play the game (i.e., whitelisting emails; MTurk IDs, etc.). In this feature, the experiment designer can upload additional information about the participants (i.e., their previous scores, gender, etc.).
• Dealing with disconnections:
  • Pausing the experiment and displaying a notice to all connected clients with a countdown to give a chance for the player to come back.
  • If the countdown reaches ends, the experimenter can configure the game to:
    • Continue with fewer players
      • Letting smaller groups continue ensures that real people generate all the information that participants respond to
    • Connect a bot player
      • Potentially compromises the internal validity of the data from groups affected by a dropout
      • Also raises issues of deception if such computer-generated information is not disclosed
    • or cancel the game, and redirect participants to the exit survey.
      • This will damage the reputation of the experimenter as participants will be unable to earn as much as they had anticipated.
  • The participant can come back, or otherwise fallback with a default behavior
    • I.e., that participant will give ‘null’ answers, and it is up to the experimenter to deal with the disconnection, i.e., player.get("status") will be offline and they can show a disconnection avatar or something). This will require implementing player.get("status") which can return: online, offline, idle, notLooking etc.
  • Note about disconnections:
    • If the disconnection happens exogenous to the experiment (e.g., due to network issues, screen freezes, a random real-life event that prevent the player from continuing the experiment), then it is ok and unlikely to affect the overall results of the experiment (just an expensive annoyance)
    • If a disconnection happens endogenously to the experiment (i.e., participants disconnect because of something that happened in the game--losing points, getting bored in one of the conditions, etc.) then this will jeopardize the internal validity of the results. This is so bad for the experimenter! They have to be careful.

For example, if we set up a game with playerCount=3, we can make it start with 2 following this procedure:

• http://group-discussion.meteorapp.com/?workerId=Test1
  • go to the lobby
• a new browser: http://group-discussion.meteorapp.com/?workerId=Test2
  • and go to the lobby
• Then from a new browser: http://group-discussion.meteorapp.com/?workerId=Test1
• The game will start with 2 players (instead of 3)! Although, two of the screens will be the same.

This is a highly likely scenario when working with MTurk workers (i.e., opening the URL from multiple browsers).

Also for player.round.set and round.set, etc.

Treatment object should always be under game including before game creation such as instructions.

Experiment designers need to be able to use Empirica core, design their experiment and later update core with the least amount of breakage possible. Currently the idea is to "fork" the repository and pull/merge upstream modifications of the core. This is a viable strategy, but there are others that might also be more practical for the user (e.g. Meteor package). Whichever strategy we end up recommending, we should also document this standard approach for using Empirica.

Should we add .set(.) and .get() for the game object? it seems useful for cases where the smallest unit of analysis is the round.set("answer",group_answer) like the room assignment game.

In that case, there is one score per round for all players round.set("score",score) and the cumulative score should be at the game level

export const onRoundEnd = (game, round, players) => {
  //add the round score to the game total cumulative score
  game.set(
    "cumulativeScore",
    Math.round(round.get("score") + game.get("cumulativeScore"))
  );
};

At the moment, game.set() is not supported.

We want to be able to edit and delete configurations (treatments, conditions, condition values and lobby configuration, etc.) but we don't want to break games that have already ran. So we should copy (freeze) all the configuration into each game.

We need to have treatmentobject in the Quiz section to ask questions like:

• How many participants will play at the same time, including yourself?
  Where the answer will depend on `game.treatment.playerCount'

changing things like the name/title of the app from Empirica to something else (i.e., 'guess the correlation' or something else). this should change the title of the app everywhere except the admin page (i.e., from the player perspective)

this issue just to collect ideas .. will split them into different tickets later.

From running few pilots, things that the experimenter would like to know are:
1- Participant level: id/ip/game/at what step for each connection and 1-way mirror (i.e., observing that player), and admin/participant chat.
2- Game level: how many participants, how many at the instructions, how many at the quiz, did the game start/end, what round/stage.
3- Batch level: how many connections (players connected), how many games started.

It would be great to add a clear option for an infinite timer and also to skip the default page.

At the moment, after the game became much smoother (i.e., using the new data loading scheme), the waiting time before the game starts (game loading) takes too long, relatively. Also, when the game loading page disappears we still have <\loading> for a second before the first stage runs.

it seems that the order of callbacks at the end of a game is:
onGameEnd => onStageEnd => onRoundEnd

The expected behavior would would be:
onStageEnd => onRoundEnd => onGameEnd

it shouldn't be in imports/core/startup/server/bootstrap.js .. we need to find a better way for users to set up their username/passwords.

For example,

1. code like this will not work:

 ExitSteps(game, player) {
    console.log(player)
    if (player.exitStatus !== "finished") {
      return [Sorry];
    }
    return [ExitSurvey, Thanks];
  }

Would always display Sorry as by the time the player gets into the ExitSteps the player.exitStatus is still not updated to finished. The update happens afterwards.

2. However, this works fine:

  ExitSteps(game, player) {
    if (player.exitStatus) {
      return [Sorry];
    }
    return [ExitSurvey, Thanks];
  }

I would say that the first one is more intuitive/expected than the second one.

In the instructions (i.e., intro) do we have access to the player data? (i.e., if the instruction depends on the player id or the source the player came from?

Can't tell whether it is set to ignore or fail.

we don't have onStageStart callback.

Based on a Pilot with workers:

• Almost 40% of workers missed noticing that their scores and survey code were on top of the exit survey.
• In the spirit of having good defaults for the experimenter:
  • We need to make it more conspicuous on the exit survey
  • We need to show it again after submitting the exit survey on the thank you page as many people submitted the survey and THEN expected to be shown the code.

The Blueprint JS library has released v2 (we're at v1) with various improvements such as the use of React 16's native Portal and icons as SVG. Version 3 is also in the works and seems to be progressing rapidly, so maybe upgrade to v3 by the time work is done on this ticket.

When creating a new batch, it would be nice to have a way to indicate that this batch is "test" so it can be excluded from the analysis. Maybe, adding more metadata to the batch so the experimenter can identify it (will be batch.data.something when exported).

At the moment, both the player.stage and player.round have two timestamps:

• createdAt : which is created at the initialization of the game.
• updatedAt: which can be seen as when the stage/round for that player has ended.

But this is missing startedAt which is the time that this stage/round started for this particular player. this is crucial for computing the duration it took for the player to finish a stage/round.

Add way to change the lobby UI. Pretty much a hook like intro and exit steps (provide your component).

This demand appeared in experiment where the number of people waiting in lobby should not be displayed. We could add option to not display but might as well give the tools to customize in whatever way wanted (timer, more instructions, waiting game, etc.)

The export functionality can be improved:

• From the admin UI, you can choose what games/batches you want to export.
• Export is missing on a lot of data (i.e., the ID inputted by the player such as MTurk ID or email)
• the column round.data.task is JSON because that's how we inputted it in constants.js .. is there a way that we check if a column is going to be an object/JSON then we flatten it for them? (i.e., round.data.task becomes multiple columns round.data.task.correctAnswer, round.data.task.id, round.data.task.path, ...

Say you have 5 steps in the intro (instructions & quiz) .. If you hit refresh, it takes you back to the very first page of the instructions.

Some player.stages are missing submittedAt. is the field submittedAt only exits if player.stage.submit(); is invoked? otherwise, it doesn't? (i.e., if the stage ends due to timeout).

I think we should always have submittedAt and then have another attribute submitMethod that can indicate whether it was userSubmitted or stageTimedOut .. I am sure better names for the key/value can be found.

I think we might want to have these additional two hooks in the config at the server side of the game. In particular:

• onGameStart is just renaming init (if it makes sense; I am thinking out loud here).
• onGameEnd could be a good place to convert the game score into dollar amounts etc. (
• onRoundStart at the beginning of the round. For example, when the round starts, I want to have something like: player.round.set("alterIds", player.get("alterIds")); to solve issue #24 .. although it can be done in other places such in between stages etc; it seems to me that at the start of the round is the most logical place.

We should have sequential non-random assignment (i.e., first come first served the first available game). This is useful for testing + live demos.

Deploying the default Empirica App gives the following error:

2018-06-18 14:01:39-04:00/app/bundle/programs/server/node_modules/fibers/future.js:313
7mtnd
2018-06-18 14:01:39-04:00	throw(ex);
7mtnd
2018-06-18 14:01:39-04:00	^
7mtnd
2018-06-18 14:01:39-04:00
7mtnd
2018-06-18 14:01:39-04:00Error: cyclic dependency detected
7mtnd
2018-06-18 14:01:39-04:00 at serializeObject (/app/bundle/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/bson/lib/bson/parser/serializer.js:331:34)
7mtnd
2018-06-18 14:01:39-04:00 at serializeInto (/app/bundle/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/bson/lib/bson/parser/serializer.js:934:17)
7mtnd
2018-06-18 14:01:39-04:00 at serializeObject (/app/bundle/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/bson/lib/bson/parser/serializer.js:345:18)
7mtnd
2018-06-18 14:01:39-04:00 at serializeInto (/app/bundle/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/bson/lib/bson/parser/serializer.js:934:17)
7mtnd
2018-06-18 14:01:39-04:00 at serializeObject (/app/bundle/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/bson/lib/bson/parser/serializer.js:345:18)
7mtnd
2018-06-18 14:01:39-04:00 at serializeInto (/app/bundle/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/bson/lib/bson/parser/serializer.js:934:17)
7mtnd
2018-06-18 14:01:39-04:00 at serializeObject (/app/bundle/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/bson/lib/bson/parser/serializer.js:345:18)
7mtnd
2018-06-18 14:01:39-04:00 at serializeInto (/app/bundle/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/bson/lib/bson/parser/serializer.js:934:17)
7mtnd
2018-06-18 14:01:39-04:00 at serializeObject (/app/bundle/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/bson/lib/bson/parser/serializer.js:345:18)
7mtnd
2018-06-18 14:01:39-04:00 at serializeInto (/app/bundle/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/bson/lib/bson/parser/serializer.js:934:17)
7mtnd
2018-06-18 14:01:39-04:00 at serializeObject (/app/bundle/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/bson/lib/bson/parser/serializer.js:345:18)
7mtnd
2018-06-18 14:01:39-04:00 at serializeInto (/app/bundle/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/bson/lib/bson/parser/serializer.js:934:17)
7mtnd
2018-06-18 14:01:39-04:00 at serializeObject (/app/bundle/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/bson/lib/bson/parser/serializer.js:345:18)
7mtnd
2018-06-18 14:01:39-04:00 at serializeInto (/app/bundle/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/bson/lib/bson/parser/serializer.js:934:17)
7mtnd
2018-06-18 14:01:39-04:00 at serializeObject (/app/bundle/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/bson/lib/bson/parser/serializer.js:345:18)
7mtnd
2018-06-18 14:01:39-04:00 at serializeInto (/app/bundle/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/bson/lib/bson/parser/serializer.js:934:17)

Details can be found on the Galaxy container.

• I am now convinced that adding/deleting conditions should be from the Admin UI rather than from /imports/experiment/server/game/conditions.js .. it makes running adding a condition more involved that it is needed.

• It is a bit annoying that making a mistake in the conditions (i.e., wanting to change value) requires resetting the entire app. Especially when there are many conditions.

• Also, it is not very friendly that once the app is configured in development, once it is pushed to production, the entire conditions have to be refilled with values (especially when many values exist).

  • This problem is also related to reproducibility of experimental results. For example, when someone clones an experiment that was developed by someone else, they should be able to run it as is (with the values of the conditions by the original devloper). Then they can reproduce the resulsts and/or extend them.

will need to think of the UX/UI of the conditions and come up with something!

Adding object.append("key",value) functionality. This will be useful for example to:

• player.append("answer",answer) for time series analysis of players actions (e.g., getting intermediate ansers).
• round.append("chat", text) to impelement a chat between multiple users (it can happen at the stage level too) or for logging events (at any level).

It seems that there are many experiments that have treatments that are intro invariant, while other experiments have treatments that are intro dependent (i.e, the instructions or the quiz depends on what treatment you are in).

When creating a batch with complete randomization, can we add an option (can be a checkbox, for instance), where you specify whether assignments to treatments will happen BEFORE the intro or AFTER the intro.

In the case of no variation of instructions across treatments (like our group-discussion experiment right now), we want the assignment to happen AFTER the intro. We will have less 'wasted' players because we only make the assignment at the lobby. Therefore, no overbooking will be needed and people who don't get to the lobby will always be able to join future batches (can be treated like new players; doesn’t matter that they’ve seen the instructions before) ...

in the case of instruction dependence, what we have currently is ok. Except that allowing people to play again (when the game starts without them) is trickier (they already saw one version of the instructions, if they get assigned to another, they’ll notice that and they will be able to figure out what we are manipulating.

The bot should have something that indicates that everyone else submitted.
something like: if all.submitted? bot.submit(); (or players.submitted)

people tend to confuse conditions and treatments based on their field of study. It will be better to rename conditions to factors to make it less ambiguous.

Using something like (mizzao/meteor-user-status) and make it available to the game designer. Statuses could include things like:

• active (i.e., looking at the game browsers)
• inactive (i.e., not looking at the game browser)
• idle (looking at the browser but no activity detected for 10 seconds?)
• offline (the browser is closed or the user is disconnected)

Luxurious feature: Would be nice if we have the duration of each statue for each player during a game. For example, maybe I do not want to pay people who are offline for more than 30 seconds. Or penalize people who were ide and inactive for 20 seconds etc.

adding .get(key) and .set(key,value) for the objects in init and trying to make similar to the rest of the game (i.e., treatment should be game.treatment maybe?

In addition to the between games/rounds/stages callbacks, we might want to add additional callbacks that are invoked when an event within a stage happens.

This could include a general onSet(.) and onAppend(.) callbacks or more detailed ones such as onPlayerSet(.), onRoundSet(.), onStageSet(.) and instead of Set/Append maybe replacing it with onObjectChangein order to be invoked whenever object.set("key",value) or object.append("key",value) are invoked.

All deployments of Empirica on Galaxy + MongoDB atlas with oplog trailing enabled provides the following error at the end of the game:

eevvv
2018-06-15 13:31:00-04:00The game has ended for eAzubigz7MFYGJ4sE
eevvv
2018-06-15 13:31:02-04:00Error in oplog callback MinimongoError: Invalid modifier specified $v
eevvv
2018-06-15 13:31:02-04:00 at MinimongoError (packages/minimongo/common.js:1087:17)
eevvv
2018-06-15 13:31:02-04:00 at Object.keys.forEach.operator (packages/minimongo/local_collection.js:1139:15)
eevvv
2018-06-15 13:31:02-04:00 at Array.forEach (<anonymous>)
eevvv
2018-06-15 13:31:02-04:00 at Function.LocalCollection._modify (packages/minimongo/local_collection.js:1132:27)
eevvv
2018-06-15 13:31:02-04:00 at Matcher.Minimongo.Matcher.canBecomeTrueByModifier (packages/minimongo/minimongo_server.js:128:21)
eevvv
2018-06-15 13:31:02-04:00 at packages/mongo/oplog_observe_driver.js:641:34
eevvv
2018-06-15 13:31:02-04:00 at Object.Meteor._noYieldsAllowed (packages/meteor.js:730:12)
eevvv
2018-06-15 13:31:02-04:00 at OplogObserveDriver._handleOplogEntrySteadyOrFetching (packages/mongo/oplog_observe_driver.js:575:12)
eevvv
2018-06-15 13:31:02-04:00 at packages/mongo/oplog_observe_driver.js:129:20
eevvv
2018-06-15 13:31:02-04:00 at packages/mongo/oplog_observe_driver.js:15:9
eevvv
2018-06-15 13:31:02-04:00 at Object.Meteor._noYieldsAllowed (packages/meteor.js:730:12)
eevvv
2018-06-15 13:31:02-04:00 at packages/mongo/oplog_observe_driver.js:117:16
eevvv
2018-06-15 13:31:02-04:00 at packages/mongo/oplog_tailing.js:100:7
eevvv
2018-06-15 13:31:02-04:00 at runWithEnvironment (packages/meteor.js:1240:24)
eevvv
2018-06-15 13:31:02-04:00 at Object.callback (packages/meteor.js:1253:14)
eevvv
2018-06-15 13:31:02-04:00 at packages/ddp-server/crossbar.js:109:36
eevvv
2018-06-15 13:31:02-04:00 at Array.forEach (<anonymous>)
eevvv
2018-06-15 13:31:02-04:00 at Function._.each._.forEach (packages/underscore.js:139:11)
eevvv
2018-06-15 13:31:02-04:00 at DDPServer._Crossbar.fire (packages/ddp-server/crossbar.js:107:7)
eevvv
2018-06-15 13:31:02-04:00 at packages/mongo/oplog_tailing.js:304:26
eevvv
2018-06-15 13:31:02-04:00 at Meteor.EnvironmentVariable.EVp.withValue (packages/meteor.js:1186:15)
eevvv
2018-06-15 13:31:02-04:00 at packages/meteor.js:502:25

The Galaxy Configuration (could it be the problem in the MONGO_OPLOG_URL) :

{
  "galaxy.meteor.com": {
    "env": {
      "MONGO_URL":
        "mongodb://admin:<PASSWORD>@interactive-estimation-shard-00-00-b9hsg.mongodb.net:27017,interactive-estimation-shard-00-01-b9hsg.mongodb.net:27017,interactive-estimation-shard-00-02-b9hsg.mongodb.net:27017/RME?ssl=true&replicaSet=interactive-estimation-shard-0&authSource=admin&retryWrites=true",
      "MONGO_OPLOG_URL":
        "mongodb://oploguser:<PASSWORD>@interactive-estimation-shard-00-00-b9hsg.mongodb.net:27017,interactive-estimation-shard-00-01-b9hsg.mongodb.net:27017,interactive-estimation-shard-00-02-b9hsg.mongodb.net:27017/local?ssl=true&replicaSet=interactive-estimation-shard-0&authSource=admin"
    }
  },
  "public": {
    "playerIdParam": "workerId",
    "playerIdParamExclusive": false,
    "debug_newPlayer": false,
    "debug_resetSession": false,
    "debug_resetDatabase": true,
    "debug_gameDebugMode": false
  }
}

It is worth noting that once this error appear at the end of the game, then when a new batch is added, the error appears before the consent page. The APP incorrectly shows No experiments available and the error appears in the log (i.e., no new games can start once the error appears from the end of the first game)

As the timer in the UI belongs to the current stage, then maybe we should add the timer to the root stage object such that the experiment developer can do: stage.remainingSeconds in order to get the live countdown.

It seems that the admin UI can be split into 3 tabs/categories:

1. Configurations: things that happen before you actually run the experiment
2. Monitoring: things that happen during & after running experiments .. things like creating batches, monitoring on-going games, exporting data
3. Advanced Settings: The JSON file we currently have

Participants that complete the experiments with no issue should have an exitStatus of finished .. I think at the moment we only have exitStatus for the incomplete players.

As we updated to Meteor 1.7 we can drop client/server/imports folders to have something that is simpler and less intimidating for people who haven't seen Meteor before!