I stopped our tray-transfer test after a spacer had left the source but before the destination update was saved. Restart offered the old pocket again. Worse, the file only has one tray index, so I can't even tell which tray the recovery prompt means.
I'd like to get the state model straight on paper before we add more buttons. What should identify the attempted move, and what should the operator be allowed to say when the physical outcome isn't clear?
Does the saved information identify both physical trays, or only a pocket within whichever tray the program currently calls active? That needs settling before the recovery choices can refer to a meaningful location.
Only the index. Source and destination trays have labels but those aren't stored with the attempt. The draft screen calls the destination next tray, which isn't helping either.
Associate the attempted transfer with source tray and pocket, destination tray and pocket, and a durable attempt reference; the saved next index alone cannot describe a transfer interrupted between those locations.
I would welcome actual tray names on that screen. I helped with a test where left meant the designer's left, and I stood on the other side. We were both completely certain about the wrong pocket
Names help, Simon, but the recovery also needs to distinguish what is known from what somebody must inspect. A clearly named destination can still contain a spacer whose placement was never recorded.
Nora, not all pockets are visible from there. Farah, yes, I had written confirm placed as though anyone could just glance over. The tray names will be explicit, but that doesn't solve the uncertain placement.
Who defines how the operator establishes the physical outcome when it cannot be seen from there? That belongs with the integrator and shift lead, not a software prompt improvising access.
Our training cell had 'transfer paused' for both an empty source and an uncertain placement. The operator called for help because the screen hid the difference. I would show those as separate cases before testing whether people understand either one.
Would recording the existing tray labels be enough for this first model? I wouldn't buy a reader before the team agrees what a tray identity actually controls.
AaronBaker, yes, the identification method can be assessed once the required states are clear. Alex should not let a stored label act as confirmation that the same physical tray is still fitted after an interruption.
David, the current draft can't distinguish them. I've split the paper cases now and sent the hidden-pocket question to the integrator and shift lead. AaronBaker, we're using the existing labels in the offline examples, no reader order.
For the known-empty source case, include how that knowledge was obtained too. I would not want absence in an old file promoted to a fresh observation merely because it has a more helpful label.
Retain the unresolved state across a second restart, including an interruption during recovery; otherwise the corrected first startup may still lead back to the ordinary transfer queue later.
The offline model failed exactly that second restart: recovery pending went back into normal pending. Author has separated those states. The physical review decision stays required, with both tray identities retained.
Yes, both replays pass now: second restart retains unresolved, and missing destination identity prevents an ordinary continuation. The physical recovery procedure and operator wording aren't finished. Thanks, Georgia, your empty-source example exposed the screen problem early.