IBM didn't want Microsoft to use the Tab key to move between dialog fields

Original Article ↗ Hacker News Discussion ↗

Keyboard shortcuts like Tab and Enter, now taken for granted in graphical interfaces, were once the subject of intense debate between IBM and a young Microsoft, highlighting a clash between rigid corporate standards and fast-moving “hacker” culture. Commenters recall how IBM mainframe and terminal conventions (Tab/BackTab, Field Advance, separate Enter vs Return keys) evolved into today’s inconsistent form-navigation and messaging behaviors, and speculate about motives ranging from UX purity to patent strategy and internal politics. The thread broadens into reflections on how key meanings (Tab vs spaces, Caps Lock, Insert, Scroll Lock) and corporate bureaucracy still shape software usability decades later.

IBM vs. Microsoft over the Tab key

  • Commenters are puzzled what IBM wanted instead of Tab; the story as told doesn’t specify.
  • Several speculate IBM disliked dual‑use keys (Tab as both input character and navigation control).
  • Others think it may have been internal politics, standards battles, or patent concerns rather than a coherent UX stance.
  • Some see it mainly as an anecdote illustrating cultural conflict: IBM as process‑heavy vs Microsoft as “ship it” hackers.

Historical behavior on IBM systems

  • Multiple people recall IBM 3270 mainframe terminals using Tab/Back‑Tab to move between fields and Enter to submit, making IBM’s objection seem inconsistent.
  • Midrange 5250/AS‑400 terminals had dedicated “Field Advance” / “Field Backspace” keys and separate Enter vs Return, supporting multiline input without conflicting with “submit.”
  • IBM’s later CUA guidelines explicitly specified Tab/Back‑Tab for field navigation, suggesting the escalation in the story may have predated or contradicted their own standard.

Enter/Return, field navigation, and modern UX

  • Several note the long‑running confusion where Enter can mean “next field,” “submit,” or “newline,” especially in chat apps.
  • Some argue Enter‑to‑advance and Ctrl+Enter‑to‑submit or separate Enter/Return keys are more coherent; others prefer Tab for navigation.
  • There are conflicting memories about DOS apps: some recall Enter for moving between fields, others remember Tab.

Tabs as characters vs navigation; tabs vs spaces

  • A major sub‑thread discusses how Tab is “hijacked” by UI navigation, making it hard to insert literal tab characters in web forms.
  • This is used as an argument for using spaces for indentation in code: Space almost always produces a space, Tab often changes focus.
  • Counter‑arguments emphasize tabs as “logical indentation” whose visual width can be user‑configured; spaces lock everyone into one width.
  • People highlight practical problems when mixed tabs/spaces meet different tab widths, causing misaligned code.

Keyboard design and anachronisms

  • Several posts dive into IBM keyboard history (3270 layouts, separate Enter/Return, Back‑Tab, beam‑spring vs later designs).
  • Others lament modern PC keyboards: oversized Caps Lock, largely unused Scroll Lock/Pause/Insert, and missed opportunities for dedicated “next field” keys.

Corporate culture and credibility

  • Some see the story as emblematic of IBM‑style bureaucracy; others note Microsoft today feels similarly bureaucratic.
  • At least one commenter questions the anecdote’s evidentiary strength and missing details (especially what IBM proposed as the alternative key).