When devices of different capability share a room, the experience must align to the weakest

What it is

One person on a 6DoF headset can walk around the part; another holds a phone that only tracks a plane; a third has no hand tracking. If the shared task is written for the strongest device — mid-air pinch, look around the back, fine gesture — the people on weak devices become narration, and the people on strong devices assume the others “can see it, can do it.” Weakest-link capability requires that the completable path of the joint task be the weakest device in the room. Stronger capabilities may enhance; they may not be required.

What is aligned is whether the task can be finished, not whether every picture is drawn at the low spec.

Why it happens

Collaboration assumes “what you see I see, what you can do I can do.” Device gaps split that default: a narrower field of view misses a side label, no depth misregisters front and back, no hand tracking cannot pinch, worse passthrough cannot read a real nameplate. The strong-device holder issues commands from their own abilities (“pinch that layer,” “look at the back”); the weak-device holder can neither comply nor easily prove they cannot, and is read as uncooperative.

If the task structure does not admit the asymmetry, social pressure makes the weak side try anyway and then patch with voice. Time is spent translating a capability gap. Drop the shared path to the intersection (pointing everyone has, the face everyone can see) and offer strong-only abilities as optional inspection or a personal view, and people on the intersection stay participants rather than audience.

Studying it

Mixed-device groups on the same assembly or review: headset + tablet, two-hand tracking + controller-only, wide FOV + narrow FOV. Compare a strongest-path script with an intersection-path script on completion, how much the weak side speaks, and how often they are ignored.

Device factors: tracking DoF, input kind, field of view, passthrough or not. Outcomes: task completion, share of effective actions from the weak side, times the strong side wrongly assumed execution, rated exclusion.

A lab of identical devices cannot see this. There has to be a real capability hole.

Where it stops holding

In a teaching demo the instructor on a strong device and students who only watch is designed asymmetry; it need not align to student operation. Expert-on-a-desktop, technician-on-a-headset can let the expert take the strong path, but the technician on site must still complete the physical steps — alignment happens on the site side. A capability drop from a temporary disconnect is a fault degradation, not “they never could.” Accessibility (voice-only, one hand) should count as a weakest device, not a patch after the fact.

Applying it

• Before a session, enumerate the intersection of devices in the room: pointing everyone has, the face everyone can see, the confirm action everyone has. The joint task walks only that intersection.
• Mark strong-only operations as “only you can see / only you can do,” and put an equivalent intersection action beside them.
• When the weak side cannot execute, let the system say so (“this device has no gesture”). Do not make people socially admit they “can’t.”
• How to check: run a step that can only be finished by walking around the back, headset plus phone. If the phone user cannot finish and the headset user does not know, the task is still written on the strongest path. After both faces are operable, or an equivalent tablet control is provided, the weak side should be able to close the step alone.

Related

• Same group：N5.10.1 Avatar pose is the main cue to others' intent; without it, collaboration drops · N5.10.2 Simultaneous operation of a shared object needs an explicit control-arbitration rule · N5.10.3 Network latency briefly desynchronizes how participants see the same object's state · N5.10.5 Accuracy of pointing in a joint task depends on precise sync of participant positions
• Nearby：N5.05 Shared Space · N5.09 Spatial Anchors and Persistence
• Search terms：weakest-link capability · asymmetric collaboration · device heterogeneity