Threshold

When Parkinson's freezes your feet at a doorway, Threshold draws stepping lines on the floor and plays a steady beat from the door, then fades away once you walk on. Nothing to press.

Comment

You're walking to the kitchen. You reach the same doorway as always, and your feet just... stop. Your brain says "go". Your legs don't answer.

That's freezing of gait, and for many people with Parkinson's it strikes at the exact same doorway, day after day. Threshold is a Specs Lens that waits quietly at that doorway. When you freeze there, it puts three lines on the floor to step toward and a steady beat in your ears, and the moment you're moving again, it gets out of the way.

A cueing aid to try with your physio; not a medical device.

Inspiration

More than 11 million people live with Parkinson's, and more than half of them experience freezing of gait: the feet stop responding, often at the same doorway every time. Freezing is a leading cause of falls. For some people, a visual line to step over or a steady beat can get the feet moving again. Laser cue shoes cut freezing episodes by 46% in a small lab study. But cueing works for some people and not others, and a phone or watch adds a task at exactly the wrong moment.

Glasses can do something a phone can't. They put the line where the feet go and play the beat from the doorway, while the hands stay free.

What it does

Threshold has two people in mind.

  • Before the walk, a physiotherapist or carer uses a small setup panel on the same glasses. They pinch Marking Mode, pick the doorway that has caused trouble, and pinch Mark as Trouble Spot. That doorway gets a soft outline and a small corner marker, so it reads as "recognised", not as a warning. Three sliders set line spacing, beat speed and first-line distance, each showing its number.
  • During the walk, the wearer does nothing. There is nothing to press, hold or confirm.
    1. MONITORING. Threshold waits for a stop at a marked doorway. A cue needs the person within the doorway's area, stopped (under 5 cm/s) for 2 s, with their head within 45° of straight through, from either side. Standing at the door while facing away doesn't trigger it.
    2. CUE_ACTIVE. A LOOK DOWN chevron appears about 1 m ahead. It follows the head gently instead of being glued to the face. Three cyan lines are laid on the real floor 2.5 m, 2.1 m and 1.7 m ahead, toward the doorway. They come into view one by one as the head tilts (about 12°, 17° and 23°), because the Specs view is only about 37° tall, so the lines are never lifted into view. A steady tick plays from the doorway at the set speed (90 BPM by default).
    3. RECOVERY. After about 80 cm of forward movement, everything fades over 1 s and Threshold goes back to watching.

Honest endings. Looking down counts as engagement, not recovery; only movement counts as recovery. If nothing changes, the cue ends at 15 s, or at 8 s if they never looked down. That outcome is logged as UNRESOLVED and never claimed as a recovery. A new cue needs the person to leave the doorway area and come back. With no floor detected, no lines are drawn and the beat plays alone. Nothing is stored or reported.

How I built it

  1. Planning. I answered the Devpost Learn plan-lens interview myself. It checked the idea against AR design practice and the preview's limits, and wrote devpost/design-brief.md. Every decision in the Lens comes from that brief, including the facing check, the 2.5 m first line for a 37° view, and "no wearer toggle". When the brief and an earlier spike disagreed, the brief won.
  2. Building. Claude Code, with the CLAD plugin and the Lens Studio MCP, built the Lens in Lens Studio 5.23.2 from the brief: the scene, the stand-in room with two real-size doorways, the TypeScript scripts, and the Spectacles UI Kit setup panel. The beat tick was synthesised locally by CLAD's sound tool, with no samples.
  3. Structure. CueDecider.ts is the state machine. It is pure logic with no scene references, so the same file runs in the Lens and in Node. CueController.ts drives the chevron, lines, beat and fades. Doorway.ts holds a doorway and its marked indicator. ThresholdSetupUI.ts is the panel.
  4. Testing. There is one LEAF scenario per done criterion in the brief (C1–C5), plus X1_BriefExtras for the other rules in the brief. All of them run in the Lens Studio preview through the MCP, and C1–C5 pass. There are also 15 Node tests for CueDecider.ts.
  5. Video. The demo includes an uncut, real-time recording of the Lens in the Lens Studio preview. An editor script grabbed the Preview panel frame by frame, and the video says how it was made.

Challenges I ran into

  • The 37° view. The first version put lines where the feet are, which is outside the display unless you look straight down. The fix was to start the lines 2.5 m out, add the LOOK DOWN chevron, and let the lines come into view one at a time, instead of moving them up to fit the screen.
  • Not over-triggering. A stop isn't a freeze. The facing check, the 2 s hold, and re-arming only after leaving the doorway area all exist so the Lens stays quiet when it isn't needed.
  • Telling the truth about endings. It would be easy to count every ending as a success. Separating engagement (looking down) from recovery (moving), and logging timeouts as UNRESOLVED, took deliberate design in both the state machine and the tests.
  • Testing a scripted user. LEAF drives the preview with injected input. A few runs failed under editor load (one long frame stretched a beat interval, and one simulated slider drag missed). Each passed when rerun, and I've kept the failure records.
  • Bigger buttons. After the live review stressed big pinch targets, I grew the setup panel to 32 × 38 cm and made the buttons 6 cm tall. Only the sizes changed.

Accomplishments I'm proud of

  • The wearer never has to do anything. All the interaction belongs to the person who sets it up.
  • Every number in the Lens traces to a line in the design brief, and every done criterion has a LEAF scenario that checks it.
  • It doesn't overclaim: no recovery is reported unless the person actually moved.

What I learned

  • Good AR here meant designing around the body: where the eyes go, what the hands are doing, and how tall the display really is.
  • The most important features were the ones that make the Lens stay quiet.
  • Writing the brief first made the agent's build reviewable. I could check every behaviour against a sentence I had chosen.

What's next

  • Try it on Specs glasses. Real hand tracking, head-tracking jitter and real floor detection are untested.
  • Let doorways be marked on a device. The stand-in room is preview-only today.
  • Supervised testing with physiotherapists before anyone relies on it.

Limits, stated plainly

  • Stopping for 2 s is a guess, not a diagnosis of a freeze. Every number (2 s, 45°, 5/8/15 s, 80 cm, 40 cm, 90 BPM, 2.5 m) is a first prototype setting, and none is clinically validated.
  • Looking down, or following a line, may not be safe for everyone.
  • Visual cues on HoloLens did not reduce freezing during turns in a published study, so whether this helps is an open question.
  • It has not been tried on Specs glasses or with patients.

Built with / prior work

Nothing here was written before the hackathon. It uses the Lens Studio Specs Base Template, Spectacles Interaction Kit 2.0.0, Spectacles UI Kit 2.0.0, LEAF 2.0.2, code and assets generated by CLAD, and the hackathon's plan-lens brief template. MIT licensed.

Sources

Built With

  • clad
  • claude-code
  • leaf
  • lens-studio
  • lens-studio-mcp
  • node.js
  • specs
  • spectacles-interaction-kit
  • spectacles-ui-kit
  • typescript
Share this project:

Updates

Submission history