StaggR: an interactive R/Shiny application for planning and visualizing staggered experimental protocols

Implementation

At the core of StaggR is a scheduling algorithm that uses an iterative search heuristic which simulates an experimental workflow involving multiple experiments with starting times offset by a defined time step automatically identified by the application or manually input by the user. In “automatic” mode, it begins with a minimal interval specified by the user through the “granularity” parameter and simulates the experiment. StaggR then checks for time points where the researcher is simultaneously occupied by the hands-on requirements for more than one task. If a conflict is detected, the interval is iteratively increased by the granularity value and the simulation is repeated until a conflict-free schedule is found. This ensures the shortest possible total experiment time without creating logistical impossibility. The algorithm also accounts for user-defined “buffer time” (e.g., 60 s), a short duration added to the end of the operation to model the time it takes to switch between tasks. Although more complex optimization methods exist, this iterative search heuristic was chosen for its straightforward implementation, computational speed for typical lab-scale problems, and its ability to guarantee a conflict-free, if not globally optimal, solution. StaggR runs the optimization by default. By enabling “manual” mode, the user may experiment with different staggering intervals to examine alternate treatment schedules.

The core scheduling logic of StaggR was implemented in base R (v4.4.0), with data manipulation handled by the dplyr package (Wickham et al., 2019). The interactive Gantt chart was generated using ggplot2 (v3.5.2) (Wickham, 2011), and the user interface was built using shiny (v1.11.1) and shinyjs (v2.1.0) for dynamic reactivity. Data tables were rendered using the DT package (v0.33). The application is designed to run locally from the source code or be accessed as a hosted web service. The initial drafts of this code and manuscript were edited with the assistance of ChatGPT o3 (OpenAI) and Gemini 2.5 Pro (Google). All panels outside of Figure 1 are derived from screenshot images natively generated using the StaggR app.

Figure 1. StaggR shiny app overview.

Upon initialization of the application, the user inputs the experimental parameters and generates a schedule automatically, or with a given staggering interval. The workflow is then visualized with a Gantt chart and tables illustrating the staggered processing protocols for each sample or batch of samples. Using the “Live Time Course” tab, users can easily track the progression of their charted experimental workflow.

Operation

The StaggR interface is divided into a control sidebar for the parameter input and a main panel for visualizing the output. The workflow is described below (Figure 1).

Case #1 - Formaldehyde fixation (Highly parallel short incubations)

Fixatives such as formaldehyde crosslink proteins and nucleic acids to preserve their cellular state for applications such as imaging, immunoprecipitation, and mass spectrometry. However, over- and underfixation can easily introduce artifacts that affect reproducibility (Baranello et al., 2016; Schnell et al., 2012). In this use case, the user has a 12-well dish of coverslips bearing cells of different genetic backgrounds. Each coverslip will receive a 60-minute drug or mock (vehicle) treatment after which the cells will be prepared for confocal imaging targeting a protein of interest. They plan to fix each coverslip for 15 min. The user estimates that it will take 0.5 minutes to add the drug, but each sample will require ~5 min to wash and start the fixation, and another 5 min to wash and halt the fixation.

The user opens the app and defines the samples and operations used to process each sample, as well as the hands-on duration to execute each operation using the side bar ( Figure 2A). The user then clicks “Generate Schedule” and discovers that a 14-minute and 30-second staggering would be the best solution if they desired to handle each sample individually ( Figure 2B). By enabling the manual mode and inputting a 6-minute interval, the user can immediately visualize the resulting scheduling conflicts ( Figure 2C). This application of StaggR highlights its utility in allowing the exploration of viable and inviable workflows.

Figure 2. Use Case #1 – Experiment Parameter Input.

(A) The experiment parameter side panel is used to define the protocol. Users input sample descriptions and define each protocol step, including its name, color, hands-on duration, and the subsequent inter-step interval (wait time). In this example, each sample receives a 60-minute drug treatment followed by a 15-minute fixation. (B) Automatically identified interval for Use Case #1. Upon generating the schedule, the main panel of StaggR updates with a Gantt chart displaying a viable workflow, minimizing the staggering interval with the given constraints. The “Hands-On Time” row indicates periods that will require the user’s attention and periods where the user is expected to be unoccupied. (C) Manually defined interval for Use Case #1. Users may also provide a pre-defined staggering interval that may or may not produce a viable workflow. Conflicts between steps are immediately apparent and visualized in the “Hands-on Time” row.

Case #2 – RNA metabolic labeling (Simple time courses executed in parallel)

