前言：在 上篇文章 中，我们探索了 Arc 浏览器为何能实现工作流。本篇文章将参考 Arc，改造一个工作流工具的基础框架。
对于工作流而言，Arc 的侧边层级设计是极具创新性的。
但 Arc 终究是一款浏览器，或者以 Arc 自己的表达，它是 A better way to use the internet。这个愿景决定了它的很多体验是围绕互联网的，工作流是它的运作结果，但不是目的。
当我们想重新设计一款专属工作流的工具时，参考现有最好的工具，并在探索中逐渐变化，找到自己的方向，或许是成长最好的方式。所以让我们对 Arc 进行改造，保留其具有工作流创新的部分，在此之上探索一个专属工作流的工具。
为了便于区分和指代，我将这个新工具命名为 AI/R。
需要特别说明的是：AI/R 是一个设计稿上的探索项目，而非实际开发。
首先，最重要的是保留 Arc 上有关工作流体验的设计。
具体指 Space 空间、侧边栏层级结构、Favorites/Pinned/Today Tabs（收藏/固定/临时标签）、Back to Pinned URL。它们代表着多个工作流项目、流程关系、固定和混乱态的转化。这些 前文 已有解释，就不再赘述了。
其次。在底部「新建」按钮上，增加「第三方工具内新建」选项。
例如可以直接新建 Notion 页面、新建 Figma 文档、新建 Linear 任务、新建飞书思维导图等。
这个小功能会鼓励用户脱离原有工具的结构框架，在 AI/R 的侧边栏结构中构建流程，打破不同工具间的壁垒。而且当这些工具都变成了 AI/R 能力的一部分，AI/R 也就不再需要单独开发 Note 等功能了。
首先会去除 Arc 的 Theme 和各种个性化界面，回归到 macOS 的默认设计。
Arc 的 Theme 等设计虽然能体现审美、工艺和乐趣，但它们让工具本身变得太引人注目了。工具本身并不是重点，重点应该是在工具内做的事情。所以我希望工具能尽可能地贴近原生，像水一样透明无感，让人们在使用时尽可能地忘记它，全然地沉浸在工作之中。
其次。在排版上参考 Safari 的侧边栏。
更加紧凑严肃，能呈现更多内容，更便于复杂的工作。
与此同时，文件夹图标变为箭头。
同样能表现层级关系，但看起来不再有存储的感觉，更轻盈流动。
最后，Favorites 在设计上从 Cube 改为选项条，在交互上 Tab 被 Favor 之后也不再从原位置消失。
Cube 的确是一个非常好的设计，Arc 的拖拽体验也十分丝滑，甚至比同样设计的 Apple Reminders 更好用。但 Cube 其实也是一种组织方式，我希望把它变为更通用的方案。用户可以自由选择将任意位置的 Tabs 转为 Cube 设计。交互上，因为产品定义是工作流，所以原 Tab 是在一个工作流之中的，Favor 之后消失就会破坏原有的工作流结构，所以保持不变。
对工具能力的增强，也有可能让工具本身变得越来越复杂。所以我们需要在前期规划好工具的基础框架，使其具有拓展性，避免混乱。
这里以微信为例。和 Telegram、Messenger 等更加专注 IM 的软件相比，微信功能更加广泛。但随着它的业务边界不断拓宽，软件基础的设计框架依然保持稳定，甚至依旧是设计早期的四个 Tab。相较而言，推特随着业务的增加，不断增改 Tab，增加了系统的复杂度。Insgramm、Snapchat 也无不如此。
对于 Arc。它当前的设计拓展性有限。如果我想折叠所有文件夹，按照官方的指引，需要 CMD T 唤出搜索框再进行操作，还有诸多操作也是如此。这些是隐性的和不自然的。如果后续需要更复杂的操作，或是增加更体系化的 AI 功能，当前的设计较难应对。
所以我希望能设计出一种具有拓展性的框架，为之后工作流的探索提供可能性。
首先，让 Tab 包容万物。
AI/R 在定义之初，就是一个工作流工具，而不是一个浏览器。而工作流里面的事项是包罗万象的，可能是网页，但也可能是文件、应用，甚至是一段话，一种能力。所以对于 Tab，对它的设计就不再是网页，而是一个启动器。你可以在里面打开任何你想打开的内容：网页、视频、AE 文件、Office，等等等等。一切只取决于现有技术能不能，而不取决于想不想。
如此一来，AI/R 在软件架构保持不变的前提下，能实现的能力大大拓宽。
而且这种基础性的设计也会影响开发。开发不再把 AI/R 当作是浏览器，而是当作一个启动器。在此之上实现的功能都是模块化拼装的。用户一打开 AI/R 时可能只占极小的内存能耗，预览各种文件也是如此。只有搜索网页才会触发更多资源密集型模块。最终用户会放心地随时打开 AI/R，把它当作所有文件、进程的启动器，像空气一样自然。
为了实现这种统一性，AI/R 也会将 Arc 的标签页和地址栏融为一体，让 Tab 脱离网页的概念。
地址栏主要有编辑和复制链接两个功能，融合起来并不复杂。在 AI/R 的设定中，当用户鼠标悬浮到 Tab 上，Tab 图标就会变成链接按钮，引导用户点击复制链接。当用户鼠标悬浮到链接按钮，则会出现编辑按钮，点击即可编辑链接。
这种融合除了让 Tab 更具拓展性，还有一个好处：让逻辑关系更为统一。
在 Chrome 中，地址栏位于标签页之中，代表从属关系，是逻辑统一的。Safari 15 尝试融合，设计初衷是简化操作栏，能看见更多页面内容，让整体更加自然有序。融合后地址栏 = 标签栏，也是逻辑统一的。但在 Arc 中，Tab 和地址栏是分离的，并行的。但实际上它们是从属关系，整体逻辑是不统一的。
融合之后，逻辑统一。当我想对这个 Tab 进行操作时，所有的操作就在 Tab 上完成。不仅让指代性更为清晰，还是软件结构上的一次简化。设计上非常自然，仿佛本就应该是这样。
不过从 Safari 15 多次改弦更张来看，这种融合是具有争议性。能否有其它更好的方案呢？
让我们转向右侧的窗口设计。
Arc 在收起侧边栏后，所有干扰元素全部消失，只留下最纯粹的网页本身。如此纯净、美好。
在 AI/R 设计之初，我也把「折叠侧边栏后，能纯粹地显示网页本身」作为第一设计目标。与此同时，基于把 AI/R 作为启动器的需求，我又希望在折叠侧边栏时，用户依然可以执行关闭打开等基础操作。
希望纯净，又想要保留操作。这两个需求本身就是矛盾的，导致我纠结了一个月，设计了各种千奇百怪的交互。最后我发现，像 Arc 插件这种隐藏触发式的设计似乎是最优解。但我很抗拒这种有门槛的交互。
后来有一天我忽然醒悟：所有的纠结只源于最初我给自己定下了一个错误的预设：网页一定要纯净。但这并不是正确的设计思路。我应该想清楚自己的工具究竟想要什么，从下往上推导功能。
前面提到，AI/R 在定义之初，就是一个工作流工具，一个效率工具。用户每天可能会和各种功能频繁交互，尤其是引入 AI 后，操作密度更会大幅提升。也就是说，工具栏的存在并不是减分，而是增幅。想象在 Figma 中，如果为了美把左右侧边栏隐藏，整体的使用体验会多么糟糕。
破除预设的执念后，我在窗口上方增加了工具栏。
不仅能放置各种插件，也能放置各种操作，例如「前进、返回、刷新」。当然也能放「链接」按钮（或地址栏），解决上文标签页和地址栏融合后的操作问题。（这里作为隐藏操作）
更重要的是，对于 Tab 的操作能力也更具拓展性。未来。我可以在工具栏放置 AI 功能、放置 Boost 功能，放置各种可以增幅 Tab 的操作。对于用户来说，他们和插件一样，都是能力，理解起来也很清晰。
另外，Arc 因为侧边栏折叠后无法进行基本操作的原因，设计出了 Little Arc 这一中间产物。但在 AI/R，侧边栏折叠后就是「Little AI/R」，便可以省去中间产物，化繁为简。
和窗口理念相同，我也增加了侧边栏工具栏，置于侧边栏底部。
这样，当用户想要折叠所有文件夹，点击底部按钮即可，不再需要 CMD T 唤出搜索框再进行操作了。后续想要增加其它能力也都可以放在此处。具有拓展性。
基于此设定，Space 栏目也被移至顶部。
（当然也可以把 Space 和侧边工具栏调换位置，或者放在一起，有各种排列方案。囿于无法测试，我暂时选了直觉上可能使用起来最为顺手的方案）
另外，和 Arc Library 类似，我把系统层面的操作、历史记录等全部集合一起，放在最右侧的「我」Space。
类似于微信第四个「我」Tab。这样后续 AI/R 增加元素都可以放置在这里，亦具有拓展性。特别的是，「我」Space 里采用和普通 Space 一样的设计，甚至下方内容也都可以被 Favor，以化繁为简。
在 AI/R 里，我们会探索很多不同的组织方式，除了目前的侧边层级式，未来可能还有类似 Edge 的横边并行式，类似 macOS 的自由式等等。它们之间是可以相互变化的。应该如何设计工具结构，避免混乱呢？
让我们先清晰一下当前的 AI/R 结构。
侧边栏上方是 Space。每个 Space 里包含很多 Tab，它们以层级结构组织起来。点击 Tab 后，会在右边的窗口呈现 Tab 的内容。
抽象来看，AI/R 只有三层结构：Space 空间 → Tab 工作流/组织方式 → 窗口内容。
其中，Space 空间可以作为一种特殊的 Tab，包含于「Tab 工作流/组织方式」。换而言之，可以抽象为两层结构：Tab 工作流/组织方式 + 窗口内容。这两层结构各有各自的工具栏。
只要抓住这个核心进行开发和设计。不管组织方式怎样变化，不管未来拓展怎样的组织方式，都不会混乱。
案例可看文末彩蛋 =)
以上是原子化的思维。其实我们还可以更进一步，参考 Notion 的模块化逻辑：所有内容都是块，页面里包含块，页面本身又能成为块，彼此相互转化。对于 AI/R 也是，Tab 是块，Tab 工作流也是块。Tab 工作流里包含 Tab，Tab 里也能打开工作流，彼此相互转化。
举个例子，我可以如下，在 Tab 里打开侧边工作流。看起来就像在窗口又打开了一个内嵌的 AI/R。这种原子化、模块化的结构不仅可以让 AI/R 能拓展不同的组织方式，不同的组织方式间也可以交织组织，让你构建出属于自己的复杂而强大的工具。
另外，从这个意义上，窗口工具栏就变成了「侧边工作流」的工具栏，也就是上文的侧边工具栏。换而言之，这两个工具栏本来就是一体的。因此在开发上，我们可以进一步简化逻辑，把 AI/R 工具本身当成是一个窗口，辅以工具栏。当窗口里打开工作流时，工具栏就是工作流工具栏；当窗口里打开 Tab 窗口时（类似于侧边栏折叠），工具栏则就是 Tab 窗口的工具栏；当窗口打开工作流，工作流中的某个 Tab 又被打开时，就相当于是窗口嵌套窗口，以此类推。
听起来有点拗口。其实不理解也没有关系。这种设计是从工具结构层面考虑的，使用时并不会感到困惑。
Douglas Engelbart 是发明超文本、多窗口和鼠标的人机交互先驱，也是启迪 Notion 的思想家之一。不同于乔布斯、拉姆斯、毕加索等大师对简洁的追求，Engelbart 更偏好复杂和强大。他认为有些东西就是没有那么简单，但一旦学会，就能大幅提升效率。因而他构建的 NLS 系统极其复杂，最终高达五万个指令。
对于 AI/R，我也希望它是一个没有那么简单，但一旦学会，就能大幅提升效率的工具。但与此同时，我也并不认为像 NLS 系统一样极其复杂的结果是好的。我一直认为，虽然需求复杂，但如果设计得到的话，最后呈现的结果也一定是简洁的、直觉性的、自然的。
就如同 Figma。它要实现的作图是复杂的。历史上相同功能的软件往往是复杂的，例如 Photoshop。但 Figma 通过极好地设计，极大地简化了使用体验，让 UI 设计师从繁复的操作中脱离，专注于画布本身。
像 Figma 一样好地设计，以平衡简洁与高效，会是 AI/R 不断实践的设计理念。
另外，这里要强调一下，简洁是结果，不是目的。不能为了简洁，把功能全砍了。而应该在功能有必要的时候，好好设计它，最后自然而然呈现出了简洁的结果。如同 Figma 变量，添加一个功能，省去很多设计。
最后，简单和复杂有时是相对的。当你只想要一张图片时，Midjourney 才是简单，Figma 反而复杂；当你对一个功能没有需求时，再简单的功能也是复杂的。
所以和 macOS 大多数应用一样，AI/R 支持用户自定义按钮。
不仅能让用户的使用体验更个性化，也能让用户在需求的不同阶段，都能找到最适合自己、最简单的使用方式。
在这篇文章中，我思考了工作流，并在 Arc 浏览器的基础上改造了一个专属工作流的基础框架：AI/R。
在 AI/R 里。用户可以打开多种工作流（组织结构），以组织多种类型的工作项目（Tabs）。得益于其原子化、模块化的整体结构，用户可以搭建自己的多样化的工作流程，以提升工作效率。
因为我开发能力有限，所以遗憾的是，AI/R 只是一个设计稿上的实验性项目，旨在探索与启发。但也正因产品未被实际开发，难以测试判断可行性，反而让项目本身更具开放性和探索空间。这里我将 AI/R 的 Figma 源文件分享，欢迎你在画布里试验并分享。
AI/R 从 Arc 中来。我知道这件事听起来不性感，没有那种从 0 到 1 开创的开创感。但我很喜欢这件事，每每思考都由衷地喜欢，不迷茫。便不再去纠结这件事。
后续我也将在 AI/R 1.0 的基础上，通过 5-10 篇文章，继续探索工作流工具的可行性。等到那时再回望，或许两者已然截然不同。
前文提到，AI/R 抽象为两层结构：Tab 工作流/组织方式 + 窗口内容。这两层结构各有各自的工具栏。我们可以参考这个核心，把 AI/R 从侧边层级式，变为类似 Edge 的横式排布，如下设计。应用结构、交互和使用都如出一辙，开发和用户理解起来都很容易。
换而言之，如果 Chrome 能实现这样的设计，体验会不会别有趣味呢？
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。