双链笔记已经不香了?号称 EverythingOS 的「节点标签」笔记来了 #猜猜是谁

写在前面

在介绍今天要讲的这款「新概念」笔记App 之前,请允许我先讲一下,火箭君自己的笔记。

目前,我已经将笔记全部迁移到了本地的 Obsidian 当中。 Obsidian提供了非常实用的「双链」体系。 Obsidian 的链接指向是一个个笔记(文件),这是链接的最小单位,一般来说够用了。

如果,像火箭君一样,喜欢将事情按大纲罗列的话,其实每个大纲的节点也是一个很重要的单位。 下面是我用 Obsidian 的常规套路,内容纯属虚构(显然的)。

大家会注意到,按照层级节点,可以快速分解几乎所有的事情。另外我会习惯在节点后面加上「#标签」。 Obsidian的「标签」机制其实一点也不比 「双链」逊色。 通过标签,我们可以快速将一些文本聚合在一起, 例如在例子中,我们可以快速将所有笔记里面的 #meeting 聚合在一起审视。 也可以查看所有标记沙漏的节点,这也就是基本的「待办清单」了。

所以,我们看到 节点+标签 对于火箭君这类「条理人」来说有重要意义。这点上 OB 已经做得非常不错,直到……

直到最近火箭君最近才拿到了 一款 新概念笔记 Tana 的邀请(很多油管大V两个月前就拿到邀请了),这才顿时有种「原来还能这样」的感觉。

接下去,我就介绍一下 新概念笔记 Tana 的上手体验。

Tana 登场

Tana 是一款很新的笔记 App,目前还在邀请测试阶段。Tana 号称是 EverythingOS,也被称为是「数据库笔记」,我觉得更像是 「节点标签」笔记。

Tana的野心在于:有潜力管理我们身边的任何事情,换言之,将所有事情高度结构化的组织起来

某种意义上来讲,如果我们是一个「讲条理」的人,那么多半会被 Tana 立刻吸引。 更具体一点来说, 如果我们常用 清单类工具, 喜欢幕布或Workflowy之类的大纲工具,喜欢 Roam Research和 LogSeq 之类节点笔记的话, 我们多半会被 Tana 吸引。

节点

Tana 的哲学很简单,所有的事情,都是一个个「节点」。 这个所谓节点(node)就是各位大纲笔记里面的一个 point,也是清单 App 里面的一个 task,牵强一点,也是 row, 也是 line。

节点可以并列,可以互相嵌套,互相引用。 节点嵌套,不是什么新鲜的概念。 我们的文件夹树状结构,也可以看作是文件节点的呈现。 所有信息都是文件(或文件夹),文件(文件夹)可以互相嵌套从属(严格来说,传统的文件结构有父子顺序,不能循环嵌套)。

所以,我们首先要意识到,Tana最革命性的地方在于打破了「笔记」必须是一篇文档的概念,笔记可以是一个节点,亦可是节点的组合(听听就 亦可赛艇)。 可以是父子嵌套节点,也可以是并列的类似的节点或者某类节点的聚合。

  • 比如:可能有一份节点笔记叫做 当日输入 (这是 Tana 默认的节点种类,可理解成 自带 Daily Log 视图),里面有 所有今天输入的内容节点,组成了一个笔记。
  • 比如:一个名为 Launching to Mars 的项目,下面所有的子任务节点项目,组成了一个笔记
  • 又比如:所有的 Project,又能 组成一个项目列表的笔记。

……

因此,节点才是Tana的基本单位,我们传统意义的笔记并不是 Tana 的基本单位, 而是 节点的视图。这是一种「全部打碎,再重新组合」的概念。