In this use case, the user wishes to track genome-wide RNA synthesis and decay kinetics in yeast cells after depleting a transcription factor. To do this, they will add 4-thiouracil (4tU), which metabolically labels newly synthesized transcripts, allowing for the measurement of RNA synthesis and decay kinetics. The collection of RNA for 4tU-sequencing experiments (Barrass et al., 2015), provides genome-wide measurements of RNA production and degradation for every gene. However, this type of experiment is critically sensitive to the labeling time. For their experiment, the user will harvest cell pellets after 5, 15, 30, and 60 min of RNA labeling. They wish to perform these experiments in biological triplicate across four cell lines.

The user wants to know if they should schedule their experiments across multiple days, or if they can perform 12 independent time courses in parallel. The user performs a dry run of the experiment and thinks that they can initiate the 4tU treatment within 1 min and harvest the cells within 3 min. The user simply defines the anchor step (adding 4tU) and harvest step in the side bar ( Figure 3A) and enables the Time Course Helper, in which they specify the harvesting time points of 5, 15, 30, and 60 minutes after 4tU addition ( Figure 3B). After applying the time course, the step parameters were automatically updated ( Figure 3C), and the user immediately generates their optimal schedule with a 22-minute 30-second staggering period ( Figure 3D). Here, the user leveraged StaggR to quickly and easily produce a viable time course and execute a procedure in one day, which might otherwise have taken several days.

Figure 3. Use Case #2 – Time Course Helper Function.

(A-C) Using the Time Course Helper. To use the Time Course Helper, the user will (A) define the “Anchoring” step for initiating the time course and the “Template” step to be repeated throughout (e.g., quench a reaction or harvest a sample), (B) activate the time course helper panel to select the appropriate steps and input the time points of the time course, and (C) apply the time course to automatically insert the time-stamped template steps with the appropriate inter-step interval. (D) Automatically identified interval for Use Case #2. Gantt chart illustrating the automatically-generated interval for Use Case #2.

Case #3 – Sequential drug treatment followed by time course harvest (Complex, multi-sample workflow)

This example outlines a complex workflow to process cultures of human K562 chronic myeloid leukemia cells, in which a protein of interest has been engineered to contain an auxin-inducible degron tag (Nishimura et al., 2009). The user wishes to examine how cells respond to DNA damage when the protein of interest has been depleted. The objective is to deplete the protein for 4 h with the drug auxin, and then challenge the cells with hydroxyurea (HU), an agent that promotes the accumulation of DNA damage (Yarbro, 1992). Over 4 h, the user plans to collect protein extracts to probe for levels of γH2AX, a marker of the DNA damage response (Mah et al., 2010) at time points of 0.5, 1, 2, and 4 h. The user plans to perform this experiment on two cell lines, but each cell line requires four conditions (+auxin/+HU, -auxin/+HU, +auxin/-HU, and-auxin/-HU) for a total of eight independent time courses. They estimated 30 s to add each drug, and 6 min to harvest at each time point.

The user sets up their sample parameters using the Time Course Helper, as in Case #2. After generating the schedule, they find that a 28-minute staggering would work ( Figure 4A). Their trainee wishes to perform a similar protocol, so the mentor downloads the session to share as a.json file ( Figure 4B) which their trainee uploads into their own StaggR instance. However, after a dry run, the trainee estimates that it would take approximately 10 minutes to run the harvest themselves. Inputting 10 min for each harvest and re-generating the schedule shows that in this case, the workflow would require an 84-minute stagger between each sample to execute ( Figure 4C). The trainee decides that they will need to either perform a faster harvesting step or split the experiment over multiple days. The trainee practices the harvest procedure to reduce the time to 6 min per step, loads the original workflow, and navigates to the Live Time Course tab. Here, they initiate the timer to show well-telegraphed step-by-step instructions for sample processing ( Figure 5). Using StaggR, the trainee avoids what would have been an inevitable and critical error in executing this complex workflow.

Figure 4. Use Case #3 – Adapting a Complex Workflow for Different Users.

(A) Gantt chart showing the optimized schedule for a complex workflow assuming a 6-minute harvest time, resulting in a 28-minute staggering interval. (B) The UI allows the protocol to be saved and shared with a trainee. (C) When the trainee adjusts the harvest duration to their estimated 10 minutes, the regenerated schedule shows that a conflict-free workflow now requires a much longer 84-minute staggering interval, highlighting a potential bottleneck.

Figure 5. Use Case #3 – Executing the planned workflow with live guidance.

StaggR provides live guidance for executing a planned workflow. (A) The timer counts down to the start of the next required hands-on action for any sample. (B) The “Schedule by Time” table provides a chronological list of all steps, with live highlighting to track progression through the protocol.

Software availability