Pimp My IDE / input mechanics
Back to garage
October 3, 2026 | keyboards / interaction / weird hardware

What if the keys came to you?

Google's conveyor-belt Gboard replaces hand travel with arrival time. The prototype suggests a useful interface test.

When a tool brings commands to the operator, measure the wait. Keep the target visible. Add a pause. Preserve direct input for people who do not want to ride the belt.

The machine is real. The product pitch is a bit.

Google Japan's Gboard team built four moving belts with 29 keys on each belt. The keys travel toward one hand. The operator presses each character when it reaches the typing position. The announcement says the layout can enter uppercase and lowercase letters directly.[1]

The repository is more than a render. It has KiCad board files, firmware, printable case parts, and a build guide. Google labels it an unsupported project rather than an official product.[2]

The guide calls the build the Moving Keys Edition. It lists 116 switches, 116 keycaps, a 150 RPM gear motor, and 157 printed pieces across 18 part types. A Bluetooth edition is marked "Coming soon."[3]

The keyboard reduces hand travel by making the operator wait for each key.

Space and time are two ways to hide a command.

A normal keyboard puts every letter at a fixed coordinate. You learn where to reach. The conveyor keeps the hand near one point, but the correct letter may not be there yet. You learn when to act.

That trade appears in software too. A command palette waits for a query. A radial menu waits for a gesture. An adaptive toolbar waits for the system to predict the next action. Each design can reduce movement while adding search, delay, or uncertainty.

Do not call that bad by default. Measure the actual task. A one-handed input option may matter more than raw speed. A changing control may work well when the choices are few and the next one is predictable. A coding tool still needs a stable route for commands that must fire now.

A moving control needs five fixed parts.

Keep the target in one place. Mark the point where input happens. Show what is approaching. Give the operator a pause that does not erase state. Keep a direct route for exact or urgent input.

Those rules apply to carousel toolbars, rotating suggestions, voice menus, agent action queues, and any interface that changes before the operator acts. Motion can carry information. It cannot own the only route to a command.

Test the wait, not the spectacle.

Pick a short real phrase. Run it through the moving interface and the direct input. Record missed targets, corrections, pauses, and completion time. Repeat with keyboard-only use and reduced motion. The result belongs to that phrase, speed, browser, and operator.

The browser rig below is a timing sketch. It does not reproduce the physical keyboard, motor, key travel, or one-handed ergonomics. It makes the trade visible without pretending to measure Google's hardware.

Interactive makeover / input conveyor bench

Trade reach for timing.

This pairs a normal text box with a four-lane conveyor simulation. The moving version keeps one strike action but adds lane choice, timing, speed, and pause. Try both before copying the test card.

Direct input

Fixed coordinates

Type the phrase with the keyboard you already use. Every key remains in one place.

What it optimizes: immediate access and learned position.
What it costs: hand travel, reach, and a large fixed control field.

Run one fair lap

  1. Pick one short phrase.
  2. Use the same hand and posture.
  3. Time each input route once.
  4. Count misses and corrections.
  5. Record the browser and input device.

One lap is a comparison for that setup. It is not an accessibility verdict or a typing benchmark.

Conveyor input

Fixed strike gate

Choose a lane with the radio controls or Up and Down. Press Enter or the strike button when the wanted character reaches the green key. Space pauses the belt when focus is outside a text field.

Active belt lane
3 / 5
ABCDEFGABCDEFG
0 characters / 0 strikes
Lane A to G. Strike A.
This is a browser simulation and teaching aid. It does not measure the Gboard Conveyor Belt Version, accessibility, typing speed, muscle load, or input accuracy. Fill the observation fields after a real test.

Sources read

Source log and evidence boundary
  1. Google Japan Blog, "Gboard team proposes a new keyboard for 2026", published October 1 and read October 4, 2026. The Japanese announcement describes the four 29-key belts, moving-key interaction, one-handed intent, direct uppercase and lowercase entry, and the lack of a sales plan.
  2. Google mozc-devices, Gboard Conveyor Belt Version repository, release files read October 4, 2026. The repository publishes board data, firmware, printable models, and the unsupported-project notice.
  3. Google mozc-devices, conveyor-belt build guide, read October 4, 2026. It supplies the edition status, bill of materials, part counts, motor specification, and assembly route.
  4. Hacker News discussion 49927514, read October 4, 2026. The exact item ID was resolved through the Hacker News API. The discussion was used as a discovery and reader-response source, not as proof of the build.

Evidence boundary. Pimp My IDE did not build or test the physical keyboard. The spatial-versus-temporal input analysis, five fixed-part rule, and browser rig are editorial work. Product facts and build counts come from the cited Google pages and repository.