本文旨在探索快速软件的优势，及其如何影响用户对于工程质量以及整体可用性的感知。

我喜欢速度快的软件，我指的是那种在功能与界面响应方面都很快的软件。具体来讲，在这类软件中，用户的激活或操纵行为与实际生效之间的延迟很短。只有这样，用起来才舒服。

软件速度快，一般意味着开发人员投入了巨大的心力。当然，就像好工具往往比较简单一样，这样的结论并不绝对。在我看来，软件速度可能是软件当中最有价值，但同时又最被低估的指标。作为用户，我认为速度快的软件能够顺利融入我们的生活，而那些速度表现差的应用程序则不然——只要有得选，我们就不想用它。速度快的软件，就像是一本好书——我们会读得津津有味，虽然很难说出具体理由。

我使用频率最高、速度最快的软件之一是nvALT。从这个奇怪的名字就能看出，这是一款非常乏味的功能性应用程序。事实上，这是一套纯文本文件数据库，其中用到纯文本编辑器。但它真的很快，是我用过的速度最快的文本编目软件。无论是打开还是显示结果，整个过程似乎都能瞬间完成。我的nvALT数据库当中包含过去十年来积累的无数工作笔记，就算数据量如此庞大，只要一打开，光标仍能立刻显示在搜索字段当中，供我立刻操作。这也是一款对键盘设备非常友好的软件：如果当前焦点不在搜索字段中，只需按下ESC即可快速切换。键入几个字母，nvALT就能显示带有这些字母的全部笔记。单凭这一点，我就愿意把自己生命当中有价值的一切文本都添加到nvALT当中。

nvALT能够与Simplenote同步。这一点很方便，因为nvALT只有macOS版本。在同步之后，我们就可以使用Simplenote的iOS应用在旅途当中继续查看有价值的内容。当然，Simplenote也拥有自己的macOS版应用。很多朋友可能会问：那为什么不干脆桌面、移动端统一起来？答案很简单，因为Simplenote的mac版本不够快。虽然这里说的只是毫秒级别的差别，但在感受上仍然有着显著区别。这就像是售价1000美元的日本园艺剪，和150美元的普通园艺剪的区别。它们都能很好地完成任务，但如果您整天都要在花圃里工作，那么二者带来的感受还是不可同日而语。

在写作方面，我主要使用Ulysses。事实上，您读到的这篇文章也是使用Ulysses写出来的。Ulysses在组织大规模写作内容时表现出色，这也是我爱用它的主要原因。（在跨多个文件处理大量文本时，组织能力就是一切。我喜欢Ulysses那种类似于普通文件夹，但又能够跟踪所需文件的排序方式。这一点与Scrivner不同，它只会把写作项目变成一套巨大的专有数据库。因此，我使用Ulysses的核心理由（90%）就是实现这种组织能力上的自由。另外5%来自简单的编辑操作，还有5%来自设备间的同步功能。）但是，Ulysses会变慢，而且这种情况经常出现。如果我的文章超过了5000个单词，然后回到开头继续添加内容，就会发现显示速度跟不上我的输入速度。Ulysses在检测到每次键入时都会重新渲染整体文章，这让我抓狂不已。虽然Ulysses出色的组织能力与便捷性有时会让我选择忽视速度上的问题，但这就像是机器内部因为腐烂飘出的隐约异味，终究会给人带来不快的感觉。更重要的是，速度变慢的问题开始影响到我对Ulysses的信心——信心就是这样测试出来的。如果它速度不行，我就会怀疑其同步功能是否也存在问题，或者说它会不会导致数据丢失等等。（Ulysses在Twitter上回应，“是的，macOS中的自适应背景颜色会导致软件在处理较长文章时出现严重的性能下降。我们已经向苹果方面提交了一份错误报告，希望他们在未来的系统更新中进行修复。目前的解决方法是：使用开灯模式、D14之外的主题或者对工作表进行拆分。” ）

