Command Classic
Command Classic is a family of computer keyboard designs, varying mostly by national layout and the presence or absence of a numeric keypad. They are intended for Mac-like GUIs and Unix-like command line environments, and they draw most of their features from earlier keyboards by the likes of Apple and Sun.
Name
Command refers to the primary modifier key on Macintosh computers and their spiritual relatives (NeXT, Be). Its prominent size and location is one of these keyboards' most important features, and a major motivating factor in their creation.
Classic is a reference to the original Mac OS, widely referred to as such in the Mac OS X era, and its design principles. It's also a play on old Apple product naming conventions like "Macintosh Classic."
Keymap: Why do we want this?
The basic concept is a modern iteration on Apple's in-house keymaps predating the Extended Keyboard. They evolved through several platforms and models, but all featured a single keybank, with a numeric keypad added on business-oriented machines like the Apple III and Lisa. If navigation keys were present, they lived on the bottom of the main keybank, not in a separate cluster or as an additional mode of other keys.
Admiration for the relative simplicity of early Apple keyboards is not limited to me - the Happy Hacking Keyboard is famously inspired by the original Macintosh's symmetrical indented keybank without arrow keys. I think the better place to look is to the first Apple Desktop Bus keyboards, which standardized a layout intended to meet the needs of both Apple II and Mac users in a way roughly analogous to the demands of a modern Unix-like workstation environment.
The common take among people who are not HHKB devotees seems to be that the Extended Keyboard, with all of its extra keys and double the price tag, is the more desirable option for Classic Mac fans, but I disagree. None of the additional keys were used in Mac OS outside of DOS compatibility cards and a few idiosyncratic software titles (like Microsoft's), that largely remains true to this day, and even in a *nix/X11 environment, I find it to be the case. Keybindings from Readline or the Toolbox are far more important than the IBM-style alternatives and their dedicated keys.
Cursor Keys
Cursor key placement on Command Classic is entirely an Apple convention. I am unaware of any off-the-shelf keyboards other than those made by Apple or for Apple platforms that use this placement.
History
Apple first featured a full four-direction set of cursor navigation keys on the Apple III (1980), which squeezed them into the bottom right corner of the main keybank in a dogleg configuration, with the up arrow above the down arrow, and a pair of horizontal navigation keys to the side.
Apple's next computer, the IIe, brought many of the Apple III's features to the Apple II line, including an improved keyboard with four cursor navigation keys. While continuing to place the arrows in the bottom right of the main bank, the Apple IIe keyboard moved the up arrow to the bottom, making the cursor keys into a single row.
Apple continued to use this configuration on everything featuring cursor keys, outside of the Extended Keyboard line and a one-off reappearance of the dogleg layout on the Macintosh Plus keyboard, until the IBM-derived "Extended" style completely took over in the mid-1990s. This is the placement used for Command Classic keyboards.
Why This Placement?
- Familiarity: This is the placement I know best, that works with my muscle memory, and so it was what I wanted when building a keyboard for myself.
- Aesthetics: My personal subjective feeling is that this placement looks good, and that shoehorning cursor navigation keys into the upper rows of the main bank looks messy. This includes today's compact mainstream keyboards that place the up arrow to the left of a 1U right Shift in order to implement inverse-T cursor navigation clusters in "60-65%."
- Compatibility: Single-row placement on the bottom does not interfere with the size or position of the right Shift key, keeping Command Classic slightly closer to common keymaps and making keycap sourcing that much easier. Sourcing parts for these keymaps is challenging enough already that I will take a win where I can.
Why not vi Placement?
vi is my command line editor of choice, and those who know me somewhat well may be curious as to why I didn't go with its traditional hjkl left/down/up/right cursor navigation sequence. The honest truth is that I never developed a habit for it. I first got used to vi on IRIX, which supports cursor navigation with the arrow keys. vim also supports this, and I have only had brief encounters with "real vi" implementations that don't, so hjkl navigation never became muscle memory for me.
Of course, anybody with a Command Classic who wants to navigate that way in vi(m) can just use hjkl as usual, and even outfit hjkl keycaps with alternate arrow legends, and program their firmware to support them as actual cursor navigation keys on the Fn layer if they choose. I may even start doing that just to be nice, because it doesn't interfere with anything I use. The dedicated arrow keys used in both command line and graphical contexts in the bottom corner, though, adhere Apple conventions because I prefer Apple-style graphical environments.
Modifiers
The type and position of modifier keys is the major difference between Apple keyboards and others. Command Classic modifier layouts generally follow Apple conventions, although Sun keyboards are also an influence.
Command
Apple keys were another Apple III innovation brought to the Apple II beginning with the IIe. In Apple III and Apple II environments, "Open Apple" and "Closed Apple" were small keys used for only a handful of functions, but they established a precedent of platform-specific modifier keys beyond those included in mainstream teletype and terminal layouts. The Lisa enlarged the Apple key and made it the centerpiece of its graphical menu system's keybindings, which carried over to the Macintosh as the Command key.
Given its significance, the Command key should be one of the easiest keys on the keyboard to hit. On Lisa and Macintosh keyboards, it is usually 1.5U or 1.75U wide. Command Classic keyboards use a 1.5U Command key placed immediately to the left of the space bar, and sometimes feature a right Command key, depending on the variation.
Option
The Option key is another Apple innovation, often equated with the IBM PC Alt key. Unlike the Alt key, though, Option is primarily for chording with Command to access additional GUI keybindings, or combining with mouse actions to modify the result. Apple is less consistent about Option key sizes, but I prefer them to be larger. Command Classic usually uses a 1.5U Option key.
Control
Numeric Keypad
Numeric keypads were exclusive to Apple's unsuccessful business platforms (Apple III, Lisa) until they appeared as options on the Macintosh. All of Apple's ADB keyboards have one, as do the last Apple IIes.
Full-size Command Classic keyboards use a bank layout identical to these, with a only main bank and a numeric keypad to the right, separated by a small gap. Unlike IBM, Sun, and most other keyboards, clusters of navigation keys and dedicated function keys are not used.
National Variations
The core concept does not require a specific national layout, but it was originally imagined as a JIS keyboard. Each national variation can be considered to have a "reference layout," which is what I would build in an ideal scenario without regard to parts availability. Actual Command Classic keyboards aim for these, but make adjustments to use keycaps that are actually available.
JIS
- View on Keyboard Layout Editor
- 3.5U spacebar
- Two 1U keys for input method mode control
- Nearly identical the Macway TP-110JIS
ANSI
- 5.5U spacebar
- Uncommon but available
- Not a particularly strong preference. Westerners seem to like long space bars, but I think 4.5U is more than enough, and I am not going out of my way to build with a 5.5U space bar.
- Build 3 adds a 1U Option key to make a 4.5U space bar fit
- Similar to Sun Type 5/6/7 "UNIX Keyboards"
Builds
All Command Classic keyboards in existence to date are handmade one-off prototypes. Designing or commissioning standardized parts for on-demand reproduction is a future goal, but in the meantime, I have been throwing some together so that I may have something to use until such time, and in order to test combinations of parts and materials.
# | Date | Form Factor | Keymap | Opt Size | Language Keys | Connection | Plate | Switch | Key Material | Key Profile | Case |
---|---|---|---|---|---|---|---|---|---|---|---|
1 | 2020.07-08 | Full-Size | JIS | 1.5U | 1U Hankaku/Zenkaku | USB C | Stainless | Kailh BOX White | PBT | Cherry | Acrylic Sandwich |
2 | 2022.01 | Compact | JIS | 1.25U | 1.25U Eisuu+Kana | USB A (cable) | Aluminum | Kailh BOX Jade | PBT | Cherry | Poker |
3 | 2022.07 | Compact | ANSI | 1.5U | - | Bluetooth | Stainless | Kailh BOX Silent Brown | PBT | XDA | Poker |
4J | 2023.?? | Compact | JIS | 1.5U | 1U Hankaku/Zenkaku Fn layer on split space bar |
USB C | Stainless | Kailh BOX White | PBT | Cherry | TOFU60 2.0 (Top Mount) |
4K | 2023.?? | Compact | ANSI(K) | 1.5U | 1.25U Hanja+Hangul | USB C | Stainless | dangkeebs Cookies n' Cream | PBT | Cherry | TOFU60 2.0 (Top Mount) |
Compromises
- (JIS only) No 英数 key left of spacebar
- 3.5U spacebars unavailable. Would need to be custom made
- Use slightly more common 4.5U spacebar
- IBM style number pad operator keys
- Mac-style operators would require custom keycaps
- IBM style operator keys are not particularly objectionable
National Variants
Design Goals
- Large Command and Option keys for people who use them often
- Not minimalist
- Dedicated arrow keys
- Incidentally smaller than 101/104 keyboards, but compactness itself is not a goal
- No IBM-style navigation cluster
- Arrow keys can go on the bottom row as on many Apple keyboards
- Home/End/PageUp/PageDown on Fn layer of arrow keys
- Has a numeric keypad
- No Num Lock (no modes!). Always numbers
Problems with existing PCBs
Reasons why the Tsundoku Keyboard must be designed from scratch.
- No JIS Right Shift support
- Layouts all referenced from AT101/Windows 104
- 75%, 60%, etc... all expressed as reductions of AT101
- No consideration for different combinations of elements. Tenkeyless? 75% 60%? What about a tenkey but no IBM nav cluster?