设计与产品brandur.org
从终端学习，设计用户界面的未来
Learning from Terminals to Design the Future of User Interfaces
2017 — 2018，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章从终端界面中提炼设计原则，讨论现代用户界面为何常常变慢、为何过度偏重视觉效果，并主张借鉴终端的即时响应、命令驱动和可组合性来设计未来界面。作者通过终端与图形界面的对比，强调响应速度对使用体验和熟练度培养的重要性。
为什么经久不衰：它把“终端为什么快”转化为可迁移的界面设计原则，并持续引发关于效率、动画、可学习性和专业工具形态的讨论。
HN 评论精选
Slack 的斜杠命令让非技术用户第一次体验到 CLI 范式的效率。
前几天我在 Slack 上看非技术同事聊天时有了种“恍然大悟”的感觉。有人做了个 Slackbot，用来显示当天楼外是哪辆餐车，大家只要输入 /foodtruck 就能用，都特别喜欢。相比打开浏览器、在分散的菜单页面里点来点去，他们可以直接在“控制台”里发一条命令。我意识到，人们喜欢 Slack，是因为它第一次把命令行计算范式带给了他们。只要用户能被激励着投入时间变得熟练，CLI 就高效强大得多，而 Slack 很注重这一点。对我们开发者来说这可能显得低效又傻，但 Slack 靠无数基于命令的集成，在这方面取得了其他东西至今没做到的成功。
aphextron查看英文原文
I had sort of an "aha" moment reading a non-technical co-workers conversation on Slack the other day. Someone built a Slackbot to show the menu for whatever food truck is outside our building that day, and people could use it just by typing "/foodtruck". They were blown away and loved it. Rather than opening a browser and navigating some disparate menu pages, they could simply fire off a command in their "console". I realized that people love Slack because it has introduced them to the CLI paradigm of computing for the first time. CLI is so much more efficient and powerful if users can somehow be incentivized to put in the time and effort to become productive, which Slack has focused on a lot. As inefficient and silly as it may seem to us developers, Slack with it's endless command based integrations has succeed wildly at that where nothing else has so far.
动画对新用户有解释作用，理想方案是随熟练度自适应加速而非一刀切。
动画其实有重要价值，尤其对新用户来说，它们能展示正在发生什么。很多老界面（比如 VT100 模拟器里的）会从一个视图瞬间切到另一个，让人搞不清发生了什么、为什么。即使我有时希望动画更快（比如 Spaces），也很少希望它完全不存在。我经常被人看着操作，有动画时他们会说“你手好快”，而在没有动画的环境里（比如 Emacs），他们只会说“我完全不知道你干了什么”。我希望电脑显得高效，而不是难以接近的魔法。能不能让动画一开始稍慢，用得越多就越快？我们不该给所有用户定一个动画速度，也不该让专家用户手动去调。而且我肯定希望不熟悉的新应用保留完整动画，但用过一千次的老应用就别了。
ken查看英文原文
The animations serve a valuable purpose, though, especially for new users. They show what's happening. Lots of old UIs (like those running in VT100 emulators) had instant wipes from one view to another, but made it impossible to tell what had happened, or why. Even when I wish animation was faster (like with Spaces, sometimes), I rarely wish it didn't exist at all. I often have people watching me, and with animations they say "you're working fast!", while in environments with no animation (like Emacs), it's just "I have no idea what you did". I want computers to seem efficient, not unapproachably magic. What if animations started at a slightly slower speed, and gradually increased in speed the more you used them? We shouldn't need to pick one animation speed for all users, but we also shouldn't make expert users tweak it manually. And I definitely want to see full animations for new applications that I'm not familiar with yet, but not those in old applications which I've seen 1000 times.
UI 是尚未解决的难题，空谈方案不如承认其难度并给出实践。
我几天前在另一个帖子下写过评论，那条评论有点失控，也没我希望的那么清楚。但核心观点很简单，也适用于这篇文章：UI 很难。用户界面看起来很简单，我认识的每个程序员都曾看着某个 UI 想“我一小时就能写出来”，结果花了几周甚至几个月。我认为 UI 是现代计算机科学里一个巨大的未解问题，和我们领域其他未解问题一样难，跟通用人工智能和 P=?NP 一个级别，我不是开玩笑。我们最终会解决 UI 问题，但每天有一千零一篇文章要么抱怨现有 UI，要么告诉所有人解决方案（却没有提供真实具体的新库、框架、代码）。没人愿意承认这东西就是难，我们不该因为还没解决它而自责。换句话说，抱怨容易，展示傲慢容易，提出真正实用的方案很难，或者至少谦逊地承认我们还没有方案。
fpgaminer查看英文原文
I wrote a comment under a different post just a few days ago. My comment got _way_ out of hand and wasn't as articulate as I had hoped. But the salient point I made with it is simple and applies equally well to this article. UI is hard. User interfaces seems really simple. Every programmer I know has looked at a UI and thought to themselves "I can code that in an hour!" and then ended up spending weeks, sometimes _months_ building the UI. I believe UI is a big, unsolved problem in modern computer science. Just as hard as any other unsolved problem in our field. Right up there with general artificial intelligence and P=?NP. I'm not even joking. We will eventually solve the problem of UI. But there are a thousand and one articles posted every day either A) complaining about existing UI or B) telling everyone the solution (without providing real, concrete new libraries, frameworks, code, etc). No one wants to admit that this stuff is just plain hard and we shouldn't beat ourselves up over the fact that we haven't solved it yet. In other words, it's easy to complain. It's easy to display hubris. It's hard to put forth real, practical solutions. Or at least be humble and admit that we _don't_ have the solution.
彭博终端是命令驱动、极速界面在专业领域长期成功的现实例证。
有趣的是还没人提到彭博终端，它基本上就是作者描述的东西。彭博好像很早就“懂了”，在其他公司都转向 Win32、Excel 插件、Web 的时候，他们死死守住键盘驱动的终端式界面。它一点也不性感，看起来像 80 年代大型机上的东西，但对很多人来说很好用。图像，有；字体，有；命令驱动，有；快如闪电，有。由于效率和熟悉度下降，想让交易员等前台人员离开彭博终端几乎不可能。几乎每个“功能”（更接近开发者说的“应用”）都能通过在命令栏输入命令启动，索引得极好、搜索极快。从看新闻、查消息、看 AUDUSD 报价（然后买入），全都不需要鼠标。
srazzaque查看英文原文
It's interesting to me that nobody has yet mentioned the Bloomberg terminal, which is basically what the author is describing. It seems Bloomberg "got this" a while back, and dug their heels on for their keyboard-driven terminal-like UI whilst all other shops were going w32, Excel plugins, Web, etc. It's not sexy by any means, looks like it's from the 80s in a mainframe, but it works well for a lot of people. Images, check. Fonts, check. Command-driven, check. Lightning fast, check. Moving traders and other front-office staff away from BBG terminals is next to impossible due to the drop in efficiency and familiarity. Pretty much every "function" (more similar to what devs might call an "app") can be launched via a command typed into their command bar. And it's incredibly well indexed and fast to search. Everything from reading news, checking messages, seeing a quote for AUDUSD (then subsequently purchasing). No mouse required. Edit: typos
历次讨论
同类还值得读
贝塞尔曲线入门
A Primer on Bézier Curves
Pomax 编写的贝塞尔曲线在线教程，从基础概念一路讲到曲线求交、投影、曲率等进阶内容，并配有可交互的示例和配套的 bezier.js 库。
设计与产品上首页 7 次 · 2014–2022pomax.github.io编辑精选WebGL 水面模拟
WebGL Water
Evan Wallace 制作的 WebGL Water 演示：在浏览器里实时渲染一片水面，展示折射、反射和焦散等 GPU 图形效果。
设计与产品上首页 6 次 · 2011–2025madebyevan.com设计建议：永远不要使用黑色
Design Tip: Never Use Black
设计随笔提出“永远不要用纯黑”的建议，主张在界面和绘画中改用深灰或带色相的暗色，并借阴影与色彩关系来论证。
设计与产品上首页 5 次 · 2012–2021ianstormtaylor.com用于思考不可想象之物的媒介
Media for Thinking the Unthinkable
Bret Victor 的这个页面围绕《Media for Thinking the Unthinkable》展开，探讨我们用来思考和表达复杂问题的媒介，以及以文字/符号为主的传…
设计与产品上首页 5 次 · 2013–2020worrydream.com编辑精选页面重量很重要
Page Weight Matters
博文讲 YouTube 工程师 Chris Zacharias 的一次页面瘦身实验：团队做了一个更轻量的页面版本，起初从整体平均加载时间看反而更慢；按地理区域分层后才发现，轻量版…
设计与产品上首页 4 次 · 2012–2022blog.chriszacharias.com