HN Weekly 中文
← #808

GUI 应该做到完全可键盘驱动

查看原文 HN 讨论

文章摘要

作者 Charalampos Kardaris 写这篇短文，是对此前 HN 上另一篇热帖的回应。那篇帖子主张应用开发者应该停止做终端界面（TUI），转而专注于图形界面（GUI），同样上了 HN 首页并引发激烈争论。

Kardaris 认为双方都有道理。一方面他理解拥 GUI 派的论证：理论上 GUI 框架的能力是 TUI 框架能力的超集，所以应当优先选择 GUI。另一方面，作为一个重度终端用户，他也非常珍视那些让他能「留在终端里」把事情办完的 TUI。

但他要反对的是拥 TUI 一方反复出现的一个论点，也就是「TUI 更好，因为它是键盘驱动的」。他认为这个论点站不住脚。诚然，如果随机挑一个 GUI 和一个 TUI，后者更可能是完全键盘可驱动的；但这并不能成为选择开发 TUI 而非 GUI 的理由，它真正说明的是——大量 GUI 应用的键盘导航做得很烂。

没有任何东西阻止一个 GUI 做到完全键盘驱动，甚至做得比 TUI 更好。事实上很多 GUI 框架的设计指南明确鼓励开发者提供覆盖全部功能的键盘导航支持。他举了 GNOME 人机界面指南（HIG）为例：指南明确写着「正如每个操作都应该能通过指点设备完成，每个操作也都应该能通过键盘完成」，以及「应该能够只用键盘在界面的每一个部分之间移动和交互」。

作为用户，这一点对他很有说服力：能够直觉地、可预测地只用键盘操作一个 GUI，会让他更倾向于选择它而不是替代品。切换到开发者身份时，他也据此要求自己的应用必须对键盘友好——在他的第一个 GUI 应用 Klisi 中，他投入了不少时间为全部可用操作实现了键盘快捷键。

他的结论是：在大多数情况下，键盘导航并不难实现，而且能带来整体更好的用户体验；这不是可行性问题，而是开发者意愿问题。不要在应用的用户体验上妥协，尽可能做到直观，为此不该忽略完整的键盘导航支持。

他在脚注里也留了余地：对某些任务而言，鼠标带来的灵活精度仍然是更优甚至必需的；此外还有比「键盘驱动」更有说服力的支持 TUI 的理由，比如可移植性。

这篇文章拿到了 1054 分和数百条评论，评论区几乎变成了一场关于键盘、鼠标、可访问性和 UI 设计史的大型集体回忆。

HN 评论精华

共识很强，但边界争议不小

bigstrat2003 代表了主流态度：他 100% 同意，鼠标很棒、GUI 不该丢掉它，但在数据录入这类任务里手不离键盘的能力太宝贵了；而且他认为同时为键盘和鼠标做设计，会逼你直面那些只针对单一输入方式时可以糊弄过去的界面粗糙处，最终产品会因此更好。

onion2k 给出了最有力的一击：在 Web 上，键盘可访问是 WCAG 2.1.1 的 A 级要求——也就是最基础的无障碍标准等级（除非你把「不合格」也算一级）。如果你的网站做不到这一点，那你根本没怎么努力。

rootedbox 从事 ADA 合规工作，给出了最具体的建议：戴上耳机、打开系统语音助手、遮住眼睛，然后不用鼠标只用键盘跑一遍你的应用。他说了两点——民主关乎可及性，请确保所有人都能用你的软件；键盘让残障用户和高级用户都能飞速穿行，但只要有一个 tab 顺序错了，残障用户就会一头撞墙。

不过反对意见也相当清晰。adverbly（他自己是 vimium 用户）列了一串例外：别让我用键盘画画、别让我用键盘打游戏、别让我用键盘做 3D 建模，「别推行全局规则，接受多样性」。binary132 的论点更理论化：GUI 的核心优势正是二维坐标输入（指针、手势），而键盘恰恰缺这个能力，所以强制要求整个 GUI 必须可键盘驱动，等于限制了 GUI 的最大优势；他更欣赏 Emacs 或 Plan 9 那种键盘与指针协同的风格。manlymuppet 则直接批评了 HN 的文化偏差：高级用户体验不等于普遍用户体验，大多数人不愿意承担键盘驱动界面的学习曲线，这没什么不对；「HN 总是假装所有用户都是 Arch Linux 效率完美主义黑客，这挺土的」。tracerbulletx 指出如今大多数计算发生在触摸屏上，这个视角太窄了。

真正的难点是「可发现性」，而不是「可能性」

这条线索是评论区里最有价值的部分。YmiYugy 提出了关键区分：给每个操作分配一个快捷键，那不叫键盘驱动（keyboard-driven），那只叫键盘兼容（keyboard-compatible）。他甚至认为按钮本身就与键盘范式根本不匹配，而真正键盘驱动的 CLI/TUI 又饱受可发现性之苦——问题是：我们能否做出一个像鼠标点击一样直观的键盘驱动界面？

SebastianKra 把可选方案列得最全：（1）把所有元素放到网格上以便方向键导航——这对设计师是很大限制；（2）在每个按钮旁直接标出快捷键，放在 tooltip 里是不够的（他点名 Raycast），游戏里常见但占空间；（3）加命令面板，最容易实现，但需要镜像每一个操作，且在「对集合中每一项执行同一操作」的场景里表现不佳。他的结论是：给技术用户请全都上，但给普通用户就没那么清楚了，这里仍有创新空间。

