Navigating between embryos requires going back to the bottom camera. Add an explicit go-to control so the SPIM head view can jump to a chosen embryo.
The users want this conservative. Ryan, 19:04: "it would make a lot of sense if you clicked on one here, it would go to — like a go-to button or something." Then explicitly against auto-move: "for right now I think it would maybe be okay to be a little conservative and have like a go-to button. I think as people get more familiar with it, then we might be able to just let people know you just click on it and we'll go to it… it might be better to be a little conservative and make sure you actually want to go to it, and not just misclick on it."
Verified state
The embryo rail beside the SPIM pane (index.html:553) renders rows with a label, an XY span and a × delete button (operate.js:831-857) — no move control. Its click handler does selectEmbryo and nothing else (operate.js:1213-1226).
The move-to-embryo affordance exists, but only in the Acquisition roster: renderRoster emits a [data-center] button handled at operate.js:1258-1271, routing into centerOnEmbryo → moveStageTo. renderEmbryoRail and renderRoster are two separate row builders with two separate delegated handlers, and the rail — the list actually visible next to the SPIM camera — was built select-only.
Note the only move affordance on the bottom camera today is auto-move on canvas click (operate.js:570-576), which is the behaviour Ryan asked not to have. It is also the source of #105.
Smallest fix: append the same [data-center] button the roster already uses to renderEmbryoRail (~operate.js:855), and hoist the roster's [data-center] branch (:1264-1269) into one delegated handler both lists share, so rail and roster route through the same three lines into centerOnEmbryo — which already selects and passes through the single XY interlock in moveStageTo. Nothing server-side.
Blocked in practice by the XY lock (#112): with the head lowered, moveStageTo refuses every move, so a Go to button would be inert exactly when it is wanted.
Separate defect on the same interaction
Filed separately: selecting a different embryo changes only the caption while the image stays put, so the view shows the previous embryo while claiming another is selected. Ryan and Magdalena both flagged that as the more confusing half. It should be fixed whether or not Go to lands.
Evidence: 2026-08-07 walkthrough, 18:41–20:11.
Navigating between embryos requires going back to the bottom camera. Add an explicit go-to control so the SPIM head view can jump to a chosen embryo.
The users want this conservative. Ryan, 19:04: "it would make a lot of sense if you clicked on one here, it would go to — like a go-to button or something." Then explicitly against auto-move: "for right now I think it would maybe be okay to be a little conservative and have like a go-to button. I think as people get more familiar with it, then we might be able to just let people know you just click on it and we'll go to it… it might be better to be a little conservative and make sure you actually want to go to it, and not just misclick on it."
Verified state
The embryo rail beside the SPIM pane (
index.html:553) renders rows with a label, an XY span and a×delete button (operate.js:831-857) — no move control. Its click handler doesselectEmbryoand nothing else (operate.js:1213-1226).The move-to-embryo affordance exists, but only in the Acquisition roster:
renderRosteremits a[data-center]button handled atoperate.js:1258-1271, routing intocenterOnEmbryo→moveStageTo.renderEmbryoRailandrenderRosterare two separate row builders with two separate delegated handlers, and the rail — the list actually visible next to the SPIM camera — was built select-only.Note the only move affordance on the bottom camera today is auto-move on canvas click (
operate.js:570-576), which is the behaviour Ryan asked not to have. It is also the source of #105.Smallest fix: append the same
[data-center]button the roster already uses torenderEmbryoRail(~operate.js:855), and hoist the roster's[data-center]branch (:1264-1269) into one delegated handler both lists share, so rail and roster route through the same three lines intocenterOnEmbryo— which already selects and passes through the single XY interlock inmoveStageTo. Nothing server-side.Blocked in practice by the XY lock (#112): with the head lowered,
moveStageTorefuses every move, so a Go to button would be inert exactly when it is wanted.Separate defect on the same interaction
Filed separately: selecting a different embryo changes only the caption while the image stays put, so the view shows the previous embryo while claiming another is selected. Ryan and Magdalena both flagged that as the more confusing half. It should be fixed whether or not Go to lands.
Evidence: 2026-08-07 walkthrough, 18:41–20:11.