[connorboyle]

A great read, although I'd still like to know what IBM's reasoning for opposing this use of the Tab key was.

Is it because they didn't want Tab to be both an input and a control character? I.e. there are some cases where you can type a Tab into an input field, and there are other cases where you can't, and it's not immediately obvious which ones are which?

All the way in 2026, I would still be sympathetic to this view.

[bruce511]

Personally I don't like the tab key for field change.

Firstly it was a breaking change from dos. Dos programs used Enter. And enter meant you could capture numeric data using 1 hand, since the numeric keypad has an enter key.

That means left hand can stay on the (paper) source. Right hand types. People got fast at this. (Really fast). And this pattern lives on in some programs kline Excel).

Lots of people (ie my customers) hated needing both hands on the keyboard. Lots of our programs allowed mapping of enter=tab.

I should be clear. It's not the "name" of the key that matters, it's the location.

The dual-use of the key is just an annoyance we live with. Sometimes the key behaves as a navigator, but in other cases it behaves as a spacer. Daft. (Enter would have the same problem. )

The best solution (by far) would gave been to add another key to the keyboard. Preferably in the numeric key pad. We got lots of new keys in that era. Hindsight says we should have added a "move on" key at that time.

[dark-star]

> Dos programs used Enter.

I have used plenty of DOS programs back in the late 80s/early 90s, and I don't remember a single one that used "enter" to move between fields. Most of the time, "enter" closes the dialog. They all use TAB to move to the next field.

But maybe you're talking about even older software?

[bruce511]

>> But maybe you're talking about even older software?

Maybe.

[munk-a]

If you're designing a text editor that's intended to run within a browser you need to fully break user expectations about the functionality of the tab key - there are two completely logical and intuitive roles it can serve in such an environment that are in conflict.

The same issue arises (with much higher frequency) with Enter and even in the modern world I'm sure we all have a pretty complex ruleset we've committed of when ctrl+crlf triggers a newline, or a message send and what the corresponding behaviors of a bare crlf and shift+crlf are.

In HN's editor shift+crlf and a bare crlf cause a newline creation and ctrl+crlf does nothing - but often times ctrl+crlf will trigger a form/message/whatever submission, shift+crlf often causes a raw newline insertion (even when in a form context) and then a bare crlf might do one - might do the other or might even do neither! Those are the common bindings but I have seen exceptions and inversions of bindings with shift+crlf causing form submission while requiring ctrl+crlf for raw newline insertion.

All this stuff is just super annoying and causes a lot of user friction (and for a long time MSFT's style guide was considered a seminal reference for best practices as ironic as they may seem to folks these days).

[deburo]

I now imagine a world where CAPSLOCK is used as "select the next input" and TAB as the character.

[OhMeadhbh]

You mean the Control key to the left of the 'A' key? That's already the control key.

[daemin]

Arguably the capslock key is more useful than something like the insert or break keys.

[asdfman123]

I assume so. Obviously there are very different concerns if you're managing an organization with countless moving parts versus you want to build something for the user quickly.

[hylaride]

The way I interpreted it was that there was no complete "IBM" reason. I read it as "one person in the IBM bureaucracy stepped in and brought things to a halt, which highlights the cultural differences" considering it is a post about said differences.

[rwmj]

Maybe because it would compete with IBM mainframes / 3270 terminal emulators?