✳ SAHILVERSE / THE GLITCH MUSEUM
THE GLITCH MUSEUM / ADMISSION FREE / NO LOGIN

Turn fictional creative failures into testable revision principles and a private postmortem you can save.

BEAUTIFUL
MISTAKES.

AN EXHIBITION OF THINGS THAT DIDN'T WORK. AND THE CRAFT OF MAKING THEM BETTER.

A museum that admits its repairs. Open a case, compare what changed, run an honest local simulation, and leave with a clearer way to revise your own work.

BREAK THE PERFECT FRAME Skip intro / view six galleries ↓
01. EXAMINE02. COMPARE03. REPAIR04. KEEP
The pristine frame is a metaphor. Start the experience to reveal how a revision exposes six useful layers.
00 / THE CURATOR'S NOTE
A working theory of revision

THE CRACK IS
THE EVIDENCE.

A polished interface can hide its origin story. A useful archive makes the journey legible.

When a deployment breaks, a paragraph confuses someone, or an interaction excludes a keyboard visitor, the tempting question is: “What does this say about me?” The more useful question is: “Which assumption failed, under what conditions, and what would count as an improvement?” The first makes the event a verdict on identity; the second turns it into something inspectable.

That shift does not romanticise errors. Broken experiences cost readers time and trust. A revision matters because it reduces that cost, records what was learned, and helps the next creator avoid repeating the same avoidable mistake. Visibility is not the same as public confession; you can document a mechanism without exposing private details.

These six exhibits are deliberately constructed teaching cases, not verified stories about Sahil Tayal's deployments. A real incident needs artifacts, reproduction steps and an author-approved timeline. Here we demonstrate the anatomy of a repair without pretending we possess that evidence.

FIELD ESSAY / 01
A—Z / REVISION

FAILURE IS
INFORMATION.
NOT IDENTITY.

Calling an artifact “bad” compresses many distinct observations into one blunt judgment. A page can be beautiful yet confusing, fast yet inaccessible, inventive yet impossible to maintain. The description that helps a creator revise is smaller and less dramatic: at 360 pixels wide, the navigation covered the primary action. That is a condition someone else can reproduce, not a character assessment.

A useful postmortem separates four layers. Observation: what a person or system actually did. Interpretation: why we suspect it happened. Test: what could distinguish a guess from a mechanism. Revision: the specific thing changed and how to verify it. The interpretation may remain uncertain even after a fix; that is allowed. Technical maturity is partly the ability to write “we don't yet know” without feeling that uncertainty undermines the work.

There is a difference between a mistake that reveals a boundary and a failure that repeats through neglect. Documenting the boundary, identifying who was affected, and giving the audience an honest path forward shows respect. Disguising the error behind a spectacular animation does not. Nor does a fashionable “fail fast” slogan absolve a product from reasonable care when stakes are high.

Healthy experimentation makes risk proportional. A playful typography experiment can fail in public with modest consequences; a form storing people's private notes deserves stronger safeguards. The point is not to chase error. It is to design a process in which errors that occur can be noticed, examined, corrected and remembered.

02 / THE CONSERVATION LAB

PULL THE SEAM.
WATCH THE RULE CHANGE.

Four real comparisons. Move a slider with a pointer or arrow keys, or choose Before / Split / After. The Test action uses the selected rule and describes its result. This is a demonstration, not a research experiment.

01 / OUTCOME

The button that keeps its promise

Before: A styled button has no defined action or feedback.

After: A named action returns a visible confirmation and tells the visitor what changed.

Choose a comparison state, then test it. At 50% or more, the repaired rule runs.

What does this test show?

This is a local, illustrative simulation. The slider visibly reveals the revised design; the Test button changes its response according to the selected rule. It does not measure visitor behaviour or prove a general claim.

02 / CONTROL

The animation you can refuse

Before: Movement loops regardless of the visitor’s preference.

After: The same motif pauses on demand and honours reduced-motion settings.

Choose a comparison state, then test it. At 50% or more, the repaired rule runs.

What does this test show?

This is a local, illustrative simulation. The slider visibly reveals the revised design; the Test button changes its response according to the selected rule. It does not measure visitor behaviour or prove a general claim.

03 / EVIDENCE

The claim with a provenance trail

Before: “This always works.” No method, boundary or test is stated.

After: “This worked in a local demonstration.” The method and limits are visible.

Choose a comparison state, then test it. At 50% or more, the repaired rule runs.

What does this test show?

This is a local, illustrative simulation. The slider visibly reveals the revised design; the Test button changes its response according to the selected rule. It does not measure visitor behaviour or prove a general claim.

04 / DISCOVERY

The door with a clear label

Before: A mysterious icon has no instruction or explained destination.

After: A described action reveals a usable three-step task with a keyboard path.

Choose a comparison state, then test it. At 50% or more, the repaired rule runs.

What does this test show?