速度与可靠性通常直接相关，因为速度能够很好地体现出整体工程质量。如果一款应用程序在处理简单任务时出现拖慢，那可能意味着工程师不是关注细节的强迫症患者。虽然这只是一种初步判断，但确实意味着软件中可能存在其它灾难性的问题。我希望人们能够坚守工匠精神。当然，并不是说Ulysses的工程质量很差，但无法达到预期的输入处理与界面速度，令我逐渐丧失了对它的信心。反过来，更快的速度也能引导用户建立起信心。

再来看另一个角度的例子，根据我的实际体验，Sublime Text就永远不会减速。我可以直接在上面扔一个拥有5万行的文件，完全没有问题。有些朋友可能又要问，为什么不干脆用Subime Text写作（有时候我自己也会考虑）？答案是：在完整的构图方面，它还不够好。Sublime的排版、拼写检查、文件组织（没有关键字、无法组织排序等）并不是没有，只是做得不够精致。Sublime Text主要针对代码内容进行优化，而非自然语言。相反，Ulysses则更关注语言词汇。这种差异很微妙，但却意义深远。换言之，根据我的经验，Sublime Text在发展中只会不断提升速度表现。我喜欢这样的软件：随着时间推移变得越来越好，这也应该成为所有软件的共同目标。历史越悠久，设计越精巧，如同河水冲击过的鹅卵石一样。我完全信任Subime Text工具，而且拥有超过十年的使用经历。它对我来说是一款不断变好、速度很快，而且专注于特定功能的工具（这里只说主观感受，实际上Sublime已经非常复杂且泛用）。

Adobe Lightroom就不是这种快速、专用型工具，Photoshop当然也不是。但在过去的特定历史时期内，它们是这种工具，我也因此而选择了它们。上世纪九十年代那会儿，Photoshop的运行速度非常快——真的，我可以肯定这不是我对那段岁月的美好记忆，而是代码内容呈现出的绝对事实。同样的，我在2007年左右开始接触Lightroom时，它的速度要比苹果Aperture快得多。但多年过去，苹果Aperture早已不见踪影，Lightroom也变得不再敏捷平顺。如今，Lightromm在我脑海中的印象就像一个粗糙的斑点，上面布满暗淡且和缓的纹理。为什么不能做得更快？这可能是个永远解不开的谜团，但我个人怀疑原因是：1）功能膨胀；2）核心工程在功能膨胀的情况下变得无法充分优化。Adobe公司是不是自己也意识到了问题，所以才发布了Lightroom CC？有这个可能。有时候，开发新程序反而比修复旧程序还容易些。

Photoshop现在已经变得臃肿不堪。当初，我们只需要几秒钟就能在Photoshop当中打开新文件对话框，创建新的空白文件同样只需要几秒。但到了2019年，如果大家按下CMD-OPT-SHIFT-W来导出图像，单是加载出操作屏幕就需要3到5秒。（如果不小心按成了cmd-opt-w，还会直接关闭所有窗口。）每一次版本更新，只会让速度越来越慢。正因如此，我才愿意付费使用Affinity Photo，就是为了速度。我仍然在使用付费Creative Cloud许可（主要是使用Lightroom和InDesign），但我乐意为Affinity付钱，因为它真的很快，能迅速导出在网上使用的文件。它的速度，让我每次打开Photoshop时都会叹气，是真的叹气。

有些朋友可能会说，像Sketch这样的设计应用就因为速度快而越来越受欢迎。没错，Sketch在发布之初确实更快、更简单，用户体验设计也要比Adobe提供的产品更集中。虽然Sketch的可靠性有点问题，但我们甚至情愿忽略这一点，因为速度快的软件用着舒服有趣。从这个角度来看，速度其实是一种巨大的商业资产。对于这类我们每天需要大量使用的软件而言，即使是3%的体验提升都是种可观的进步。

