Matrix 首页推荐
Matrix 是少数派的写作社区，我们主张分享真实的产品体验，有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章，展示来自用户的最真实的体验和观点。
文章代表作者个人观点，少数派仅对标题和排版略作修改。
作为一个成熟的打工人，我 90% 的上班时间都在和电脑打交道。当然我也和大多数人一样，时常需要并行推进多个项目或任务。虽然我做好了文件管理——电脑桌面没有被各种各样的文件塞满，但依然逃不出工作时窗口开得密密麻麻的情况；使用时也需要反复在这些窗口之间跳转，直到最后迷失在这些窗口里。
而在今年 WWDC 上 iPadOS 公布了「台前调度」的功能以后，不少人都对 iPadOS 上的这个功能表示兴奋虽然这个功能后来在正式版普遍风评不佳。但当这个功能出现在 macOS 上的时候更多的人表示不解，不仅是因为桌面端有很多更好的解决方案，还因为「台前调度」看起来就是给 iPad 多任务处理定制的，放在 macOS 上就显得格外不协调。
不过，我在这篇文章中并不打算对 macOS 上「台前调度」以后的人机交互理念做过多的分析和讨论。本文只是我最近两个月使用macOS 上「台前调度」的一点个人经验总结和分享。
窗口越开越多很多时候是一件很正常的事情，因为桌面系统天然地允许打开非常多的窗口并允许用户在其中交互，加上无论是 macOS 还是 Windows 本身都有非常悠久的开发历史，而人机交互这件事也在不断地进化和发展。
本段中的部分内容最早由发布于 2022 年 9 月 15 日的奏折，如果你对更多会员文章感兴趣，欢迎订阅少数派会员。
就拿软件窗口这件平平无奇的系统组件来说，实际上关乎着操作系统系统中三个独立但又相互依赖的概念：
一个程序程序可以打开多个窗口，每个窗口又可以打开一份或者多份的文稿。最典型的就是日常生活中的浏览器，可以打开任意多的窗口，每个窗口中又可以打开不同的网页标签页，独立工作不乎干扰。
但在上个世纪计算机处理器性能相对赢弱的时候，做到这一点可是不容易。我们可以简单举个例子，一个程序程序打开 N 个窗口是不是意味着这个程序需要被加载 N 次呢？如果需要的话，初代 Macintosh 可只有 128KB 大小的内存，如果加载 10 次还有足够的内存留给系统或者其他程序程序吗？
答案是不会，在当时的情况下即使每个程序只加载 1 次，内存和算力也不够同时允许多个「可见」的前台程序。
首先是每个程序只会打开一次，且只有前台程序才可以交互，最典型的地方就是全局菜单栏明确告诉用户当前的工作状态；其次是用户可以打开一个程序的多个窗口，来尽量停留在一个应用程序中，进而减少程序重新打开和切换所需要的时间。
而随着处理器和内存的提升，上面的这些「规定」部分就有了更优的解，比如：即使不在前台程序的窗口依然可以滚动、Dock 会通过指示灯显示当前一个程序已经处于打开的状态了，但底层逻辑依旧没变。
但其实早在上个世纪 80 年代后期，macOS 就已经有足够的内存来打开多个程序了，但是为了向后的兼容性，先前定下的「全局菜单栏明确告诉用户当前的工作状态」这一点并不能发生改变，这样就自然而然导致了关掉一个程序程序的所有窗口的话它还是处于打开的状态。进一步衍生出了现代 macOS 的这套多窗口逻辑：窗口和文档绑定，所有的窗口只由一个应用程序打开。这套逻辑通常被称为多文档界面（MDI）。
在上世纪 90 年代 Windows 开创性地由系统分配和调度系统资源，这样 Windows 就可以主动把资源从消耗资源更大的程序转向更需要资源的程序了。而且从那时开始，处理器、内存等硬件的性能开始遵循着摩尔定律飞速攀爬着科技树，更高的性能和由系统主要的性能调度，让 Windows 转向了单文档界面（SDI）。SDI 和 MDI 最显著的不同就是，每一个窗口都可以打开一次程序本身，而一个窗口往往也只对应一个文档，简单来说每个窗口就是一个程序和对应的文档，最典型的 SDI 软件就是 Office 家族。
当然现在 macOS 和 Windows 在管理程序、窗口和文档上其实已经没有很早那么大了，比如 Adobe 全系无论是在 macOS 上还是 Windows 上都遵循着 SDI 一样的逻辑。而 MDI 和 SDI 本质上没有优劣之分，使用符合应用本身场景和逻辑的方式才是最重要的，
但不可否认的是 GUI 背后的设计理念依然影响着和系统底层有关的逻辑，就比如多窗口管理以及窗口标签页化。
不过相信你也发现了，无论是 MDI 还是 SDI 都避免不了在繁杂工作时需要打开大量的窗口。想要解决工作时窗口大量堆砌的方法有两种，一个是像浏览器一样把窗口标签页化，这种往往被称为标签页文档界面（TDI）；另一种方法则是进行窗口管理。
期望所有的程序都支持 TDI 是不可能的，我们自然也不能继续指望系统层推出类 TDI 式窗口管理机制，不然 Windows 的 Sets 功能就不会被砍掉了，但工作还是需要继续推进的。
不过根据我发现，杂乱的界面本质上可以归结为屏幕显示面积不够、屏幕不够导致打开的窗口不能完整平铺——窗口与窗口之间会彼此层叠，进而在使用时需要反复找到具体窗口，再切换过去。「查找-定位-切换」的过程才是让我们头痛和感到不快的主要原因。
想要解决这个问题其实目前有两个思路，一个是钞能力：在能看清内容的基础上屏幕显示内容的越大越好或者是屏幕数量越多越好；另一个则是不额外添置屏幕的基础上使用窗口管理软件。
自计算机性能有了长足进步以后，窗口管理一直是一个老生常谈的问题，早在 Windows 7 中 Microsoft 就内置了一个贴靠式的分屏机制，而在后续的 Windows 11 则提供了更细致的分屏机制，甚至在 Microsoft 还在 PowerToys 中的FancyZones 功能允许用户手动划分和调整区块的窗口管理机制；而 macOS 上除了系统内置的简单的左右分屏机制以外，优秀的第三方分屏软件也活跃在很多的不少 Power User 的 Mac 上比如 BetterSnapTool 和 Mosaic 等工具。
但这类工具我普遍都不怎么爱用，或者说我最常用的还是左右分屏和全屏。这是因为我一直管用的是 16:10 尺寸的外接显示器，所以除了左右分屏可以完整显示两个窗口中的所有信息，其他的布局或多或少都会影响到软件 UI 或是内容的显示。而水平上下型的分屏除去系统没有快捷特性支持，绝大部分的软件在这种情况下左右不是会空出一大块被浪费的空间，就是阅读时视线水平方向上所要移动的距离过长，不符合充分利用屏幕的原则，固然不是一个好方案。
当然如果是「带鱼屏」一样的宽型显示器，还可以考虑多增加一个水平排列的窗口——也就是左中右结构，并行浏览和使用三个窗口的体验应该会更好。不过我因为嫌弃带鱼屏 PPI 偏低和背光不均匀，所以后续就没买过宽型显示器。
而软件的 UI 布局则是另一个让我在分屏软件中抓狂的一点。就拿最常见的浏览器来说，网页通常中间是内容，左右的空间都可以压缩，而上下的空间自然越长越好，所以把浏览器放入「纵向长度大于横向长度」的区块中看起来是更好的选择，但在我的实践中很多时候都会遇到打开过多的标签页以后，辨识标签页的方式只有一个 Logo 的方式；而且这种「纵向长度大于横向长度」的区块也意味着我没办法使用「垂直标签页」来解决标签页过多导致的辨识度下降的问题。
当然 UI 布局的让区块式分屏难以处理的例子还有很多，我这里想到的另一个例子就是聊天软件，现代聊天软件桌面端的 UI 设计大同小异最左侧一列功能标签页，中间靠左侧的则是聊天会话列表，而右侧则是具体的聊天窗口。至少对于我来说，在工作时最左侧的功能标签页是无效，其次就是会话列表很多时候也是无效的，部门中的大部分事情基本都在部门群中进行处理，很多时候瞟一眼就知道有没有信息、以及需不需要我来处理。但如果借助分屏软件，这些左侧功能栏依然会在分屏中占据一定的面积，导致右边需要真正显示的内容面积被挤占。
不过我也试过在分屏软件的帮助下借助虚拟桌面进行窗口管理，但依旧是问题重重序贯。首先是虚拟桌面本身的呈现问题，切换时很容易导致「前一个虚拟桌面」和「后一个虚拟桌面」丢失类似「上下文」一样的联系。因此打开过多的虚拟窗口以后在切换时我有大概率会忘记「具体的窗口到底在哪一个虚拟桌面上」，这就导致了我需要反复在多个虚拟桌面上切换的情况，这种情况偶尔会让我非常烦躁。虚拟桌面还有另一个比较严重影响的体验的地方，类似 Safari 一样的比较万金油软件会在多个虚拟桌面上打开，万一你在一个没有 Safari 的虚拟桌面上点开了一个链接，你永远不知道会用哪一个 Safari 打开，那个体验简直了。
除了虚拟桌面的问题，搭配使用时分屏软件的问题也不少——只要我接入一个外接显示器，基本就没有分屏软件能够处理好不同虚拟桌面之间的逻辑，甚至于使用它们跨虚拟桌面移动窗口时出现各种问题我都已经见怪不怪了。因此与其说是进行「管理窗口」不如说「窗口在管理我」。
所以后来我也在 macOS 上我一直都是内置的「调度中心」和「App Exposé」这一套多任务处理方式。这套方式对我来说最大的好处的就是够「直观」，这是我在 macOS 下更习惯使用的是触摸板，「调度中心」和「App Exposé」刚好是一组动作相反的四指滑动动作，非常符合我的使用逻辑。但这套方案也不是完美的，「调度中心」虽然好看，但是只要多开一个应用「调度中心」的布局就会发生改变，想要找特定应用在大部分情况下就需要全部看过来，应用程序太多的时候会非常恼人。
我从 10 月份 macOS 13 正式版推送以后就开始使用「台前调度」这个功能了，一开始只是出于好玩的想法，但在慢慢使用的过程中我逐渐喜爱上了这个功能。
台前调度将一个虚拟桌面分为了 2 部分，一个「舞台（Stage）」和一个「下场区（Stage Left）」。舞台很好理解，台前调度中的舞台就是各种应用展示自己窗口的地方，而且不同应用和不同应用的窗口也可以任意组合，形成一个又一个窗口组，这也是我们工作时主要交互的地方。在打开了特定设置以后，甚至于桌面文件都会临时性地隐藏起来，需要点击一次桌面，请舞台上的应用先下去才会显示桌面的文件。
而下场区则是一个来自传统舞台的概念，演员离开舞台时会通过舞台左边的通道离开；在打开前台调度以后，从一组窗口切换到另一组窗口时，前一组窗口组则会自动收缩到整个屏幕的左边，就和传统舞台的退场逻辑相似。但和传统舞台不同的是，我们作为用户，可以随时观察到当前窗口的打开状态，并且还可以随时把他们请回来；下场区中的 App 也可以随时进行刷新，并把实时状态刷新在缩略图中。
除了基础的观察和点击交互，下场区还存在着一些特殊的交互方式。一个是拖拽，我们可以：
另一个则是点击缩略图旁边的应用图标，会显示当前应用所有（在这个虚拟桌面上）打开的窗口，方便用户及时找到这个应用的所有的窗口。
介绍完了基本交互，接下来就要谈谈我为什么喜欢台前调度了。在我看来台前调度解决了很多上面提到的问题，其中最重要一点就是解决了虚拟桌面上所有的窗口不能完整平铺的问题。
在打开台前调度以后，虽然窗口依然不能完全平铺，但通过「舞台」和「下场区」的配合，可以做到类似平铺的体验——每个窗口大致的情况、所在的位置我都能掌握地清清楚楚，找窗口的时候也可以直接点击应用程序的图标展示这个应用的所有窗口，能给精准定位一个应用程序的特定窗口。
除了能够准确掌握每个窗口位置和信息以外，将窗口组合成符合实际工作需求的窗口组也非常有用，因为这样我们就不用在使用时反复切换了。虽然台前调度和第三方分屏工具都可以做到，但台前调度会显得更加灵活一些。台前调度对窗口的大小、位置并没有太多的限制，只要用户可以任意组合不同类型的窗口、调整窗口的大小并把窗口放在合适的位置上，跨虚拟桌面、跨显示器调度时的兼容性也很好；此外使用台前调度的时候达成我之前的想要的「允许窗口与窗口互相重叠一小部分」的分屏方式，以进一步利用屏幕空间。
当然基于本地机器学习也会参与到台前调度中，我通常会将 Ulysses 和 Safari 放在放在同一个窗口组中，多次使用以后 macOS 就会记住 Ulysses 和 Safari 各自窗口的大小和位置，下次再将它们组合到一起的时候 macOS 就会自动还原对应的位置以及大小。
在我使用过程中我还注意到，「下场区」中每个窗口或是窗口组就像是一个个「虚拟桌面中的子桌面」一样，可以直接通过点击切换到特定的一个「子桌面」上；同时配合实时浏览，同一个虚拟桌面的利用率会高很多，也减少了需要反复切换的问题；配合整整。此外，台前调度还算半个「专注模式」，当窗口遮住位于左边的「下场区」时，「下场区」就会被暂时地隐藏起来，让我可以更专注于眼前位于舞台上的那些窗口。
当然，macOS 上台前调度也不是完美的。最典型的问题就是在舞台上拖动一个窗口到下场区形成一个新窗口（或者窗口组）时，你永远不知道什么时候会成功，或者怎么样失败，在多次沮丧的经历以后我选择长按左上角绿色的全屏按钮，在弹出的菜单中选择「将窗口移除组」来规避这个问题。
其次，就是缺少「切换到上一个组/下一个组」这样必要的快捷键，iPad 上使用台前调度时可以借助 Globe/Fn - ← 和 Globe/Fn - → 来实现，但在 macOS 上这组快捷键已经被系统映射成了 Home 和 End 两个快捷键了。所以只能通过鼠标进行点击，这对于键盘快捷键爱好者来说是个坏消息。
再者就是 Apple 一贯的「优雅范」，会根据屏幕的尺寸限制下场区可以显示的应用组数量，在 27 英寸的屏幕上最多只会显示 6 个应用组，在 14 英寸上的屏幕则只会显示 4 个，虽然上下还有一定的空隙但是就不给你显示更多的应用组了。不过这个比较好解决，新开一个虚拟桌面就好，说实话用了台前调度，我自己新建虚拟桌面次数都少了不少。
最后就是一些奇怪的小问题了，比如下场区中的应用图标消失，切换到某个组时应用原先的位置统统不对劲，还需要手动重新归位。一些窗口会被台前调度给隐藏到下场区中，比如软件的更新提示窗口、smb 连接的认证窗口等。以及你依然不知道，在打开了很多浏览器窗口以后，在其他应用中点击一个链接时，台前调度会把调度到哪一个浏览器窗口中打开。
不过瑕不掩瑜，我依然还是爱上了这个功能。以上就是我在 macOS 上使用台前调度的经验，希望可以给你到一点启发，也欢迎大家在评论区分享自己台前调度的使用方式。
> 下载 少数派 2.0 客户端、关注 少数派公众号，解锁全新阅读体验 📰
> 实用、好用的 正版软件，少数派为你呈现 🚀
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。