我们可以在任何节点下面,引用另一个节点,引用时通过 @开头,填写关键字检索, 类似双链笔记的 [[ 开头检索。 但是, 值得注意的是,Tana 产生的不是传统的超链接,而是被引用节点本身,类似Notion 的「同步块」(Sync Block)。 被引用节点内容可以被立刻呈现,立刻编辑。 这个背后的逻辑还是, 笔记只是节点的一个组织视图, 节点就是节点,无论在哪个视图下,都是同一个节点。

超级标签

这个词 SuperTag, 貌似已经被Tana注册商标了, 可见Tana 对这个概念的重视程度。

当我们把信息打碎到「节点」级别的时候,势必要有一种高效聚合信息的手段。 除了刚才说的「从属嵌套」(大纲)结构以外, 「标签」可能是最好的聚合手段。 Bear 这类App 把标签运用在基于文档的笔记里面,构建一个标签分类体系,代替文件夹体系。 而 Tana 更彻底,把标签运用到「更原子」的节点上。

这样一来,我们说的,所有 #会议记录, 所有的 #重要, #稍后再说, 都可以被 快速聚合起来, 再配合之前所看到的大纲结构,我们几乎立刻可以看到所有项目的大致信息和详细信息。

我曾经在 Todoist 组织自己的任务,按照层级,按照标签,但是很难做好。 按照标签时会丢失层级,按照层级又无法按照标签聚合。而Tana 的「标签」从根本上彻底的解决了这类问题。

数据库笔记

这也是外界给 Tana 的一个常用称号,Tana 把 数据库查询语言的接口暴露给了用户。如果用户有一定的组织和逻辑能力,可以构造自己的数据查询视图。 对于很多用户来说,这点可能要求比较高,但是对于专业用话来说,可能如鱼得水(DB工程师狂喜)。

例如:我们可以自己组织出,所有「#企业级」标签下,关于「#李姐」的,而且提到「元宇宙」字样的笔记视图。

这个功能,我们先就此按住,按照节点笔记的思路走下去,Tana 后续可以玩出很多数据库级别的用法。以后可能要看着参考手册才能玩下去(《MySQL 从入门到删库跑路》这类手册)。

另一个角度来说, 当我们提到Notion 表现出色的 Database 功能时, 很多时候我们是赞叹于:Notion 对检索结果的多种视图展现。 例如: 清单,表格,卡片,画廊 …… 这些 Notion Databse 的 优点,也被 Tana 吸收了。 Tana 可以用多种形式展现节点结果。 所以以前有人和我反复说(有抬杠嫌疑):Notion不是笔记是数据库时,我那时觉得 Notion 最多就是 伪装成数据库的笔记。 其实,Tana 才是真正的 伪装成笔记的数据库

十动然拒

火箭君之前在一款合作小伙伴的笔记产品中建议过 将笔记内容打碎 重新按照 标签和筛选条件组成 新的 「智能文档」。 这个功能的原型,小伙伴也已经做出来了,但是产品本身未能大规模面世,非常遗憾。 而 Tana 的出现,很大程度上实现了我个人的一个夙愿。

尽管我十分感动,但我还是要 「一票拒绝」Tana。不是因为它不优秀,不是因为它理念不够先进,而是因为它是一个「云存储」的在线笔记。 我不是绝对排斥云产品,云产品在我这里只能是一个中间环节,最终的笔记归档,一定要落在我的本地,这也是我选择 Obsidian的原因之一。尤其到了今天,我们应该愈发清醒的认识到,「信息的所有权」是我们在数字世界里,非常重要且少数可以自己掌握的权利。

Tana 如此优秀,结构层级标签一应俱全,是一个理想的「归档体系」。但是,即使内容可以导出到本地,结构层级很可能无法导出到本地,或者说,一旦导出,就会丧失那些节点数据库的优势,除非本地有个数据库。 一考虑到这些,理智的选择就是,不要在一开始就投入太多,防止最后出现「割爱」的痛苦。

通俗来说, Tana 是个好人,但我不配(声明:我不是渣男)。

另一点来说,我觉得大家有必要正视这个可能, 一个 (开源的或不开源的)Tana-like 的本地版本或许是一个潜在的机会。这个本地化的 类Tana App 也许满足不了投资人对 团队协同,AI,数据挖掘的想象, 但确确实实是我们每个个人的福祉所在。 在这之前, Obsidian,LogSeq 都会是很好的选择。

最后

如果各位想尝试 Tana, 需要到官网去,注册等待列表,并等待官方邀请。

总的来说,如果各位答应我 不过度沉溺于 Tana, 不把一切笔记交付给 Tana 归档的话,我就把 Tana 的官网地址告诉大家。Tana 还是非常非常值得各位体验一下的笔记工具。

目前 Tana 还是免费试用, 不过根据内部消息,很快将会根据用户的用量进行收费(这也合理)。

另外,提醒一下,Tana 官网上声称的部分功能,还未完全开放。我觉得,数据层面已经完全准备好了,剩下的只是个实现的时间问题。大家看看即可。

Tana 官网

https://tana.inc/