除了Sketch与Illustrator之外，Figma也是一款类似的设计工具。虽然基于浏览器，但Figma的速度非常快，快到我使用的时候经常不由自主地笑出声来。它给人的感觉，就是现代计算机应该有的运行效果，这正是人们最想得到的。我了解FIgma背后的工程与设计团队，我也知道这款产品很受欢迎。它给人一种原始而纯粹的感觉，速度不仅仅是速度，速度也代表着直观。以钢笔工具为例，Figma中的工具就比Illustrator中的同类工具更合理，因为前者的起始位置就是要舒服一些。从这种意义上讲，“速度”不仅表现在每一个计算机工作周期当中，同时也表现在每一个用户工作周期当中。

谷歌地图就因为缓慢的运行速度而逐渐失去了人们的支持。谷歌方面在谷歌地图上添加了动画效果，虽然单独来看是一个不错的主意，但却严重拖慢了整体速度。谷歌地图曾经也是一款快速的专注型工具，但它现在变得很迟钝。一旦按错了按钮，接下来用户就会遭受折磨。太过复杂、太多不必要的分层，也许谷歌想做的太多？可能吧，总之要退出某些模式（例如指向模式），用户必须点击四到五个区域并忍受大量速度缓慢的动画效果。

我们之所以还在忍受，是因为谷歌地图是一座关于我们周遭世界的巨大宝库，是一个真正的信息奇迹，也是应用层面的伟大产物。然而，越来越多的信息被埋藏在多种UI变体（例如：如果您点击了东京的某个位置，那么指示该位置的按钮会首先出现在屏幕的右上角——但最终指示位置永远不可能在这里。）以及一套似乎每周都在更新的界面之后。我的直觉告诉我，这更像是一种管理问题而非工程问题，可能是谷歌在管理上出了什么偏差。

谷歌地图慢到这个地步，以至于我做了连一个自己都不敢相信的决定——我在iPhone上重新安装了苹果地图。相比之下，目前的苹果地图仍然速度快、响应及时。虽然数据无法与谷歌地图相提并论，但这已经能充分说明速度在用户体验中的重要意义。我重新安装了一个自己主动删除的应用，就是为了享受苹果地图带来的速度快感。

至于软件速度方面的绝对下限，让我们用热烈的掌声请出——iTunes。耶，如此缓慢、如此笨拙、如此沉重，以至于连苹果自己都决定把它扔进历史的垃圾桶，转而推出一系列独立应用程序。给你点赞，这绝对是最好的解决办法。

但也必须承认，苹果公司开发出不少优秀的软件。Keynote可能是macOS上最好的软件之一，它也是以简单界面成就伟大产品的重要典范。可能上一代版本存在一些简单的问题，但迭代之后，用户能够明显感觉到新版本在模式、功能与简单性之间找到了更好的平衡点——快速且直观。至于我最喜欢的替代工具？Instant Alpha，用着就是个舒心。能够搞定90%的预期用例，属于那种没有任何使用负担的产品。我们不会主动想到它，甚至不会意识到它的存在，但在需要时它总能解决问题。不过一般来说，Keynote很快，使用感受也很好。

但为什么速度慢有这么大的罪过？答案很简单：速度快的软件并不一定就是好软件，但速度慢的软件几乎一定不是好软件。快速软件使用户有可能与工具集“合为一体”，或者说不破坏顺畅的操作流程。程序员们之所以会为了Vi和Emacs谁更好而打得头破血流，正是因为他们非常重视这种流畅性与整体性。他们投入了，工具改进了，他们满意了。不破坏流畅性，是成就伟大工具的必要前提。

打字机就是一种优秀的工具，因为尽管它的速度相对缓慢，但机器本身却能够随用户的心意而快速运行。它的功能非常专一，换行和显示没有丝毫延迟。是的，我们需要在打完一页之后手动将新纸放进机器，但这种操作并不是延迟，而是机器设计的一部分。另外，纸张的累积也成为一种可视化的工作进度指标，而不是单纯在浪费时间。机器使用本身没有机械性延迟，因此最好的软件也应该带来接近打字机的物理直接性。（打字机有可能损失，也需要定期更换色带——但这是维护问题，与工具本身无关。如果能让速度快一点，我非常非常愿意定期“维护”一下Photoshop。）

