papers/keymaps: add notation surface as a structural section

+76 -4

2 changed files

expand all

papers

arxiv-keymaps

keymaps.tex

references.bib

+21 -4

papers/arxiv-keymaps/keymaps.tex

··· 147 147 148 148 I will call the category \emph{social software}, deliberately punning on Shirky's 2003 term~\citep{shirky2003etech,allen2004socialsoftware}. Where Shirky and his contemporaries used ``social software'' to designate \emph{software that mediates social interaction} --- forums, wikis, chat systems --- I use it to designate \emph{software whose existence \textbf{is} social agreement}. A keymap has no compiler, no runtime, no maintainer organization, and rarely a financial mechanism behind it. It exists because enough people decided to act as if it does. It persists because users demand cross-binary compatibility with it. When that compatibility breaks, users notice; when it is preserved, the keymap propagates further. 149 149 150 - The paper proceeds in five movements. \textsection\ref{sec:category} states the category problem: keymaps are software-shaped but not software, and the open-source/proprietary axis cannot see them. \textsection\ref{sec:lineage1}--\ref{sec:lineage2} trace two lineages of keymap invention --- the typewriter-to-computer lineage (Sholes, Dvorak, Colemak) and the musical-instrument lineage (Janko, Wicki--Hayden, the modern hex-isomorphic controllers). \textsection\ref{sec:daw} examines the dominant contemporary case: the chromatic-staircase QWERTY-piano keymap that Ableton, Logic, GarageBand, and FL Studio all ship by default --- an unowned convention that nobody designed, nobody maintains, and everybody implements. \textsection\ref{sec:notepat} reads \texttt{notepat}'s ``notes that name themselves'' keymap as a deliberate intervention against that incumbent: not an inheritance, not a fork, but a competing proposal for what the table should look like. \textsection\ref{sec:corollaries} catalogs the broader genus, showing that input mappings, notation systems, and category labels share a common social-software pattern. \textsection\ref{sec:lialina} reads the body of evidence through Lialina's \emph{Turing Complete User}, arguing that keymaps are the empirical body of her claim that users are programmers in waiting. \textsection\ref{sec:design} closes with what this asks of designers: ship the keymap as a first-class object --- readable, exportable, forkable. 150 + The paper proceeds in seven movements. \textsection\ref{sec:category} states the category problem: keymaps are software-shaped but not software, and the open-source/proprietary axis cannot see them. \textsection\ref{sec:lineage1}--\ref{sec:lineage2} trace two lineages of keymap invention --- the typewriter-to-computer lineage (Sholes, Dvorak, Colemak) and the musical-instrument lineage (Janko, Wicki--Hayden, the modern hex-isomorphic controllers). \textsection\ref{sec:daw} examines the dominant contemporary case: the chromatic-staircase QWERTY-piano keymap that Ableton, Logic, GarageBand, and FL Studio all ship by default --- an unowned convention that nobody designed, nobody maintains, and everybody implements. \textsection\ref{sec:notepat} reads \texttt{notepat}'s ``notes that name themselves'' keymap as a deliberate intervention against that incumbent: not an inheritance, not a fork, but a competing proposal for what the table should look like. \textsection\ref{sec:notation} introduces the notation surface: every keymap has a textual form in which usage of the keymap travels, and the notation is often the more durable half of the artifact --- a structural claim with Vim as the canonical positive case and the DAW chromatic-staircase as the negative one. \textsection\ref{sec:corollaries} catalogs the broader genus, showing that input mappings, notation systems, and category labels share a common social-software pattern. \textsection\ref{sec:lialina} reads the body of evidence through Lialina's \emph{Turing Complete User}, arguing that keymaps are the empirical body of her claim that users are programmers in waiting. \textsection\ref{sec:design} closes with what this asks of designers: ship the keymap as a first-class object --- readable, exportable, forkable --- and the notation alongside it. 151 151 152 152 \section{The Category Problem} 153 153 \label{sec:category} ··· 198 198 199 199 This is the move the paper is asking the reader to see. The dominant DAW chromatic-staircase keymap was never \emph{chosen} --- it was \emph{inherited} from tracker software, persisted by user expectation, and locked in by cross-application convention. \texttt{notepat} demonstrates that the gap is open: that a deliberately-designed alternative can be authored by a single developer in a few hundred lines of code, shipped across multiple implementations in a year, and offered to a wider community as a competing social-software contract. The political stake is small in any one instance and large in aggregate: \emph{the gap is open everywhere}. 200 200 201 + \section{Notation: The Discursive Surface} 202 + \label{sec:notation} 203 + 204 + The argument so far has treated the keymap as a table. But a keymap is not only a table. It also has a \emph{notation} --- a textual form in which usage of the keymap is read, written, taught, cited, and argued over. The notation is the discursive surface of the keymap. It is also, I will argue, the half of the keymap that actually travels. A keymap whose notation is portable propagates as text; a keymap whose notation is awkward or absent propagates only as muscle memory. The quality of the notation is therefore a designable property of the keymap, not a derivative artifact. A designer who ships only the binding-table has shipped half of the object. 205 + 206 + The canonical case is Vim. Vim's underlying keymap is a table mapping keystrokes to editor commands: \texttt{d} initiates a delete operator, \texttt{i} an inner text-object, \texttt{w} a word motion. What travels in Vim discourse, however, is not the table. What travels is a \emph{notation}: \texttt{dd}, \texttt{ciw}, \texttt{gg}, \texttt{:wq}, \texttt{<C-w>}. Tutorials, blog posts, README files, vimtutor, and the long-running vim-vs-emacs argument are all conducted in this notation. The notation is so portable that it survives outside Vim entirely: \emph{vim mode} appears in Visual Studio Code, in JupyterLab, in shells via \texttt{set -o vi}, in macOS Cocoa text fields, in browsers via Vimium. What is being ported is the notation. The runtime is contingent. 207 + 208 + The DAW chromatic-staircase is the negative case. There is no portable notation for it. Writing a melody played on Ableton's musical typing requires falling back to event-sequence prose --- ``press \texttt{A}, then \texttt{S}, then \texttt{D}'' --- which describes input rather than music. Compare to Singmaster cube notation~\citep{singmaster1981notes}, where \texttt{R U R' U' R U2 R'} lets a Rubik's-cube algorithm travel intact between cubers; or to the Nashville Number System~\citep{matthews1984nashville,williams1988nashville}, where ``1--4--5'' lets a chord progression travel between session musicians; or to Plover steno theory~\citep{knight2010plover}, where the chord notation lets stenographic patterns travel through a community-edited dictionary. The DAW staircase has no such handle. Its keys are addressable only by their physical position. The keymap therefore exists in muscle memory and rarely on the page --- which is exactly why it has lower discursive presence than Vim despite an arguably larger user base. 209 + 210 + \texttt{notepat}'s ``notes-name-themselves'' design has, as a structural side-effect, a notation that costs nothing to learn. To write a notepat sequence, one writes \texttt{C D E F G A B} --- which is also standard music notation. The notation is not invented for \texttt{notepat}; it is \emph{inherited} from an existing literacy. A pianist who has never seen a notepat keymap can read a notepat score; conversely, a notepat performer who learns the keymap is also rehearsing standard pitch-letter literacy. This is what a well-designed notation surface looks like: the notation is so trivially derivable from prior knowledge that learning the notation costs nothing. Ableton's chromatic-staircase, in contrast, would require a notepat-like score to be re-coded as \texttt{A S D F G H J} --- a private notation tethered to one keymap, useful nowhere else. 211 + 212 + The empirical literature on keyboard shortcut adoption supports this reading. Peres et al.\ found that working alongside other shortcut users is a stronger predictor of shortcut use than computer experience alone~\citep{peres2004shortcut}. Lozhkina et al.\ extend the result: the discovery channel for shortcuts is interpersonal and visual~\citep{lozhkina2025discovery}. Wang et al.\ explicitly use the term \emph{vocabulary} to name what shortcut design hands a user~\citep{wang2020keymap}. The argument of this paper sharpens those findings: the social mediation is not a generic effect of being-around-other-users; it is a specific transmission via the notation surface. Colleagues read each other's screens, see \texttt{:wq}, ask, learn. Where there is no transmissible notation, there is no social mediation to mediate. The same logic explains the success of live-coding mini-notations like Strudel~\citep{roos2023strudel} and ABC notation~\citep{walshaw_abc}: the runtime is contingent; the notation carries the practice. 213 + 214 + The corollary catalog of \textsection\ref{sec:corollaries} is, when read through this lens, almost entirely a catalog of notations. Singmaster, Nashville, ABC, IPA, Camelot, fighting-game numpad notation, scientific pitch, the NATO spelling alphabet, knitting abbreviations --- each is a notation derived from a keymap (or input mapping) that allowed the underlying practice to travel as text. The keymap-notation pair is the unit. The keymap supplies the affordance; the notation supplies the propagation surface. 215 + 201 216 \section{The Corollary Catalog} 202 217 \label{sec:corollaries} 203 218 ··· 252 267 253 268 The corollary catalog of \textsection\ref{sec:corollaries} sharpens the point. Each entry in Table~\ref{tab:corollaries} is a surface on which a user community has authored a small declarative table that the underlying technology did not require. The Western scale does not require ABC notation; the QWERTY keyboard does not require Plover steno theory; the Rubik's cube does not require Singmaster notation; the chromatic 12-tone equal-tempered scale does not require notepat's ``names-themselves'' keymap. Each is a piece of user-authored convention that survives and propagates because a community decided it should. 254 269 255 - The political stake of \emph{Turing Complete User} is the preservation of these surfaces. The contribution of this paper is to give the surfaces a name --- \emph{social software} --- and to demonstrate, by enumeration, that the category is large enough to be politically consequential. The disappearance of any one keymap is small. The disappearance of the entire user-authorable layer is the disappearance of Lialina's user. 270 + The political stake of \emph{Turing Complete User} is the preservation of these surfaces. The contribution of this paper is to give the surfaces a name --- \emph{social software} --- and to demonstrate, by enumeration, that the category is large enough to be politically consequential. The argument of \textsection\ref{sec:notation} sharpens the political claim: where the keymap has a portable notation, the user's authorship is legible to other users; where it has none, the keymap dies in muscle memory and the social-software contract becomes invisible even to the people upholding it. The disappearance of any one keymap is small. The disappearance of the entire user-authorable layer is the disappearance of Lialina's user. The disappearance of the \emph{notation surface} is the disappearance of the user's voice, in addition to the user's hand. 256 271 257 272 \section{What This Asks of Designers} 258 273 \label{sec:design} 259 274 260 275 If the argument of \textsection\ref{sec:lialina} is right --- if keymaps are the empirical body of the Turing Complete User --- then a small, concrete request follows for designers of any system that consumes a keymap. \textbf{Ship the keymap as a first-class object.} Make it readable: print the table somewhere a user can see it. Make it exportable: let a user save the table to a file. Make it forkable: let a user load a different table. Make the format documented: prefer a plain-text table to an opaque binary. Prefer a published convention to a private one. Prefer a community-shared keymap to a vendor-only one. 276 + 277 + \textbf{And ship the notation as a first-class object too} (\textsection\ref{sec:notation}). The keymap is half the artifact; the notation is the other half. A keymap whose notation is awkward, untranscribable, or invented from scratch will sit dormant in muscle memory. A keymap whose notation is terse, typographic, and derivable from existing community literacy will travel as text, propagate through tutorials, and survive its current runtime. The two design questions are inseparable: when you choose a binding, you are also choosing how that binding will be written about, taught, and ported. 261 278 262 279 \texttt{notepat} ships its keymap as Figure~\ref{fig:notepat-keymap} --- a one-page diagram, freely reproducible, present in every implementation. The DAW chromatic-staircase ships its keymap as a tutorial buried in a manual, identical across applications by accident, owned by no one and contestable by no one. The difference is not technical. The difference is whether the social-software contract is treated as an explicit object or an implicit one. 263 280 264 281 \section{Conclusion} 265 282 266 - A keymap is a small declarative table. It is not a binary. It is not a service. It is not a project. The standard frames of computing scholarship cannot see it. And yet keymaps are versioned, named, forked, and demanded across applications --- they are software in every sense that matters. I have argued that they constitute a category, called the category \emph{social software}, traced two lineages that produced it, examined the dominant contemporary case (the DAW chromatic-staircase) and a deliberate intervention against it (\texttt{notepat}'s notes-that-name-themselves), enumerated a broader catalog of corollaries, and read the body of evidence through Lialina's \emph{Turing Complete User} as evidence for her claim that users are programmers in waiting. The disappearance of any single keymap is small. The disappearance of the entire user-authorable layer is the political problem Lialina names. 283 + A keymap is a small declarative table. It is not a binary. It is not a service. It is not a project. The standard frames of computing scholarship cannot see it. And yet keymaps are versioned, named, forked, and demanded across applications --- they are software in every sense that matters. I have argued that they constitute a category, called the category \emph{social software}, traced two lineages that produced it, examined the dominant contemporary case (the DAW chromatic-staircase) and a deliberate intervention against it (\texttt{notepat}'s notes-that-name-themselves), shown that each keymap has a \emph{notation surface} that is often the half of the artifact that actually travels, enumerated a broader catalog of corollaries that are themselves predominantly notations, and read the body of evidence through Lialina's \emph{Turing Complete User} as evidence for her claim that users are programmers in waiting. The disappearance of any single keymap is small. The disappearance of the entire user-authorable layer is the political problem Lialina names. 267 284 268 - The methodological contribution is a unit of analysis: the keymap as the first-class object of computing scholarship that the binary, the project, the platform, and the format together cannot resolve. The political contribution is a small request: \emph{ship the keymap as a first-class object}. 285 + The methodological contribution is a unit of analysis: the keymap-and-its-notation as the first-class object of computing scholarship that the binary, the project, the platform, and the format together cannot resolve. The political contribution is a small request: \emph{ship the keymap as a first-class object, and the notation alongside it}. 269 286 270 287 \bibliographystyle{plainnat} 271 288 \bibliography{references}

