【译】关于「多层日历」工具的思考

写在前面

各类生产力工具，基本都是在讲增加单位时间内的产出。 时间和产出一直是研究重点。

火箭君最近看到的一篇文章，讲述我们对时间的感知，所谓的「事情」应该怎样 「嵌入」到时间长流中。 这种嵌入也分「维度」和「层级」。文章最终向我们展示了一个 潜在的 all-in-one 心理模型。 个人觉得，值得与大家分享。

但我们知道 all-in-one 不是终点，各种工具的打通才是火箭君觉得值得追逐的「圣杯」。 好在我们在这两年看到的新概念日历 Cron， Amie， 甚至传统的 Google Canlendar 都注意到了这点。

新的工具融合趋势正在形成， 而这一切的基础，可以从下面这篇关于「多层日历」思考的文章中，看到一些启发。

原文地址：

https://julian.digital/2023/07/06/multi-layered-calendars/

原作者：Julian

以下文章由火箭君翻译，略有编辑和注释。

正文

01 简介

时间是个奇怪的东西。这是一条不断流动的溪流，无法暂停、停止或重复。我们经历它，但我们无法控制它。我们甚至无法触摸或感觉到它。

为了更好地掌握这种控制我们周围一切的奇怪的「无形资源」，人类发明了各种「装置」。这些设备帮助我们规划和优化时间的运用方式。

最流行的时间设备是手表。手表是一种有用的工具，但其功能仅限于当下。我们看到时间，但不能管理时间。手表只告诉我们「现状」。

另一方面，日历涵盖了整个时间范围。过去、现在和未来。它们是我们最接近「时间机器」的东西。日历让我们能够「时间旅行」看到未来和过去。更重要的是，还让我们能够「改变」未来。

「改变未来」意味着将时间投入到重要的事情上。这意味着将我们最宝贵的资源分配给预期投资回报率最高的活动。

我们可能会期望技术专家和企业家集中精力完善这样一个神奇的时间旅行设备，但令人惊讶的是，事实并非如此，我们的「数字日历」仅比笔纸日历稍好一些。自发布以来，Outlook 和 Google 日历都没有发生任何实质性有意义的变化。

这篇文章探讨了如果日历不被时间限制的话，它们会是什么样子。但在我们讨论他们的未来之前，我们首先需要分析日历的现状以及如何适应其余的生产力工具。

02 日历和 生产力栈

我的生产力堆栈由四种类型的工具组成：

• Note-taking apps 
  记录和组织我们的想法
• Email
  与他人沟通
• Task managers 
  组织我们需要完成的事情
• Calendars 
  管理我们的时间

我们使用四种不同工具的事实表明，记笔记、电子邮件、任务管理和时间管理像是四种不同的活动。但仔细观察时，我们会发现这些活动实际上并不是那么明确。事实上，它们都或有重叠。笔记只是发给未来的自己的电子邮件。电子邮件像是任务。任务也会变成日历事件。

我个人的工作流程是这样的：

• 我将电子邮件「收件箱」视为我的主要任务管理器（和笔记工具）。
• 「任务」是我从别人那里收到的电子邮件或我发送给自己的电子邮件。
• 我会「推迟」处理（snooze）电子邮件，直到我想要完成它们的那一周。
• 每周初，我都会浏览电子邮件待办事项列表，并在日历中为每项任务划出时间。

该工作流程的 email <> todo 部分实际上运行得相当好。当今的大多数电子邮件客户端都是围绕「收件箱清零」（Inbox Zero）的概念构建的，这个理念可以有效地将电子邮件收件箱变成具有公共写入访问权限的待办事项列表。

我们还没有真正弄清楚的部分是任务管理器和日历之间的交集。

将待办事项视为日历事件很有帮助，因为日历引入了约束。日历迫使你估算每项任务需要多长时间，然后在 24 小时 × 7 天的网格中找到它的空闲空间，网格中已经挤满了其他东西。这就像用时间块玩俄罗斯方块一样。

那么，我们如何将任务添加到日历中，而又不会在两个互不通信的不同应用程序之间来回尴尬地切换呢？

Amie 等新的生产力工具正试图通过在日历体验中原生插入待办事项列表来解决这个问题。在 Amie 中，每个日历事件都是一个可以标记为已完成的任务。

这种方法是朝着正确方向迈出的一步，但还远远不够。我同意任务应该存在于日历中，但这并不意味着每个日历事件都应该是一个任务。在我看来，任务只是许多不同类型的日历事件之​​一。

这只是许多不同日历的「层级」之一。

03 三个维度的时间管理

为了使「日历层级」的概念更加具体，让我们看一下大家以前可能见过的场景：

