From 92ef1b7ef0166a1ce2c9f2f3c41f6bba997dd601 Mon Sep 17 00:00:00 2001 From: Sean O'Connor Date: Mon, 23 Feb 2026 13:32:09 -0500 Subject: [PATCH] Refine background and system design chapters; enhance clarity and structure in experiment protocols and trial execution descriptions --- thesis/chapters/02_background.tex | 12 ++++++------ thesis/chapters/04_system_design.tex | 12 ++++++------ 2 files changed, 12 insertions(+), 12 deletions(-) diff --git a/thesis/chapters/02_background.tex b/thesis/chapters/02_background.tex index 101d321..bb02b7d 100644 --- a/thesis/chapters/02_background.tex +++ b/thesis/chapters/02_background.tex @@ -26,12 +26,12 @@ Moreover, few platforms directly address the methodological concerns raised by s This thesis represents the culmination of a multi-year research effort to develop infrastructure that addresses the challenges identified in the WoZ platform landscape. Based on the analysis of existing platforms and identified methodological gaps, I derived requirements for a modern WoZ research infrastructure. Through our preliminary work \cite{OConnor2024}, we identified six critical capabilities that a comprehensive platform should provide: \begin{description} -\item[R1:] \textbf{Integrated workflow.} All phases of the experimental workflow--design, execution, and analysis--should be integrated within a single unified environment to minimize context switching and tool fragmentation. -\item[R2:] \textbf{Low technical barrier.} Creating interaction protocols should require minimal to no programming expertise, enabling domain experts from psychology, education, or other fields to work independently \cite{Bartneck2024}. -\item[R3:] \textbf{Real-time control.} The system must support fine-grained, responsive real-time control during live experiment sessions across a variety of robotic platforms. -\item[R4:] \textbf{Automated logging.} All actions, timings, and sensor data should be automatically logged with synchronized timestamps to facilitate analysis. -\item[R5:] \textbf{Platform agnosticism.} The architecture should decouple experimental logic from robot-specific implementations, meaning experiments designed for one robot type can be adapted to others, ensuring the platform remains viable as hardware evolves. -\item[R6:] \textbf{Collaborative support.} Multiple team members should be able to contribute to experiment design and review execution data, supporting truly interdisciplinary research. +\item[R1: Integrated workflow.] All phases of the experimental workflow--design, execution, and analysis--should be integrated within a single unified environment to minimize context switching and tool fragmentation. +\item[R2: Low technical barrier.] Creating interaction protocols should require minimal to no programming expertise, enabling domain experts from psychology, education, or other fields to work independently \cite{Bartneck2024}. +\item[R3: Real-time control.] The system must support fine-grained, responsive real-time control during live experiment sessions across a variety of robotic platforms. +\item[R4: Automated logging.] All actions, timings, and sensor data should be automatically logged with synchronized timestamps to facilitate analysis. +\item[R5: Platform agnosticism.] The architecture should decouple experimental logic from robot-specific implementations, meaning experiments designed for one robot type can be adapted to others, ensuring the platform remains viable as hardware evolves. +\item[R6: Collaborative support.] Multiple team members should be able to contribute to experiment design and review execution data, supporting truly interdisciplinary research. \end{description} To the best of my knowledge, no existing platform satisfies all six requirements. Most critically, the trade-off between accessibility and flexibility remains unresolved, and few tools embed methodological best practices directly into their design--like training wheels on a bicycle, guiding experimenters to follow sound methodology by default. diff --git a/thesis/chapters/04_system_design.tex b/thesis/chapters/04_system_design.tex index 134dfd8..0c06987 100644 --- a/thesis/chapters/04_system_design.tex +++ b/thesis/chapters/04_system_design.tex @@ -7,11 +7,11 @@ The previous chapters established the motivation for a web-based WoZ platform an To address the need for self-documenting, executable experiment specifications (R1, R2), HRIStudio introduces a hierarchical organization of elements that allows researchers to express WoZ studies at multiple levels of abstraction. This structure enables experiment designs to be simultaneously intuitive for researchers to create and precise enough for the system to execute. -At the top level, researchers create a \emph{study} element that defines the overall research context, including metadata about the experiment, collaborators, and experimental conditions. A study comprises multiple \emph{experiment} elements, each representing a single session with one human subject using one robot configuration. This separation of study from experiment allows researchers to manage multiple instantiations of the same protocol while maintaining clear traceability. +At the top level, researchers create a \emph{study} element that defines the overall research context, including metadata about the research project, collaborators, and general experimental conditions. A study contains two types of subordinate elements: \emph{experiment} elements represent reusable protocols (e.g., ``The Interactive Storyteller'' experiment), each specifying the sequence of steps and actions that define an interaction design. \emph{Trial} elements represent specific instantiations where a particular participant executes a particular experiment protocol. This distinction between protocol (experiment) and execution instance (trial) allows researchers to manage multiple repetitions of the same protocol (trials with different participants) while maintaining clear traceability. -Each experiment comprises a sequence of \emph{step} elements, which model distinct phases of the interaction. For example, an experiment might have steps such as ``Introduction,'' ``Learning Task,'' and ``Closing.'' Within each step, researchers define one or more \emph{action} elements that are the atomic units of the experimental procedure. Actions can be directed at the wizard (e.g., ``Wait for subject to finish task, then say encouraging phrase'') or at the robot (e.g., ``Move arm to point, play audio greeting, wait for subject response''). +Each experiment protocol comprises a sequence of \emph{step} elements, which model distinct phases of the interaction design. For example, an experiment protocol might define steps such as ``Introduction,'' ``Learning Task,'' and ``Closing.'' Within each step, researchers define one or more \emph{action} elements that are the atomic units of the experimental procedure. Actions can be directed at the wizard (e.g., ``Wait for subject to finish task, then say encouraging phrase'') or at the robot (e.g., ``Move arm to point, play audio greeting, wait for subject response''). -This hierarchical structure serves multiple purposes. First, it permits researchers to design experiments without programming knowledge, using visual or declarative specifications at each level. Second, it naturally maps to the temporal structure of the experimental session, making the protocol easy to follow during execution. Third, it provides a foundation for comprehensive logging: each action executed during a session can be recorded with precise timestamps and outcomes, making the experimental trace reproducible and analyzable. +This hierarchical structure serves multiple purposes. First, it permits researchers to design experiment protocols without programming knowledge, using visual or declarative specifications at each level. Second, it naturally maps to the temporal structure of a trial session, making the protocol easy to follow during live execution. Third, it provides a foundation for comprehensive logging: each action executed during a trial can be recorded with precise timestamps and outcomes, making the experimental trace reproducible and analyzable. Fourth, the separation of experiment (protocol) from trial (execution) enables researchers to run the same protocol with different participants, facilitating direct comparison across trials while maintaining clear record-keeping of which participant ran which protocol. \section{Modular Interface Architecture} @@ -25,11 +25,11 @@ By treating experiment design as a visual specification task, the interface lowe \subsection{Execute Interface} -During live experiment sessions, the system presents synchronized but distinct views to the wizard and observers. The \emph{wizard's Execute view} displays the current step and available actions, guiding the wizard through the experimental protocol while allowing flexibility for spontaneous, contextual responses. Actions are presented sequentially, but the wizard can manually trigger specific actions based on participant responses, ensuring that the interaction remains natural and responsive rather than rigidly scripted. +During live trials, the Execute interface provides a synchronized live view of experiment execution. The wizard sees the current step and available actions, guiding the wizard through the experimental protocol while allowing flexibility for spontaneous, contextual responses. Actions are presented sequentially, but the wizard can manually trigger specific actions based on participant responses, ensuring that the interaction remains natural and responsive rather than rigidly scripted. -The wizard's view includes manual controls for unscripted behaviors such as additional robot movements, speech, or gestures. These unscripted actions are recorded in the experimental log as explicit deviations from the protocol, enabling researchers to later analyze both scripted and improvised interactions. This design balances the need for consistent, monitored behavior (which supports reproducibility) with the flexibility required for realistic human-robot interactions. +The Execute view includes manual controls for unscripted behaviors such as additional robot movements, speech, or gestures. These unscripted actions are recorded in the trial log as explicit deviations from the protocol, enabling researchers to later analyze both scripted and improvised interactions. This design balances the need for consistent, monitored behavior (which supports reproducibility) with the flexibility required for realistic human-robot interactions. -The \emph{observer's Execute view} enables additional researchers to monitor the experiment in real-time, take notes, and observe participant behavior without interfering with the wizard's control or the participant's experience. Multiple observers can simultaneously access this view, supporting collaborative oversight and interdisciplinary observation (R6). +Additional researchers can simultaneously access this same synchronized live view through the platform's Dashboard by selecting a live trial to ``spectate.'' Multiple researchers observing the same trial view the identical synchronized display of the wizard's controls, participant interactions, and robot state, supporting real-time collaboration and interdisciplinary observation (R6). Observers can take notes and mark significant moments without interfering with the wizard's control or the participant's experience. \subsection{Analysis Interface}