Display glasses web apps, simulated in your browser
Point WASD at any public URL and it renders the page the way a wearer of optical waveguide glasses sees it: added light over a real scene. Free, in-browser, no hardware.
Added light, not pixels
Your app loads in an <iframe> and is composited with mix-blend-mode: plus-lighter, the same arithmetic a waveguide performs when it injects light into the eye.
Load a URL. Any public page. It stays fully interactive inside the display.
Set placement. Size, position and the optics model. Defaults match the monocular right lens.
Change the scene. Lighting and motion decide contrast. Test until something breaks.
Capture, record, share, QR. A still, a video, a link that restores your setup, or open it on real glasses.
Seven rules, each one falsifiable
A web app for the glasses is a standard web page. Meta's documentation covers setup, input and publishing; these seven cover the part that is genuinely different, and every one of them is running live below.
The tiles are not illustrations. Each is composited with mix-blend-mode: plus-lighter over a frame shot on Ray-Ban Display glasses, at the opacity the same optics model in the simulator returns for the ambient level you have set. What dies here dies on the glasses.
DISPLAY HELD AT 1 000 NITS, the middle of the Meta Ray-Ban Display range. Ambient runs 50 lux (a dim room) to 30 000 lux (open sun). The ratio is (display + ambient) / ambient: usable above 3:1, marginal to 1.5:1, lost below.
Pure black emits nothing, so it arrives as clear glass. The card you drew does not exist on the glasses: only the marks you lit up do. This is why a design that looks composed on a monitor arrives as loose text floating over traffic. Draw the container in a dark grey that still emits, or accept that there is no container.
CHECK IT IN THE SIMULATOR ↗A pixel has no size on glasses. The panel floats about a metre away and subtends a fixed angle, so the only honest unit is how much of the wearer's vision a letter occupies. Roughly 0.6 degrees is the floor for legibility, and anything you expect read at a glance, in motion, should sit well above it.
On Meta Ray-Ban Display that arithmetic is fixed: 20 degrees across a 600 pixel grid, so one degree is 30 authored pixels. The simulator prints the angle your current size works out to, live, next to the size slider.
CHECK IT IN THE SIMULATOR ↗On a monitor, contrast is a property of two colours you chose. Here it is a property of the light falling on the wearer's face, which you do not control and cannot predict. The same layout is crisp in a library and gone on a forecourt at noon.
So there is no such thing as a design that passes. There is only a design and the illuminance it stops working at. Find that number and decide whether you can live with it.
CHECK IT IN THE SIMULATOR ↗Saturated colour is dim colour: a pure red is one channel doing all the work, and one channel cannot out-shout daylight. Cyan, green and near white carry two or three channels, which is why they survive. Deep blue is the worst case on almost every combiner.
Which breaks the usual convention, because red is what you reach for to say stop. On glasses red says nothing at all outdoors. Carry the urgency with size, motion or position instead.
CHECK IT IN THE SIMULATOR ↗A drop shadow is a subtraction: it works by taking light away from what is behind it. An additive display has no way to take anything away, so a shadow is simply not rendered. Every elevation cue built on shadow is invisible here.
Build hierarchy the other way round. A dark but non-black surface with a brighter edge reads as a seat for content, and the difference between two levels becomes a difference in emitted light rather than in cast darkness.
A notification on a phone competes with a screen the user is already looking at. A notification on glasses competes with the road. Anything that snaps into place pulls focus from the world whether or not it deserved to, and the wearer has to physically refocus about a metre out to answer it.
Let information arrive over roughly two seconds so it can be noticed and declined without a decision. Keep instant response for direct feedback only: a focus ring, a selection, anything the wearer just caused.
CHECK IT IN THE SIMULATOR ↗The real budget is not the 600 by 450 grid. It is about one second of attention, taken off-axis, usually while walking. Whatever cannot be understood in that second is not slow, it is absent.
In practice this means one number and one label. If a second idea genuinely has to be there, it belongs on the next screen, not the next line.
CHECK IT IN THE SIMULATOR ↗Pixels to degrees, on this device
Rule 02 needs an exchange rate. Meta Ray-Ban Display puts a 600 by 450 grid across roughly 20 degrees of horizontal field of view, so every size you author converts at 30 pixels per degree. Other panels differ; the simulator computes it from whichever device profile is loaded and prints the result next to the size slider.
X-Frame-Options: DENY or a strict frame-ancestors CSP will not render in the simulator. Deploy without those headers, or open the application directly on the glasses.Three demos, one click each
Served from this same origin so they always load. Black ground, bright marks, no stroke under 2px. Load one, raise Ambient, and watch what survives.
The archetypal glanceable HUD: big distance, street name, heavy arrow.
Countdown, progress ring, step indicator. Test it against the Cooking scene.
Bright-on-black keeps reading; dark-on-white disappears. Raise Ambient to watch them separate.
demos/ in the repository, with no build step and no dependencies.Agent-generated surfaces obey the same physics
Protocols like A2UI let an agent emit a user interface as declarative JSON, drawn by the client from a catalogue of approved components rather than by shipping code across a trust boundary. It is a good answer to a real security problem, and it is going to be how a lot of glasses content gets built, because an agent that can only return text cannot do much on a display.
The catch is that every component catalogue in circulation was designed for opaque screens. Cards with white surfaces, drop shadows for elevation, saturated status colours, body text sized in density-independent pixels: each of those is a rule above, broken by default. An agent picking sensibly from such a catalogue will produce something unreadable on a waveguide every time, and neither the agent nor the protocol has any way to know.
Rendering an A2UI surface additively over real footage, so a catalogue can be judged before it is adopted, is the next thing planned for WASD. Until then, the rules above are the checklist to hold a catalogue against.
Where these came from
- Google, Designing for transparent screens. Rules 02, 05 and 06 are theirs: type measured in visual angle with a 0.6 degree floor, depth built from dark surfaces rather than shadow, and motion slow enough to earn attention rather than demand it. Rule 04 is half theirs. Worth reading in full; it is the best published account of this problem.
- Three months of daily wear. Rules 01, 03 and 07 come from building apps on Meta Ray-Ban Display and walking outside with them, which is also where the background footage on this page was shot.
- The optics model. The contrast ratio and the opacity every tile is drawn at come from
optics.jsin this repository, the same file the simulator uses. The physics is a diffuse-reflector approximation, documented in that file.
Corrections welcome. If a rule here does not match what you see on your own hardware, that is worth an issue on the repository.