Possible Improvements

System design

• Design: Data structure for representing data collection procedure
• Currently:
  • Design has-a Graph with additional edge types to represent treatment, nesting, etc. [] Inclusion of data

API

• Design: Between-subjects vs. Within-subjects a main function primitive?
• Design: Language primitive for "repeats"/repeated measures?
• Design: Assumptions or clarity about fully vs. partially factorial designs? (I think current implementing supports both)
• StatisticalModel: How to express "something like" (e.g., I want to model something like "Y ~ X1 + X2" with some uncertainty around the formulation)

Interaction

• "Neither"/"None of the above" option for picking among the UNSAT core
• Depth-first instead of Breadth-first interaction (ideally allow both?) w related constraints.
  • Use case: If indicate want to perform Transformation on a variable, ask about what kind of Transformation (depth-first) instead of asking if want to Transform all variables and then following-up on specific transformations for all variables after (currently, breadth-first)
• Dynamically update weights for constraints and/or add new constraints based on end-user interaction?
• (Constraints) “Listening”/Reactive constraint solver (similar to even listening and handling)
  • Use case: If user indicate intention to transform data, then ask about transformation types vs. eagerly asking about transformations → Slacked Julie about this, thinking through this…

Output

• Generate R script when end-point is StatisticalModel?

GUI?

• Lightweight GUI to see updates to Design, Graph, and StatisticalModel simultaneously?

Other

• Try dagre for graph vis layout?
• (future work?) Develop and test a visual grammar for Graph?