decide how to represent the information that "stage" needs in order to determine what to render and what to hide

[JamesPHoughton]

When we render a stage, the stage component will determine which elements listed in the stage to render, depending on a) what player we are displaying the page for, b) the current stage time, and c) the evaluation of a number of "conditions" set on each page element.

          - type: prompt
            desc: shown to both
            file: projects/example/testDisplay10.md
            conditions:
              - reference: prompt.sharedMultipleChoiceWizards
                comparator: equals
                position: shared
                value: Merlin

         - type: prompt
            desc: shown to both
            file: projects/example/testDisplay12.md
            conditions:
              - reference: prompt.individualMultipleChoice
                comparator: equals
                position: all
                value: HTML

          - type: prompt
            desc: shown to both
            file: projects/example/testDisplay14.md
            conditions:
              - reference: prompt.individualMultipleChoiceColors
                comparator: equals
                position: 0
                value: Octarine

          - type: prompt
            desc: shown to neither
            file: projects/example/testDisplay15.md
            conditions:
              - reference: prompt.individualMultipleChoiceColors
                comparator: equals
                position: 1
                value: Octarine

We need to be able to set these items (ie, the stage time) so that the stage renderer can compare the condition for display with the current "state".

Options

1. Take list of condition dependencies from the treatment file for the stage

• Have an entire panel dedicated to checkboxes or options dedicated to every possible player configuration,
• have the researcher set each of them whenever they click a stage

Pros:

• really explicit what everything is set to. Exhaustively lists all the conditions needed for a particular stage to determine what to render, so that we know we haven't forgotten to set (or intentionally omit) any particular item.

Cons:

• if we don't persist this between clicks on different stages, then whenever the user switches stages that they want to render, they'll have to set up the whole state again
• need to update the mocked player object dynamically each time we click on a stage.

2. Maintain a separate, consistent "state" for each player that persists regardless of what is shown in the render panel

• keep an object for each player, use the mocked setters and getters to set state.
• if the user interacts with the page in such a way that modifies the state, persist those changes regardless of what happens next.
• maybe have a player object for each stage? Clicking on a stage

Pros:

• don't have to reset every condition whenever we change states
• don't have to list out every condition, just have to list the players and select one to modify

Cons:

• if you jump between stages, you could get things out of order - something could be set before it's supposed to be. Could get into some "impossible" conditions.

##Option 3: Render everything, add styling to show that a certain element will show up at a certain time under a certain condition.

Option 4:

When you click on a stage, it will:

1. Build a list of all the render dependencies for that stage, which may have changed since the last time we clicked on it
2. Check its storage to see if any of those render dependencies have had a value set from a previous time we clicked on the stage, this may be some but not all of the dependencies
3. create a form that displays to the researcher all the dependencies, prepopulated with values from previous times this stage was rendered.
4. create a mocked stage and players objects with the correct values based on the form values, which will be read by the elements imported form deliberation-empirica
5. the form also has a dropdown (or set of buttons) for which player to render, and the current stage time. these default both to 0.
6. the render panel renders the stage

If the user interacts with the page, ie, clicking a button or entering a value in a text box, then:

1. add that to the dependencies object that is saved to the stage, creating new key/value pairs if needed

If a user modifies the conditions so that a reference is not being used in a condition, then delete that reference's key/value from the dependencies object

If the user interacts with the form and modifies a dependency

1. immediately save that change to the dependencies object and update the player(s) and stage object that get used by the renderer.

If the user switches away to a different stage:

• we don't care, everything has already been saved.

Example Conditions panel for the YAML above:

player to render: 1

current stage time: 30

shared:
  - sharedMultipleChoiceWizards: [Gandalf, Merlin, etc...] (dropdown?)

position 0:
- individualMultipleChoice: HTML
- individualMultipleChoiceColors: Octarine

position 1:
- individualMultipleChoice: HTML

We decided to go with option 4, as it has the benefits of both options 1 and 2, with marginally less complexity.

[JamesPHoughton]

Maybe need to create subissues for each of the pieces:

• rendering a panel
• identifying what information goes where
• defining the data structure

Still need to start on this, so will add questions as they come up.

[JamesPHoughton]

Add a panel in the renderpanel that gets all the reference items that are needed to render the stage, and gives the experiment designer the opportunity to fill their values.