GUI 应用为何必须全面支持键盘操作
GUIs should be fully keyboard-driven
上周 Hacker News 上关于停止开发 TUI 的讨论引发了热烈争论。作为重度终端用户，我理解 TUI 的魅力，但反对将“键盘驱动”作为 TUI 优于 GUI 的理由。事实上，GUI 完全有能力像 TUI 一样实现全键盘导航，甚至做得更好。GNOME 的人机交互指南也明确指出，所有操作都应能通过键盘完成。在我开发首款 GUI 应用 Klisi 时，特意实现了覆盖全功能的快捷键，这极大提升了用户体验。键盘导航并非技术难题，而是开发者意愿的体现。我们不应在用户体验上妥协，而应致力于让应用更加直观易用。
键盘导航在大多数情况下并不难实现，却能带来整体更好的用户体验。
HN 评论区
326- rootedbox
我在公司经常处理 ADA 相关的工作。请戴上耳机，打开操作系统的语音助手，再戴上眼罩，然后运行你的应用或网站……不用鼠标，只用键盘。
1. 民主关乎可访问性；请确保每个人都能使用你的软件。
2. 键盘能让残障人士和高级用户在你的网站/应用中如鱼得水……话虽如此……一旦标签页失效，残障人士就会撞墙。
- cosmic_cheese
键盘可访问性是那种容易被扫到地毯下，或者连同整体可访问性一起被彻底遗忘的事情。有趣的是，前者通常就是后者的一部分。
部分责任要归咎于流行的 UI 框架（或者对于那些选择避开这些框架的人来说，是做出该选择的开发者）。旧框架在这方面通常做得相当容易；例如在 Cocoa/AppKit（Mac 原生 UI 框架）中，你可以相当轻松地通过可视化方式将整个 UI 配置为正确的键盘导航（主要就是在控件之间连接 nextKeyView 出口，以生成一个用于 Tab 聚焦的逻辑链）。定义快捷键也很简单：为命令添加一个菜单项并设置对应的快捷键（这反过来允许用户在系统设置中随意重新绑定快捷键）。
不幸的是，这种设计在新框架中已不再流行。新的首选风格似乎是一个线框图，由开发者决定填充哪些部分，而且往往只有最基本的功能能入选。
- lunar_rover
可悲的是，即使是那些支持键盘导航的界面，其实现也往往很差。Microsoft Office 大概是这方面的黄金标准，几乎一切都可以用助记符导航，所有按键都会被缓冲，用户很少需要超过 5 次按键就能到达任何地方。
- manlymuppet
高级用户体验并不等同于普通用户体验。如果你想论证所有开发者工具都应由键盘驱动，好吧，随你便。但大多数人不愿意应对键盘驱动 GUI 的学习曲线，这没问题。我们不应该强加于人。
HN 坚持表现得好像所有用户都是追求极致效率的 Arch Linux 黑客类型，这实在令人尴尬。
（这段话读起来比我本意要严厉。抱歉。我喜欢 Arch Linux 的用户。我只是觉得，服务普通大众和为高级用户打造完美工具同样值得尊敬。）
- YmiYugy
不过，GUI 由键盘驱动到底意味着什么？
显而易见的方式是为每个操作分配一个快捷键。
我的反驳是，那其实并不是真正的键盘驱动，而仅仅是键盘兼容。这里存在可发现性的问题。目前的最佳实践似乎是在工具提示、菜单项中显示快捷键，或者在按下其他快捷键时显示。
我认为按钮与键盘存在根本性的不匹配。真正的键盘驱动 UI 不应该有按钮。
问题在于，真正由键盘驱动的 UI（如 CLI 或 TUI）的可发现性极差，而这正是鼠标驱动 UI 存在的首要原因。那么，我们能否拥有一种像鼠标点击一样直观的键盘驱动 UI 呢？
- a-dub
上次我构建 CRUD 应用时（哦，大概是 24 年前），我特意做了这一点。我记得看着薪酬部门的人们在终端模式的 VAX VMS 应用中飞速操作，其速度和灵巧度让任何精通命令行艺术的 Unix 管理员都脸红，这让我想到：“哦对了，90 年代所有这些点击式 GUI 都搞错了。如果人们在工作中需要重度使用某个系统，他们会更倾向于先经历学习曲线，然后获得速度、舒适度和灵巧度，而不是选择一条更容易的学习曲线，却用灵巧度换取可发现性。”
那是一个 Web 应用框架，但……所有浏览/列表页面都包含行 ID 和一个聚焦的文本框——这样输入行 ID 并按回车就能选中。所有操作按钮都有下划线，表示哪个 Ctrl-Shift 热键会触发它们。所有编辑页面默认将焦点放在第一个可编辑文本框上，整个过程完全不需要鼠标。最后，加载时间被优化以瞄准 75 毫秒。
有趣的是，用户反馈是：“键盘控制挺好的，但能不能再快一点。”
我原本以为 Chrome 只是个锦上添花，结果它对用户不感到痛苦至关重要。
- marklar423
我同意，但我认为仅能用键盘操作还不够，因为快捷键往往难以发现和记忆。我认为理想的状态是——就像优秀的 TUI 一样——GUI 应该在屏幕上提供明显的提示，说明如何通过键盘导航。
如果有一些针对常见平台（包括 Web！）的 GUI 框架，专门为此设计，并对常见操作的常见快捷键持有一些观点，从而让我们能统一标准，那就太好了。
- minimeow
作者的观点非常精彩。有太多糟糕的终端 UI 仅仅是为了有个 TUI 而创建。这些往往构建不佳，或缺乏足够的思考，无法发挥效用或提升生产力。
但 GUI 应用的更广泛趋势是追求市场份额，而非为键盘用户提供生产力。回到 80 年代和 90 年代，Photoshop、Illustrator 等之所以成为如今的行业巨头，是因为它们专注于让专业人士通过强大的键盘快捷键阵列实现极高的效率。到了 2026 年，当软件公司因“KPI 病”而奄奄一息，用创建吸引人的订阅模式来钩住客户来考核其产品管理时，关注实际为键盘用户提供生产力往往成了事后补救。移动应用没有键盘快捷键，桌面应用似乎正越来越多地被当作只有几亿目标用户（相对于移动设备上的数十亿用户）的狭窄“边缘情况”。对于那些认真致力于通过利用键盘快捷键的力量来交付价值，使其 GUI 高度生产力化并全面支持键盘操作的人来说，这是一个机会。尽管微软存在诸多缺点，但他们在 VSCode 上做到了这一点。
- eviks
> 事实上，许多 GUI 框架的应用指南明确鼓励 GUI 应用开发者
相反，它们应该被设计成允许用户以（至少）框架一致的方式绕过这些开发者，因为他们永远不可能集体变得“精通键盘”。
- charles_f
完全同意，但我认为这主要是“极客”的事。我在个人 Linux 上使用 i3，在工作 Mac 上使用 aerospace；浏览器里用 vimium，其他应用里用 Neru（功能类似 Neru）。我最近找到了一种为 Electron 应用创建用户脚本的方法，从那以后，我在任何地方都添加类 vimium 的扩展（比如在 Teams 里）。
我希望这能成为默认设置，同时也希望有一个更标准的 UI 导航方式。这就是为什么我真的很喜欢 vimium 和其他类似扩展，它遵循 vi 的逻辑跨网站导航，而不是让我去学每个人对如何导航的想法。