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:
Build a list of all the render dependencies for that stage, which may have changed since the last time we clicked on it
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
create a form that displays to the researcher all the dependencies, prepopulated with values from previous times this stage was rendered.
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
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.
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:
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
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.
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.
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
Pros:
Cons:
2. Maintain a separate, consistent "state" for each player that persists regardless of what is shown in the render panel
Pros:
Cons:
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:
If the user interacts with the page, ie, clicking a button or entering a value in a text box, then:
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
If the user switches away to a different stage:
Example Conditions panel for the YAML above:
We decided to go with option 4, as it has the benefits of both options 1 and 2, with marginally less complexity.