April 24, 2021
去年十月，我把博客从Wordpress搬到了Blot这个服务上。和笨重的Wordpress相比，Blot的轻盈让我如沐春风：我的所有文章和插图就存在本地的几个文件夹里，通过Dropbox同步，修改本地文章，网站即刻更新；新建一篇草稿，它就自动生成一份HTML以供预览；发布文章也只需简单地移动文件。
后来，好朋友Alex帮我把网站重写并转移到了静态网页托管服务上。我拥有了更大的自主权，但也不得不面对构成整个网站的代码文件，好似揭开机器外壳，望着哧哧咬合的齿轮和盘根错节的电线。我感到十分不安，缺乏相关的技术知识让我有种失控感。
从笨重的Wordpress，到轻盈的Blot，再到自由的自建博客，它们似乎越来越难用，在某种程度上却又越来越「返璞归真」。这让我回到一直在思考的数位产品设计哲学，想要进一步考察行业里被奉为圭臬的现代主义美学——「简约」（simplicity）。
到底什么是简约？对于这个问题，或许很难有确凿的答案。因此，我并不打算直接回答，而是通过辨析与「简约」有关的三对概念，借语义区分呈现「简约」一词背后的复杂性。由于篇幅过长，文章分为上下两篇，上篇探讨「简约」和「容易」以及「复杂」和「繁杂」之间的关系，而下篇则分析「简约」与「简化」。
虽然在日常语境中，simplicity更常被译为「简单」，但我选择将其译为「简约」，因为前者中所含的「轻松」、「容易」之意正是下文中想要加以区分的。
虽然极简主义几乎是苹果美学的代名词，乔布斯也常谈自家产品 「super easy to use」，但简约和容易却并不能简单划等号。
在一次题为「化简为易」的演讲上，编程语言Clojure的作者Rich Hickey提出了「Simple != Easy」的观点。他认为许多工程师把「简约」误当作「容易」，解决问题时选择那些最熟悉、最趁手的方法，实际上却让整个系统更复杂了。
对此，Dereck Sivers在播客里也举了个建博客的例子：是选择用一道命令行把庞大的Wordpress下载安装到电脑上，还是自己手工写一个纯HTML的网页？虽然后者并不容易，但从本质上来说比前者更简约。他坚定地支持后者。
可是话说回来，不必学习代码就能建一个自己的赛博空间，Wordpress难道不是确实对使用者更友好吗？「Super easy to use」和这些工程师们所提倡的「简约」，区别究竟在哪里？
在技术哲学家Albert Borgmann提出的「装置范式」（Device Paradigm）中，一个装置由「商品前台」和「机械后台」组成。
商品前台指的是装置呈现出一副人畜无害的外表，它无障碍、无负担，容易上手，容易使用，即时满足，无处不在；它也与具体情境无关，随时享用，随时弃置，即用即走，无痛免责。机械后台则是那隐藏在背后的复杂技术，它沉默无言，不为人知。智能手机就是一个很好的例子：我们天天用它，时时用它，却对其中浓缩的尖端技术一无所知。
从个人电脑普及的历史中即可一窥前后台的分离。一开始电脑只是技术弄潮儿的玩物，极客们通过诘屈聱牙的命令行指挥电脑。直到 1984 年，苹果的Macintosh带来了革命性的图形用户界面（Graphical User Interface）[1]，我们才得以摆脱晦涩的命令行，代之以「文件夹」、「废纸篓」，计算机商品化，开始走入寻常人家。对普罗大众而言，技术民主化也是技术后台逐渐隐身的过程。这个过程既是一种恩典，又是一种诅咒。
好处自不必多言，我们无需理会背后的运算过程，也能用上各种「黑科技」。而坏处也恰恰在于其「黑」，当技术变成一个无法理解的黑箱，我们也将自己敞露于无数风险之下：计算失误、人为的滥用、程序内隐的价值判断……而系统越是复杂，出差错的几率也越大，无怪计算机科学家Edsger W. Dijkstra说：「简约乃稳定之前提。」[2]
前后台的区分演化出了两种角色，使用者（user）和技术人员（technician）。
上文中，Hickey是作为技术人员，聚焦在后台讨论何为简约[3]；而Sivers则混淆了两者的诉求，作为一个懂技术的人去评论建博客所采取的技术是否简约，却忽略了对一个希望在网上发表文章的人来说，到底什么才是简约的。
对使用者来说，简约可以粗略地等同于容易。简约的界面、符合直觉的操作方式，意味着更低的认知成本、缓和的学习曲线，用不了多久就能上手，不明白原理也能利用技术解决问题。这是大多数人嚷嚷着「简单一点！」时的诉求，是「super easy to use」。
但显而易见，一件产品容易使用并不代表它容易制作。在《创意竞择》一书中，前苹果工程师Ken Kocienda揭秘了初代iPhone的开发过程，我们得以见到今日大家习以为常的触控屏是熔铸了多少天才设计师与工程师的心血才变得如此「简单易用」。因此对于技术设计者来说，简约并非容易——与此相反，追求简约往往需要去克服那些难的事情。
接着我们来看简约的反面——「复杂」，区分一下complex和complicated。在日常的使用中，complex和complicated的意思基本相同，都是「复杂的」，但若仔细想想，两者仍有些微妙的不同。
Complicated可以理解为其动词complicate的形容词态，而complicate的意思是「使……复杂化」，这其中蕴含的一层意思是把「原本不复杂的东西」复杂化，即「这事儿本没有必要这么复杂」。所以在此把complicated译作「繁杂」，以「繁」来意喻比事物原本状态更「多」。
与此相对的，complex则表示事物中多个组成部分互相纠缠的状态。其后缀「-plex」来源于拉丁语plectere的过去时态，意为「编织，使交缠」，从complex一词的其他释义「建筑群」、「情结」中也可见一斑。
这样看来，我们想要避免的不是复杂，而是那些人为地把事情搞得复杂的「繁杂」。用户体验之父Don Norman在《与复杂共处》中写道，复杂是万事万物的客观状态，而「简约」不过是人们头脑中的认知感受。设计师的任务不是减少复杂，而是通过建立容易理解和学习的「概念模型」（conceptual model）来帮助人们减少「感受到的复杂」。
Norman的看法意味着，越是复杂的事物，设计师就要越努力地「驯服」复杂。
无独有偶，前苹果副总裁、人机交互先驱Larry Tesler提出过一个「复杂守恒定律」[4]。他说，一个系统内的复杂度是恒定的，复杂只会在系统内部转移，不会减少。当我们想要让前台的操作更简单，后台的技术就得更能干，使用者和技术人员总有一方要面对复杂。
可是，我们今天使用的电脑要比八十年代的电脑精巧多了，系统内的复杂度不变，整个系统是怎么变得越来越庞大的？
可用性专家Bruce Tognazzini（简称Tog）有个「通勤定律」：通勤的时间是固定的，通勤距离才是变量。原来Tog观察到，人们在意的仅仅是通勤时间长短，当交通变得更加便捷时，人们就会选择搬到更远的地方。他想用这条定律说明无论技术设计者们如何简化技术前台，人总会试图维持他所能处理的复杂度；一项任务变得简单了，人们就会开始挑战更复杂的任务[5]。
综合这两条定律，我们便可以得出推论：由于使用者总是倾向于保持同样水平的复杂度，而技术人员又总是尽全力减少暴露出来的复杂，可以想见随着时间推移，工程师和设计师们的任务只会越来越困难。
那么，技术人员是如何面对日益复杂的技术后台的？
Rich Hickey和《软件设计哲学》的作者John Ousterhout不约而同地提出了相同的准则：抽象（Abstraction）和封装（Encapsulation）。抽象是一种在编程中广泛存在的思想，而封装则是它的具体实现方式。抽象指的是将代码的实现和使用分离，怎么做呢，把实现的逻辑和过程那些复杂的东西统统装进黑箱里隐藏起来——封装。
举个简单的例子，这就好像在Excel里面调用计算平均数的函数，虽然我们都知道算平均数的公式是什么，但即使不知道，也不妨碍我们用它。我们只需要知道，圈定几个数字，这个函数就会帮我们得出结果。这样一来，工程师只需要通过看注释、文档，就能使用另外一个工程师写好的代码模块，不必深究背后是怎么做到的。
听起来是不是非常熟悉？没错，这个时候，使用模块的工程师成了前台的使用者，撰写这个模块及其使用说明的工程师则成了后台的技术人员。在计算机导论课上，教授不断地重复说「你不需要知道它是怎么实现的，你只需要知道怎么用它」。不得不令人感叹，即使是技术人员自身，在技术内部也被层层遮蔽着。
（未完待续）