这里发生了什么事？

1. 你和迈克有个会面
会议是多人日历活动。它与任务不同。它只是提醒所有会议参与者，人们需要（或希望）在特定时间和地点出席。除了准时出现之外，这里没有“要做的事”。

2. 您需要往返会议

为了确保在这些旅行时间内不会安排其他会议，您添加了两个「不安排」块 (DNS，Do Not Schedule)。这些既不是会议，也不是任务。他们唯一的目的是避免与其他即将举行的活动发生冲突。

DNS 块出现在会议之前和之后，但它们真正代表的是从 10:30 到 12:30 的一整层时间。我们与迈克的对话是「阻塞时间层」之上的「会议层」（下图）。

我们倾向于将日历视为具有互斥时间块的二维网格，但正如本示例所示，并非所有事件都会自动相互抵消。根据它们的特性，它们可以彼此分层级。这意味着我们应该至少在三个维度而不是两个维度来管理时间。

让我们看看是否可以再添加另一层。

正如本章开头所讨论的，阻塞时间和会议都不是任务——但是会议中需要讨论的谈话要点或议程项目又该如何看待呢？

我们现在正在研究三种不同类型的日历事件，每种类型都有自己独特的属性集。问题是我们的日历对所有这些不同的事件一视同仁。他们本身并不区分任务和会议，即使它们是两个完全不同的事物。

当我与 Cron 创始人 Raphael Schaad 讨论这个问题时，他指出了另一个缺失的层：「活动」（Activities）。一项活动会持续很长一段时间，但只需要您在其中的某些时刻集中注意力，而不需要始终集中注意力。

例如，航班应该是具有自己独特属性的本机日历对象，以突出显示关键时刻，例如登机时间或可能的延误。

这让我们想到一个有趣的问题：如果我们的日历能够支持其他类型的「活动」，我们还可以将哪些内容映射到它们上？

04 时光倒流

这个模型曾经出现在我的 Twitter 上：

这个想法的有趣之处不仅在于它引入了另一个独特的日历层，而且该层的数据植根于过去。与传统的日历事件不同，所有这些 Spotify 条目都是在事件发生后创建的。

我以前从未真正注意到的是，我们只使用日历来展望未来，从不反思过去发生的事情。这感觉像是错失了机会。

虽然 Spotify 层看起来更像是一个噱头，而不是一个有意义的生产力黑客，但以日历事件的形式可视化来自其他应用程序的数据的想法感觉非常强大。例如，如果我可以在工作活动的同时查看健康数据怎么办？

我对几乎所有量化自我工具最大的抱怨是它们都是纯输入设备。他们能够收集数据，但无法返回任何有意义的输出。我的 Garmin 手表可以根据我的心率变异性判断我当前的压力水平，但不能判断压力的原因或将来如何预防压力。智能手表缺乏「上下文」。

然而，一旦我将数据与其他事件一起查看，事情就开始变得更有意义了。例如，添加锻炼或冥想课程将为我提供更多背景来理解（和管理）压力。

睡眠是另一个数据层，它在我的日历中比在独立应用程序中更有意义。我已经在日历中设置了睡眠时间（主要作为给其他时区同事的 DNS 备忘录），那么为什么不直接将睡眠质量数据添加到该日历事件中呢？

这样我就可以更准确地提前计划我的一天。经过八小时的睡眠后，你是否已经充满电了？留出更多的专注时间。缺乏深度睡眠？在议程中添加另一个茶歇时间。

这个例子特别有趣，因为它利用了我们日历的所有时间旅行功能。它使我们能够通过研究过去来塑造未来。

一旦您开始将日历视为一台时间机器，它不仅仅涵盖未来的计划，您就会意识到几乎所有活动都可以存在于您的日历中。只要它具有时间维度，就可以将其可视化为原生日历层。

大多数这些数据层孤立起来毫无意义。只有当我们将它们放在一起时，它们才会释放出它们的价值。当你将压力数据（哪种音乐让我平静下来？）、生产力指标（哪种音乐帮助我集中注意力？）或过去的个人活动（怀旧）结合起来查看时，即使是 Spotify 图层也开始变得有意义。

05 小结

这篇文章的要点有两个：

• 日历本身应该区分不同类型的日历事件。任务、会议、阻塞时间和其他活动的外观和行为应根据其各自的属性而有所不同。
  
• 这将为几乎无限数量的其他用例打开大门，这些用例可以以独特的日历层的形式集成到日历体验中。

这些变化不仅会使日历成为上述生产力栈中更强大的重心，而且会变成一种实际的思考工具，时间充当我们未来计划和过去记忆宫殿的「脚手架」。