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

StaggR: an interactive R/Shiny application for... | F1000Research "use strict";function _typeof(t){return(_typeof="function"==typeof Symbol&&"symbol"==typeof Symbol.iterator?function(t){return typeof t}:function(t){return t&&"function"==typeof Symbol&&t.constructor===Symbol&&t!==Symbol.prototype?"symbol":typeof t})(t)}!function(){var t=function(){var t,e,o=[],n=window,r=n;for(;r;){try{if(r.frames.__tcfapiLocator){t=r;break}}catch(t){}if(r===n.top)break;r=r.parent}t||(!function t(){var e=n.document,o=!!n.frames.__tcfapiLocator;if(!o)if(e.body){var r=e.createElement("iframe");r.style.cssText="display:none",r.name="__tcfapiLocator",e.body.appendChild(r)}else setTimeout(t,5);return!o}(),n.__tcfapi=function(){for(var t=arguments.length,n=new Array(t),r=0;r 3&&2===parseInt(n[1],10)&&"boolean"==typeof n[3]&&(e=n[3],"function"==typeof n[2]&&n[2]("set",!0)):"ping"===n[0]?"function"==typeof n[2]&&n[2]({gdprApplies:e,cmpLoaded:!1,cmpStatus:"stub"}):o.push(n)},n.addEventListener("message",(function(t){var e="string"==typeof t.data,o={};if(e)try{o=JSON.parse(t.data)}catch(t){}else o=t.data;var n="object"===_typeof(o)&&null!==o?o.__tcfapiCall:null;n&&window.__tcfapi(n.command,n.version,(function(o,r){var a={__tcfapiReturn:{returnValue:o,success:r,callId:n.callId}};t&&t.source&&t.source.postMessage&&t.source.postMessage(e?JSON.stringify(a):a,"*")}),n.parameter)}),!1))};"undefined"!=typeof module?module.exports=t:t()}(); dataLayer = dataLayer || []; // Standard GTM initialization - Google Consent Mode handles consent automatically (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start': new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0], j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src= 'https://www.googletagmanager.com/gtm.js?id='+i+dl+ '>m_auth=hzk0Vc3qFsQYhCrIoHz68A>m_preview=env-1>m_cookies_win=x';f.parentNode.insertBefore(j,f); })(window,document,'script','dataLayer','GTM-MWFK8L5J'); ;window.NREUM||(NREUM={});NREUM.init={distributed_tracing:{enabled:true},privacy:{cookies_enabled:true},ajax:{deny_list:["bam.nr-data.net"]}}; ;NREUM.loader_config={accountID:"438030",trustKey:"438030",agentID:"772317073",licenseKey:"97f8f67f26",applicationID:"772317073"} ;NREUM.info={beacon:"bam.nr-data.net",errorBeacon:"bam.nr-data.net",licenseKey:"97f8f67f26",applicationID:"772317073",sa:1} ;/*! For license information please see nr-loader-spa-1.236.0.min.js.LICENSE.txt */ (()=>{"use strict";var e,t,r={5763:(e,t,r)=>{r.d(t,{P_:()=>l,Mt:()=>g,C5:()=>s,DL:()=>v,OP:()=>T,lF:()=>D,Yu:()=>y,Dg:()=>h,CX:()=>c,GE:()=>b,sU:()=>_});var n=r(8632),i=r(9567);const o={beacon:n.ce.beacon,errorBeacon:n.ce.errorBeacon,licenseKey:void 0,applicationID:void 0,sa:void 0,queueTime:void 0,applicationTime:void 0,ttGuid:void 0,user:void 0,account:void 0,product:void 0,extra:void 0,jsAttributes:{},userAttributes:void 0,atts:void 0,transactionName:void 0,tNamePlain:void 0},a={};function s(e){if(!e)throw new Error("All info objects require an agent identifier!");if(!a[e])throw new Error("Info for ".concat(e," was never set"));return a[e]}function c(e,t){if(!e)throw new Error("All info objects require an agent identifier!");a[e]=(0,i.D)(t,o),(0,n.Qy)(e,a[e],"info")}var u=r(7056);const d=()=>{const e={blockSelector:"[data-nr-block]",maskInputOptions:{password:!0}};return{allow_bfcache:!0,privacy:{cookies_enabled:!0},ajax:{deny_list:void 0,enabled:!0,harvestTimeSeconds:10},distributed_tracing:{enabled:void 0,exclude_newrelic_header:void 0,cors_use_newrelic_header:void 0,cors_use_tracecontext_headers:void 0,allowed_origins:void 0},session:{domain:void 0,expiresMs:u.oD,inactiveMs:u.Hb},ssl:void 0,obfuscate:void 0,jserrors:{enabled:!0,harvestTimeSeconds:10},metrics:{enabled:!0},page_action:{enabled:!0,harvestTimeSeconds:30},page_view_event:{enabled:!0},page_view_timing:{enabled:!0,harvestTimeSeconds:30,long_task:!1},session_trace:{enabled:!0,harvestTimeSeconds:10},harvest:{tooManyRequestsDelay:60},session_replay:{enabled:!1,harvestTimeSeconds:60,sampleRate:.1,errorSampleRate:.1,maskTextSelector:"*",maskAllInputs:!0,get blockClass(){return"nr-block"},get ignoreClass(){return"nr-ignore"},get maskTextClass(){return"nr-mask"},get blockSelector(){return e.blockSelector},set blockSelector(t){e.blockSelector+=",".concat(t)},get maskInputOptions(){return e.maskInputOptions},set maskInputOptions(t){e.maskInputOptions={...t,password:!0}}},spa:{enabled:!0,harvestTimeSeconds:10}}},f={};function l(e){if(!e)throw new Error("All configuration objects require an agent identifier!");if(!f[e])throw new Error("Configuration for ".concat(e," was never set"));return f[e]}function h(e,t){if(!e)throw new Error("All configuration objects require an agent identifier!");f[e]=(0,i.D)(t,d()),(0,n.Qy)(e,f[e],"config")}function g(e,t){if(!e)throw new Error("All configuration objects require an agent identifier!");var r=l(e);if(r){for(var n=t.split("."),i=0;i {r.d(t,{D:()=>i});var n=r(50);function i(e,t){try{if(!e||"object"!=typeof e)return(0,n.Z)("Setting a Configurable requires an object as input");if(!t||"object"!=typeof t)return(0,n.Z)("Setting a Configurable requires a model to set its initial properties");const r=Object.create(Object.getPrototypeOf(t),Object.getOwnPropertyDescriptors(t)),o=0===Object.keys(r).length?e:r;for(let a in o)if(void 0!==e[a])try{"object"==typeof e[a]&&"object"==typeof t[a]?r[a]=i(e[a],t[a]):r[a]=e[a]}catch(e){(0,n.Z)("An error occurred while setting a property of a Configurable",e)}return r}catch(e){(0,n.Z)("An error occured while setting a Configurable",e)}}},6818:(e,t,r)=>{r.d(t,{Re:()=>i,gF:()=>o,q4:()=>n});const n="1.236.0",i="PROD",o="CDN"},385:(e,t,r)=>{r.d(t,{FN:()=>a,IF:()=>u,Nk:()=>f,Tt:()=>s,_A:()=>o,il:()=>n,pL:()=>c,v6:()=>i,w1:()=>d});const n="undefined"!=typeof window&&!!window.document,i="undefined"!=typeof WorkerGlobalScope&&("undefined"!=typeof self&&self instanceof WorkerGlobalScope&&self.navigator instanceof WorkerNavigator||"undefined"!=typeof globalThis&&globalThis instanceof WorkerGlobalScope&&globalThis.navigator instanceof WorkerNavigator),o=n?window:"undefined"!=typeof WorkerGlobalScope&&("undefined"!=typeof self&&self instanceof WorkerGlobalScope&&self||"undefined"!=typeof globalThis&&globalThis instanceof WorkerGlobalScope&&globalThis),a=""+o?.location,s=/iPad|iPhone|iPod/.test(navigator.userAgent),c=s&&"undefined"==typeof SharedWorker,u=(()=>{const e=navigator.userAgent.match(/Firefox[/\s](\d+\.\d+)/);return Array.isArray(e)&&e.length>=2?+e[1]:0})(),d=Boolean(n&&window.document.documentMode),f=!!navigator.sendBeacon},1117:(e,t,r)=>{r.d(t,{w:()=>o});var n=r(50);const i={agentIdentifier:"",ee:void 0};class o{constructor(e){try{if("object"!=typeof e)return(0,n.Z)("shared context requires an object as input");this.sharedContext={},Object.assign(this.sharedContext,i),Object.entries(e).forEach((e=>{let[t,r]=e;Object.keys(i).includes(t)&&(this.sharedContext[t]=r)}))}catch(e){(0,n.Z)("An error occured while setting SharedContext",e)}}}},8e3:(e,t,r)=>{r.d(t,{L:()=>d,R:()=>c});var n=r(2177),i=r(1284),o=r(4322),a=r(3325);const s={};function c(e,t){const r={staged:!1,priority:a.p[t]||0};u(e),s[e].get(t)||s[e].set(t,r)}function u(e){e&&(s[e]||(s[e]=new Map))}function d(){let e=arguments.length>0&&void 0!==arguments[0]?arguments[0]:"",t=arguments.length>1&&void 0!==arguments[1]?arguments[1]:"feature";if(u(e),!e||!s[e].get(t))return a(t);s[e].get(t).staged=!0;const r=[...s[e]];function a(t){const r=e?n.ee.get(e):n.ee,a=o.X.handlers;if(r.backlog&&a){var s=r.backlog[t],c=a[t];if(c){for(var u=0;s&&u {let[t,r]=e;return r.staged}))&&(r.sort(((e,t)=>e[1].priority-t[1].priority)),r.forEach((e=>{let[t]=e;a(t)})))}function f(e,t){var r=e[1];(0,i.D)(t[r],(function(t,r){var n=e[0];if(r[0]===n){var i=r[1],o=e[3],a=e[2];i.apply(o,a)}}))}},2177:(e,t,r)=>{r.d(t,{c:()=>f,ee:()=>u});var n=r(8632),i=r(2210),o=r(1284),a=r(5763),s="nr@context";let c=(0,n.fP)();var u;function d(){}function f(e){return(0,i.X)(e,s,l)}function l(){return new d}function h(){u.aborted=!0,u.backlog={}}c.ee?u=c.ee:(u=function e(t,r){var n={},c={},f={},g=!1;try{g=16===r.length&&(0,a.OP)(r).isolatedBacklog}catch(e){}var p={on:b,addEventListener:b,removeEventListener:y,emit:v,get:x,listeners:w,context:m,buffer:A,abort:h,aborted:!1,isBuffering:E,debugId:r,backlog:g?{}:t&&"object"==typeof t.backlog?t.backlog:{}};return p;function m(e){return e&&e instanceof d?e:e?(0,i.X)(e,s,l):l()}function v(e,r,n,i,o){if(!1!==o&&(o=!0),!u.aborted||i){t&&o&&t.emit(e,r,n);for(var a=m(n),s=w(e),d=s.length,f=0;fn,p:()=>i});var n=r(2177).ee.get("handle");function i(e,t,r,i,o){o?(o.buffer([e],i),o.emit(e,t,r)):(n.buffer([e],i),n.emit(e,t,r))}},4322:(e,t,r)=>{r.d(t,{X:()=>o});var n=r(5546);o.on=a;var i=o.handlers={};function o(e,t,r,o){a(o||n.E,i,e,t,r)}function a(e,t,r,i,o){o||(o="feature"),e||(e=n.E);var a=t[o]=t[o]||{};(a[r]=a[r]||[]).push([e,i])}},3239:(e,t,r)=>{r.d(t,{bP:()=>s,iz:()=>c,m$:()=>a});var n=r(385);let i=!1,o=!1;try{const e={get passive(){return i=!0,!1},get signal(){return o=!0,!1}};n._A.addEventListener("test",null,e),n._A.removeEventListener("test",null,e)}catch(e){}function a(e,t){return i||o?{capture:!!e,passive:i,signal:t}:!!e}function s(e,t){let r=arguments.length>2&&void 0!==arguments[2]&&arguments[2],n=arguments.length>3?arguments[3]:void 0;window.addEventListener(e,t,a(r,n))}function c(e,t){let r=arguments.length>2&&void 0!==arguments[2]&&arguments[2],n=arguments.length>3?arguments[3]:void 0;document.addEventListener(e,t,a(r,n))}},4402:(e,t,r)=>{r.d(t,{Ht:()=>u,M:()=>c,Rl:()=>a,ky:()=>s});var n=r(385);const i="xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx";function o(e,t){return e?15&e[t]:16*Math.random()|0}function a(){const e=n._A?.crypto||n._A?.msCrypto;let t,r=0;return e&&e.getRandomValues&&(t=e.getRandomValues(new Uint8Array(31))),i.split("").map((e=>"x"===e?o(t,++r).toString(16):"y"===e?(3&o()|8).toString(16):e)).join("")}function s(e){const t=n._A?.crypto||n._A?.msCrypto;let r,i=0;t&&t.getRandomValues&&(r=t.getRandomValues(new Uint8Array(31)));const a=[];for(var s=0;s {r.d(t,{Bq:()=>n,Hb:()=>o,oD:()=>i});const n="NRBA",i=144e5,o=18e5},7894:(e,t,r)=>{function n(){return Math.round(performance.now())}r.d(t,{z:()=>n})},7243:(e,t,r)=>{r.d(t,{e:()=>o});var n=r(385),i={};function o(e){if(e in i)return i[e];if(0===(e||"").indexOf("data:"))return{protocol:"data"};let t;var r=n._A?.location,o={};if(n.il)t=document.createElement("a"),t.href=e;else try{t=new URL(e,r.href)}catch(e){return o}o.port=t.port;var a=t.href.split("://");!o.port&&a[1]&&(o.port=a[1].split("/")[0].split("@").pop().split(":")[1]),o.port&&"0"!==o.port||(o.port="https"===a[0]?"443":"80"),o.hostname=t.hostname||r.hostname,o.pathname=t.pathname,o.protocol=a[0],"/"!==o.pathname.charAt(0)&&(o.pathname="/"+o.pathname);var s=!t.protocol||":"===t.protocol||t.protocol===r.protocol,c=t.hostname===r.hostname&&t.port===r.port;return o.sameOrigin=s&&(!t.hostname||c),"/"===o.pathname&&(i[e]=o),o}},50:(e,t,r)=>{function n(e,t){"function"==typeof console.warn&&(console.warn("New Relic: ".concat(e)),t&&console.warn(t))}r.d(t,{Z:()=>n})},2587:(e,t,r)=>{r.d(t,{N:()=>c,T:()=>u});var n=r(2177),i=r(5546),o=r(8e3),a=r(3325);const s={stn:[a.D.sessionTrace],err:[a.D.jserrors,a.D.metrics],ins:[a.D.pageAction],spa:[a.D.spa],sr:[a.D.sessionReplay,a.D.sessionTrace]};function c(e,t){const r=n.ee.get(t);e&&"object"==typeof e&&(Object.entries(e).forEach((e=>{let[t,n]=e;void 0===u[t]&&(s[t]?s[t].forEach((e=>{n?(0,i.p)("feat-"+t,[],void 0,e,r):(0,i.p)("block-"+t,[],void 0,e,r),(0,i.p)("rumresp-"+t,[Boolean(n)],void 0,e,r)})):n&&(0,i.p)("feat-"+t,[],void 0,void 0,r),u[t]=Boolean(n))})),Object.keys(s).forEach((e=>{void 0===u[e]&&(s[e]?.forEach((t=>(0,i.p)("rumresp-"+e,[!1],void 0,t,r))),u[e]=!1)})),(0,o.L)(t,a.D.pageViewEvent))}const u={}},2210:(e,t,r)=>{r.d(t,{X:()=>i});var n=Object.prototype.hasOwnProperty;function i(e,t,r){if(n.call(e,t))return e[t];var i=r();if(Object.defineProperty&&Object.keys)try{return Object.defineProperty(e,t,{value:i,writable:!0,enumerable:!1}),i}catch(e){}return e[t]=i,i}},1284:(e,t,r)=>{r.d(t,{D:()=>n});const n=(e,t)=>Object.entries(e||{}).map((e=>{let[r,n]=e;return t(r,n)}))},4351:(e,t,r)=>{r.d(t,{P:()=>o});var n=r(2177);const i=()=>{const e=new WeakSet;return(t,r)=>{if("object"==typeof r&&null!==r){if(e.has(r))return;e.add(r)}return r}};function o(e){try{return JSON.stringify(e,i())}catch(e){try{n.ee.emit("internal-error",[e])}catch(e){}}}},3960:(e,t,r)=>{r.d(t,{K:()=>a,b:()=>o});var n=r(3239);function i(){return"undefined"==typeof document||"complete"===document.readyState}function o(e,t){if(i())return e();(0,n.bP)("load",e,t)}function a(e){if(i())return e();(0,n.iz)("DOMContentLoaded",e)}},8632:(e,t,r)=>{r.d(t,{EZ:()=>u,Qy:()=>c,ce:()=>o,fP:()=>a,gG:()=>d,mF:()=>s});var n=r(7894),i=r(385);const o={beacon:"bam.nr-data.net",errorBeacon:"bam.nr-data.net"};function a(){return i._A.NREUM||(i._A.NREUM={}),void 0===i._A.newrelic&&(i._A.newrelic=i._A.NREUM),i._A.NREUM}function s(){let e=a();return e.o||(e.o={ST:i._A.setTimeout,SI:i._A.setImmediate,CT:i._A.clearTimeout,XHR:i._A.XMLHttpRequest,REQ:i._A.Request,EV:i._A.Event,PR:i._A.Promise,MO:i._A.MutationObserver,FETCH:i._A.fetch}),e}function c(e,t,r){let i=a();const o=i.initializedAgents||{},s=o[e]||{};return Object.keys(s).length||(s.initializedAt={ms:(0,n.z)(),date:new Date}),i.initializedAgents={...o,[e]:{...s,[r]:t}},i}function u(e,t){a()[e]=t}function d(){return function(){let e=a();const t=e.info||{};e.info={beacon:o.beacon,errorBeacon:o.errorBeacon,...t}}(),function(){let e=a();const t=e.init||{};e.init={...t}}(),s(),function(){let e=a();const t=e.loader_config||{};e.loader_config={...t}}(),a()}},7956:(e,t,r)=>{r.d(t,{N:()=>i});var n=r(3239);function i(e){let t=arguments.length>1&&void 0!==arguments[1]&&arguments[1],r=arguments.length>2?arguments[2]:void 0,i=arguments.length>3?arguments[3]:void 0;return void(0,n.iz)("visibilitychange",(function(){if(t)return void("hidden"==document.visibilityState&&e());e(document.visibilityState)}),r,i)}},1214:(e,t,r)=>{r.d(t,{em:()=>v,u5:()=>N,QU:()=>S,_L:()=>I,Gm:()=>L,Lg:()=>M,gy:()=>U,BV:()=>Q,Kf:()=>ee});var n=r(2177);const i="nr@original";var o=Object.prototype.hasOwnProperty,a=!1;function s(e,t){return e||(e=n.ee),r.inPlace=function(e,t,n,i,o){n||(n="");var a,s,c,u="-"===n.charAt(0);for(c=0;c 2?n-2:0),o=2;o {r(A[T],e,w),r(E[T],e,w)})),r(l._A,"fetch",y),t.on(y+"end",(function(e,r){var n=this;if(r){var i=r.headers.get("content-length");null!==i&&(n.rxSize=i),t.emit(y+"done",[null,r],n)}else t.emit(y+"done",[e],n)})),t}const O={},j=["pushState","replaceState"];function S(e){const t=function(e){return(e||n.ee).get("history")}(e);return!l.il||O[t.debugId]++||(O[t.debugId]=1,s(t).inPlace(window.history,j,"-")),t}var P=r(3239);const C={},R=["appendChild","insertBefore","replaceChild"];function I(e){const t=function(e){return(e||n.ee).get("jsonp")}(e);if(!l.il||C[t.debugId])return t;C[t.debugId]=!0;var r=s(t),i=/[?&](?:callback|cb)=([^&#]+)/,o=/(.*)\.([^.]+)/,a=/^(\w+)(\.|$)(.*)$/;function c(e,t){var r=e.match(a),n=r[1],i=r[3];return i?c(i,t[n]):t[n]}return r.inPlace(Node.prototype,R,"dom-"),t.on("dom-start",(function(e){!function(e){if(!e||"string"!=typeof e.nodeName||"script"!==e.nodeName.toLowerCase())return;if("function"!=typeof e.addEventListener)return;var n=(a=e.src,s=a.match(i),s?s[1]:null);var a,s;if(!n)return;var u=function(e){var t=e.match(o);if(t&&t.length>=3)return{key:t[2],parent:c(t[1],window)};return{key:e,parent:window}}(n);if("function"!=typeof u.parent[u.key])return;var d={};function f(){t.emit("jsonp-end",[],d),e.removeEventListener("load",f,(0,P.m$)(!1)),e.removeEventListener("error",l,(0,P.m$)(!1))}function l(){t.emit("jsonp-error",[],d),t.emit("jsonp-end",[],d),e.removeEventListener("load",f,(0,P.m$)(!1)),e.removeEventListener("error",l,(0,P.m$)(!1))}r.inPlace(u.parent,[u.key],"cb-",d),e.addEventListener("load",f,(0,P.m$)(!1)),e.addEventListener("error",l,(0,P.m$)(!1)),t.emit("new-jsonp",[e.src],d)}(e[0])})),t}var k=r(5763);const H={};function L(e){const t=function(e){return(e||n.ee).get("mutation")}(e);if(!l.il||H[t.debugId])return t;H[t.debugId]=!0;var r=s(t),i=k.Yu.MO;return i&&(window.MutationObserver=function(e){return this instanceof i?new i(r(e,"fn-")):i.apply(this,arguments)},MutationObserver.prototype=i.prototype),t}const z={};function M(e){const t=function(e){return(e||n.ee).get("promise")}(e);if(z[t.debugId])return t;z[t.debugId]=!0;var r=n.c,o=s(t),a=k.Yu.PR;return a&&function(){function e(r){var n=t.context(),i=o(r,"executor-",n,null,!1);const s=Reflect.construct(a,[i],e);return t.context(s).getCtx=function(){return n},s}l._A.Promise=e,Object.defineProperty(e,"name",{value:"Promise"}),e.toString=function(){return a.toString()},Object.setPrototypeOf(e,a),["all","race"].forEach((function(r){const n=a[r];e[r]=function(e){let i=!1;[...e||[]].forEach((e=>{this.resolve(e).then(a("all"===r),a(!1))}));const o=n.apply(this,arguments);return o;function a(e){return function(){t.emit("propagate",[null,!i],o,!1,!1),i=i||!e}}}})),["resolve","reject"].forEach((function(r){const n=a[r];e[r]=function(e){const r=n.apply(this,arguments);return e!==r&&t.emit("propagate",[e,!0],r,!1,!1),r}})),e.prototype=a.prototype;const n=a.prototype.then;a.prototype.then=function(){var e=this,i=r(e);i.promise=e;for(var a=arguments.length,s=new Array(a),c=0;c e())),t};function m(e,t){i.inPlace(t,["onreadystatechange"],"fn-",E)}function b(){var e=this,t=r.context(e);e.readyState>3&&!t.resolved&&(t.resolved=!0,r.emit("xhr-resolved",[],e)),i.inPlace(e,f,"fn-",E)}if(function(e,t){for(var r in e)t[r]=e[r]}(o,p),p.prototype=o.prototype,i.inPlace(p.prototype,J,"-xhr-",E),r.on("send-xhr-start",(function(e,t){m(e,t),function(e){h.push(e),a&&(y?y.then(A):u?u(A):(w=-w,x.data=w))}(t)})),r.on("open-xhr-start",m),a){var y=c&&c.resolve();if(!u&&!c){var w=1,x=document.createTextNode(w);new a(A).observe(x,{characterData:!0})}}else t.on("fn-end",(function(e){e[0]&&e[0].type===d||A()}));function A(){for(var e=0;e {r.d(t,{t:()=>n});const n=r(3325).D.ajax},6660:(e,t,r)=>{r.d(t,{A:()=>i,t:()=>n});const n=r(3325).D.jserrors,i="nr@seenError"},3081:(e,t,r)=>{r.d(t,{gF:()=>o,mY:()=>i,t9:()=>n,vz:()=>s,xS:()=>a});const n=r(3325).D.metrics,i="sm",o="cm",a="storeSupportabilityMetrics",s="storeEventMetrics"},4649:(e,t,r)=>{r.d(t,{t:()=>n});const n=r(3325).D.pageAction},7633:(e,t,r)=>{r.d(t,{Dz:()=>i,OJ:()=>a,qw:()=>o,t9:()=>n});const n=r(3325).D.pageViewEvent,i="firstbyte",o="domcontent",a="windowload"},9251:(e,t,r)=>{r.d(t,{t:()=>n});const n=r(3325).D.pageViewTiming},3614:(e,t,r)=>{r.d(t,{BST_RESOURCE:()=>i,END:()=>s,FEATURE_NAME:()=>n,FN_END:()=>u,FN_START:()=>c,PUSH_STATE:()=>d,RESOURCE:()=>o,START:()=>a});const n=r(3325).D.sessionTrace,i="bstResource",o="resource",a="-start",s="-end",c="fn"+a,u="fn"+s,d="pushState"},7836:(e,t,r)=>{r.d(t,{BODY:()=>A,CB_END:()=>E,CB_START:()=>u,END:()=>x,FEATURE_NAME:()=>i,FETCH:()=>_,FETCH_BODY:()=>v,FETCH_DONE:()=>m,FETCH_START:()=>p,FN_END:()=>c,FN_START:()=>s,INTERACTION:()=>l,INTERACTION_API:()=>d,INTERACTION_EVENTS:()=>o,JSONP_END:()=>b,JSONP_NODE:()=>g,JS_TIME:()=>T,MAX_TIMER_BUDGET:()=>a,REMAINING:()=>f,SPA_NODE:()=>h,START:()=>w,originalSetTimeout:()=>y});var n=r(5763);const i=r(3325).D.spa,o=["click","submit","keypress","keydown","keyup","change"],a=999,s="fn-start",c="fn-end",u="cb-start",d="api-ixn-",f="remaining",l="interaction",h="spaNode",g="jsonpNode",p="fetch-start",m="fetch-done",v="fetch-body-",b="jsonp-end",y=n.Yu.ST,w="-start",x="-end",A="-body",E="cb"+x,T="jsTime",_="fetch"},5938:(e,t,r)=>{r.d(t,{W:()=>o});var n=r(5763),i=r(2177);class o{constructor(e,t,r){this.agentIdentifier=e,this.aggregator=t,this.ee=i.ee.get(e,(0,n.OP)(this.agentIdentifier).isolatedBacklog),this.featureName=r,this.blocked=!1}}},9144:(e,t,r)=>{r.d(t,{j:()=>m});var n=r(3325),i=r(5763),o=r(5546),a=r(2177),s=r(7894),c=r(8e3),u=r(3960),d=r(385),f=r(50),l=r(3081),h=r(8632);function g(){const e=(0,h.gG)();["setErrorHandler","finished","addToTrace","inlineHit","addRelease","addPageAction","setCurrentRouteName","setPageViewName","setCustomAttribute","interaction","noticeError","setUserId"].forEach((t=>{e[t]=function(){for(var r=arguments.length,n=new Array(r),i=0;i 1?r-1:0),i=1;i {e.exposed&&e.api[t]&&o.push(e.api[t](...n))})),o.length>1?o:o[0]}(t,...n)}}))}var p=r(2587);function m(e){let t=arguments.length>1&&void 0!==arguments[1]?arguments[1]:{},m=arguments.length>2?arguments[2]:void 0,v=arguments.length>3?arguments[3]:void 0,{init:b,info:y,loader_config:w,runtime:x={loaderType:m},exposed:A=!0}=t;const E=(0,h.gG)();y||(b=E.init,y=E.info,w=E.loader_config),(0,i.Dg)(e,b||{}),(0,i.GE)(e,w||{}),(0,i.sU)(e,x),y.jsAttributes??={},d.v6&&(y.jsAttributes.isWorker=!0),(0,i.CX)(e,y),g();const T=function(e,t){t||(0,c.R)(e,"api");const h={};var g=a.ee.get(e),p=g.get("tracer"),m="api-",v=m+"ixn-";function b(t,r,n,o){const a=(0,i.C5)(e);return null===r?delete a.jsAttributes[t]:(0,i.CX)(e,{...a,jsAttributes:{...a.jsAttributes,[t]:r}}),x(m,n,!0,o||null===r?"session":void 0)(t,r)}function y(){}["setErrorHandler","finished","addToTrace","inlineHit","addRelease"].forEach((e=>h[e]=x(m,e,!0,"api"))),h.addPageAction=x(m,"addPageAction",!0,n.D.pageAction),h.setCurrentRouteName=x(m,"routeName",!0,n.D.spa),h.setPageViewName=function(t,r){if("string"==typeof t)return"/"!==t.charAt(0)&&(t="/"+t),(0,i.OP)(e).customTransaction=(r||"http://custom.transaction")+t,x(m,"setPageViewName",!0)()},h.setCustomAttribute=function(e,t){let r=arguments.length>2&&void 0!==arguments[2]&&arguments[2];if("string"==typeof e){if(["string","number"].includes(typeof t)||null===t)return b(e,t,"setCustomAttribute",r);(0,f.Z)("Failed to execute setCustomAttribute.\nNon-null value must be a string or number type, but a type of was provided."))}else(0,f.Z)("Failed to execute setCustomAttribute.\nName must be a string type, but a type of was provided."))},h.setUserId=function(e){if("string"==typeof e||null===e)return b("enduser.id",e,"setUserId",!0);(0,f.Z)("Failed to execute setUserId.\nNon-null value must be a string type, but a type of was provided."))},h.interaction=function(){return(new y).get()};var w=y.prototype={createTracer:function(e,t){var r={},i=this,a="function"==typeof t;return(0,o.p)(v+"tracer",[(0,s.z)(),e,r],i,n.D.spa,g),function(){if(p.emit((a?"":"no-")+"fn-start",[(0,s.z)(),i,a],r),a)try{return t.apply(this,arguments)}catch(e){throw p.emit("fn-err",[arguments,this,"string"==typeof e?new Error(e):e],r),e}finally{p.emit("fn-end",[(0,s.z)()],r)}}}};function x(e,t,r,i){return function(){return(0,o.p)(l.xS,["API/"+t+"/called"],void 0,n.D.metrics,g),i&&(0,o.p)(e+t,[(0,s.z)(),...arguments],r?null:this,i,g),r?void 0:this}}function A(){r.e(439).then(r.bind(r,7438)).then((t=>{let{setAPI:r}=t;r(e),(0,c.L)(e,"api")})).catch((()=>(0,f.Z)("Downloading runtime APIs failed...")))}return["actionText","setName","setAttribute","save","ignore","onEnd","getContext","end","get"].forEach((e=>{w[e]=x(v,e,void 0,n.D.spa)})),h.noticeError=function(e,t){"string"==typeof e&&(e=new Error(e)),(0,o.p)(l.xS,["API/noticeError/called"],void 0,n.D.metrics,g),(0,o.p)("err",[e,(0,s.z)(),!1,t],void 0,n.D.jserrors,g)},d.il?(0,u.b)((()=>A()),!0):A(),h}(e,v);return(0,h.Qy)(e,T,"api"),(0,h.Qy)(e,A,"exposed"),(0,h.EZ)("activatedFeatures",p.T),T}},3325:(e,t,r)=>{r.d(t,{D:()=>n,p:()=>i});const n={ajax:"ajax",jserrors:"jserrors",metrics:"metrics",pageAction:"page_action",pageViewEvent:"page_view_event",pageViewTiming:"page_view_timing",sessionReplay:"session_replay",sessionTrace:"session_trace",spa:"spa"},i={[n.pageViewEvent]:1,[n.pageViewTiming]:2,[n.metrics]:3,[n.jserrors]:4,[n.ajax]:5,[n.sessionTrace]:6,[n.pageAction]:7,[n.spa]:8,[n.sessionReplay]:9}}},n={};function i(e){var t=n[e];if(void 0!==t)return t.exports;var o=n[e]={exports:{}};return r[e](o,o.exports,i),o.exports}i.m=r,i.d=(e,t)=>{for(var r in t)i.o(t,r)&&!i.o(e,r)&&Object.defineProperty(e,r,{enumerable:!0,get:t[r]})},i.f={},i.e=e=>Promise.all(Object.keys(i.f).reduce(((t,r)=>(i.f[r](e,t),t)),[])),i.u=e=>(({78:"page_action-aggregate",147:"metrics-aggregate",242:"session-manager",317:"jserrors-aggregate",348:"page_view_timing-aggregate",412:"lazy-feature-loader",439:"async-api",538:"recorder",590:"session_replay-aggregate",675:"compressor",733:"session_trace-aggregate",786:"page_view_event-aggregate",873:"spa-aggregate",898:"ajax-aggregate"}[e]||e)+"."+{78:"ac76d497",147:"3dc53903",148:"1a20d5fe",242:"2a64278a",317:"49e41428",348:"bd6de33a",412:"2f55ce66",439:"30bd804e",538:"1b18459f",590:"cf0efb30",675:"ae9f91a8",733:"83105561",786:"06482edd",860:"03a8b7a5",873:"e6b09d52",898:"998ef92b"}[e]+"-1.236.0.min.js"),i.o=(e,t)=>Object.prototype.hasOwnProperty.call(e,t),e={},t="NRBA:",i.l=(r,n,o,a)=>{if(e[r])e[r].push(n);else{var s,c;if(void 0!==o)for(var u=document.getElementsByTagName("script"),d=0;d {s.onerror=s.onload=null,clearTimeout(h);var i=e[r];if(delete e[r],s.parentNode&&s.parentNode.removeChild(s),i&&i.forEach((e=>e(n))),t)return t(n)},h=setTimeout(l.bind(null,void 0,{type:"timeout",target:s}),12e4);s.onerror=l.bind(null,s.onerror),s.onload=l.bind(null,s.onload),c&&document.head.appendChild(s)}},i.r=e=>{"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},i.j=364,i.p="https://js-agent.newrelic.com/",(()=>{var e={364:0,953:0};i.f.j=(t,r)=>{var n=i.o(e,t)?e[t]:void 0;if(0!==n)if(n)r.push(n[2]);else{var o=new Promise(((r,i)=>n=e[t]=[r,i]));r.push(n[2]=o);var a=i.p+i.u(t),s=new Error;i.l(a,(r=>{if(i.o(e,t)&&(0!==(n=e[t])&&(e[t]=void 0),n)){var o=r&&("load"===r.type?"missing":r.type),a=r&&r.target&&r.target.src;s.message="Loading chunk "+t+" failed.\n("+o+": "+a+")",s.name="ChunkLoadError",s.type=o,s.request=a,n[1](s)}}),"chunk-"+t,t)}};var t=(t,r)=>{var n,o,[a,s,c]=r,u=0;if(a.some((t=>0!==e[t]))){for(n in s)i.o(s,n)&&(i.m[n]=s[n]);if(c)c(i)}for(t&&t(r);u {i.r(o);var e=i(3325),t=i(5763);const r=Object.values(e.D);function n(e){const n={};return r.forEach((r=>{n[r]=function(e,r){return!1!==(0,t.Mt)(r,"".concat(e,".enabled"))}(r,e)})),n}var a=i(9144);var s=i(5546),c=i(385),u=i(8e3),d=i(5938),f=i(3960),l=i(50);class h extends d.W{constructor(e,t,r){let n=!(arguments.length>3&&void 0!==arguments[3])||arguments[3];super(e,t,r),this.auto=n,this.abortHandler,this.featAggregate,this.onAggregateImported,n&&(0,u.R)(e,r)}importAggregator(){let e=arguments.length>0&&void 0!==arguments[0]?arguments[0]:{};if(this.featAggregate||!this.auto)return;const r=c.il&&!0===(0,t.Mt)(this.agentIdentifier,"privacy.cookies_enabled");let n;this.onAggregateImported=new Promise((e=>{n=e}));const o=async()=>{let t;try{if(r){const{setupAgentSession:e}=await Promise.all([i.e(860),i.e(242)]).then(i.bind(i,3228));t=e(this.agentIdentifier)}}catch(e){(0,l.Z)("A problem occurred when starting up session manager. This page will not start or extend any session.",e)}try{if(!this.shouldImportAgg(this.featureName,t))return void(0,u.L)(this.agentIdentifier,this.featureName);const{lazyFeatureLoader:r}=await i.e(412).then(i.bind(i,8582)),{Aggregate:o}=await r(this.featureName,"aggregate");this.featAggregate=new o(this.agentIdentifier,this.aggregator,e),n(!0)}catch(e){(0,l.Z)("Downloading and initializing ".concat(this.featureName," failed..."),e),this.abortHandler?.(),n(!1)}};c.il?(0,f.b)((()=>o()),!0):o()}shouldImportAgg(r,n){return r!==e.D.sessionReplay||!1!==(0,t.Mt)(this.agentIdentifier,"session_trace.enabled")&&(!!n?.isNew||!!n?.state.sessionReplay)}}var g=i(7633),p=i(7894);class m extends h{static featureName=g.t9;constructor(r,n){let i=!(arguments.length>2&&void 0!==arguments[2])||arguments[2];if(super(r,n,g.t9,i),("undefined"==typeof PerformanceNavigationTiming||c.Tt)&&"undefined"!=typeof PerformanceTiming){const n=(0,t.OP)(r);n[g.Dz]=Math.max(Date.now()-n.offset,0),(0,f.K)((()=>n[g.qw]=Math.max((0,p.z)()-n[g.Dz],0))),(0,f.b)((()=>{const t=(0,p.z)();n[g.OJ]=Math.max(t-n[g.Dz],0),(0,s.p)("timing",["load",t],void 0,e.D.pageViewTiming,this.ee)}))}this.importAggregator()}}var v=i(1117),b=i(1284);class y extends v.w{constructor(e){super(e),this.aggregatedData={}}store(e,t,r,n,i){var o=this.getBucket(e,t,r,i);return o.metrics=function(e,t){t||(t={count:0});return t.count+=1,(0,b.D)(e,(function(e,r){t[e]=w(r,t[e])})),t}(n,o.metrics),o}merge(e,t,r,n,i){var o=this.getBucket(e,t,n,i);if(o.metrics){var a=o.metrics;a.count+=r.count,(0,b.D)(r,(function(e,t){if("count"!==e){var n=a[e],i=r[e];i&&!i.c?a[e]=w(i.t,n):a[e]=function(e,t){if(!t)return e;t.c||(t=x(t.t));return t.min=Math.min(e.min,t.min),t.max=Math.max(e.max,t.max),t.t+=e.t,t.sos+=e.sos,t.c+=e.c,t}(i,a[e])}}))}else o.metrics=r}storeMetric(e,t,r,n){var i=this.getBucket(e,t,r);return i.stats=w(n,i.stats),i}getBucket(e,t,r,n){this.aggregatedData[e]||(this.aggregatedData[e]={});var i=this.aggregatedData[e][t];return i||(i=this.aggregatedData[e][t]={params:r||{}},n&&(i.custom=n)),i}get(e,t){return t?this.aggregatedData[e]&&this.aggregatedData[e][t]:this.aggregatedData[e]}take(e){for(var t={},r="",n=!1,i=0;i t.max&&(t.max=e),e 2&&void 0!==arguments[2])||arguments[2];super(e,r,j.t,n),c.il&&((0,t.OP)(e).initHidden=Boolean("hidden"===document.visibilityState),(0,N.N)((()=>(0,s.p)("docHidden",[(0,p.z)()],void 0,j.t,this.ee)),!0),(0,O.bP)("pagehide",(()=>(0,s.p)("winPagehide",[(0,p.z)()],void 0,j.t,this.ee))),this.importAggregator())}}var P=i(3081);class C extends h{static featureName=P.t9;constructor(e,t){let r=!(arguments.length>2&&void 0!==arguments[2])||arguments[2];super(e,t,P.t9,r),this.importAggregator()}}var R,I=i(2210),k=i(1214),H=i(2177),L={};try{R=localStorage.getItem("__nr_flags").split(","),console&&"function"==typeof console.log&&(L.console=!0,-1!==R.indexOf("dev")&&(L.dev=!0),-1!==R.indexOf("nr_dev")&&(L.nrDev=!0))}catch(e){}function z(e){try{L.console&&z(e)}catch(e){}}L.nrDev&&H.ee.on("internal-error",(function(e){z(e.stack)})),L.dev&&H.ee.on("fn-err",(function(e,t,r){z(r.stack)})),L.dev&&(z("NR AGENT IN DEVELOPMENT MODE"),z("flags: "+(0,b.D)(L,(function(e,t){return e})).join(", ")));var M=i(6660);class B extends h{static featureName=M.t;constructor(r,n){let i=!(arguments.length>2&&void 0!==arguments[2])||arguments[2];super(r,n,M.t,i),this.skipNext=0;try{this.removeOnAbort=new AbortController}catch(e){}const o=this;o.ee.on("fn-start",(function(e,t,r){o.abortHandler&&(o.skipNext+=1)})),o.ee.on("fn-err",(function(t,r,n){o.abortHandler&&!n[M.A]&&((0,I.X)(n,M.A,(function(){return!0})),this.thrown=!0,(0,s.p)("err",[n,(0,p.z)()],void 0,e.D.jserrors,o.ee))})),o.ee.on("fn-end",(function(){o.abortHandler&&!this.thrown&&o.skipNext>0&&(o.skipNext-=1)})),o.ee.on("internal-error",(function(t){(0,s.p)("ierr",[t,(0,p.z)(),!0],void 0,e.D.jserrors,o.ee)})),this.origOnerror=c._A.onerror,c._A.onerror=this.onerrorHandler.bind(this),c._A.addEventListener("unhandledrejection",(t=>{const r=function(e){let t="Unhandled Promise Rejection: ";if(e instanceof Error)try{return e.message=t+e.message,e}catch(t){return e}if(void 0===e)return new Error(t);try{return new Error(t+(0,D.P)(e))}catch(e){return new Error(t)}}(t.reason);(0,s.p)("err",[r,(0,p.z)(),!1,{unhandledPromiseRejection:1}],void 0,e.D.jserrors,this.ee)}),(0,O.m$)(!1,this.removeOnAbort?.signal)),(0,k.gy)(this.ee),(0,k.BV)(this.ee),(0,k.em)(this.ee),(0,t.OP)(r).xhrWrappable&&(0,k.Kf)(this.ee),this.abortHandler=this.#e,this.importAggregator()}#e(){this.removeOnAbort?.abort(),this.abortHandler=void 0}onerrorHandler(t,r,n,i,o){"function"==typeof this.origOnerror&&this.origOnerror(...arguments);try{this.skipNext?this.skipNext-=1:(0,s.p)("err",[o||new F(t,r,n),(0,p.z)()],void 0,e.D.jserrors,this.ee)}catch(t){try{(0,s.p)("ierr",[t,(0,p.z)(),!0],void 0,e.D.jserrors,this.ee)}catch(e){}}return!1}}function F(e,t,r){this.message=e||"Uncaught error with no additional information",this.sourceURL=t,this.line=r}let U=1;const q="nr@id";function G(e){const t=typeof e;return!e||"object"!==t&&"function"!==t?-1:e===c._A?0:(0,I.X)(e,q,(function(){return U++}))}function V(e){if("string"==typeof e&&e.length)return e.length;if("object"==typeof e){if("undefined"!=typeof ArrayBuffer&&e instanceof ArrayBuffer&&e.byteLength)return e.byteLength;if("undefined"!=typeof Blob&&e instanceof Blob&&e.size)return e.size;if(!("undefined"!=typeof FormData&&e instanceof FormData))try{return(0,D.P)(e).length}catch(e){return}}}var X=i(7243);class W{constructor(e){this.agentIdentifier=e,this.generateTracePayload=this.generateTracePayload.bind(this),this.shouldGenerateTrace=this.shouldGenerateTrace.bind(this)}generateTracePayload(e){if(!this.shouldGenerateTrace(e))return null;var r=(0,t.DL)(this.agentIdentifier);if(!r)return null;var n=(r.accountID||"").toString()||null,i=(r.agentID||"").toString()||null,o=(r.trustKey||"").toString()||null;if(!n||!i)return null;var a=(0,_.M)(),s=(0,_.Ht)(),c=Date.now(),u={spanId:a,traceId:s,timestamp:c};return(e.sameOrigin||this.isAllowedOrigin(e)&&this.useTraceContextHeadersForCors())&&(u.traceContextParentHeader=this.generateTraceContextParentHeader(a,s),u.traceContextStateHeader=this.generateTraceContextStateHeader(a,c,n,i,o)),(e.sameOrigin&&!this.excludeNewrelicHeader()||!e.sameOrigin&&this.isAllowedOrigin(e)&&this.useNewrelicHeaderForCors())&&(u.newrelicHeader=this.generateTraceHeader(a,s,c,n,i,o)),u}generateTraceContextParentHeader(e,t){return"00-"+t+"-"+e+"-01"}generateTraceContextStateHeader(e,t,r,n,i){return i+"@nr=0-1-"+r+"-"+n+"-"+e+"----"+t}generateTraceHeader(e,t,r,n,i,o){if(!("function"==typeof c._A?.btoa))return null;var a={v:[0,1],d:{ty:"Browser",ac:n,ap:i,id:e,tr:t,ti:r}};return o&&n!==o&&(a.d.tk=o),btoa((0,D.P)(a))}shouldGenerateTrace(e){return this.isDtEnabled()&&this.isAllowedOrigin(e)}isAllowedOrigin(e){var r=!1,n={};if((0,t.Mt)(this.agentIdentifier,"distributed_tracing")&&(n=(0,t.P_)(this.agentIdentifier).distributed_tracing),e.sameOrigin)r=!0;else if(n.allowed_origins instanceof Array)for(var i=0;i 2&&void 0!==arguments[2])||arguments[2];super(r,n,Z.t,i),(0,t.OP)(r).xhrWrappable&&(this.dt=new W(r),this.handler=(e,t,r,n)=>(0,s.p)(e,t,r,n,this.ee),(0,k.u5)(this.ee),(0,k.Kf)(this.ee),function(r,n,i,o){function a(e){var t=this;t.totalCbs=0,t.called=0,t.cbTime=0,t.end=E,t.ended=!1,t.xhrGuids={},t.lastSize=null,t.loadCaptureCalled=!1,t.params=this.params||{},t.metrics=this.metrics||{},e.addEventListener("load",(function(r){_(t,e)}),(0,O.m$)(!1)),c.IF||e.addEventListener("progress",(function(e){t.lastSize=e.loaded}),(0,O.m$)(!1))}function s(e){this.params={method:e[0]},T(this,e[1]),this.metrics={}}function u(e,n){var i=(0,t.DL)(r);i.xpid&&this.sameOrigin&&n.setRequestHeader("X-NewRelic-ID",i.xpid);var a=o.generateTracePayload(this.parsedOrigin);if(a){var s=!1;a.newrelicHeader&&(n.setRequestHeader("newrelic",a.newrelicHeader),s=!0),a.traceContextParentHeader&&(n.setRequestHeader("traceparent",a.traceContextParentHeader),a.traceContextStateHeader&&n.setRequestHeader("tracestate",a.traceContextStateHeader),s=!0),s&&(this.dt=a)}}function d(e,t){var r=this.metrics,i=e[0],o=this;if(r&&i){var a=V(i);a&&(r.txSize=a)}this.startTime=(0,p.z)(),this.listener=function(e){try{"abort"!==e.type||o.loadCaptureCalled||(o.params.aborted=!0),("load"!==e.type||o.called===o.totalCbs&&(o.onloadCalled||"function"!=typeof t.onload)&&"function"==typeof o.end)&&o.end(t)}catch(e){try{n.emit("internal-error",[e])}catch(e){}}};for(var s=0;s 1?e[1]=i:e.push(i)}else e[0]&&e[0].headers&&s(e[0].headers,n)&&(this.dt=n);function s(e,t){var r=!1;return t.newrelicHeader&&(e.set("newrelic",t.newrelicHeader),r=!0),t.traceContextParentHeader&&(e.set("traceparent",t.traceContextParentHeader),t.traceContextStateHeader&&e.set("tracestate",t.traceContextStateHeader),r=!0),r}}function x(e,t){this.params={},this.metrics={},this.startTime=(0,p.z)(),this.dt=t,e.length>=1&&(this.target=e[0]),e.length>=2&&(this.opts=e[1]);var r,n=this.opts||{},i=this.target;"string"==typeof i?r=i:"object"==typeof i&&i instanceof Y?r=i.url:c._A?.URL&&"object"==typeof i&&i instanceof URL&&(r=i.href),T(this,r);var o=(""+(i&&i instanceof Y&&i.method||n.method||"GET")).toUpperCase();this.params.method=o,this.txSize=V(n.body)||0}function A(t,r){var n;this.endTime=(0,p.z)(),this.params||(this.params={}),this.params.status=r?r.status:0,"string"==typeof this.rxSize&&this.rxSize.length>0&&(n=+this.rxSize);var o={txSize:this.txSize,rxSize:n,duration:(0,p.z)()-this.startTime};i("xhr",[this.params,o,this.startTime,this.endTime,"fetch"],this,e.D.ajax)}function E(t){var r=this.params,n=this.metrics;if(!this.ended){this.ended=!0;for(var o=0;o 2&&void 0!==arguments[2])||arguments[2];super(e,t,we.t,r),this.importAggregator()}}new class{constructor(e){let t=arguments.length>1&&void 0!==arguments[1]?arguments[1]:(0,_.ky)(16);c._A?(this.agentIdentifier=t,this.sharedAggregator=new y({agentIdentifier:this.agentIdentifier}),this.features={},this.desiredFeatures=new Set(e.features||[]),this.desiredFeatures.add(m),Object.assign(this,(0,a.j)(this.agentIdentifier,e,e.loaderType||"agent")),this.start()):(0,l.Z)("Failed to initial the agent. Could not determine the runtime environment.")}get config(){return{info:(0,t.C5)(this.agentIdentifier),init:(0,t.P_)(this.agentIdentifier),loader_config:(0,t.DL)(this.agentIdentifier),runtime:(0,t.OP)(this.agentIdentifier)}}start(){const t="features";try{const r=n(this.agentIdentifier),i=[...this.desiredFeatures];i.sort(((t,r)=>e.p[t.featureName]-e.p[r.featureName])),i.forEach((t=>{if(r[t.featureName]||t.featureName===e.D.pageViewEvent){const n=function(t){switch(t){case e.D.ajax:return[e.D.jserrors];case e.D.sessionTrace:return[e.D.ajax,e.D.pageViewEvent];case e.D.sessionReplay:return[e.D.sessionTrace];case e.D.pageViewTiming:return[e.D.pageViewEvent];default:return[]}}(t.featureName);n.every((e=>r[e]))||(0,l.Z)("".concat(t.featureName," is enabled but one or more dependent features has been disabled (").concat((0,D.P)(n),"). This may cause unintended consequences or missing data...")),this.features[t.featureName]=new t(this.agentIdentifier,this.sharedAggregator)}})),(0,T.Qy)(this.agentIdentifier,this.features,t)}catch(e){(0,l.Z)("Failed to initialize all enabled instrument classes (agent aborted) -",e);for(const e in this.features)this.features[e].abortHandler?.();const r=(0,T.fP)();return delete r.initializedAgents[this.agentIdentifier]?.api,delete r.initializedAgents[this.agentIdentifier]?.[t],delete this.sharedAggregator,r.ee?.abort(),delete r.ee?.get(this.agentIdentifier),!1}}}({features:[J,m,S,class extends h{static featureName=oe;constructor(t,r){if(super(t,r,oe,!(arguments.length>2&&void 0!==arguments[2])||arguments[2]),!c.il)return;const n=this.ee;let i;(0,k.QU)(n),this.eventsEE=(0,k.em)(n),this.eventsEE.on(se,(function(e,t){this.bstStart=(0,p.z)()})),this.eventsEE.on(ae,(function(t,r){(0,s.p)("bst",[t[0],r,this.bstStart,(0,p.z)()],void 0,e.D.sessionTrace,n)})),n.on(ce+ne,(function(e){this.time=(0,p.z)(),this.startPath=location.pathname+location.hash})),n.on(ce+ie,(function(t){(0,s.p)("bstHist",[location.pathname+location.hash,this.startPath,this.time],void 0,e.D.sessionTrace,n)}));try{i=new PerformanceObserver((t=>{const r=t.getEntries();(0,s.p)(te,[r],void 0,e.D.sessionTrace,n)})),i.observe({type:re,buffered:!0})}catch(e){}this.importAggregator({resourceObserver:i})}},C,xe,B,class extends h{static featureName=de;constructor(e,r){if(super(e,r,de,!(arguments.length>2&&void 0!==arguments[2])||arguments[2]),!c.il)return;if(!(0,t.OP)(e).xhrWrappable)return;try{this.removeOnAbort=new AbortController}catch(e){}let n,i=0;const o=this.ee.get("tracer"),a=(0,k._L)(this.ee),s=(0,k.Lg)(this.ee),u=(0,k.BV)(this.ee),d=(0,k.Kf)(this.ee),f=this.ee.get("events"),l=(0,k.u5)(this.ee),h=(0,k.QU)(this.ee),g=(0,k.Gm)(this.ee);function m(e,t){h.emit("newURL",[""+window.location,t])}function v(){i++,n=window.location.hash,this[ve]=(0,p.z)()}function b(){i--,window.location.hash!==n&&m(0,!0);var e=(0,p.z)();this[pe]=~~this[pe]+e-this[ve],this[ye]=e}function y(e,t){e.on(t,(function(){this[t]=(0,p.z)()}))}this.ee.on(ve,v),s.on(be,v),a.on(be,v),this.ee.on(ye,b),s.on(ge,b),a.on(ge,b),this.ee.buffer([ve,ye,"xhr-resolved"],this.featureName),f.buffer([ve],this.featureName),u.buffer(["setTimeout"+le,"clearTimeout"+fe,ve],this.featureName),d.buffer([ve,"new-xhr","send-xhr"+fe],this.featureName),l.buffer([me+fe,me+"-done",me+he+fe,me+he+le],this.featureName),h.buffer(["newURL"],this.featureName),g.buffer([ve],this.featureName),s.buffer(["propagate",be,ge,"executor-err","resolve"+fe],this.featureName),o.buffer([ve,"no-"+ve],this.featureName),a.buffer(["new-jsonp","cb-start","jsonp-error","jsonp-end"],this.featureName),y(l,me+fe),y(l,me+"-done"),y(a,"new-jsonp"),y(a,"jsonp-end"),y(a,"cb-start"),h.on("pushState-end",m),h.on("replaceState-end",m),window.addEventListener("hashchange",m,(0,O.m$)(!0,this.removeOnAbort?.signal)),window.addEventListener("load",m,(0,O.m$)(!0,this.removeOnAbort?.signal)),window.addEventListener("popstate",(function(){m(0,i>1)}),(0,O.m$)(!0,this.removeOnAbort?.signal)),this.abortHandler=this.#e,this.importAggregator()}#e(){this.removeOnAbort?.abort(),this.abortHandler=void 0}}],loaderType:"spa"})})(),window.NRBA=o})(); window.jQuery || document.write(' ') CKEDITOR_BASEPATH='https://f1000research.com/js/vendor/ckeditor/' window.reactTheme = 'research'; window.MathJax = { CommonHTML: { linebreaks: { automatic: true } }, 'HTML-CSS': { linebreaks: { automatic: true } }, SVG: { linebreaks: { automatic: true } }, AuthorInit: function() { MathJax.Hub.Register.MessageHook('End Process', function () { let timeout = false; // holder for timeout id const delay = 250; // delay after event is "complete" to run callback const reflowMath = function() { const dispFormulas = document.querySelectorAll('.disp-formula.panel'); if (!dispFormulas) { return; } for (const dispFormula of dispFormulas) { const child = dispFormula.querySelector('.MathJax_Preview').nextSibling.firstChild; const isMultiline = MathJax.Hub.getAllJax(dispFormula)[0].root.isMultiline; if (dispFormula.offsetWidth < child.offsetWidth || isMultiline) { MathJax.Hub.Queue(['Rerender', MathJax.Hub, dispFormula]); } } }; window.addEventListener('resize', function() { clearTimeout(timeout); // clear the timeout timeout = setTimeout(reflowMath, delay); // start timing for event "completion" }); }); }, }; if (window.location.hash == '#_=_'){ window.location = window.location.href.split('#')[0] } !function(f,b,e,v,n,t,s){if(f.fbq)return;n=f.fbq=function() {n.callMethod? n.callMethod.apply(n,arguments):n.queue.push(arguments)} ;if(!f._fbq)f._fbq=n; n.push=n;n.loaded=!0;n.version='2.0';n.queue=[];t=b.createElement(e);t.async=!0; t.src=v;s=b.getElementsByTagName(e)[0];s.parentNode.insertBefore(t,s)}(window, document,'script','https://connect.facebook.net/en_US/fbevents.js'); fbq('init', '1641728616063202'); fbq('track', "PixelInitialized", {}); (function(h,o,t,j,a,r){ h.hj=h.hj||function(){(h.hj.q=h.hj.q||[]).push(arguments)}; h._hjSettings={hjid:2318163,hjsv:6}; a=o.getElementsByTagName('head')[0]; r=o.createElement('script');r.async=1; r.src=t+h._hjSettings.hjid+j+h._hjSettings.hjsv; a.appendChild(r); })(window,document,'https://static.hotjar.com/c/hotjar-','.js?sv='); search file_upload Submit your research search menu close search Browse Gateways & Collections How to Publish Submit your Research My Submissions Article Guidelines Article Guidelines (New Versions) Open Data, Software and Code Guidelines Open Data and Accessible Source Materials Guidelines (HSS) Open Data, Software and Code Guidelines (PSE) Prepublication Checks Production Process Posters and Slides Guidelines Document Guidelines Article Processing Charges Peer Review Finding Article Reviewers About How it Works For Reviewers Our Advisors Policies Glossary FAQs For Developers Newsroom Contact My Research Submissions Content and Tracking Alerts My Details Sign In file_upload Submit your research { "@context": "https://schema.org", "@type": "ScholarlyArticle", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://f1000research.com/articles/14-927" }, "headline": "StaggR: an interactive R/Shiny application for planning and visualizing staggered experimental protocols", "datePublished": "2025-09-15T16:45:21", "dateModified": "2026-01-13T07:04:32", "author": [ { "@type": "Person", "name": "Alex Michael Francette" } ], "publisher": { "@type": "Organization", "name": "F1000Research", "logo": { "@type": "ImageObject", "url": "https://f1000research.com/img/AMP/F1000Research_image.png", "height": 480, "width": 60 } }, "image": { "@type": "ImageObject", "url": "https://f1000research.com/img/AMP/F1000Research_image.png", "height": 1200, "width": 150 }, "description": "Biological experiments often require a series of precisely timed operations, and small variations in treatment can result in inconsistent or biased results. To handle multiple samples in parallel with precise temporal resolution, experimentalists may stagger treatments by initiating the workflow of one sample during the wait or incubation time of another. However, as the number of samples processed in parallel and the number of operations increase, it becomes increasingly difficult to identify and execute valid treatment regimens that permit the handling of each sample. To address this, I developed StaggR, an interactive web application that calculates and visualizes compatible staggering intervals for parallelized execution of identical processing workflows. This tool provides a user-friendly interface for defining protocol operations, durations, and wait times. It can automatically calculate the shortest possible conflict-free interval for initiating sample treatments, or allow users to simulate specific intervals to explore potential treatment regimens or bottlenecks. Using StaggR, users of any experience level can rapidly generate complete, color-coded experimental schedules, visualize these workflows in an easy-to-read chart, and execute them using a built-in timer displaying a treatment schedule with live updates. The experimental designs can be saved, shared, and re-imported, ensuring full reproducibility and user control. The application of StaggR is expected to expedite the design and throughput of complex experimental workflows while maximizing reproducibility." } { "@context": "http://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": "1", "item": { "@id": "https://f1000research.com/", "name": "Home" } }, { "@type": "ListItem", "position": "2", "item": { "@id": "https://f1000research.com/browse/articles", "name": "Browse" } }, { "@type": "ListItem", "position": "3", "item": { "@id": "https://f1000research.com/articles/14-927", "name": "StaggR: an interactive R/Shiny application for planning and visualizing..." } } ] } Home Browse StaggR: an interactive R/Shiny application for planning and visualizing... ALL Metrics - Views Downloads Get PDF Get XML Cite How to cite this article Michael Francette A. StaggR: an interactive R/Shiny application for planning and visualizing staggered experimental protocols [version 3; peer review: 2 approved, 1 approved with reservations] . F1000Research 2026, 14 :927 ( https://doi.org/10.12688/f1000research.168987.3 ) NOTE: If applicable, it is important to ensure the information in square brackets after the title is included in all citations of this article. Close Copy Citation Details Export Export Citation Sciwheel EndNote Ref. Manager Bibtex ProCite Sente EXPORT Select a format first Track Share ▬ ✚ Software Tool Article Revised StaggR: an interactive R/Shiny application for planning and visualizing staggered experimental protocols [version 3; peer review: 2 approved, 1 approved with reservations] Alex Michael Francette https://orcid.org/0000-0003-1145-5847 Alex Michael Francette https://orcid.org/0000-0003-1145-5847 PUBLISHED 13 Jan 2026 Author details Author details Department of Cell Biology and Physiology, Washington University in St Louis, St. Louis, Missouri, 63110, USA Alex Michael Francette Roles: Conceptualization, Data Curation, Formal Analysis, Funding Acquisition, Investigation, Methodology, Project Administration, Resources, Software, Supervision, Validation, Visualization, Writing – Original Draft Preparation, Writing – Review & Editing OPEN PEER REVIEW DETAILS REVIEWER STATUS This article is included in the RPackage gateway. Abstract Biological experiments often require a series of precisely timed operations, and small variations in treatment can result in inconsistent or biased results. To handle multiple samples in parallel with precise temporal resolution, experimentalists may stagger treatments by initiating the workflow of one sample during the wait or incubation time of another. However, as the number of samples processed in parallel and the number of operations increase, it becomes increasingly difficult to identify and execute valid treatment regimens that permit the handling of each sample. To address this, I developed StaggR, an interactive web application that calculates and visualizes compatible staggering intervals for parallelized execution of identical processing workflows. This tool provides a user-friendly interface for defining protocol operations, durations, and wait times. It can automatically calculate the shortest possible conflict-free interval for initiating sample treatments, or allow users to simulate specific intervals to explore potential treatment regimens or bottlenecks. Using StaggR, users of any experience level can rapidly generate complete, color-coded experimental schedules, visualize these workflows in an easy-to-read chart, and execute them using a built-in timer displaying a treatment schedule with live updates. The experimental designs can be saved, shared, and re-imported, ensuring full reproducibility and user control. The application of StaggR is expected to expedite the design and throughput of complex experimental workflows while maximizing reproducibility. READ ALL READ LESS Keywords Workflow Optimization, Experimental Design, Reproducibility, High-Throughput Assays, Gantt Chart, Operations Research, R, Shiny Corresponding Author(s) Alex Michael Francette ( [email protected] ) Close Corresponding author: Alex Michael Francette Competing interests: No competing interests were disclosed. Grant information: The author(s) declared that no grants were involved in supporting this work. Copyright: © 2026 Michael Francette A. This is an open access article distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. How to cite: Michael Francette A. StaggR: an interactive R/Shiny application for planning and visualizing staggered experimental protocols [version 3; peer review: 2 approved, 1 approved with reservations] . F1000Research 2026, 14 :927 ( https://doi.org/10.12688/f1000research.168987.3 ) First published: 15 Sep 2025, 14 :927 ( https://doi.org/10.12688/f1000research.168987.1 ) Latest published: 13 Jan 2026, 14 :927 ( https://doi.org/10.12688/f1000research.168987.3 ) Revised Amendments from Version 2 Note, the positioning of figures were also “rearranged” in version 3 of the manuscript in order to put them in their correct positions reflected in my original version 2 submission: Between version 2 and version 3 of the article, the zenodo repository link was updated to the most recent version of StaggR that fixes critical bugs introduced by transferring core scheduling logic outside of the Shiny server function. The app no longer disconnects when changing sample names/count or clicking example protocols, and the first three "?" icons now display appropriate information. A “Download Sample Session (.json)” button was added to the application to better help users understand the format and parameters input to the application. These changes promote the ethos of StaggR to be simple to use and customize. Note, the positioning of figures were also “rearranged” in version 3 of the manuscript in order to put them in their correct positions reflected in my original version 2 submission: Between version 2 and version 3 of the article, the zenodo repository link was updated to the most recent version of StaggR that fixes critical bugs introduced by transferring core scheduling logic outside of the Shiny server function. The app no longer disconnects when changing sample names/count or clicking example protocols, and the first three "?" icons now display appropriate information. A “Download Sample Session (.json)” button was added to the application to better help users understand the format and parameters input to the application. These changes promote the ethos of StaggR to be simple to use and customize. See the author's detailed response to the review by Charuka D Wickramasinghe See the author's detailed response to the review by Thomas Darde READ REVIEWER RESPONSES Introduction Biological processes, such as pre-mRNA splicing, intracellular signaling cascades, and protein decay occur on rapid timescales ranging from microseconds to days ( Shamir et al., 2016 ). Therefore, to capture these dynamic events, research in fields such as pharmacology, biochemistry, and genomics often relies on complex and time-sensitive sample workflows. To execute protocols across multiple conditions with multiple replicates, an experimentalist will often stagger their treatments so that some samples can be handled during the waiting periods of others. When experiments are sensitive to small time variations, staggering treatments can be an effective tool for reducing experimental noise while simultaneously increasing productivity by reducing the time required to handle multiple samples. However, calculating a valid, let alone minimized, staggering interval is a non-trivial cognitive task. An excessively long staggering interval can make experiments too long to fit within the work period. Conversely, reducing the interval too much can be overwhelming for an experimentalist to keep track of. Mishandling of samples due to poor experimental design can lead to compromised reproducibility and loss of valuable materials. While simple protocols can be scheduled with a spreadsheet, complex workflows with numerous, non-uniform operations quickly become intractable to plan manually. Each additional time-sensitive task and sample added to the workflow creates a new potential scheduling conflict. Furthermore, some staggered experimental setups may have no conflict-free solutions. However, without extensive trial and error during planning, it is difficult to determine whether a schedule is possible. This challenge is a practical instance of a well-defined class of optimization problems in operations research, known as the Permutation Flow Shop Scheduling Problem (FSSP) ( Emmons, 2013 ). FSSP approaches optimize how agents (in this case humans) perform sequential jobs (sample processing pipelines) which consist of multiple operations (sample processing steps) of discrete durations with the constraint that operations must occur in the same order. In this case, there is a single operator responsible for all tasks who cannot be engaged with two tasks simultaneously. Typical solutions in this space are designed for machining applications. However, open-source tools to optimize the workflows for average users on the bench are lacking. To address this problem intuitively, I present StaggR, an interactive platform that serves to optimize, simulate, and facilitate staggered experimental protocols with identical processing workflows. StaggR provides a graphical user interface for defining the number of samples to be processed in parallel and the key operations of a protocol consisting of “hands-on” durations (i.e. the estimated time required to execute an operation) and “wait times” (i.e. how long between the completion of one operation and the start of the next). Based on this plan, StaggR will attempt to optimize the minimal valid staggering interval allotting for a known amount of user imprecision and provide 1) a Gantt chart that visualizes a work schedule for processing the user-defined samples in parallel, 2) a downloadable table with step-by-step instructions showing the chronological series of events that comprise the solved workflow, and 3) a tool to dynamically track the progression of a workflow plan in real time to assist in the timely execution of operations. StaggR is a simple application designed to provide a clean, easy-to-use interface that quickly expands the capacity of experimentalists to explore and execute complex sample-processing pipelines. Methods Implementation At the core of StaggR is a scheduling algorithm that uses an iterative search heuristic which simulates an experimental schedule to process an arbitrary number of samples, each starting at times offset by a fixed interval automatically identified by the application or manually input by the user ( Figure 1 and Figure 2 ). In “automatic” mode, StaggR tests increasing staggering intervals until a valid schedule is identified. A “granularity” parameter (default of 0.25 min) defines the initial protocol staggering interval and the increment by which the interval is iteratively increased. For a given interval, StaggR checks for time points where the researcher is simultaneously occupied by the hands-on time requirements for more than one task. If a conflict is detected, the staggering interval is increased by the granularity value and the simulation is repeated until a conflict-free schedule is found. This approach approximates the shortest possible total experiment time without creating logistical impossibility. The algorithm also accounts for user-defined “buffer time” (e.g., 1 min) a short duration added to the end of each operation to model the time it takes to switch between tasks. If the staggering interval exceeds the base duration required for a single protocol, then the optimization will end as it failed to identify a valid interval and the user will be prompted to adjust the input parameters. StaggR runs the optimization by default. By enabling “manual” mode, the user may experiment with different staggering intervals to examine alternate treatment schedules. Figure 1. StaggR shiny app overview. Upon initialization of the application, the user inputs the experimental parameters and generates a schedule automatically with a manually-provided or automatically-determined 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. Figure 2. Core logic for staggering interval optimization. Conceptual diagram of the architecture behind the staggering interval optimization algorithm of StaggR. Upon receiving a user defined protocol, a treatment schedule is generated depicting the time for which an operation is scheduled to be executed (e.g. pipetting a drug into a sample) extended by a buffer duration, and the wait time between one task and the next (e.g. incubation period). Identical protocols are initialized for each sample input staggered by the granularity time increment. This initial prospective schedule is evaluated for incompatibilities where more than one task is scheduled at the same time (invalid). If incompatible, the schedule is recalculated with an incrementally larger interval and re-evaluated until a compatible schedule is found or the interval exceeds the base duration of the single-sample protocol. If the user manually provides an interval, this process skips directly to a GUI rendering highlighting any detected scheduling conflicts. 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. Classical approaches have steep learning curves and will often produce asynchronous staggering intervals perfect for machine operation. However, human agents are poorly suited to handle the resultant chaotic schedules. The heuristic behind StaggR is developed primarily to be accessible for a broad user base, focusing on ease of understanding, input, and execution with a regular cadence. The StaggR algorithm imposes key constraints. Identical protocol schedules for each sample are assumed. Therefore, heterogeneous treatment schedules with samples undergoing differently spaced protocol steps are not permitted to be entered. StaggR also assumes an identical staggering interval for all samples and incurs a flat buffering period for all tasks. The granularity defined by the user further limits how close the reported staggering interval is to the true optimal interval. For example, increasing the granularity from the 0.25 min default to 5 min means that only staggering intervals which are a multiple of 5 min (10 min, 15 min, 20 min, etc.) will be examined. Therefore, if the optimal staggering interval was not an interval of 5 min (e.g. 7 min), it will be skipped over and remain unchecked. This can lead to a failure (no solution) or a sub-optimal, but valid, solution unless the granularity is reduced. 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 figure panels demonstrating use cases are derived from screenshot images natively generated using the StaggR app. 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 ( Figure 1 ). 1. Define Protocol - The user first provides the following information to the scheduler: • Sample descriptions : The number and names of samples used for the protocol. • Operation descriptions : The number and names of the operations used in the protocol. Each operation is an action or a series of actions that require constant attention. • Step duration : The hands-on duration in min for each operation. This is the maximum time allotted to an individual operation to take place. For example, a user may estimate that it takes 2 min to add a drug to a sample, put that sample away, and move on to the next. This parameter may be shorter for a more experienced experimentalist or longer for trainees new to the protocol. For the best results, it is recommended that inexperienced users perform a dry run for each operation to obtain a better understanding of their individual pacing. • Time between steps : The inter-operation interval or “wait time” that occurs between the end of one manual operation and the beginning of the next (e.g., the duration of an incubation after adding a drug, or the duration of a centrifugation step after loading a centrifuge). The user may additionally utilize the “Time Course Helper” to easily insert a simple time series by first choosing an anchoring operation (e.g., the start of a drug treatment), then defining an operation to be repeated (e.g., harvest cells) and lastly identifying the time points to enact the repeating operation (e.g., 5, 15, 30, and 60 min). All parameters may be saved and edited externally for re-uploading if desired. (Optional) Additional Parameters - StaggR provides additional flexibility in the planning through additional parameters that may be modified but are pre-populated with convenient values by default. • Buffer time : The user may specify a defined “buffer time” to allow switching between tasks. For example, the default buffer time of 1 min means a staggering interval will not be accepted if another manual operation is scheduled to begin within 1 min after the end of any other operation. This is designed to accommodate for a known degree of human imprecision during protocol execution. • Optimizer granularity : The user can define the lengths of the time steps for which the optimizer checks for conflict. This value will also be used as the first test interval. For example, the default granularity of 0.25 min means an initial schedule with a 0.25 min staggering of each sample will be tested. If conflicts are detected, a 0.5 min staggering will be evaluated and so on until the staggering interval exceeds the duration of a single protocol at which point samples would be processed sequentially and not staggered. A smaller granularity often leads to a solution closer to the optimal solution, but requires greater computational resources. Adjust according to the time scale of the workflow. • Graphical parameters : The user can also modulate several features of the output displays including the colors of each operation used for visualization, a base color to generate a spread of colors for samples, and the X-axis tick interval. 2. Generate Schedule: Upon clicking “Generate Schedule,” StaggR calculates the start time for every operation of every sample. In the optimization mode, it iteratively tests increasing staggering intervals until it finds the shortest interval that results in no temporal overlap of manual tasks. 3. Visualize and Export: The results are presented in three tabs: • Gantt Chart: A comprehensive visualization of the entire experimental timeline showing the timing for each sample and operation. It also includes a “Hands-On Time” track that aggregates all manual tasks, clearly indicating when the researcher is busy, free, or has scheduling conflicts (in manual mode). • Schedule by Time: A chronological, time-stamped list of every action to be performed. • Schedule by Sample: A table detailing the start time of each operation for each sample. 4. Execute: StaggR provides multiple views that can assist in the execution of charted workflows. The “Live Time Course” tab helps you execute the plan, providing live updates as operations become due. Under the “Schedule by Time” tab, the chronological table provides live updates for constant clarity in the execution of the past, current, and forthcoming operations. The “Schedule by Sample” tab shows the timing for processing grouped by each sample. All outputs, including the plot (PDF, PNG, etc.), parameter set, and data tables can be downloaded individually as a zip report for record-keeping and sharing workflows. Core logic Use cases To demonstrate the utility of StaggR, I provide three pre-loaded protocols that exemplify setups common in laboratory work. These use cases can be directly loaded from the “About” tab and act as templates for workflow design with minimal modification. 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-min 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 min 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 3A ). The user then clicks “Generate Schedule” and discovers that a 14.5 min staggering would be the best solution if they desired to handle each sample individually ( Figure 3B ). By enabling the manual mode and inputting a 6-minute interval, the user can immediately visualize the resulting scheduling conflicts ( Figure 3C ). This application of StaggR highlights its utility in allowing the exploration of viable and inviable workflows. Figure 3. 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-min drug treatment followed by a 15-min 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 red in the “Hands-on Time” row. Users are further alerted to an incompatible schedule using a manually-defined interval in the subtitle of the Gantt chart. 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 4A ) and enables the Time Course Helper, in which they specify the harvesting time points of 5, 15, 30, and 60 min after 4tU addition ( Figure 4B ). After applying the time course, the step parameters were automatically updated ( Figure 4C ), and the user immediately generates their optimal schedule with a 22-min staggering period ( Figure 4D ). 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 4. 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 0.5 min 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-min staggering would work ( Figure 5A ). Their trainee wishes to perform a similar protocol, so the mentor downloads the session to share as a.json file ( Figure 5B ) 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 min stagger between each sample to execute ( Figure 5C ). 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 6 ). Using StaggR, the trainee avoids what would have been an inevitable and critical error in executing this complex workflow. Figure 5. Use Case #3 – Adapting a Complex Workflow for Different Users. (A) Gantt chart showing the optimized schedule for a complex workflow assuming a 6-min 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 min, the regenerated schedule shows that a conflict-free workflow now requires a much longer 84 min staggering interval, highlighting a potential bottleneck. Figure 6. 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. StaggR performance To establish how user-defined parameters impact the performance of StaggR, the core “findOptimalInterval” function was isolated and benchmarked against 500 iterations of schedule optimization with varying input parameters ( Figure 7 ). As granularity decreases, the cost to run StaggR increases exponentially ( Figure 7A-B ). While increasing the number of samples processed elevates resource usage, this effect quickly plateaus ( Figure 7C-D ). However, increasing the number of discrete operations for each protocol (complexity) does incur escalating cost to optimize ( Figure 7E-F ). The density of hands-on time for a given protocol has a minimal impact on the performance of StaggR, and these costs quickly saturate once the density exceeds a point where a viable staggering schedule can no longer be found ( Figure 7G-H ). Decreasing optimization granularity combined with increased protocol complexity leads to sharp increases in resource usage ( Figure 7I-J ). However, even in the most extreme scenarios examined the wall-time remains under one minute and RAM usage remains under 125 MB. Figure 7. Wall-time and RAM usage of StaggR as a function of input parameters. Performance metrics from 500 runs of StaggR schedule optimization logic against simulated protocols. A base protocol was defined with 5 steps of equal duration, optimization granularity = 0.5 min, nSamples = 50, buffer time = 0.25 min, and a total protocol time of nSteps * 10 min. The fraction of each protocol occupied by hands-on time was given by a density parameter from 0-1 where a density of 0.3 means 30% of the protocol duration was hands-on. Density was set to 0.5 unless otherwise stated. Each protocol was evaluated for the time to complete the optimization (A, C, E, G, I) and the total RAM used in the process (B, D, F, H, J). (A, B) Performance cost with increasing protocol granularity. (C, D) Performance cost with increasing sample throughput. (E, F) Performance cost with increasing number of operations per protocol. (G, H) Performance cost with increasing hands-on time density. (I, J) Resource usage with co-varying granularity and number of operations. Shaded areas represent the standard deviation in run times. Overall, this analysis reveals that simulation granularity and the total number of operations to execute each protocol are the major performance bottlenecks of the scheduling algorithm. Given that realistic sample treatment regimens executed by humans are unlikely to exceed 50 sequential operations requiring extreme temporal precision, StaggR is expected to rapidly generate a report for most standard and non-standard protocols. However, users with highly complex protocols or large sample numbers are encouraged to run the application locally to utilize full system RAM. Conclusion StaggR reduces the cognitive load when managing multiple samples with identical treatment schedules by compressing the planning process. This enables the rapid exploration of alternative workflows so that users can quickly assess what is feasible, where conflicts might arise, and where natural breaks occur. This is particularly helpful when protocols are transferred between labs or users, as new execution-time constraints can introduce scheduling conflicts. Sharing protocols and sessions with StaggR makes such conflicts readily apparent and easily preventable. StaggR also boosts the laboratory throughput by minimizing the time required to handle batches of samples. Many strategies exist to address the FSSP, such as Genetic Algorithms, Simulated Annealing, and Tabu Search ( Komaki et al., 2018 ) which can efficiently search the space of heterogeneous sample processing regimes to provide an optimal solution. StaggR is not designed to present a novel solution to the FSSP but to provide a convenient platform for experimental design and execution. Future versions of StaggR may implement more nuanced FSSP strategies that make fewer assumptions regarding the homogeneity of each treatment schedule and more efficiently search the space of potential treatment workflows. Nonetheless, as a standalone planning and execution tool, StaggR reduces cognitive barriers to provide immediate value for any lab that aims to perform time-sensitive assays in parallel. By removing the guesswork and potential error in scheduling identical procedures with asynchronous start times, StaggR can empower researchers from diverse fields to perform high-throughput experiments with greater confidence, efficiency, and reproducibility. Its open source and interactive nature makes it an ideal and broadly applicable tool for planning novel experiments and training personnel on established laboratory workflows. Software availability • Web Application: StaggR is available for immediate use at https://alexfrancette.shinyapps.io/staggr/ • Source code available from: The complete R source code is available on GitHub: https://github.com/amfrancette/StaggR • Archived source code at time of publication : https://doi.org/10.5281/zenodo.18132229 • License: StaggR is distributed under the MIT License. Data availability • Raw benchmarking data are available in the associated Zenodo repository. Acknowledgments I would like to thank Dr. Karen Arndt for her feedback on this manuscript. References Baranello L, Kouzine F, Sanford S, et al. : ChIP bias as a function of cross-linking time. Chromosom. Res. 2016; 24 : 175–181. PubMed Abstract | Publisher Full Text | Free Full Text Barrass JD, Reid JE, Huang Y, et al. : Transcriptome-wide RNA processing kinetics revealed using extremely short 4tU labeling. Genome Biol. 2015; 16 : 282. PubMed Abstract | Publisher Full Text | Free Full Text Emmons HV, George: Flow Shop Scheduling. New York, NY: Springer; 1st ed. 2013. Publisher Full Text Komaki GM, Sheikh S, Malakooti B: Flow shop scheduling problems with assembly operations: a review and new trends. Int. J. Prod. Res. 2018; 57 : 2926–2955. Publisher Full Text Mah LJ, El-Osta A, Karagiannis TC: gammaH2AX: a sensitive molecular marker of DNA damage and repair. Leukemia. 2010; 24 : 679–686. Publisher Full Text Nishimura K, Fukagawa T, Takisawa H, et al. : An auxin-based degron system for the rapid depletion of proteins in nonplant cells. Nat. Methods. 2009; 6 : 917–922. PubMed Abstract | Publisher Full Text Schnell U, Dijk F, Sjollema KA, et al. : Immunolabeling artifacts and the need for live-cell imaging. Nat. Methods. 2012; 9 : 152–158. PubMed Abstract | Publisher Full Text Shamir M, Bar-On Y, Phillips R, et al. : SnapShot: Timescales in Cell Biology. Cell. 2016; 164 : 1302–1302.e1. PubMed Abstract | Publisher Full Text Wickham H: Ggplot2. Wiley Interdisciplinary Reviews: Computational Statistics. 2011; 3 : 180–185. Publisher Full Text Wickham H, Averick M, Bryan J, et al. : Welcome to the Tidyverse. Journal of Open Source Software. 2019; 4 : 1686. Publisher Full Text Yarbro JW: Mechanism of action of hydroxyurea. Semin. Oncol. 1992; 19 : 1–10. PubMed Abstract Comments on this article Comments (0) Version 3 VERSION 3 PUBLISHED 15 Sep 2025 ADD YOUR COMMENT Comment Author details Author details Department of Cell Biology and Physiology, Washington University in St Louis, St. Louis, Missouri, 63110, USA Alex Michael Francette Roles: Conceptualization, Data Curation, Formal Analysis, Funding Acquisition, Investigation, Methodology, Project Administration, Resources, Software, Supervision, Validation, Visualization, Writing – Original Draft Preparation, Writing – Review & Editing Competing interests No competing interests were disclosed. Grant information The author(s) declared that no grants were involved in supporting this work. Article Versions (3) version 3 Revised Published: 13 Jan 2026, 14:927 https://doi.org/10.12688/f1000research.168987.3 version 2 Revised Published: 12 Dec 2025, 14:927 https://doi.org/10.12688/f1000research.168987.2 version 1 Published: 15 Sep 2025, 14:927 https://doi.org/10.12688/f1000research.168987.1 Copyright © 2026 Michael Francette A. This is an open access article distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. Download Export To Sciwheel Bibtex EndNote ProCite Ref. Manager (RIS) Sente metrics Views Downloads F1000Research - - PubMed Central info_outline Data from PMC are received and updated monthly. - - Citations open_in_new 0 open_in_new 0 open_in_new SEE MORE DETAILS CITE how to cite this article Michael Francette A. StaggR: an interactive R/Shiny application for planning and visualizing staggered experimental protocols [version 3; peer review: 2 approved, 1 approved with reservations] . F1000Research 2026, 14 :927 ( https://doi.org/10.12688/f1000research.168987.3 ) NOTE: If applicable, it is important to ensure the information in square brackets after the title is included in all citations of this article. COPY CITATION DETAILS track receive updates on this article Track an article to receive email alerts on any updates to this article. TRACK THIS ARTICLE Share Open Peer Review Current Reviewer Status: ? Key to Reviewer Statuses VIEW HIDE Approved The paper is scientifically sound in its current form and only minor, if any, improvements are suggested Approved with reservations A number of small changes, sometimes more significant revisions are required to address specific details and improve the papers academic merit. Not approved Fundamental flaws in the paper seriously undermine the findings and conclusions Version 3 VERSION 3 PUBLISHED 13 Jan 2026 Revised Views 0 Cite How to cite this report: Correig-Fraga E. Reviewer Report For: StaggR: an interactive R/Shiny application for planning and visualizing staggered experimental protocols [version 3; peer review: 2 approved, 1 approved with reservations] . F1000Research 2026, 14 :927 ( https://doi.org/10.5256/f1000research.194752.r460176 ) The direct URL for this report is: https://f1000research.com/articles/14-927/v3#referee-response-460176 NOTE: it is important to ensure the information in square brackets after the title is included in this citation. Close Copy Citation Details Reviewer Report 10 Mar 2026 Eudald Correig-Fraga , Universitat Rovira i Virgili, Tarragona, Spain; Reserach Department, Innovamat Education, Sant Cugat del Vallès, Catalonia, Spain Approved VIEWS 0 https://doi.org/10.5256/f1000research.194752.r460176 This paper presents a software tool to organize staggered experiments in a simple yet useful way. The motivation is well explained, and the methods are clear. The source code is provided, together with a link to an instance of the ... Continue reading READ ALL This paper presents a software tool to organize staggered experiments in a simple yet useful way. The motivation is well explained, and the methods are clear. The source code is provided, together with a link to an instance of the program hosted by the author himself. The case examples already loaded on the app are a very nice addition by the author to understand how to start with the tool. A few comments: Manuscript: - I feel like the first and second paragraph were unadvertedly separated? - It's not completely clear to me what's the state of the art to solve this issue. The author says "quickly become intractable to plan manually", and then present solutions for machining operations, but people are planning now; are they using commercial software (if so, which one), or very complex and unmaintainable spreadsheets? this comparison again should be raised in the conclusion - the citations are a bit haphazard: why is dplyr or ggplot cited, but shiny is not? Or Tabu Search, but not Simulated Annealing. - There is a "Core logic" title that I don't know what refers to. - I don't think the performance section is relevant for such a simple tool. In any case, if it's added, I'm more interested in how long does it take for the tool to give me a solution, than the amount of RAM it uses. Code: - Since the author started using tidyverse (dplyr), I would recommend go all the way, and do all the manipulations in tidyverse. - There are benchmark tests, but not logic tests; it would be nice to add them. - The code should be formatted consistently (for example, in RStudio, doing Ctrl+A, then Ctrl + Shift + A). Is the rationale for developing the new software tool clearly explained? Yes Is the description of the software tool technically sound? Yes Are sufficient details of the code, methods and analysis (if applicable) provided to allow replication of the software development and its use by others? Yes Is sufficient information provided to allow interpretation of the expected output datasets and any results generated using the tool? Yes Are the conclusions about the tool and its performance adequately supported by the findings presented in the article? Yes Competing Interests: No competing interests were disclosed. Reviewer Expertise: Statistics, Programming, Computational neuroscience. I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard. Close READ LESS CITE CITE HOW TO CITE THIS REPORT Correig-Fraga E. Reviewer Report For: StaggR: an interactive R/Shiny application for planning and visualizing staggered experimental protocols [version 3; peer review: 2 approved, 1 approved with reservations] . F1000Research 2026, 14 :927 ( https://doi.org/10.5256/f1000research.194752.r460176 ) The direct URL for this report is: https://f1000research.com/articles/14-927/v3#referee-response-460176 NOTE: it is important to ensure the information in square brackets after the title is included in all citations of this article. COPY CITATION DETAILS Report a concern Respond or Comment COMMENT ON THIS REPORT Views 0 Cite How to cite this report: Wickramasinghe CD. Reviewer Report For: StaggR: an interactive R/Shiny application for planning and visualizing staggered experimental protocols [version 3; peer review: 2 approved, 1 approved with reservations] . F1000Research 2026, 14 :927 ( https://doi.org/10.5256/f1000research.194752.r449912 ) The direct URL for this report is: https://f1000research.com/articles/14-927/v3#referee-response-449912 NOTE: it is important to ensure the information in square brackets after the title is included in this citation. Close Copy Citation Details Reviewer Report 15 Jan 2026 Charuka D Wickramasinghe , Wayne State University, Detroit, Michigan, USA; Oncology, Wayne State University School of Medicine (Ringgold ID: 12267), Detroit, Michigan, USA Approved VIEWS 0 https://doi.org/10.5256/f1000research.194752.r449912 No further comments to ... Continue reading READ ALL No further comments to make. I Approved this. Competing Interests: No competing interests were disclosed. Reviewer Expertise: Bioinformatics; Pharmacology; Applied Mathematics; Programming; Machine Learning I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard. Close READ LESS CITE CITE HOW TO CITE THIS REPORT Wickramasinghe CD. Reviewer Report For: StaggR: an interactive R/Shiny application for planning and visualizing staggered experimental protocols [version 3; peer review: 2 approved, 1 approved with reservations] . F1000Research 2026, 14 :927 ( https://doi.org/10.5256/f1000research.194752.r449912 ) The direct URL for this report is: https://f1000research.com/articles/14-927/v3#referee-response-449912 NOTE: it is important to ensure the information in square brackets after the title is included in all citations of this article. COPY CITATION DETAILS Report a concern Respond or Comment COMMENT ON THIS REPORT Version 2 VERSION 2 PUBLISHED 12 Dec 2025 Revised Views 0 Cite How to cite this report: Wickramasinghe CD. Reviewer Report For: StaggR: an interactive R/Shiny application for planning and visualizing staggered experimental protocols [version 3; peer review: 2 approved, 1 approved with reservations] . F1000Research 2026, 14 :927 ( https://doi.org/10.5256/f1000research.193274.r442762 ) The direct URL for this report is: https://f1000research.com/articles/14-927/v2#referee-response-442762 NOTE: it is important to ensure the information in square brackets after the title is included in this citation. Close Copy Citation Details Reviewer Report 02 Jan 2026 Charuka D Wickramasinghe , Wayne State University, Detroit, Michigan, USA; Oncology, Wayne State University School of Medicine (Ringgold ID: 12267), Detroit, Michigan, USA Approved with Reservations VIEWS 0 https://doi.org/10.5256/f1000research.193274.r442762 This article presents StaggR , an interactive web application that calculates and visualizes compatible staggering intervals for parallelized execution of identical processing workflows. StaggR provides a user-friendly interface for defining protocol operations, durations, and wait times. Overall, the article has a ... Continue reading READ ALL This article presents StaggR , an interactive web application that calculates and visualizes compatible staggering intervals for parallelized execution of identical processing workflows. StaggR provides a user-friendly interface for defining protocol operations, durations, and wait times. Overall, the article has a strong potential for indexing after the following corrections. A few bugs were identified in the R Shiny code. (Major) The R Shiny application is disconnected from the server when the number of samples or sample names is changed. (Major) Under the “About” tab, the R Shiny application is disconnected from the server when the example protocols are clicked. (Minor) The first three question mark (“?”) icons in the left panel of the user interface do not display any information. Adding appropriate descriptions for these three icons is recommended. (Minor – optional) Adding a downloadable sample input file next to the file upload tab is recommended to help users better understand how the application works. (Minor – optional) Adding a short video demonstration illustrating the functionality of the application is recommended. Is the rationale for developing the new software tool clearly explained? Yes Is the description of the software tool technically sound? Yes Are sufficient details of the code, methods and analysis (if applicable) provided to allow replication of the software development and its use by others? Yes Is sufficient information provided to allow interpretation of the expected output datasets and any results generated using the tool? Yes Are the conclusions about the tool and its performance adequately supported by the findings presented in the article? Yes References 1. Wickramasinghe C, Kim S, Li J: SpatialCNS ‐PBPK : An R/Shiny Web‐Based Application for Physiologically Based Pharmacokinetic Modeling of Spatial Pharmacokinetics in the Human Central Nervous System and Brain Tumors. CPT: Pharmacometrics & Systems Pharmacology . 2025; 14 (5): 864-880 Publisher Full Text Competing Interests: No competing interests were disclosed. Reviewer Expertise: Bioinformatics; Pharmacology; Applied Mathematics; Programming; Machine Learning I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard, however I have significant reservations, as outlined above. Close READ LESS CITE CITE HOW TO CITE THIS REPORT Wickramasinghe CD. Reviewer Report For: StaggR: an interactive R/Shiny application for planning and visualizing staggered experimental protocols [version 3; peer review: 2 approved, 1 approved with reservations] . F1000Research 2026, 14 :927 ( https://doi.org/10.5256/f1000research.193274.r442762 ) The direct URL for this report is: https://f1000research.com/articles/14-927/v2#referee-response-442762 NOTE: it is important to ensure the information in square brackets after the title is included in all citations of this article. COPY CITATION DETAILS Report a concern Author Response 13 Jan 2026 Alex Francette , Department of Cell Biology and Physiology, Washington University in St Louis, St. Louis, 63110, USA 13 Jan 2026 Author Response I thank you for identifying several areas for improvement for the app. I have addressed your comments as follows: Reviewer 2, Comments 1,2,3: Fixed bugs introduced by transferring core ... Continue reading I thank you for identifying several areas for improvement for the app. I have addressed your comments as follows: Reviewer 2, Comments 1,2,3: Fixed bugs introduced by transferring core scheduling logic outside of the Shiny server function. The app no longer disconnects when changing sample names/count or clicking example protocols, and the first three "?" icons now display appropriate information. Reviewer 2, Comment 4: Added a "Download Sample Session (.json)" button next to the file upload tab to make the app more user-friendly. Reviewer 2, Comment 5: I believe a video demonstration is a good idea, and I will strongly consider creating one to include in future updates of the app. I thank you for identifying several areas for improvement for the app. I have addressed your comments as follows: Reviewer 2, Comments 1,2,3: Fixed bugs introduced by transferring core scheduling logic outside of the Shiny server function. The app no longer disconnects when changing sample names/count or clicking example protocols, and the first three "?" icons now display appropriate information. Reviewer 2, Comment 4: Added a "Download Sample Session (.json)" button next to the file upload tab to make the app more user-friendly. Reviewer 2, Comment 5: I believe a video demonstration is a good idea, and I will strongly consider creating one to include in future updates of the app. Competing Interests: No competing interests were disclosed. Close Report a concern Respond or Comment COMMENTS ON THIS REPORT Author Response 13 Jan 2026 Alex Francette , Department of Cell Biology and Physiology, Washington University in St Louis, St. Louis, 63110, USA 13 Jan 2026 Author Response I thank you for identifying several areas for improvement for the app. I have addressed your comments as follows: Reviewer 2, Comments 1,2,3: Fixed bugs introduced by transferring core ... Continue reading I thank you for identifying several areas for improvement for the app. I have addressed your comments as follows: Reviewer 2, Comments 1,2,3: Fixed bugs introduced by transferring core scheduling logic outside of the Shiny server function. The app no longer disconnects when changing sample names/count or clicking example protocols, and the first three "?" icons now display appropriate information. Reviewer 2, Comment 4: Added a "Download Sample Session (.json)" button next to the file upload tab to make the app more user-friendly. Reviewer 2, Comment 5: I believe a video demonstration is a good idea, and I will strongly consider creating one to include in future updates of the app. I thank you for identifying several areas for improvement for the app. I have addressed your comments as follows: Reviewer 2, Comments 1,2,3: Fixed bugs introduced by transferring core scheduling logic outside of the Shiny server function. The app no longer disconnects when changing sample names/count or clicking example protocols, and the first three "?" icons now display appropriate information. Reviewer 2, Comment 4: Added a "Download Sample Session (.json)" button next to the file upload tab to make the app more user-friendly. Reviewer 2, Comment 5: I believe a video demonstration is a good idea, and I will strongly consider creating one to include in future updates of the app. Competing Interests: No competing interests were disclosed. Close Report a concern COMMENT ON THIS REPORT Version 1 VERSION 1 PUBLISHED 15 Sep 2025 Views 0 Cite How to cite this report: Darde T. Reviewer Report For: StaggR: an interactive R/Shiny application for planning and visualizing staggered experimental protocols [version 3; peer review: 2 approved, 1 approved with reservations] . F1000Research 2026, 14 :927 ( https://doi.org/10.5256/f1000research.186237.r428843 ) The direct URL for this report is: https://f1000research.com/articles/14-927/v1#referee-response-428843 NOTE: it is important to ensure the information in square brackets after the title is included in this citation. Close Copy Citation Details Reviewer Report 25 Nov 2025 Thomas Darde , SciLicium, 10 Rue de La Sauvaie, Rennes, France Approved with Reservations VIEWS 0 https://doi.org/10.5256/f1000research.186237.r428843 This manuscript presents StaggR, an interactive and open-source R/Shiny application designed to assist researchers in planning, visualizing, and executing staggered experimental workflows, particularly for time-sensitive molecular biology assays. The complexity of coordinating multiple samples with identical but offset treatment sequences ... Continue reading READ ALL This manuscript presents StaggR, an interactive and open-source R/Shiny application designed to assist researchers in planning, visualizing, and executing staggered experimental workflows, particularly for time-sensitive molecular biology assays. The complexity of coordinating multiple samples with identical but offset treatment sequences is a well-known bottleneck in wet-lab research. StaggR provides a practical solution that integrates workflow definition, conflict detection, Gantt chart visualization, and a live execution timer. The tool is accessible, fully open-source, and addresses a reproducibility challenge often overlooked in workflow design. The manuscript is clearly written and the tool appears directly usable. Overall, the article has strong potential for indexed once several key revisions are addressed. 1. (Major) Lack of performance and scalability evaluation The scheduling algorithm is described as a simple heuristic. However, the manuscript provides no benchmarks evaluating: - runtime as sample number increases, - scalability to large workflows, - memory/time constraints during optimization. A small benchmarking section or supplementary figure would greatly strengthen the work. 2. (Minor)Insufficient description of failure modes The manuscript does not clearly explain: - how StaggR behaves when no conflict-free solution exists, - how users are alerted to impossibility, - whether alternative suggestions are offered. 3.(Minor) The scheduling algorithm needs more technical depth The manuscript briefly references the Flow Shop Scheduling Problem (FSSP), but does not justify the heuristic relative to classical approaches. A clearer section explaining constraints, assumptions, and limitations is required. 4. (Major) Add a conceptual software architecture diagram The paper includes only dashboard screenshots. A diagram of the internal logic and components would enhance clarity. 5. (Minor) Clarify ambiguous parameters Explain granularity, buffer time, and unit consistency with examples. 6.(Minor) Improve consistency in terminology Standardize hands-on, wait time, buffer, etc. 7.(Minor) Discuss limits of heterogeneous protocols The tool assumes identical steps across samples; this should be clearer. Is the rationale for developing the new software tool clearly explained? Yes Is the description of the software tool technically sound? Yes Are sufficient details of the code, methods and analysis (if applicable) provided to allow replication of the software development and its use by others? Yes Is sufficient information provided to allow interpretation of the expected output datasets and any results generated using the tool? Partly Are the conclusions about the tool and its performance adequately supported by the findings presented in the article? Yes Competing Interests: No competing interests were disclosed. Reviewer Expertise: Bioinformatics; Toxicology; Toxicogenomics, Bulk RNA-seq I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard, however I have significant reservations, as outlined above. Close READ LESS CITE CITE HOW TO CITE THIS REPORT Darde T. Reviewer Report For: StaggR: an interactive R/Shiny application for planning and visualizing staggered experimental protocols [version 3; peer review: 2 approved, 1 approved with reservations] . F1000Research 2026, 14 :927 ( https://doi.org/10.5256/f1000research.186237.r428843 ) The direct URL for this report is: https://f1000research.com/articles/14-927/v1#referee-response-428843 NOTE: it is important to ensure the information in square brackets after the title is included in all citations of this article. COPY CITATION DETAILS Report a concern Author Response 27 Dec 2025 Alex Francette , Department of Cell Biology and Physiology, Washington University in St Louis, St. Louis, 63110, USA 27 Dec 2025 Author Response I thank you, reviewer, for your positive comments and insightful suggestions. I have made several changes to the main manuscript to incorporate your feedback. I will address your comments point ... Continue reading I thank you, reviewer, for your positive comments and insightful suggestions. I have made several changes to the main manuscript to incorporate your feedback. I will address your comments point by point. Reviewer 1, Comment 1: (Major) Lack of performance and scalability evaluation Response: I have added a benchmarking section to the manuscript to evaluate the performance and scalability of the scheduling algorithm used in StaggR. This section includes analyses of runtime as the number of samples increases, scalability to larger workflows, and memory/time constraints during optimization. The results are presented in a new figure (Figure 7) and discussed in the main text. Reviewer 1, Comment 2: (Minor) Insufficient description of failure modes Response: I have expanded the manuscript to include more detailed descriptions of how StaggR handles situations where no conflict-free solution exists. The manuscript now explains how users are alerted to such impossibilities through error messages in the application interface. Additionally, I have clarified that while StaggR offers general suggestions for adjusting protocol parameters, it does not currently provide alternative scheduling solutions when a conflict-free schedule cannot be generated. Reviewer 1, Comment 3: (Minor) The scheduling algorithm needs more technical depth Response: I have revised the manuscript to provide a more in-depth explanation of the scheduling algorithm used in StaggR. This includes a discussion of the constraints, assumptions, and limitations of the heuristic approach relative to classical scheduling methods emphasizing the prioritization of ease of use and flexibility for researchers without computational training. Reviewer 1, Comment 4: (Major) Add a conceptual software architecture diagram Response: I have added a new figure (Figure 2) that provides a conceptual software architecture diagram of StaggR. This diagram illustrates the internal logic and components of the application, enhancing clarity for readers. Reviewer 1, Comment 5-6: (Minor) Clarify ambiguous parameters and improve consistency in terminology Response: I have expanded descriptions of "granularity," "buffer time," "hands-on time," and "wait time." Each term is explained with examples to ensure clarity. Units of time have been defaulted to minutes for consistency. Additionally, I have reviewed the manuscript to ensure consistent usage of these terms. Reviewer 1, Comment 7: (Minor) Discuss limits of heterogeneous protocols Response: I have clarified in the manuscript that StaggR currently assumes identical steps across all samples in a protocol. I have discussed the implications of this assumption and noted that future versions of the tool may explore support for heterogeneous protocols. I believe these modifications have greatly strengthened the messaging, clarity, and rigor of this work. I thank you, reviewer, for your positive comments and insightful suggestions. I have made several changes to the main manuscript to incorporate your feedback. I will address your comments point by point. Reviewer 1, Comment 1: (Major) Lack of performance and scalability evaluation Response: I have added a benchmarking section to the manuscript to evaluate the performance and scalability of the scheduling algorithm used in StaggR. This section includes analyses of runtime as the number of samples increases, scalability to larger workflows, and memory/time constraints during optimization. The results are presented in a new figure (Figure 7) and discussed in the main text. Reviewer 1, Comment 2: (Minor) Insufficient description of failure modes Response: I have expanded the manuscript to include more detailed descriptions of how StaggR handles situations where no conflict-free solution exists. The manuscript now explains how users are alerted to such impossibilities through error messages in the application interface. Additionally, I have clarified that while StaggR offers general suggestions for adjusting protocol parameters, it does not currently provide alternative scheduling solutions when a conflict-free schedule cannot be generated. Reviewer 1, Comment 3: (Minor) The scheduling algorithm needs more technical depth Response: I have revised the manuscript to provide a more in-depth explanation of the scheduling algorithm used in StaggR. This includes a discussion of the constraints, assumptions, and limitations of the heuristic approach relative to classical scheduling methods emphasizing the prioritization of ease of use and flexibility for researchers without computational training. Reviewer 1, Comment 4: (Major) Add a conceptual software architecture diagram Response: I have added a new figure (Figure 2) that provides a conceptual software architecture diagram of StaggR. This diagram illustrates the internal logic and components of the application, enhancing clarity for readers. Reviewer 1, Comment 5-6: (Minor) Clarify ambiguous parameters and improve consistency in terminology Response: I have expanded descriptions of "granularity," "buffer time," "hands-on time," and "wait time." Each term is explained with examples to ensure clarity. Units of time have been defaulted to minutes for consistency. Additionally, I have reviewed the manuscript to ensure consistent usage of these terms. Reviewer 1, Comment 7: (Minor) Discuss limits of heterogeneous protocols Response: I have clarified in the manuscript that StaggR currently assumes identical steps across all samples in a protocol. I have discussed the implications of this assumption and noted that future versions of the tool may explore support for heterogeneous protocols. I believe these modifications have greatly strengthened the messaging, clarity, and rigor of this work. Competing Interests: No competing interests were disclosed. Close Report a concern Respond or Comment COMMENTS ON THIS REPORT Author Response 27 Dec 2025 Alex Francette , Department of Cell Biology and Physiology, Washington University in St Louis, St. Louis, 63110, USA 27 Dec 2025 Author Response I thank you, reviewer, for your positive comments and insightful suggestions. I have made several changes to the main manuscript to incorporate your feedback. I will address your comments point ... Continue reading I thank you, reviewer, for your positive comments and insightful suggestions. I have made several changes to the main manuscript to incorporate your feedback. I will address your comments point by point. Reviewer 1, Comment 1: (Major) Lack of performance and scalability evaluation Response: I have added a benchmarking section to the manuscript to evaluate the performance and scalability of the scheduling algorithm used in StaggR. This section includes analyses of runtime as the number of samples increases, scalability to larger workflows, and memory/time constraints during optimization. The results are presented in a new figure (Figure 7) and discussed in the main text. Reviewer 1, Comment 2: (Minor) Insufficient description of failure modes Response: I have expanded the manuscript to include more detailed descriptions of how StaggR handles situations where no conflict-free solution exists. The manuscript now explains how users are alerted to such impossibilities through error messages in the application interface. Additionally, I have clarified that while StaggR offers general suggestions for adjusting protocol parameters, it does not currently provide alternative scheduling solutions when a conflict-free schedule cannot be generated. Reviewer 1, Comment 3: (Minor) The scheduling algorithm needs more technical depth Response: I have revised the manuscript to provide a more in-depth explanation of the scheduling algorithm used in StaggR. This includes a discussion of the constraints, assumptions, and limitations of the heuristic approach relative to classical scheduling methods emphasizing the prioritization of ease of use and flexibility for researchers without computational training. Reviewer 1, Comment 4: (Major) Add a conceptual software architecture diagram Response: I have added a new figure (Figure 2) that provides a conceptual software architecture diagram of StaggR. This diagram illustrates the internal logic and components of the application, enhancing clarity for readers. Reviewer 1, Comment 5-6: (Minor) Clarify ambiguous parameters and improve consistency in terminology Response: I have expanded descriptions of "granularity," "buffer time," "hands-on time," and "wait time." Each term is explained with examples to ensure clarity. Units of time have been defaulted to minutes for consistency. Additionally, I have reviewed the manuscript to ensure consistent usage of these terms. Reviewer 1, Comment 7: (Minor) Discuss limits of heterogeneous protocols Response: I have clarified in the manuscript that StaggR currently assumes identical steps across all samples in a protocol. I have discussed the implications of this assumption and noted that future versions of the tool may explore support for heterogeneous protocols. I believe these modifications have greatly strengthened the messaging, clarity, and rigor of this work. I thank you, reviewer, for your positive comments and insightful suggestions. I have made several changes to the main manuscript to incorporate your feedback. I will address your comments point by point. Reviewer 1, Comment 1: (Major) Lack of performance and scalability evaluation Response: I have added a benchmarking section to the manuscript to evaluate the performance and scalability of the scheduling algorithm used in StaggR. This section includes analyses of runtime as the number of samples increases, scalability to larger workflows, and memory/time constraints during optimization. The results are presented in a new figure (Figure 7) and discussed in the main text. Reviewer 1, Comment 2: (Minor) Insufficient description of failure modes Response: I have expanded the manuscript to include more detailed descriptions of how StaggR handles situations where no conflict-free solution exists. The manuscript now explains how users are alerted to such impossibilities through error messages in the application interface. Additionally, I have clarified that while StaggR offers general suggestions for adjusting protocol parameters, it does not currently provide alternative scheduling solutions when a conflict-free schedule cannot be generated. Reviewer 1, Comment 3: (Minor) The scheduling algorithm needs more technical depth Response: I have revised the manuscript to provide a more in-depth explanation of the scheduling algorithm used in StaggR. This includes a discussion of the constraints, assumptions, and limitations of the heuristic approach relative to classical scheduling methods emphasizing the prioritization of ease of use and flexibility for researchers without computational training. Reviewer 1, Comment 4: (Major) Add a conceptual software architecture diagram Response: I have added a new figure (Figure 2) that provides a conceptual software architecture diagram of StaggR. This diagram illustrates the internal logic and components of the application, enhancing clarity for readers. Reviewer 1, Comment 5-6: (Minor) Clarify ambiguous parameters and improve consistency in terminology Response: I have expanded descriptions of "granularity," "buffer time," "hands-on time," and "wait time." Each term is explained with examples to ensure clarity. Units of time have been defaulted to minutes for consistency. Additionally, I have reviewed the manuscript to ensure consistent usage of these terms. Reviewer 1, Comment 7: (Minor) Discuss limits of heterogeneous protocols Response: I have clarified in the manuscript that StaggR currently assumes identical steps across all samples in a protocol. I have discussed the implications of this assumption and noted that future versions of the tool may explore support for heterogeneous protocols. I believe these modifications have greatly strengthened the messaging, clarity, and rigor of this work. Competing Interests: No competing interests were disclosed. Close Report a concern COMMENT ON THIS REPORT Comments on this article Comments (0) Version 3 VERSION 3 PUBLISHED 15 Sep 2025 ADD YOUR COMMENT Comment keyboard_arrow_left keyboard_arrow_right Open Peer Review Reviewer Status info_outline Alongside their report, reviewers assign a status to the article: Approved The paper is scientifically sound in its current form and only minor, if any, improvements are suggested Approved with reservations A number of small changes, sometimes more significant revisions are required to address specific details and improve the papers academic merit. Not approved Fundamental flaws in the paper seriously undermine the findings and conclusions Reviewer Reports Invited Reviewers 1 2 3 Version 3 (revision) 13 Jan 26 read read Version 2 (revision) 12 Dec 25 read Version 1 15 Sep 25 read Thomas Darde , SciLicium, 10 Rue de La Sauvaie, Rennes, France Charuka D Wickramasinghe , Wayne State University, Detroit, USA; Wayne State University School of Medicine (Ringgold ID: 12267), Detroit, USA Eudald Correig-Fraga , Universitat Rovira i Virgili, Tarragona, Spain; Innovamat Education, Sant Cugat del Vallès, Spain Comments on this article All Comments (0) Add a comment Sign up for content alerts Sign Up You are now signed up to receive this alert Browse by related subjects keyboard_arrow_left Back to all reports Reviewer Report 0 Views copyright © 2026 Correig-Fraga E. This is an open access peer review report distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. 10 Mar 2026 | for Version 3 Eudald Correig-Fraga , Universitat Rovira i Virgili, Tarragona, Spain; Reserach Department, Innovamat Education, Sant Cugat del Vallès, Catalonia, Spain 0 Views copyright © 2026 Correig-Fraga E. This is an open access peer review report distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. format_quote Cite this report speaker_notes Responses (0) Approved info_outline Alongside their report, reviewers assign a status to the article: Approved The paper is scientifically sound in its current form and only minor, if any, improvements are suggested Approved with reservations A number of small changes, sometimes more significant revisions are required to address specific details and improve the papers academic merit. Not approved Fundamental flaws in the paper seriously undermine the findings and conclusions This paper presents a software tool to organize staggered experiments in a simple yet useful way. The motivation is well explained, and the methods are clear. The source code is provided, together with a link to an instance of the program hosted by the author himself. The case examples already loaded on the app are a very nice addition by the author to understand how to start with the tool. A few comments: Manuscript: - I feel like the first and second paragraph were unadvertedly separated? - It's not completely clear to me what's the state of the art to solve this issue. The author says "quickly become intractable to plan manually", and then present solutions for machining operations, but people are planning now; are they using commercial software (if so, which one), or very complex and unmaintainable spreadsheets? this comparison again should be raised in the conclusion - the citations are a bit haphazard: why is dplyr or ggplot cited, but shiny is not? Or Tabu Search, but not Simulated Annealing. - There is a "Core logic" title that I don't know what refers to. - I don't think the performance section is relevant for such a simple tool. In any case, if it's added, I'm more interested in how long does it take for the tool to give me a solution, than the amount of RAM it uses. Code: - Since the author started using tidyverse (dplyr), I would recommend go all the way, and do all the manipulations in tidyverse. - There are benchmark tests, but not logic tests; it would be nice to add them. - The code should be formatted consistently (for example, in RStudio, doing Ctrl+A, then Ctrl + Shift + A). Is the rationale for developing the new software tool clearly explained? Yes Is the description of the software tool technically sound? Yes Are sufficient details of the code, methods and analysis (if applicable) provided to allow replication of the software development and its use by others? Yes Is sufficient information provided to allow interpretation of the expected output datasets and any results generated using the tool? Yes Are the conclusions about the tool and its performance adequately supported by the findings presented in the article? Yes Competing Interests No competing interests were disclosed. Reviewer Expertise Statistics, Programming, Computational neuroscience. I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard. reply Respond to this report Responses (0) Correig-Fraga E. Peer Review Report For: StaggR: an interactive R/Shiny application for planning and visualizing staggered experimental protocols [version 3; peer review: 2 approved, 1 approved with reservations] . F1000Research 2026, 14 :927 ( https://doi.org/10.5256/f1000research.194752.r460176) NOTE: it is important to ensure the information in square brackets after the title is included in this citation. The direct URL for this report is: https://f1000research.com/articles/14-927/v3#referee-response-460176 keyboard_arrow_left Back to all reports Reviewer Report 0 Views copyright © 2026 Wickramasinghe C. This is an open access peer review report distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. 15 Jan 2026 | for Version 3 Charuka D Wickramasinghe , Wayne State University, Detroit, Michigan, USA; Oncology, Wayne State University School of Medicine (Ringgold ID: 12267), Detroit, Michigan, USA 0 Views copyright © 2026 Wickramasinghe C. This is an open access peer review report distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. format_quote Cite this report speaker_notes Responses (0) Approved info_outline Alongside their report, reviewers assign a status to the article: Approved The paper is scientifically sound in its current form and only minor, if any, improvements are suggested Approved with reservations A number of small changes, sometimes more significant revisions are required to address specific details and improve the papers academic merit. Not approved Fundamental flaws in the paper seriously undermine the findings and conclusions No further comments to make. I Approved this. Competing Interests No competing interests were disclosed. Reviewer Expertise Bioinformatics; Pharmacology; Applied Mathematics; Programming; Machine Learning I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard. reply Respond to this report Responses (0) Wickramasinghe CD. Peer Review Report For: StaggR: an interactive R/Shiny application for planning and visualizing staggered experimental protocols [version 3; peer review: 2 approved, 1 approved with reservations] . F1000Research 2026, 14 :927 ( https://doi.org/10.5256/f1000research.194752.r449912) NOTE: it is important to ensure the information in square brackets after the title is included in this citation. The direct URL for this report is: https://f1000research.com/articles/14-927/v3#referee-response-449912 keyboard_arrow_left Back to all reports Reviewer Report 0 Views copyright © 2026 Wickramasinghe C. This is an open access peer review report distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. 02 Jan 2026 | for Version 2 Charuka D Wickramasinghe , Wayne State University, Detroit, Michigan, USA; Oncology, Wayne State University School of Medicine (Ringgold ID: 12267), Detroit, Michigan, USA 0 Views copyright © 2026 Wickramasinghe C. This is an open access peer review report distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. format_quote Cite this report speaker_notes Responses (1) Approved With Reservations info_outline Alongside their report, reviewers assign a status to the article: Approved The paper is scientifically sound in its current form and only minor, if any, improvements are suggested Approved with reservations A number of small changes, sometimes more significant revisions are required to address specific details and improve the papers academic merit. Not approved Fundamental flaws in the paper seriously undermine the findings and conclusions This article presents StaggR , an interactive web application that calculates and visualizes compatible staggering intervals for parallelized execution of identical processing workflows. StaggR provides a user-friendly interface for defining protocol operations, durations, and wait times. Overall, the article has a strong potential for indexing after the following corrections. A few bugs were identified in the R Shiny code. (Major) The R Shiny application is disconnected from the server when the number of samples or sample names is changed. (Major) Under the “About” tab, the R Shiny application is disconnected from the server when the example protocols are clicked. (Minor) The first three question mark (“?”) icons in the left panel of the user interface do not display any information. Adding appropriate descriptions for these three icons is recommended. (Minor – optional) Adding a downloadable sample input file next to the file upload tab is recommended to help users better understand how the application works. (Minor – optional) Adding a short video demonstration illustrating the functionality of the application is recommended. Is the rationale for developing the new software tool clearly explained? Yes Is the description of the software tool technically sound? Yes Are sufficient details of the code, methods and analysis (if applicable) provided to allow replication of the software development and its use by others? Yes Is sufficient information provided to allow interpretation of the expected output datasets and any results generated using the tool? Yes Are the conclusions about the tool and its performance adequately supported by the findings presented in the article? Yes References 1. Wickramasinghe C, Kim S, Li J: SpatialCNS ‐PBPK : An R/Shiny Web‐Based Application for Physiologically Based Pharmacokinetic Modeling of Spatial Pharmacokinetics in the Human Central Nervous System and Brain Tumors. CPT: Pharmacometrics & Systems Pharmacology . 2025; 14 (5): 864-880 Publisher Full Text Competing Interests No competing interests were disclosed. Reviewer Expertise Bioinformatics; Pharmacology; Applied Mathematics; Programming; Machine Learning I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard, however I have significant reservations, as outlined above. reply Respond to this report Responses (1) Author Response 13 Jan 2026 Alex Francette, Department of Cell Biology and Physiology, Washington University in St Louis, St. Louis, 63110, USA I thank you for identifying several areas for improvement for the app. I have addressed your comments as follows: Reviewer 2, Comments 1,2,3: Fixed bugs introduced by transferring core scheduling logic outside of the Shiny server function. The app no longer disconnects when changing sample names/count or clicking example protocols, and the first three "?" icons now display appropriate information. Reviewer 2, Comment 4: Added a "Download Sample Session (.json)" button next to the file upload tab to make the app more user-friendly. Reviewer 2, Comment 5: I believe a video demonstration is a good idea, and I will strongly consider creating one to include in future updates of the app. View more View less Competing Interests No competing interests were disclosed. reply Respond Report a concern Wickramasinghe CD. Peer Review Report For: StaggR: an interactive R/Shiny application for planning and visualizing staggered experimental protocols [version 3; peer review: 2 approved, 1 approved with reservations] . F1000Research 2026, 14 :927 ( https://doi.org/10.5256/f1000research.193274.r442762) NOTE: it is important to ensure the information in square brackets after the title is included in this citation. The direct URL for this report is: https://f1000research.com/articles/14-927/v2#referee-response-442762 keyboard_arrow_left Back to all reports Reviewer Report 0 Views copyright © 2025 Darde T. This is an open access peer review report distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. 25 Nov 2025 | for Version 1 Thomas Darde , SciLicium, 10 Rue de La Sauvaie, Rennes, France 0 Views copyright © 2025 Darde T. This is an open access peer review report distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. format_quote Cite this report speaker_notes Responses (1) Approved With Reservations info_outline Alongside their report, reviewers assign a status to the article: Approved The paper is scientifically sound in its current form and only minor, if any, improvements are suggested Approved with reservations A number of small changes, sometimes more significant revisions are required to address specific details and improve the papers academic merit. Not approved Fundamental flaws in the paper seriously undermine the findings and conclusions This manuscript presents StaggR, an interactive and open-source R/Shiny application designed to assist researchers in planning, visualizing, and executing staggered experimental workflows, particularly for time-sensitive molecular biology assays. The complexity of coordinating multiple samples with identical but offset treatment sequences is a well-known bottleneck in wet-lab research. StaggR provides a practical solution that integrates workflow definition, conflict detection, Gantt chart visualization, and a live execution timer. The tool is accessible, fully open-source, and addresses a reproducibility challenge often overlooked in workflow design. The manuscript is clearly written and the tool appears directly usable. Overall, the article has strong potential for indexed once several key revisions are addressed. 1. (Major) Lack of performance and scalability evaluation The scheduling algorithm is described as a simple heuristic. However, the manuscript provides no benchmarks evaluating: - runtime as sample number increases, - scalability to large workflows, - memory/time constraints during optimization. A small benchmarking section or supplementary figure would greatly strengthen the work. 2. (Minor)Insufficient description of failure modes The manuscript does not clearly explain: - how StaggR behaves when no conflict-free solution exists, - how users are alerted to impossibility, - whether alternative suggestions are offered. 3.(Minor) The scheduling algorithm needs more technical depth The manuscript briefly references the Flow Shop Scheduling Problem (FSSP), but does not justify the heuristic relative to classical approaches. A clearer section explaining constraints, assumptions, and limitations is required. 4. (Major) Add a conceptual software architecture diagram The paper includes only dashboard screenshots. A diagram of the internal logic and components would enhance clarity. 5. (Minor) Clarify ambiguous parameters Explain granularity, buffer time, and unit consistency with examples. 6.(Minor) Improve consistency in terminology Standardize hands-on, wait time, buffer, etc. 7.(Minor) Discuss limits of heterogeneous protocols The tool assumes identical steps across samples; this should be clearer. Is the rationale for developing the new software tool clearly explained? Yes Is the description of the software tool technically sound? Yes Are sufficient details of the code, methods and analysis (if applicable) provided to allow replication of the software development and its use by others? Yes Is sufficient information provided to allow interpretation of the expected output datasets and any results generated using the tool? Partly Are the conclusions about the tool and its performance adequately supported by the findings presented in the article? Yes Competing Interests No competing interests were disclosed. Reviewer Expertise Bioinformatics; Toxicology; Toxicogenomics, Bulk RNA-seq I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard, however I have significant reservations, as outlined above. reply Respond to this report Responses (1) Author Response 27 Dec 2025 Alex Francette, Department of Cell Biology and Physiology, Washington University in St Louis, St. Louis, 63110, USA I thank you, reviewer, for your positive comments and insightful suggestions. I have made several changes to the main manuscript to incorporate your feedback. I will address your comments point by point. Reviewer 1, Comment 1: (Major) Lack of performance and scalability evaluation Response: I have added a benchmarking section to the manuscript to evaluate the performance and scalability of the scheduling algorithm used in StaggR. This section includes analyses of runtime as the number of samples increases, scalability to larger workflows, and memory/time constraints during optimization. The results are presented in a new figure (Figure 7) and discussed in the main text. Reviewer 1, Comment 2: (Minor) Insufficient description of failure modes Response: I have expanded the manuscript to include more detailed descriptions of how StaggR handles situations where no conflict-free solution exists. The manuscript now explains how users are alerted to such impossibilities through error messages in the application interface. Additionally, I have clarified that while StaggR offers general suggestions for adjusting protocol parameters, it does not currently provide alternative scheduling solutions when a conflict-free schedule cannot be generated. Reviewer 1, Comment 3: (Minor) The scheduling algorithm needs more technical depth Response: I have revised the manuscript to provide a more in-depth explanation of the scheduling algorithm used in StaggR. This includes a discussion of the constraints, assumptions, and limitations of the heuristic approach relative to classical scheduling methods emphasizing the prioritization of ease of use and flexibility for researchers without computational training. Reviewer 1, Comment 4: (Major) Add a conceptual software architecture diagram Response: I have added a new figure (Figure 2) that provides a conceptual software architecture diagram of StaggR. This diagram illustrates the internal logic and components of the application, enhancing clarity for readers. Reviewer 1, Comment 5-6: (Minor) Clarify ambiguous parameters and improve consistency in terminology Response: I have expanded descriptions of "granularity," "buffer time," "hands-on time," and "wait time." Each term is explained with examples to ensure clarity. Units of time have been defaulted to minutes for consistency. Additionally, I have reviewed the manuscript to ensure consistent usage of these terms. Reviewer 1, Comment 7: (Minor) Discuss limits of heterogeneous protocols Response: I have clarified in the manuscript that StaggR currently assumes identical steps across all samples in a protocol. I have discussed the implications of this assumption and noted that future versions of the tool may explore support for heterogeneous protocols. I believe these modifications have greatly strengthened the messaging, clarity, and rigor of this work. View more View less Competing Interests No competing interests were disclosed. reply Respond Report a concern Darde T. Peer Review Report For: StaggR: an interactive R/Shiny application for planning and visualizing staggered experimental protocols [version 3; peer review: 2 approved, 1 approved with reservations] . F1000Research 2026, 14 :927 ( https://doi.org/10.5256/f1000research.186237.r428843) NOTE: it is important to ensure the information in square brackets after the title is included in this citation. The direct URL for this report is: https://f1000research.com/articles/14-927/v1#referee-response-428843 Alongside their report, reviewers assign a status to the article: Approved - the paper is scientifically sound in its current form and only minor, if any, improvements are suggested Approved with reservations - A number of small changes, sometimes more significant revisions are required to address specific details and improve the papers academic merit. Not approved - fundamental flaws in the paper seriously undermine the findings and conclusions Adjust parameters to alter display View on desktop for interactive features Includes Interactive Elements View on desktop for interactive features Competing Interests Policy Provide sufficient details of any financial or non-financial competing interests to enable users to assess whether your comments might lead a reasonable person to question your impartiality. Consider the following examples, but note that this is not an exhaustive list: Examples of 'Non-Financial Competing Interests' Within the past 4 years, you have held joint grants, published or collaborated with any of the authors of the selected paper. You have a close personal relationship (e.g. parent, spouse, sibling, or domestic partner) with any of the authors. You are a close professional associate of any of the authors (e.g. scientific mentor, recent student). You work at the same institute as any of the authors. You hope/expect to benefit (e.g. favour or employment) as a result of your submission. You are an Editor for the journal in which the article is published. Examples of 'Financial Competing Interests' You expect to receive, or in the past 4 years have received, any of the following from any commercial organisation that may gain financially from your submission: a salary, fees, funding, reimbursements. You expect to receive, or in the past 4 years have received, shared grant support or other funding with any of the authors. You hold, or are currently applying for, any patents or significant stocks/shares relating to the subject matter of the paper you are commenting on. Stay Updated Sign up for content alerts and receive a weekly or monthly email with all newly published articles Register with F1000Research Already registered? Sign in Not now, thanks close PLEASE NOTE If you are an AUTHOR of this article, please check that you signed in with the account associated with this article otherwise we cannot automatically identify your role as an author and your comment will be labelled as a “User Comment”. If you are a REVIEWER of this article, please check that you have signed in with the account associated with this article and then go to your account to submit your report, please do not post your review here. If you do not have access to your original account, please contact us . All commenters must hold a formal affiliation as per our Policies . The information that you give us will be displayed next to your comment. User comments must be in English, comprehensible and relevant to the article under discussion. We reserve the right to remove any comments that we consider to be inappropriate, offensive or otherwise in breach of the User Comment Terms and Conditions . Commenters must not use a comment for personal attacks. When criticisms of the article are based on unpublished data, the data should be made available. I accept the User Comment Terms and Conditions Please confirm that you accept the User Comment Terms and Conditions. Affiliation ✕ refresh Please enter your institution. Note: To add your institution or organisation, start typing the name and then select the correct name from the list. Where applicable, the name will appear in both the original language and in English. Do not paste in the name. If the name does not appear in the drop-down list, we will display the information you have entered. ✕ refresh Country/Region * USA UK Canada China France Germany Afghanistan Aland Islands Albania Algeria American Samoa Andorra Angola Anguilla Antarctica Antigua and Barbuda Argentina Armenia Aruba Australia Austria Azerbaijan Bahamas Bahrain Bangladesh Barbados Belarus Belgium Belize Benin Bermuda Bhutan Bolivia Bosnia and Herzegovina Botswana Bouvet Island Brazil British Indian Ocean Territory British Virgin Islands Brunei Bulgaria Burkina Faso Burundi Cambodia Cameroon Canada Cape Verde Cayman Islands Central African Republic Chad Chile China Christmas Island Cocos (Keeling) Islands Colombia Comoros Congo Cook Islands Costa Rica Cote d'Ivoire Croatia Cuba Cyprus Czech Republic Democratic Republic of the Congo Denmark Djibouti Dominica Dominican Republic Ecuador Egypt El Salvador Equatorial Guinea Eritrea Estonia Ethiopia Falkland Islands Faroe Islands Federated States of Micronesia Fiji Finland France French Guiana French Polynesia French Southern Territories Gabon Georgia Germany Ghana Gibraltar Greece Greenland Grenada Guadeloupe Guam Guatemala Guernsey Guinea Guinea-Bissau Guyana Haiti Heard Island and Mcdonald Islands Holy See (Vatican City State) Honduras Hong Kong Hungary Iceland India Indonesia Iran Iraq Ireland Israel Italy Jamaica Japan Jersey Jordan Kazakhstan Kenya Kiribati Kosovo (Serbia and Montenegro) Kuwait Kyrgyzstan Lao People's Democratic Republic Latvia Lebanon Lesotho Liberia Libya Liechtenstein Lithuania Luxembourg Macao Madagascar Malawi Malaysia Maldives Mali Malta Marshall Islands Martinique Mauritania Mauritius Mayotte Mexico Minor Outlying Islands of the United States Moldova Monaco Mongolia Montenegro Montserrat Morocco Mozambique Myanmar Namibia Nauru Nepal Netherlands Antilles New Caledonia New Zealand Nicaragua Niger Nigeria Niue Norfolk Island North Korea North Macedonia Northern Mariana Islands Norway Oman Pakistan Palau Palestinian Territory Panama Papua New Guinea Paraguay Peru Philippines Pitcairn Poland Portugal Puerto Rico Qatar Reunion Romania Russian Federation Rwanda Saint Helena Saint Kitts and Nevis Saint Lucia Saint Pierre and Miquelon Saint Vincent and the Grenadines Samoa San Marino Sao Tome and Principe Saudi Arabia Senegal Serbia Seychelles Sierra Leone Singapore Slovakia Slovenia Solomon Islands Somalia South Africa South Georgia and the South Sandwich Is South Korea South Sudan Spain Sri Lanka Sudan Suriname Svalbard and Jan Mayen Swaziland Sweden Switzerland Syria Taiwan Tajikistan Tanzania Thailand The Gambia The Netherlands Timor-Leste Togo Tokelau Tonga Trinidad and Tobago Tunisia Turkey Turkmenistan Turks and Caicos Islands Tuvalu UK USA Uganda Ukraine United Arab Emirates United States Virgin Islands Uruguay Uzbekistan Vanuatu Venezuela Vietnam Wallis and Futuna West Bank and Gaza Strip Western Sahara Yemen Zambia Zimbabwe Please select your country/region. You must enter a comment. Competing Interests Please disclose any competing interests that might be construed to influence your judgment of the article's or peer review report's validity or importance. Competing Interests Policy Provide sufficient details of any financial or non-financial competing interests to enable users to assess whether your comments might lead a reasonable person to question your impartiality. Consider the following examples, but note that this is not an exhaustive list: Examples of 'Non-Financial Competing Interests' Within the past 4 years, you have held joint grants, published or collaborated with any of the authors of the selected paper. You have a close personal relationship (e.g. parent, spouse, sibling, or domestic partner) with any of the authors. You are a close professional associate of any of the authors (e.g. scientific mentor, recent student). You work at the same institute as any of the authors. You hope/expect to benefit (e.g. favour or employment) as a result of your submission. You are an Editor for the journal in which the article is published. Examples of 'Financial Competing Interests' You expect to receive, or in the past 4 years have received, any of the following from any commercial organisation that may gain financially from your submission: a salary, fees, funding, reimbursements. You expect to receive, or in the past 4 years have received, shared grant support or other funding with any of the authors. You hold, or are currently applying for, any patents or significant stocks/shares relating to the subject matter of the paper you are commenting on. Please state your competing interests The comment has been saved. An error has occurred. Please try again. Cancel Post var lTitle = "StaggR: an interactive R\/Shiny application...".replace("'", ''); var linkedInUrl = "http://www.linkedin.com/shareArticle?url=https://f1000research.com/articles/14-927/v3" + "&title=" + encodeURIComponent(lTitle) + "&summary=" + encodeURIComponent('Read the article by '); var deliciousUrl = "https://del.icio.us/post?url=https://f1000research.com/articles/14-927/v3&title=" + encodeURIComponent(lTitle); var redditUrl = "http://reddit.com/submit?url=https://f1000research.com/articles/14-927/v3" + "&title=" + encodeURIComponent(lTitle); linkedInUrl += encodeURIComponent('Michael Francette A'); var offsetTop = /chrome/i.test( navigator.userAgent ) ? 4 : -10; var addthis_config = { ui_offset_top: offsetTop, services_compact : "facebook,twitter,www.linkedin.com,www.mendeley.com,reddit.com", services_expanded : "facebook,twitter,www.linkedin.com,www.mendeley.com,reddit.com", services_custom : [ { name: "LinkedIn", url: linkedInUrl, icon:"/img/icon/at_linkedin.svg" }, { name: "Mendeley", url: "http://www.mendeley.com/import/?url=https://f1000research.com/articles/14-927/v3/mendeley", icon:"/img/icon/at_mendeley.svg" }, { name: "Reddit", url: redditUrl, icon:"/img/icon/at_reddit.svg" }, ] }; var addthis_share = { url: "https://f1000research.com/articles/14-927", templates : { twitter : "StaggR: an interactive R\/Shiny application for planning and.... Michael Francette A, published by " + "@F1000Research" + ", https://f1000research.com/articles/14-927/v3" } }; if (typeof(addthis) != "undefined"){ addthis.addEventListener('addthis.ready', checkCount); addthis.addEventListener('addthis.menu.share', checkCount); } $(".f1r-shares-twitter").attr("href", "https://twitter.com/intent/tweet?text=" + addthis_share.templates.twitter); $(".f1r-shares-facebook").attr("href", "https://www.facebook.com/sharer/sharer.php?u=" + addthis_share.url); $(".f1r-shares-linkedin").attr("href", addthis_config.services_custom[0].url); $(".f1r-shares-reddit").attr("href", addthis_config.services_custom[2].url); $(".f1r-shares-mendelay").attr("href", addthis_config.services_custom[1].url); function checkCount(){ setTimeout(function(){ $(".addthis_button_expanded").each(function(){ var count = $(this).text(); if (count !== "" && count != "0") $(this).removeClass("is-hidden"); else $(this).addClass("is-hidden"); }); }, 1000); } close How to cite this report {{reportCitation}} Cancel Copy Citation Details $(function(){R.ui.buttonDropdowns('.dropdown-for-downloads');}); $(function(){R.ui.toolbarDropdowns('.toolbar-dropdown-for-downloads');}); $.get("/articles/acj/168987/194752") new F1000.Clipboard(); new F1000.ThesaurusTermsDisplay("articles", "article", "194752"); $(document).ready(function() { $( "#frame1" ).on('load', function() { var mydiv = $(this).contents().find("div"); var h = mydiv.height(); console.log(h) }); var tooltipLivingFigure = jQuery(".interactive-living-figure-label .icon-more-info"), titleLivingFigure = tooltipLivingFigure.attr("title"); tooltipLivingFigure.simpletip({ fixed: true, position: ["-115", "30"], baseClass: 'small-tooltip', content:titleLivingFigure + " " }); tooltipLivingFigure.removeAttr("title"); $("body").on("click", ".cite-living-figure", function(e) { e.preventDefault(); var ref = $(this).attr("data-ref"); $(this).closest(".living-figure-list-container").find("#" + ref).fadeIn(200); }); $("body").on("click", ".close-cite-living-figure", function(e) { e.preventDefault(); $(this).closest(".popup-window-wrapper").fadeOut(200); }); $(document).on("mouseup", function(e) { var metricsContainer = $(".article-metrics-popover-wrapper"); if (!metricsContainer.is(e.target) && metricsContainer.has(e.target).length === 0) { $(".article-metrics-close-button").click(); } }); var articleId = $('#articleId').val(); if($("#main-article-count-box").attachArticleMetrics) { $("#main-article-count-box").attachArticleMetrics(articleId, { articleMetricsView: true }); } }); var figshareWidget = $(".new_figshare_widget"); if (figshareWidget.length > 0) { window.figshare.load("f1000", function(Widget) { // Select a tag/tags defined in your page. In this tag we will place the widget. _.map(figshareWidget, function(el){ var widget = new Widget({ articleId: $(el).attr("figshare_articleId") //height:300 // this is the height of the viewer part. [Default: 550] }); widget.initialize(); // initialize the widget widget.mount(el); // mount it in a tag that's on your page // this will save the widget on the global scope for later use from // your JS scripts. This line is optional. //window.widget = widget; }); }); } close Error Close Add Reset F1000.MICROSERVICES.AFFILIATION = ''; $(document).ready(function () { $('.js-affiliations-form').each((index, form) => { new AffiliationForm({ formId: form.id, institutionErrorSelector: '.comment-enter-institution', departmentErrorSelector: '.comment-enter-department', placeSelector: '.js-add-comment-place', stateSelector: '.js-add-comment-state', zipCodeSelector: '.js-add-comment-zipcode', countrySelector: '.js-add-comment-country', countryErrorSelector: '.comment-enter-country', }); }); }); $(document).ready(function () { var reportIds = { "445222": 0, "445223": 0, "445220": 0, "445221": 0, "428846": 0, "428847": 0, "445228": 0, "428844": 0, "445229": 0, "428845": 0, "445226": 0, "445227": 0, "428843": 22, "445224": 0, "445225": 0, "428852": 0, "428850": 0, "428851": 0, "428848": 0, "428849": 0, "454974": 0, "454975": 0, "454973": 0, "454980": 0, "454981": 0, "454978": 0, "454979": 0, "454976": 0, "454977": 0, "415822": 0, "415823": 0, "415820": 0, "415821": 0, "415828": 0, "415829": 0, "415826": 0, "415827": 0, "415824": 0, "415825": 0, "460140": 0, "460139": 0, "460138": 0, "449911": 0, "449912": 3, "419462": 0, "442759": 0, "419463": 0, "427394": 0, "453505": 0, "442766": 0, "460175": 0, "419470": 0, "442767": 0, "460174": 0, "419471": 0, "460173": 0, "442764": 0, "419468": 0, "442765": 0, "460172": 0, "419469": 0, "442762": 7, "460171": 0, "419466": 0, "442763": 0, "419467": 0, "442760": 0, "419464": 0, "442761": 0, "419465": 0, "422806": 0, "425366": 0, "422807": 0, "425367": 0, "422804": 0, "425364": 0, "422805": 0, "425365": 0, "422802": 0, "425362": 0, "422803": 0, "425363": 0, "442768": 0, "460177": 0, "460176": 3, "425361": 0, "440991": 0, "422810": 0, "425370": 0, "422811": 0, "422808": 0, "425368": 0, "422809": 0, "425369": 0, "451799": 0, "451806": 0, "451807": 0, "451804": 0, "451805": 0, "451802": 0, "451803": 0, "451800": 0, "451801": 0, "451808": 0, "457454": 0, "457455": 0, "457452": 0, "457453": 0, "457450": 0, "457451": 0, "457449": 0, "457458": 0, "457456": 0, "457457": 0, }; $(".referee-response-container,.js-referee-report").each(function(index, el) { var reportId = $(el).attr("data-reportid"), reportCount = reportIds[reportId] || 0; $(el).find(".comments-count-container,.js-referee-report-views").html(reportCount); }); var uuidInput = $("#article_uuid"), oldUUId = uuidInput.val(), newUUId = "60a735a0-4ba2-4b84-95f0-404021441524"; uuidInput.val(newUUId); $("a[href*='article_uuid=']").each(function(index, el) { var newHref = $(el).attr("href").replace(oldUUId, newUUId); $(el).attr("href", newHref); }); }); An innovative open access publishing platform offering rapid publication and open peer review, whilst supporting data deposition and sharing. Browse Gateways Collections How it Works Contact For Developers Cookie Notice Privacy Notice RSS Submit Your Research Follow us © 2012-2026 F1000 Research Ltd. ISSN 2046-1402 | Legal | Partner of Research4Life • CrossRef • ORCID • FAIRSharing R.templateTests.simpleTemplate = R.template(' $text $text $text $text $text '); R.templateTests.runTests(); var F1000platform = new F1000.Platform({ name: "f1000research", displayName: "F1000Research", hostName: "f1000research.com", id: "1", editorialEmail: "[email protected]", infoEmail: "[email protected]", usePmcStats: true }); $(function(){R.ui.dropdowns('.dropdown-for-authors, .dropdown-for-about, .dropdown-for-myresearch');}); // $(function(){R.ui.dropdowns('.dropdown-for-referees');}); $(document).ready(function () { if ($(".cookie-warning").is(":visible")) { $(".sticky").css("margin-bottom", "35px"); $(".devices").addClass("devices-and-cookie-warning"); } $(".cookie-warning .close-button").click(function (e) { $(".devices").removeClass("devices-and-cookie-warning"); $(".sticky").css("margin-bottom", "0"); }); $("#tweeter-feed .tweet-message").each(function (i, message) { var self = $(message); self.html(linkify(self.html())); }); $(".partner").on("mouseenter mouseleave", function() { $(this).find(".gray-scale, .colour").toggleClass("is-hidden"); }); }); Sign In Remember me Forgotten your password? Sign In Cancel Email or password not correct. Please try again Please wait... $(function(){ // Note: All the setup needs to run against a name attribute and *not* the id due the clonish // nature of facebox... $("a[id=googleSignInButton]").click(function(event){ event.preventDefault(); $("input[id=oAuthSystem]").val("GOOGLE"); $("form[id=oAuthForm]").submit(); }); $("a[id=facebookSignInButton]").click(function(event){ event.preventDefault(); $("input[id=oAuthSystem]").val("FACEBOOK"); $("form[id=oAuthForm]").submit(); }); $("a[id=orcidSignInButton]").click(function(event){ event.preventDefault(); $("input[id=oAuthSystem]").val("ORCID"); $("form[id=oAuthForm]").submit(); }); }); If you've forgotten your password, please enter your email address below and we'll send you instructions on how to reset your password. The email address should be the one you originally registered with F1000. Email address not valid, please try again You registered with F1000 via Google, so we cannot reset your password. To sign in, please click here . If you still need help with your Google account password, please click here . You registered with F1000 via Facebook, so we cannot reset your password. To sign in, please click here . If you still need help with your Facebook account password, please click here . Code not correct, please try again Reset password Cancel Email us for further assistance. Server error, please try again. If your email address is registered with us, we will email you instructions to reset your password. If you think you should have received this email but it has not arrived, please check your spam filters and/or contact for further assistance. Please wait... Register $(document).ready(function () { signIn.createSignInAsRow($("#sign-in-form-gfb-popup")); $(".target-field").each(function () { var uris = $(this).val().split("/"); if (uris.pop() === "login") { $(this).val(uris.toString().replace(",","/")); } }); });