这是后 COVID 世界的桌游之夜。你和几个朋友围坐在桌子旁，尝试新游戏。问题是：有很多小纸板令牌和游戏牌，甚至——我甚至不确定……图腾？
你拿起说明书大声宣读，但几分钟后，大家变得坐立不安。所以你想：开始吧，一边玩一边摸索规则。现在，由于你每十秒钟就要回头查看说明书，第一轮游戏进展得特别缓慢，因为你总是找不到上次看到的位置，每次都需要重新定位；等到第二轮结束时，你意识到需要撤销第一轮的行动，因为你做了一个无效的移动，这将会破坏整个游戏；你不断努力记住你「应该做什么」；如果每玩一会儿就需要参考说明书，就很难沉浸体验游戏。
也许我们还不如看一场电影？
书籍存在的一个问题，我在这里和其他地方[1]已经写了很多：我们往往很快就会忘记除了主旨以外的所有内容。而这里，书籍（特别是那些培养技能的书籍）存在另一个问题：这种媒介使得文字与实践之间鸿沟难以逾越。书籍很少涉及实践他们描述的事情。大多数书籍，甚至是旨在培养技能的书籍，都只是关于它们描述的内容。阅读关于桌游的书，而不是玩桌游。阅读关于对位法的书，而不是在作曲中使用对位法*。（*译注：类似于和声，都是一种构建声部的方法）
那又怎样？我在这里不谈正式的学习科学，只诉诸经验。
如果你问别人，他们何时成长最快，你会发现，最赋能的环境往往涉及实践。与队友紧张地为即将到来的比赛做准备的那个夏天；那个失败的，但学到了许多宝贵经验的创业项目；接受的连续一个月每天写首新歌的那个挑战；为期数周的那个冥想静修；令人不知所措的那个学徒期；等等。在这些故事中，书籍有时是知识的来源，但相对于伟大的导师、队友、背景动机等，它们往往是次要的，关键是实践。
可以自然地类比我们的桌游问题：想象一下，你是第一次玩桌游，但有一位老司机带你。这与之前描述的「冷启动」体验完全不同。在这种情况下，有经验的玩家可能会给你一个简短的介绍——没有任何会让你记忆负担过重的内容——然后你们就可以开始玩了。他们会处理好桌游的设置，要么自己动手，要么指导别人洗牌，发牌，等等。他们可能会讲解：「我先来，做个示范。所以我先抽两张牌，然后我可以选择在这里移动或打这张牌。我将在这里移动，这将阻止 John 移动到这个开放区域。现在轮到你了。你的目标是 XYZ，你可能会先这样移动。现在，如果你抽到了行动卡，如果你愿意，你可以立即打出；否则，请阅读卡上的内容......」在整个游戏的过程中，他们可能会继续讲解你需要知道的内容，恰到好处地解释你可能考虑的选项，提供反馈。只要你有经验的朋友有足够的风度，避免进入盛气凌人的 Clippy* 领域，这将是一种更愉快——并且更有效——的学习游戏的方式。
译注：Clippy 最早指代的是微软 Office 助手，它老是一遍一遍地想教你做事。Rust 也有一个叫做 Clippy 的工具，会检查你的代码是否符合一系列规范。笔者写 Rust 的时候 CI 老是被这玩意卡住，非常烦。
这可能是长久以来入门桌游的好方法，但技能培养的书籍有许多实际优势。比如信息密度。如果你想学习为量子计算机编程，你需要吸收大量材料才能自己「玩」。这可能需要有经验的同伴为你作几十个小时的解释，对大多数人来说，这很快就会变得繁重。说明文可能缺乏个性化和人际联系，但它可以被更仔细地打磨；它不知疲倦，只要你准备好了，随时都可以使用；它可以嵌入图像和抽象符号；它可以被非线性地吸收；它读起来比听讲更快；等等。也许最重要的是，它是一种大众媒介。世界上最资深的专家和最敏锐的传播者可以就这一主题精心编写一本书，而数百万人可以将它握在手中，几乎没有任何边际成本。
所以：我们如何创建一种拥有书本优势的大众媒体，但又立足于实践？我们如何才能创造出一种解释性的大众媒介，它感觉更像是和有经验的朋友一起玩桌游，而不是一边玩桌游一边查说明书？
动态媒介的作用
为何难以创造立足于实践的书籍？原因之一在于书籍是静态、一成不变的。你，作为读者，必须将其文字运到你可以「实践」的环境中。即使如此，「实践」的过程与页面上的文字之间也很少有交互的机会。作者可以告诉你如何在练习后反思，并自我产生反馈，但这些都是你必须在自己的头脑中执行的脚本。即便有视频，情况也没多大改观。然而，计算机和它们支持的动态媒介，是能够表现和响应的。[1]
人们常常提出，我们应该利用这一特性来整合用于实践的模拟环境。也许生物课本可以嵌入一个小型模拟培养皿，你可以用它来「实践」某些细胞生物学实验，缩短文字和行动之间的距离。
但对我来说，只要有可能，我更期待计算环境成为真实的——非模拟、非「教育型」的——实践环境时所带来的情景。非线性视频编辑界面不是剪辑电影的「玩具」方法；它就是专业电影人剪辑电影的真实方式。Mathematica 并非操纵符号表达式的「玩具」方法；它是某些数学工作最真切、最适当的方式。所以，一本关于视频编辑的动态「书籍」不必陷入「玩具」式的实践环境，也不需要模拟的培养皿。反而，它可以直接进入那些用于剪辑世界上最好电影的真实环境中。
那么，在一个真实环境中「立足于自身」的解释型媒介到底意味着什么？解释内容应如何与环境内容相互作用呢？
过去十年，作家和程序员们已经创作了许多交互文章，或许能对我们的问题提供启示（有关这方面的详细介绍，请参阅《与交互文章沟通》）。就我个人而言，这个领域的工作非常令人振奋。然而，我不了解是否有任何文章真正符合我们迄今讨论的期望。这些文章可能是交互的，可能涉及一些实践，但这些实践都被限定在特定的小沙盒里，而非实际运用技能的真实环境。它们更像是与模拟培养皿相结合，而不是真实的实验工作台。
以一篇关于编程主题的文章为例，其结构是长文中穿插小型交互代码编辑器，用于探索某个概念。虽然这肯定比普通的文章有进步，但与我们的愿景相比，「实践」在这里显得相当次要。这些编辑器与真实编程环境差距甚远；要将你所做的应用到真实程序中，你必须费尽周折。这就像是在阅读一本棋盘游戏说明书，其中的交互图片描绘了棋盘游戏的简化部分。或者，说得不那么公正些，这就像一本精致的立体书。你还没有真正投入实践。
如果这些交互文章常常呈现为文字的海洋，而其中点缀着交互的小岛，那么将这一结构倒置或许是一条将真实环境整合进来的路径。我们怎样能够创造出以交互环境为主、却又穿插着文字岛屿的「文章」呢？以编程为例：我们能否让整个体验都融入你所选择的集成开发环境，而不是包含源代码列表的文本文档，同时还能展示解释性的文字呢？[2] 能否将 YouTube 上用 Blender 进行 3D 建模的课程搬进 Blender 软件中呢？
电子游戏在这方面很出色。有时，教程出现在非交互式的剪辑中，与普通游戏截然不同，但更好的例子（例如传送门）将指导和叙述与交互式环境无缝融合，从未将摄像机或控制权从玩家手中「抢走」。产生了在游戏环境中的丰富沉浸感——与桌游的指导手册形成鲜明的对比。[4]
电子游戏还解决了交互文章的另一个难题：文字和动态展示难以分离。这类文章通过一些方法拉近了文字和交互元素之间的距离，例如，将文章中的数字和图中可直接操作的参数关联在一起。但在多数情况下，它们依然是实际分开的，而不是视觉上整合的。读者的目光在文字与交互元素之间不停穿梭，费劲地将参照物与物体联系在一起。这不仅仅是动态元素的问题，传统文字中的静态图形也有同样的困扰。然而，Edward Tufte 的著作中所描述的解决方案在动态领域却鲜有应用，或许是因为编写工具更为复杂、孤立。几乎所有人，几乎一直都还停留在「按生产模式分离」。
电子游戏通过音频将指导嵌入到玩家所看到的画面中，并且不影响看到的内容，但即使只使用文字，它们也可以将文字放在动作的相关部分旁边。这种安排使游戏能够避免玩家在指令和交互之间反复横跳，就像我们在棋盘游戏手册中所经历的那样。而且，由于叙述性交流被整合到一个动态环境中，它可以像环境中的其他元素一样行为和反应。在优秀的游戏中，精心设计的叙述就像对玩家行为的持续回应。这消解了当人们阅读与「实践」相隔离的文本时所感受到的那种距离感。
进入 Figma 文件
说来也怪，这封信的直接原因，竟然是一份非同寻常的 Figma 文件。
（如果你不了解 Figma 的话，简单来说，Figma 就是一款用于设计软件界面视觉效果的协作工具。）
这两年来，我一直在收集关于这篇文章主题的笔记。在某些时候，我想围绕这些想法建立一些原型，并发表一篇更深入的文章。但我觉得现在的想法还不够成熟。然而，你现在正在读这篇文章，正是因为一份 Figma 文件催促我提前写下了这样一份「欠条」之类的东西。
Figma 改变了他们界面中复制和粘贴的工作方式。他们为了向用户解释这一改动，特地做了一份文件。我知道这听起来似乎平淡无奇，但请别急着走。我鼓励你在继续阅读之前，亲自去看一看：点击「复制」按钮开始，然后放大左上角的画框。你可以通过网页浏览器，用一个免费账号浏览这个文件。
这篇文件乍一看就像是一个超文本幻灯片。它通过图像生动地展示了新的剪贴板功能是如何运作的。这是一份在 Figma 中创建和使用的，关于使用 Figma 的文件，这非常优秀，但并不特别。解释的前言穿插其中，文件将控制权交给了你：
这就是我们打破了创作内容和真实「实践」之间的墙。你被邀请去操纵作者所创造的物体。这些对象并不特别；它们和你在别处能自行创建的物件是同一「类别」。你可以把它们复制并粘贴到一个新文件中。当你操作这些对象时，你所用的工具和作者创建文件时所用的工具一样。更重要的是：你所使用的工具，正是你在这个领域真实工作时所会用到的。
这原本可以是一篇充斥着小小的交互「演示」区的博文，但现在，你正身处 Figma 的全景环境，与这个文件交互。在设计领域，这更像是一个实验台，而非虚构的培养皿。除了一些基本的文字外，你在此的「实践」与你自己的创意工作中的「实践」之间毫无隔阂。当我阅读这份文件时，不禁好奇起这些不同构造的组合下，粘贴功能将会如何表现，于是我用已熟悉的工具摸索着去寻找答案。那天晚些时候，我在设计布局时，不假思索地用上了其中一种新的粘贴功能。
重要的是要认识到，这份文件中有大量文字。这也是让它变得如此有趣的部分原因。这样的「练习纸」并不罕见——有很多像这样的 Figma 文件，为你提供练习和一些可以玩耍的情境。
与此相比，复制/粘贴的 Figma 文件非同寻常，因为它大概有一千多字。这里包括大量的解释材料，而且可能还能进一步拓展。这种深入而广泛的文章开启了媒介中经典作品的可能性。另外，这种复制/粘贴的文件中编写的内容与活动之间的交互更加精准微妙。这形成了更短、更精确的反馈循环，让人感觉就像在体验一款电子游戏教程，或者与老友共同玩一款桌游。
这是一篇关于如何使用 Figma 的 Figma 文件。如同一本精雕细琢的使用说明书，这的确是有用的。但是，我们不难想象一个更重要的变化：一本用 Figma 编写的关于界面设计的「教科书」[3]。在这本初级指南中，你不只是了解设计的方法，你实际上是在「实践」设计，而且是在你作为专业人员所使用的环境中。由于解释和行动之间没有人造的界限，我相信这样一本书能让人更贴近于体验一款设计精良的电子游戏教程时的感觉。
对 Figma 文件概念的详细阐述
当然，Figma 的「元文件」媒介本身还有进一步的拓展空间。
复制/粘贴文件中的说明性文本没有行为和反应。对作者来说，这不是一个真正的动态媒介。在解释和行动之间的精细交流的帮助下，读者更容易产生自己的反馈，但这种媒介还可以通过响应读者的操作从而走得更远。《地球：启蒙读本》展示了一个简单的方法，在读者完成建议时「打勾」：
我们还可以设想特定主题的计算元素。例如，讲解色彩理论的一章可以利用关联的表现手法，根据你选择的「主要」颜色来动态展示次要和互补色。讲解网格系统的一章可以协助你直观理解不同的类型层次比例如何影响你设计中的基线节奏。讲解可访问性的一章可能会在你的设计画布中嵌入对比度比率的测量工具。随着你对材料的熟悉程度增加，这些脚手架可以逐步撤去。等等。
另一个耐人寻味的方向——与 Figma 的多人协同设计非常契合——便是在文本中融入合作学习的机遇。合作学习的一个标准「动作」是：提出一个能够用多种方式解决的难题；并把多个学生的不同解答放在一起，助他们互相取长补短。Figma 设计「教科书」可以包含单独和「共享」的画板，甚至能借助异步协同功能促进学生间的思想碰撞。这种方法甚至可以包括一位协调者，配合诸如 Desmos 之类的工具，以更好地支援他们的努力。
从更广义的角度看，我所倡议的交互式解释媒介不仅局限于「教育」场合。在着手一些实质性项目的过程中，它们同样可能大有裨益。比方说，如果我们正在设计一款新的操作系统，我创造了某个新的控件，那么我可能不仅通过制作一个静态的 Figma 文件来向团队展示，还会借助一份能「实践」的文件，协助你领悟如何在你自己的设计中运用它。这样的文件也能作为专业参考资料恰到好处地派上用场：例如，倘若我初次为扩展色域显示屏进行设计，这样的工具就能大显身手。这些文件里的「通道」或许能让你把自己的设计项目「带入」解释文件，使你能在处理实际工作的同时，深入理解这一概念。
扩展到其他环境
支持这种格式的环境不只有 Figma。我们还能在哪里实现类似的东西？一个系统要实现这种文件，必须具备哪些特性？我可以概括出至少几个方面。
文件必须为作者传达解释内容提供途径，解释可能会很长。Figma 有文本元素；编程环境有注释。在其他环境中，如音频制作工具，我们可能需要在文件模型中添加这种能力。或者，解释内容可以通过音频（或视频）渠道传递，但必须确保读者操作文档中的对象时，不打断作者素材的播放。
作者得能在他们内容的某些段落与读者交互环境中的相关元素间建立联系。在 Figma 中，我们可以将文本紧贴在你要操作的每个元素上。在 Finale（一种音乐创作环境）中，文本可以在乐谱之间交错排列，或者定位在特定的乐句上方。在以 Roam 为基础的媒介中，大纲的分层结构可以用来将作者的文字与读者的文字关联起来。
作者需要线性化和结构化的解释方式；读者需要「导航」的能力。在 Figma 中，各画板依次排列，可以通过滚动或键盘快捷键轻松导航。超链接和「目录」画板也方便了导航。清晰的图层列表则如同目录一般，方便查找。在编程环境中，一连串的标签页可能与 Figma 的画板类似。或者像 Natto 的教程那样，我们可以用特殊功能来改进这些功能。
在其他什么环境中，我们可以轻易地想象创建这样的文件？
- 一份关于编写优质自选冒险游戏的 Hypercard 文件（肯定有人已经以这种方式使用 Hypercard 了？）
- 以虚幻引擎文件形式呈现的游戏开发入门读物。
- 以极其精致的 Finale 乐谱呈现的和声分析研讨会。
- 可以动手操作的《卡片笔记写作法》的 Roam 图改编。
目前为止，我所提到的仅限于现今的环境中可以创造的文件。但未来，我们或许不再只局限于现有的设施，而是可能有一天会设计出类似 Figma 这样的系统，使它们更好地支撑这类文件的创建。
————————
感谢 Molly Mielke 就这些 Figma 文件的背景进行的讨论。也感谢 Michael Nielsen 和 Jonathan Blow 在过去的讨论中对形成这些想法的帮助。
————————
[1] 这个框架来自 Bret Victor 的《停止画死鱼》。在这里，不可改变的人物（无论是印刷的还是动画的）都是「死鱼」。
[2] 那么像 Mathematica 和 Jupyter 这样的计算笔记本呢？我不认为这些符合条件；我没发现有任何骨子里是「以实践为中心」的例子，文本中穿插的代码真的与所讨论主题的实践有关。正如 Pavel Panchekha 告诉我关于他的《网络浏览器工程》一书，这种格式似乎更侧重于帮助读者理解作者编写的代码，而不太适合支撑读者自己写代码。
[3] 当然，一些非常好的例子（包括 Braid 和 The Witness）根本就没有使用明显的解释。这是一种极其有力的方法，我得找个时间再深入探讨。
[4] 这样的入门书将特别有价值，因为奇怪的是，没有用户界面设计的「标准文本」。
Thoughts Memo 汉化组译制
感谢主要译者 AsukaMinato、GPT-4，校对 Jarrett Ye
原文：Doing-centric explanatory mediums: board game instruction manuals and an unusual Figma document | Andy Matuschak