This is a local, illustrative simulation. The slider visibly reveals the revised design; the Test button changes its response according to the selected rule. It does not measure visitor behaviour or prove a general claim.

The animated layers are optional visualisations. Every before/after is also written in text. At 50% or more the Test control invokes the repaired rule; below 50% it demonstrates the limitation safely. No external calls are made.

FIELD ESSAY / 02
REPRODUCIBILITY

THE BUG IS
NOT THE
WHOLE STORY.

A screenshot proves that a screen looked a certain way at one moment. It does not, by itself, reveal the route a visitor took, the browser configuration, the state of the files, the network conditions, or whether an apparent repair survives a refresh. A reproducible description is richer than an attractive before-and-after: start at the exact address, state the viewport, describe the action, record the expected result, and note the actual result.

Good reports keep evidence granular. “The landing page broke” is a useful alarm; “the hero heading was visible but navigation links disappeared after enabling reduced motion at a narrow viewport” is an actionable test. If something happens only sometimes, say so. If you have not tried a device, say so too. Apparent confidence that outruns evidence is a second bug: it damages the archive's credibility.

Every repair also creates regression risk. Making an animation stop might also make its final caption unreachable. Making text larger might alter the layout at 360 pixels. Moving a button can break the reading order. A serious comparison tests both the intended correction and the neighbouring behaviours, especially keyboard access, reduced motion, offline rendering and the empty-state path.

The best evidence trail isn't always complicated. A small HTML example, a concise issue report, a version label, and a clear note about what remains untested can be enough to teach someone else. A century-scale archive benefits from plain language and portable files more than from a perfect-looking dashboard whose rules nobody can recover.

03 / BUG → PRINCIPLE

MAKE THE MISTAKE
PORTABLE.

Turn a fictional or real mistake into a small, careful postmortem. Nothing is transmitted, persisted to browser storage or shared by this site. Drafts live only in this open page until you copy, download, clear or close it.

PRIVATE BY DESIGN / LOCAL RULES, NOT AN AI DIAGNOSIS

How to use this instrument

Name an observable issue first. A cause is a hypothesis until you test it. A principle should be reusable without pretending every situation is identical.

REPORT / UNSAVED
04 / THE REVISION WALL

A CHANGELOG
WITHOUT THE MYTH.

A teaching sequence, not a chronological record of a real project. Stages are labelled v1–v4 because no real release evidence has been supplied.

  1. v1 / HYPOTHESIS

    It looked finished.

    The pristine mock-up asked visitors to admire it. Its most important assumption — “everything works” — had never been tested.

  2. v2 / DISCOVERY

    A real path failed.

    Small screens and scripts-disabled access exposed gaps the idealised presentation concealed. Observation replaced intuition.

  3. v3 / REPAIR

    The contract became explicit.

    Controls gained outcomes; the essential content moved into resilient HTML; motion became optional and purposeful.

  4. v4 / HONEST LIMIT

    Not the final version.

    The repaired design has a clearer test story, but no claim of universal device coverage. New evidence may warrant another revision.

FIELD ESSAY / 03
THE LONG VIEW

THE MOST USEFUL
ARTIFACT MIGHT
BE A REVISION.

Archives often preserve the celebrated object: the published essay, the screenshot of the shipped site, the final approved design. These are worth keeping. Yet the path between two versions can teach a future reader more about judgment than either version alone. A correction reveals what the creator once assumed, what the world taught them, and which trade-off they chose next.

Being willing to revise is not a guarantee of wisdom. People can change things for fashionable reasons, overfit to a single comment, or erase a useful feature while solving a minor problem. The responsible question is not “Did we change?” but “What claim about the experience justified the change, and what did the new test show?” Sometimes the answer is to revert. Sometimes it is to leave a known limitation in place and say why.

There is also a humane dimension. A person who makes things in public must protect time, privacy and ordinary life, not just output. A postmortem should identify mechanisms, not create a permanent courtroom for every imperfect afternoon. The audience deserves transparent constraints; the creator deserves freedom to learn without treating each draft as evidence for or against their worth.

The museum does not ask you to celebrate mistakes. It asks you to leave them more intelligible than you found them. A fixed button matters. So does the small sentence that tells the next person why it was fixed. Craft is not a spotless origin story. It is the ongoing relationship between intention, reality, and the willingness to look again.

05 / A PIECE OF THE MUSEUM TO KEEP

TAKE THE PRINCIPLE.
LEAVE THE SHAME.

A field guide you can use without this site: museum labels, issue templates, reproducibility, deploy and access checklists, and the question that makes a correction honest.

11-PAGE ORIGINAL PDF

THE GLITCH CATALOG

Written and designed for this museum. Includes two fillable-by-hand worksheets, six illustrated labels, four before/after mechanisms, a publishing checklist, an accessibility regression sheet and reading paths.

Download the Field Guide (PDF) ↓

Free • Actual file inside the deployable ZIP • No signup