速度也体现在软件的语言——或者说界面中的文字词汇当中。最近几年，macOS系统中的文件关闭对话框已经把原本的“不保存、取消、保存”更换为“删除、取消、保存”。虽然只是个人看法，但我觉得后一种表述其实并不准确，甚至有点怪怪的。“删除”代表着消除已经保存过的内容。那我到底保存过没有？我是保存过但自己忘记了吗？或者说内容已经自动保存过了？不管怎样，在尝试关闭一个未保存的文件时，我总会看到这个对话框。它减慢了我的处理速度，按下删除键总会给人一种很简单粗暴的感觉。在看到删除之后，我会想着“最好是别删除吧？”我讨厌这种让人纠结的感觉。所以，“不保存”最好，准确直观。

我在自己的iPad上使用iPadOS 13 beta测试版。它提供新的界面组件，速度很快而且使用感受很好。丝滑，我觉得这样的形容非常贴切。只需从右屏滑动，应用程序就会浮动出现。浮动应用相当于大型应用的一个迷你版本，能够在滑动之后快速显示。这种感觉相当令人满意。轻轻移动手指，手指下面就出现一个小小的应用提示。而在向后滑动后，它又立刻消失了，不需要“重绘”屏幕。另外，小应用的底部还有一个操作栏，可以任意滑动查看所有已打开应用。效果本身不仅速度很快，而且环状显示的动画也很漂亮，提示用户之前访问过的应用以及当前所处的应用。这样的动画有着很强的目的性，暗示使用场景的上下文信息，而且很有触觉效果。在我看来，最好的“触控界面”当然是物理按钮，因为它能给人带来真实的反馈。但在屏幕上，最好的触觉就是以无延迟的方式完成操作。

从速度和用户体验的角度来看，我认为这种滑动侧拉设计在iPad上要远远优于分屏。分屏速度很慢，我们需要点击、扫住、拖动，并等待屏幕重绘以将各应用程序摆放在新的位置。分屏模式感觉就像是系统的代码不小心暴露出来了一样。相比之下，滑动侧拉则像是iPad使用环境的自由延伸。它可以快速、可靠地发挥作用，且带来与预期相符的效果。这代表着代码与设备实现了自然同步，且速度与玻璃屏幕背后的硬件配置吻合。分屏方法也不是不行，但可能需要重写基础代码。在理想情况下，分屏也可以像滑动侧拉一样顺畅而快速。还是那句话，应该用1000美元一把的园艺剪修理花圃，不单能起效，还能做得爽。

这样的例子还有很多，但在这里我们再说最后一个——Things。在iPad与iPhone上，Things可以说是触感最好且速度最快的应用之一，其中的每一段动画都有明确目的。更重要的是，它非常有趣。这是一款好玩的应用。我们可以把东西放进去，然后重新排列。没错，Things已经有年头了，它存在了十多年。十年前我喜欢打开它，现在我也仍然喜欢。（我体验过的，唯一能够在触感与设计工艺上与之抗衡的，就是Facebook的Paper，它拥有一种奇特但令人愉快的设计效果。这款软件来自由非凡设计大师Mike Matas牵头的开发团队。）

从直觉角度讲，软件（除核心功能之外）应该以速度为目标。速度就是效率的体现。如果一款软件变得沉重、笨拙，则可能意味着开发商应该把它拆分成多款软件。最终结论——速度快，就是轻松愉悦。这种轻松，在于减轻用户或者特定任务的负担。软件开发的终极目标正在于：帮助我们口袋里的“超级计算机”减轻负担，而非增加负担。笔记本也是一样，软件应该为它实现一种流畅的创作体验，而不是在电池或性能方面压榨不休。

最后我得承认，写一篇关于快速软件的文章很容易，开发快速软件则非常困难。因此对于每一款快速软件，我们都应抱有感激之心。

原文链接：
Fast Software, the Best Software

创作场景

软件江湖快者胜：论运行速度的意义