Warping the Workspace (arXiv:2610.28712, submitted 20 October 2026) comes from Keigo Minamida, Koya Dendo, Yuto Nakamura and Jun Rekimoto. Its journal reference is ACM UIST 2026 — which, as it happens, opens in Detroit on 2 November, eleven days from now.
It is a short, honest paper about a specific problem in embodied remote control, and its most interesting feature is that it declines to declare a winner.
The problem
In first-person humanoid teleoperation, you see what the robot sees. Which means:
First-person humanoid teleoperation ties access to side and rear targets to operator rotation.
If the thing you need is behind the robot, you turn the robot — or turn yourself and have the robot follow. Either way, reaching a target off-axis costs a rotation, and rotations cost time, neck strain, and tracking drift. For anyone who has operated a telepresence rig or built a VR interface around a fixed forward view, this is the familiar tax.
The approach
The authors present coupled visual–motor remapping: a panoramic azimuth warp of the view, paired with its inverse upper-limb yaw transform.
The coupling is the idea. Warping the image alone would let you see to the side while leaving your arm pointing at the wrong place in the world — the view and the motor mapping would disagree, which is a reliable recipe for nausea and mis-reaches. Applying the inverse transform to the arm’s yaw means that when you reach toward where something appears, the robot’s arm goes to where it is. The visual compression and the motor expansion cancel.
A working prototype implements two mappings:
- Global Zoom (GZ) — compress the whole azimuth uniformly, so everything is visible and everything is squashed
- Focus+Context (F+C) — keep the centre at normal scale and compress the periphery, the classic fisheye distribution of detail
The result, and the split
A within-subject study with N = 8 and 72 trials:
| Mapping | Trials completed | Preferred by |
|---|---|---|
| Global Zoom | 23 / 24 | 1 / 8 |
| Focus+Context | 21 / 24 | 6 / 8 |
| Fixed (baseline) | 20 / 24 | — |
The authors’ conclusion is stated without spin:
Therefore, completion and preference favored different mappings in this sample.
Global Zoom got the job done most often. Focus+Context is what people wanted to use. That dissociation between performance and preference is one of the most durable findings in interface research and one of the most frequently buried, because a clean story needs a winner. Reporting it is the right call, and it is the practical takeaway: if you are building a teleoperation interface, you cannot pick the mapping from a task-completion number alone, and you cannot pick it from a preference survey alone.
Why F+C might win on preference while losing on completion is not hard to guess — it preserves an undistorted centre, so the operator’s foveal experience stays normal and only the periphery feels strange, which is more comfortable even if the uniform squash of GZ gives better off-axis reach. The paper does not need to resolve that to make its point.
The honest caveats
N = 8 and 24 trials per condition. A one-trial difference between GZ (23) and F+C (21) is not a result anyone should build a product on, and the authors do not claim it is — note the careful “in this sample.” The value here is the mechanism (coupled visual–motor remapping with an inverse yaw transform) and the demonstration that two reasonable instantiations of it diverge on which metric you optimise. A powered comparison is future work.
The paper is classified under Robotics (cs.RO) with Human-Computer Interaction (cs.HC) as secondary, ACM classes H.5.2 and I.2.9.
One note on citing it
The arXiv record lists a related DOI, 10.1145/3830397.3841893, pointing at the ACM proceedings entry. It currently returns 404 — unsurprising, since the conference has not happened yet and the proceedings are not live. We are citing the arXiv record and the journal reference instead.
This is the second consecutive round in which an arXiv “related DOI” on a strong paper has been dead on arrival; a museum AI study we covered had the same problem. The pattern looks structural: DOIs get registered when the camera-ready is accepted, and resolve when the publisher posts the proceedings, and there is a gap of weeks to months in between. If you are assembling a bibliography from arXiv metadata, those DOIs need checking, not copying.
Sources
- Warping the Workspace: Expanding Visual Access with Adjustable Reach Mapping for Humanoid Teleoperation — arXiv:2610.28712
- UIST 2026