marklar423 主张 GUI 应该像好的 TUI 那样把键盘导航提示直接画在屏幕上，并呼吁有 GUI 框架（包括 Web）在这方面给出标准化的意见。xyzsparetimexyz 举了星际争霸的例子：菜单项直接高亮标出对应字母，而且理想情况下按键应该集中在键盘的一个区域而不是简单取首字母。FranklinMaillot 和 arjie 则力挺命令面板/全局搜索栏——arjie 说他从 JetBrains IDE 认识这个模式，配合 KeyPromoter 插件还能顺带学会快捷键，如今 Cloudflare、Mercury 到处都是。

ModernMech 为微软 Ribbon 说了句公道话：大家骂了它那么多，但它确实做对了一件事——每一个选项都能通过键盘序列到达。orbital-decay 展开了这一点，并指出 TUI 阵营的一个根本问题：每个 TUI 都在重新发明轮子、自定义一套键位方案；而经典 GUI 框架及其指南默认就提供了通用的热键方案和快速遍历路径，你甚至不用去想，只需扩展自己的操作。他还称赞 Ribbon 从 Vimperator 借来了链接导航思路，同时做到了可发现、紧凑、键盘可达和可定制。lunar_rover 认可 Microsoft Office 是键盘导航的黄金标准：几乎一切都能用助记符导航，按键会被缓冲，用户很少需要超过五次按键就能到达任何地方。

「我们曾经拥有过，然后弄丢了」

这是评论区的情绪主线。Timwi 的感受最强烈：在 Windows 3.1 时代，你几乎不可能做出一个不能完全用键盘操作的程序——就算你漏掉了所有菜单热键、搞乱了 tab 顺序，用键盘走完流程仍然是可能的，只是烦人而已；而现在超过一半的软件用非原生 GUI 工具包（或者干脆不用工具包）写成，它们拒绝实现那些过去免费就有的键盘导航。「键盘让计算机使用起来是种享受。看着它消失让我非常难过。看着绝大多数人根本不在乎它的消失，让我感觉自己像个外星人。」

walrus01 说他见到越来越多的 GUI 连用 tab 在输入框和按钮间循环这种最低限度的支持都没有——那是 Windows 3.0 就有的东西。badgersnake 一句话总结：现在什么都是网站，或者是一个假装自己不是网站的、套在 Chrome 引擎里的网站，对键盘导航这类 UI 惯例彻底敌视。cosmic_cheese 从框架层面分析：Cocoa/AppKit 里你可以纯可视化地把整个界面接好键盘导航（连一下 nextKeyView 出口形成焦点链就行），定义快捷键也简单——加个菜单项设个快捷键，用户随后还能在系统设置里自行改键；而新框架流行的是「开发者选择填充线框的哪些部分」，通常只有最基本的部分入选。

eichin 提供了一个有趣的历史注脚：1990 年代初鼠标足够脆弱，以至于 Apollo 的销售人员被训练成能在演示中完全不用鼠标——这不是出于无障碍考虑，而是「我们在向更昂贵的人演示昂贵的系统，它最好别出岔子」。

实际案例与工具

a-dub 的故事很有说服力：24 年前他做 CRUD 应用时，看着工资部门的人在 VAX VMS 终端应用里飞速操作，速度和灵巧程度让任何精通命令行的 Unix 管理员都自愧不如。他由此意识到，如果人们需要在工作中大量使用一个系统，他们宁愿接受一段学习曲线然后换取速度和舒适，也不愿用灵巧度换取可发现性。他的 Web 框架做到了：列表页显示行 ID，输入 ID 加回车即可选中；所有按钮都有下划线标示热键；编辑页默认聚焦第一个可编辑框；全程不需要鼠标；加载时间优化到 75ms 目标。而用户的反馈是「键盘控制不错，但能不能再快点」——他以为是锦上添花的加载速度，才是用户不至于痛苦的关键。

zomiaen 讲了一个反例：他所在公司多年来用的是黑白终端风格的老式 POS 系统，熟练的员工操作速度超过了系统的处理速度；新的花哨 GUI 系统更慢，老员工恨它，但培训新人容易多了。

工具推荐相当密集：Arubis 说留在 Firefox 的原因已经不是浏览器引擎多样性而是 tridactyl；jonbrauninddott、josht、dingdongditchme、chrisXOXO 集体推荐 vimium 或类似的链接提示扩展；keriati1 为常用网页写了一堆 Tampermonkey 脚本，并提醒很多网站（GitHub、Gmail）按 ? 就有快捷键覆盖层；tombket（tombster）推荐 Sway，也为 GNOME Shell 说了好话。

衍生出的两个有意思的角度

crabbone 提出了一个少见但重要的论点：测试自动化。鼠标优先的 GUI 极难自动化，因为你必须计算目标元素的屏幕坐标，而元素位置会随分辨率、滚动条样式等变化；而且事件模型通常是异步的，自动化代码无法可靠判断动作何时完成。能用键盘控制的程序天然更容易被自动化——不只是为了测试。

KronisLV 走得更远：能在 GUI 里做的事，也应该能通过 CLI 做，还应该有代码库可调用；如果 Web 应用有 n 层架构，GUI 软件也该有。他半开玩笑地说：「我们可以撒谎说这是为了支持 AI，实际上是为了有正经的程序化自动化能力，而不是让 GUI 应用变成黑盒。」

jolmg 补充了一个 TUI 独有的优势：终端本身有自己的键盘导航，通过终端快捷键他可以把光标移到任何位置并复制任何文本，哪怕那是 TUI 界面自身的一部分——比如从 vim 状态栏复制文件路径只需五次按键。而图形编辑器把文件路径显示在标签页上，你根本没法复制那段文字。他抱怨说，看到眼前有一段文本却因为开发者没实现复制而必须手打，非常令人沮丧，有时候这甚至像是故意的（他举了 Steam 更新条款弹窗的例子）。

若干金句