This is part of a series. The Gutenberg/Semantic model describes how physical and logical layers relate in software. The Def-Use split describes how authors and users inhabit different semantic models. MDI is where both patterns collide.

1. What MDI Was Solving

Multiple Document Interface was Microsoft’s answer to a real problem from the late 1980s: how do you manage multiple documents in a single application on a 640×480 screen with no taskbar, no virtual desktops, and no window manager worth the name?

The solution was to put a “parent window” around all “child windows” and let the application manage them internally. The parent window is a Gutenberg container — a way to manage screen real estate within the constraints of the era. Within that container, child windows could be tiled, cascaded, minimised, or overlapped. The application, not the OS, was responsible for spatial management.

For 1989 this was reasonable. The Gutenberg constraint (screen size, OS window management) was real, and MDI addressed it directly.

2. Microsoft Standardised It and the Tribe Formed

Microsoft did what Microsoft does: they standardised the solution, built it into the Windows API (MFC, then WinForms), wrote it into their Human Interface Guidelines, and trained a generation of developers on it. Excel, Word, Access, Visual Studio — all MDI. The pattern became the tribal Def.

Once a pattern is tribal it stops being evaluated against Use. It becomes load-bearing for developer identity, certification programmes, enterprise software guidelines, and API design. Switching away from MDI would mean:

  • Admitting the Def was wrong
  • Breaking the tribal identity of Windows developers who built MDI applications
  • Potentially invalidating enterprise software certification based on MDI compliance
  • Rewriting Microsoft’s own flagship applications

The Def had become a wall. The tribe defended it not because MDI was still the best solution but because the Def was the tribe.

3. The Use Signal Was Ignored for Decades

Users clearly preferred tabs. The feedback was unambiguous and arrived early:

  • Firefox introduced tabbed browsing in 2001
  • Opera had tabs even earlier
  • IE7 added tabs in 2006 — Microsoft’s own browser team read the Use signal
  • Chrome launched with tabs as the primary UI paradigm in 2008, one tab per process, and took over the browser market

Every browser moved to tabs. Every modern IDE moved to tabs. VS Code uses tabs. Terminal applications use tabs. Users had voted with their behaviour for years.

But Office resisted. Excel MDI child windows persisted long after the rest of the world had moved on. Access still uses MDI. Visual Studio kept MDI long after VS Code proved tabs worked better. Windows Explorer only got tabs in Windows 11 — in 2022, twenty years after Firefox.

The Use signal was not ambiguous. It was ignored because acknowledging it would mean the tribe was wrong.

4. MDI Was Solving the Wrong Gutenberg Problem

The deeper issue is that MDI encoded a specific era’s Gutenberg constraints into a semantic model and then defended that semantic model after the constraints had changed.

The original constraint — limited screen real estate, no OS-level window management — was a Gutenberg problem. MDI was a Gutenberg solution. But Microsoft presented it as a semantic solution: “this is how multi-document applications should work.” The Gutenberg constraint became a semantic principle.

Tabs solve the same Gutenberg constraint with a better semantic model:

  • Each document has visible identity at all times — you can see all open documents without spatial memory
  • Switching is O(1) visually — one click, predictable position
  • No overlap, no cascade, no minimise-within-parent confusion
  • The Gutenberg container (the window) and the semantic units (the documents) are cleanly separated

MDI child windows have identity only within the parent. They disappear when minimised into the parent’s floor. They overlap arbitrarily. The user must maintain their own spatial memory of where each document went. The Gutenberg management leaks into the user’s semantic task.

This is the same pattern as the Visual C++ versioned install path: a Gutenberg detail encoded into a semantic interface, defended long after the underlying constraint changed, breaking every user who expected the interface to serve their needs rather than the era that produced it.

5. The Browser Got It Right Because It Had No Tribe to Defend

Browsers had no MDI legacy. They were new applications solving a new problem — managing multiple web pages — with no existing tribal Def to defend. Firefox, Opera, and Chrome could look at what users actually did (open many pages, switch between them, lose track of them) and design toward that Use signal directly.

The result was tabs: a clean semantic model (each page has identity) over a clean Gutenberg container (the browser window). No child windows, no spatial memory required, no cascade menu needed to find what you opened an hour ago.

The lesson is not that tabs are obviously correct and MDI was obviously wrong. It is that the browser teams had no tribe defending a prior Def, so the Use signal could flow directly into the design. Microsoft’s application teams had decades of tribal investment in MDI, so the same Use signal was filtered out.

6. VS Code versus Visual Studio — Again

The MDI story repeats within Microsoft’s own developer tools. Visual Studio maintained MDI-style document management for years — files open as child windows within the IDE frame, managed spatially, with all the associated confusion.

VS Code launched in 2015 with tabs. No MDI. No child windows. Editor groups for split views. The Gutenberg container (the window) and the semantic units (the files) cleanly separated.

Visual Studio eventually adopted tabs too — but only after VS Code had demonstrated that the Use signal was unambiguous and the old pattern was costing market share to a lighter tool built without the legacy.

The same tribe, the same Def, the same delay. The difference is that VS Code was built by a team with no investment in the existing pattern. New tool, no tribe, Use signal flows freely.

7. The Closing Pattern

MDI is a clean example of the full Def-Use failure cycle:

  1. A real Gutenberg constraint produces a reasonable solution
  2. The solution is standardised and becomes tribal
  3. The Gutenberg constraint changes (bigger screens, better OS window management, tabs)
  4. The Use signal arrives clearly and repeatedly
  5. The tribe filters it out because the Def is identity, not just design
  6. A new entrant with no tribal investment reads the Use signal and wins
  7. The tribe eventually follows — twenty years later

The weak link willing to learn would have caught the Use signal at step 4. The tribe caught it at step 7, if at all.

The printing press took centuries to develop the editor and the publisher as Use-side voices. MDI took twenty years for tabs to win. AI assistants are somewhere in the middle of their own version of this cycle right now.