+55

papers/arxiv-keymaps/references.bib

··· 460 460 note = {\url{https://aesthetic.computer}}, 461 461 } 462 462 463 + % --- SHORTCUT VOCABULARY / SOCIAL-FACTOR HCI LITERATURE --- 464 + 465 + @article{peres2004shortcut, 466 + author = {Peres, S. Camille and Tamborello, Franklin P. and Fleetwood, Michael D. and Chung, Phillip and Paige-Smith, Danielle L.}, 467 + title = {Keyboard Shortcut Usage: The Roles of Social Factors and Computer Experience}, 468 + journal = {Proceedings of the Human Factors and Ergonomics Society Annual Meeting}, 469 + volume = {48}, 470 + number = {5}, 471 + pages = {803--807}, 472 + year = {2004}, 473 + publisher = {SAGE}, 474 + doi = {10.1177/154193120404800513}, 475 + note = {Found that working alongside other shortcut users is a stronger predictor of shortcut adoption than computer experience alone --- empirical foundation for the social-software claim about how keymaps actually propagate.}, 476 + } 477 + 478 + @inproceedings{wang2020keymap, 479 + author = {Wang, Yu Shih and Tory, Melanie and Forbes, Angus G.}, 480 + title = {{KeyMap}: Improving Keyboard Shortcut Vocabulary Using Norman's Mapping}, 481 + booktitle = {Proceedings of the 2020 CHI Conference on Human Factors in Computing Systems}, 482 + year = {2020}, 483 + publisher = {ACM}, 484 + doi = {10.1145/3313831.3376483}, 485 + note = {Applies Norman's natural-mapping principle to keyboard shortcut design. Uses ``vocabulary'' as the unit of analysis --- already half-way to the notation argument made in this paper.}, 486 + } 487 + 488 + @inproceedings{lozhkina2025discovery, 489 + author = {Lozhkina, Anastasia and Anslow, Craig and Marquardt, Nicolai}, 490 + title = {The Role of Social Interactions in the Interaction Discovery of Keyboard Shortcuts}, 491 + booktitle = {Proceedings of the 36th Conference on l'Interaction Humain-Machine ({IHM} '25)}, 492 + year = {2025}, 493 + publisher = {ACM}, 494 + doi = {10.1145/3765712.3765714}, 495 + note = {Confirms and extends Peres et al.\ 2004: keyboard shortcut discovery is interpersonal and visual, with the readable form of the shortcut as the unit of transmission.}, 496 + } 497 + 498 + @article{beaudouin2014azerty, 499 + author = {Beaudouin-Lafon, Michel and Mackay, Wendy E. and Andersen, Gilles and Janssen, Christian and Smith, Erica and Karout, Sami and Pillias, Cl{\'e}ment}, 500 + title = {{AZERTY} amélioré: Computational Design on a National Scale}, 501 + journal = {Communications of the ACM}, 502 + volume = {64}, 503 + number = {2}, 504 + pages = {48--58}, 505 + year = {2021}, 506 + doi = {10.1145/3431921}, 507 + note = {Computational + participatory design of the {BÉPO}/{AZERTY}-amélioré French national keyboard standard. Extends the Lineage I cases (David, Liebowitz) into a contemporary federation-crystallization example.}, 508 + } 509 + 510 + @inproceedings{roos2023strudel, 511 + author = {Roos, Felix and McLean, Alex}, 512 + title = {Strudel: Live Coding on the Web}, 513 + booktitle = {International Conference on Live Coding ({ICLC} '23)}, 514 + year = {2023}, 515 + note = {Strudel ports TidalCycles' mini-notation to JavaScript. The notation, not the runtime, is what travels --- a live-coding case of the notation-as-discursive-surface argument.}, 516 + } 517 + 463 518 % --- ADDITIONAL SISTER-PAPER CITATIONS (for future integration) --- 464 519 % 465 520 % arxiv-url-tradition/references.bib:

Configure Feed

Configure Feed