登录 注册

非常非常想要二级文档树

感谢“二级文档列表”的插件大大 @Misuzu2027）🎉🎉🎉

2024 年 10 月 9 日

在这里夸一下“二级文档列表”的插件大大，别看现在插件市场里的此插件朴素如斯，这几天和大大聊天得到的帮助，实际让二级文档的花样变得超丰富鸟（开心兴奋）

目前插件市场里，这个二级文档插件新增的两三个设计（大家有发现吗？没发现的话提醒一下）

  • 增加了二级文档搜索框 👍
  • 在二级文档里点开文件夹，有“返回上一级文档”按钮 👍
  • 增加了二级文档定位 👍 （文档在二级文档里定位——不用跳到一级里定位展开辣么长的文档）
  • 还有其他设计，大多数都是通过 css 实现的功能，目前还不清楚大大为啥没有更新到插件市场里，但就我个人评测——狠好用！！！从之前的毛坯房到精装修鸟

碎碎念吐槽：多亏了这几天可以上 github 啊，之前真是干着急，开心叉腰转圈

❤️ 感谢大大 @EmberSky

第一个版本已经做出来了 ❤️🎉 🎉

**有需要的小伙伴，请去大大的帖子下二级文档树简略版 _release_v1.0**

  1. 请积极在大大帖子下发布反馈，有沟通才有动力 🎉 🎉🎉
  2. 别忘了给大大点赞收藏送积分表示感谢哦！！！这个很重要！！！😄 😄
  3. 希望各路程序猿大大看到，请积极踊跃加入，让“二级文档树”这个功能变得更好用吧!🙏 🙏

这个真的很重要。

2024 年 8 月 26 日更新

* 这个是楼下评论，👍 某位大大 @Imuvux 写的对于二级文档树的总结——言简意赅，建议可以优先查看。

非常非常想要二级文档树 - Imuvux 的回帖

  • 这两个是 OneNote 的二级文档树的具体介绍
    看完就明白为什么我认为二级文档树很有必要

非常非常想要二级文档树 - Floria233 的回帖

非常非常想要二级文档树 - Floria233 的回帖

* 在此感谢 ❤️ 开始关注“二级文档树”架构的程序猿大大 @EmberSky

非常非常想要二级文档树 - EmberSky 的回帖

旧帖

请问思源未来的文档界面可以升级到类似 OneNote 这种二级文档结构？

页面 mosaicmosaic.png

即左边是层级文件夹，其中每一层都只有 folder file，每点开一层文件夹，其中的 page 则在右边对应展开。

这是传统版本，另一个版本是 uwp，那种两级文件夹在同一侧。

2mosaic.png

如果这种传统 2016 版做不出，uwp 那种也勉强可以啊，总之，二级文档树非常非常想要！！！

偶尔我也很需要传统的笔记方法来管理笔记——不是双链笔记，就是传统的树状笔记，参考 OneNote 或者 Evernote。思源的设计也确实完全支持这种笔记方法，奈何一级文档树架构真是太拖后腿了。上一代笔记软件，印象，有道云，为知，蚂蚁，古早的麦库，无一例外都是这种近似二级文档树的架构设计，其可以存在那么多年，还是有一定用户认可并深度使用着这种功能啊啊（只可惜这些父辈软件无一例外花样作恶不让人省心）。

目前思源的功能对我而言已经非常丰富，完全足够当个主力软件，目前我有一个库就是这种传统的树形笔记文档。（即便是项目文档笔记，我也认为二级文档树架构比一级好太多了）

每每这种时候，思源给我的感觉就就像一个设计先进科技发达的火箭，明明架在高架台上蓄势待发，却唯独缺了可以让它点火升空的航空燃油，没有那玩意儿，这个火箭就算再牛逼，就是飞不起来啊。

之所以提出这种建议，因为我有一个很重要的痛点。

目前使用思源时，左侧文件夹一旦内容变多，那么不管是点开查看，还是翻阅，都会非常非常麻烦。

1 不够直观

折叠的文件夹和文件 page 混在一起，而显示屏的尺寸限制了当前界面所能呈现的文件，一旦有七八十个折叠文件夹，那么就需要不断往下滑动查找。

稍不小心就可能看漏，因此需要反复来回滑动。

靠搜索也完全无法解决这种查看，因为人脑记忆有限，一旦数量达到数十个，我的感受是，很多时候我就连记了哪些内容都需要依赖文档树来回顾，如果不做文档树的层级结构调整和重设，那么这种查看非常非常麻烦-鼠标滚轮都快冒烟了，还容易看漏。

2 不便管理

如 1 所述，单一层级文档树带来的第二个麻烦，一旦文档达到几百个，就连其调整顺序和拖动也变得十分麻烦。

一种场景是：一个 page 在文档树最下面，而我想要挪动到很上层的 folder。

2.1 鼠标法

如果靠鼠标拖动，有时候要拖很久，还容易一不小心误拖到中途某个文件夹中， 这个失误步骤后续带来的两个衍生麻烦是，① 有时候一走神，这个 page 究竟被拖动到哪个错误的 folder 都需要再度查找 ② 即便知道 page 在哪里，也还是需要再度往上托，重复这个漫长无聊的动作（等待文档树自动往上慢吞吞滚动）

2.2 键盘法

如果使用文档树中的“移动”这个操作——

依旧如 1 所述，一旦文档达到数百个，即便使用“移动”选项，那么右键弹出也是“数量庞大的全部文档”，对于选中其中某个特定 page 或 file，使用体验简直是灾难---就跟用鼠标直接往往上拖没什么区别。

这个痛点，目前我只能以文档子目录的方式来解决，效果也不是十分理想。因为子目录毕竟只涉及到文档内容，而我需要的，则是直接对某个文档本身操作。

OneNote2016 这种文档树架构，左 folder 右 note，是我见过的所有文档树设计中最优秀的（只可惜 OneNote 本身槽点太多）。

从我使用的 n 个软件体验来看，这种二级文档树架构，不管是对需要文档树和不需要文档树的人，都是一个完美的兜底，它对于文档层面“管理文档”极其高效。

如果是类似 OneNote 这种两侧文档树层级模式，将文件夹和文档本身分开，那么不管是查看，还是管理文档，其效率都会大幅增高。

ps：我能理解很多大佬使用双链或 tag 来管理文档，但就我的使用体验——

1 这种靠链接来管理方式只适用于当下频繁使用的文档，更接近于项目文档，它需要立刻以某种逻辑结构 or 形式呈现出来。

这种笔记方式一边以链接来管理笔记，一边帮着使用者整理思维，但它一旦应用到超庞大数量的文档时，这种精细化处理就会造成相当的思考成本和记录成本。

关键是，有时候很多内容并不需要这么处理啊。

2 笔记仓库类型这种模式的文档，并不需要太强的逻辑架构，它需要被准备安放在一个特定位置，随着时间流逝，被调取出来，或者被删除，或者被移动。

我有仓鼠症囤积癖啊，有些摘录笔记或者随便写的东西，一时间不想也没法用双链给连接起来，就只想先屯起来。如果每次写一个笔记就要立刻用双链来管理，那么记录笔记的成本就大幅提高了，关键是有些笔记也确实没有重要到需要双链

3 即便是项目文档，当前的这种一级文档树架构，也还是比不上 OneNote 这种二级文档树架构，因为偶尔有些项目文档也是超大型数量繁多，用久之后也还是会遇上我上述问题。

没有二级文档树，思源的使用体验总感觉只能达到 80%，这种无力拍击键盘感。

再 ps：在树形笔记软件中，我知道还有另一个开源的 joplin，试过了，还是思源好用，所以希望思源更好用一点 😄

  • 思源笔记

    思源笔记是一款隐私优先的个人知识管理系统，支持完全离线使用，同时也支持端到端加密同步。

    融合块、大纲和双向链接，重构你的思维。

    22335 引用 • 89371 回帖
1 引用
【重要】二级文档树可以开始试用啦！ • Floria233
4 操作
Floria233 在 2024-10-09 23:54:41 更新了该帖
Floria233 在 2024-08-30 10:56:04 更新了该帖
Floria233 在 2024-08-26 11:00:19 更新了该帖
Floria233 在 2024-08-26 10:57:39 更新了该帖
1 感谢
1 关注
4 收藏
2 赞同
1 引用
4 操作
57 回帖
23
8
8
4
2
2
1.0k 634 393 3 2

相关帖子

优质回帖
  • Imuvux • • 2 • 2 赞同
    订阅者 付费者

    稍微整理了一下。

    二级文档树的功能

    两个面板分别罗列本级文档的相邻文档和本级文档上方父文档的相邻文档。

    • 不需要增加三级、四级文档树，二级文档树的《本层 + 上层》足够产生质变
    • 与父子文档的理念并不冲突
      • 原本文档树的展开变成：将本文档(和同层文档)放到一级面板，其子层文档展开放到二级面板
      • 原本的折叠变成：将本文档(和同层文档)放到二级面板，其父层文档(和父层的同层文档)放到一级面板
      • 进一步优化操作的话可以 Ctrl+左键 展开文档子层，Ctrl+右键 展开文档父层
    二级文档树的作用
    检索文档时增加信息密度
    • 两级文档树可以增加文档上层的上下文信息展示。因为屏幕纵向高度有限，若某一层级文档较多，则单列文档树难以同时查看本文档相邻文档、上层文档相邻文档，而后者具有更宏观的分类视角
    • 文档级别的检索浏览是一个宏观操作，需要有足够大的全局视野在不同笔记分区上快速切换
      • 与文档树 + 大纲的差异：
        文档树 + 大纲 + 编辑器可以实现 文档层次上下文+大纲层次上下文+内容上下文，看上去是并列的不过后两者的作用域更加精细。而二级文档树关注的是更上层的 同层文档上下文+父层结构上下文，具有更高层次的观察视野，并不需要与大纲同时长期显示。
    • 同理，如果需要在某个层级上切换文档时观察其子层文档，不使用二级文档树就需要不断地展开折叠
    • 这一点可以采用文档层级导航插件稍作弥补，但显示效率仍然不如二级文档树；且还是不能解决文档过多时难以用文档树检索的问题
    • 采用文档链接组织 MOC 可以代替文档树的分类功能，但同样存在问题
      • MOC 的文档天然可分屏虽然有利于多视角检索，但不同页签缺乏二级文档树的联动性，还是要手动展开折叠
      • 此外，文档数量较大时 MOC 目录也会变得极其巨大，而拆分 MOC 目录页同样会损失全局预览能力
    移动文档时简化操作
    • 高效的文档切换使二级文档树能大幅提升文档移动体验，参考 MT 文件管理器的双窗口操作
    • 右键移动时同样面临只能查看单列文档树的问题，除非同时显示同层文档和子层文档；此外批量移动时手感同样较差
    • MOC 文档的链接移动起来更方便，但是：
      • 完全不移动文档本体，意味着文档数量不断增加会出现拖累性能的风险，而且不能采用关闭笔记本的方式缓解。而个人笔记这种超长使用周期的工具，即便是潜在的性能问题也会严重挫伤使用动力

    只要想移动文档，二级文档树几乎就是最优解决方案。

  • EmberSky • • 4
    付费者

    我简单想了一下代码逻辑, 覆盖的场景肯定不全, 不过感觉有搞头

    显示二级文档树

    在一级文档树旁边插入一列, 用来显示二级文档树, 大概类似于这样

    image.png

    事件监听

    监听一级文档树点击事件

    1. 获取点击的笔记本 id 和文档 id (可行)
    2. 通过以下 api, 获取子文档列表 (未验证) 
      http://127.0.0.1:59401/api/filetree/listDocsByPath
{
    "notebook": "20240309142729-wq6qzz8",
    "path": "/20240403091024-c8fa15f.sy"
}
    3. 在二级文档树里显示文档列表 (未验证)

    监听二级文档树点击事件

    1. 获取点击的 笔记本 id, 文档父节点 id, 文档 id (可行)
    2. 在一级文档树里找到文档父节点 (可行)
    3. 点击折叠按钮, 让文档父节点展开 (可行)
    4. 点击文档节点 (可行)
  • Floria233 • • 3 赞同
    付费者 作者

    双链就可以辅助摆脱树形的僵化，维基只不过是大型的聚合双链，并不比文档树先进多少。

    甚至于，维基这种形式，最大的应用层面不就是用于“浏览”笔记吗？之所以在网页上看各种百科看得很爽，只是因为“百科”有众多网友一起参与维护数据，也不需要你个人去管理底层文档。管理成本主要是众人一起分摊，也有管理员在背后维护啊，这点你是不是没考虑？

    而 wiki 应用于个人笔记，所有的东西都要自己维护，自己链接，应用于海量数据时，这个管理难度也是海啸级别。光靠文档树都没法单独搞定，所以需要两者结合。

    也有一点是，wiki 这种强调笔记浓缩，写非常干货，写非常有用的东西，笔记被 link，才有意义，而笔记被作为树状组织，难道就没意义了吗？。

    如图，真 wiki 也是有文档树的，这还仅仅只是浏览就需要这种层级文档。

    那么作为个人笔记，一级文档树帮助浏览没问题， 二级文档树来辅助管理文档，这难道没必要？

    维基百科这种索引式，嵌套过度之后--一般到七层，就会非常消耗人的心智。管理成本和回顾成本是指数级别的上升。

    文档树也没有妨碍维基形式啊，作为一个辅助手段，文档树的文档跳跃，比纯粹的 moc 索引高效太多。

57 回帖
非常非常想要二级文档树

欢迎来到这里！

我们正在构建一个小众社区，大家在这里相互信任，以平等 • 自由 • 奔放的价值观进行分享交流。最终，希望大家能够找到与自己志同道合的伙伴，共同成长。

注册 关于
请输入回帖内容 ...
  • zxkmm •
    付费者 支持者 捐赠者

    我比较好奇三个方面

    1. 这种二级文档树布局跟把文档树拉宽之后用插件增大缩进有什么区别？
    2. 如果多级文档树的话，是不是每新开一级都加一列到屏幕上？那是不是加个三四级，屏幕就占完了？
    3. 手机上怎么办，因为手机屏幕宽度按这样的布局最多就只能显示一级。
    2 回复
    1 操作
    JeffreyChen 在 2024-08-24 17:42:23 更新了该回帖
  • Floria233 •
    付费者 作者

    也有考虑过思源的数据库，不过还是那个痛点——数据库适用于内容层面的管理，而不是文档层面，so……我认为文档树真的很重要

  • Floria233 •
    付费者 作者

    回答 1：一级文档树不管怎么拉宽，都是一级，那么在查看和回顾文档时，假设父级文件夹 A 有 100 个文档，父级 B 文件夹有 100 个文档，父级文件夹有 50 个，那么要从 A100 跳转到 G35，就会非常困难，更别说如果子级文件夹内部再度进行嵌套。（想象这是一个漫长的层层展开的竖立阶梯）。当然，这里只是针对传统的树形笔记方法。

    回答 2：多级文档树，参考 OneNote2016 或者印象笔记，将父级文件夹和子级文档切成了两列两面（现在思源这种是一列），点击父级 A 时，文档 A01——A100，是在另一列的子级文档界面展开的。每点开一级，不会新增一列，而是根据父级文件夹的跳转，对应呈现每个父级下的文档（父级文件夹，怎么也会比子级文档少太多了）永远都保持两列。

    回答 3：我目前想到的是，① 参考有道云或者印象上的二级树在手机上是怎么显示，思源也就那样显示（这个没有什么专利版权）——在手机上通过跳转，永远只在界面上显示子级文档，父级默认收缩。② 这种二级文档树，适合于横屏或者平板使用，之所以提出，因为这种设计在使用上的便利，远远超过了其显示的不便利。③ 这种二级文档树不一定非要覆盖现在的一级文档树设计，（现在的一级文档树设计好像是写在设计代码里强制展现的吧），这种二级文档树可以以选项模式呈现，区别应用于 pc 与移动端。

  • EmberSky •
    付费者

    没体验过 onenote, 不过我也好奇一点, 你想要的第二级的文档树跟大纲有什么区别

    针对楼主的需求, 有几个不成熟的小建议

    1. 找文档可以使用搜索功能, 过滤类型只勾选文档, 像这样 image.png

    2. 推荐双链功能, 有关联的都链一起

    3. 推荐一个插件, 显示子层文档的

      image.png

      image.png

    1 回复
  • EmberSky •
    付费者

    左侧文件夹一旦变多, 不管是点击查看, 但是翻阅都非常麻烦

    这句话深有同感, 我也经常会遇到一直滑动鼠标, 鼠标滑冒烟的情况

    所以, 我想到了另一种交互: 上层目录自动冻结, 就是 excel 里面的那种冻结
    这种效果在 vscode 里面有, 像这样

    image.png

    往下滑, 冻结就变成三层目录了

    image.png

    1 回复
  • Floria233 •
    付费者 作者

    1 找文档的前提是——我得记得这个文档大概是什么吧 😂 如果文件达到了成百上千，搜索出来的可能也是成百上千，所以搜索效率太低。我真正的需求是——通过文档树树管理文档本身。

    2 双链的内容我在文中说过一点了，双链我一般都是精细思考和其他笔记如何连接的，但有些就只是单纯的摘录笔记，其一没有连接的必要，其二链接这种管理方式，在应对数量庞大的笔记文档时，很有点力不从心。

    3 子层文档我也使用了，这个的问题依旧是第二条，如果一个文件夹里面有一千条文档，那么不管怎么使用这个插件，其核心问题还是——文档太多，跳转和查看非常困难。并且利用插件来跳转到对应文档，也还是不能解决我管理文档的问题（如果说只是简单管理，那么就用现在的一级文档树慢吞吞去拖也可以，但如果想要高效方便，就只有二级文档树了。区别在于好用和难用）

  • Floria233 •
    付费者 作者

    相信我，一级文档树和二级文档树，并不是简单的树形设计区别，它实际是质变和量变的差异，如同汽车和马车，看着都是四个轮子，体验有云泥之别。这个差异，并不能通过简单的收缩父级文件夹来解决。因为只有二级文档树可以解决“高效切换文件夹和文档”这个问题，一级文档树因为它只有一列，这种先天不足的短板设计，让它就是没法提升效率。

    1 回复
  • EmberSky •
    付费者

    我刚刚试了下, 在显示二级文档树的前提下, 再显示大纲, 主文档确实有点窄

    1 回复
  • Floria233 •
    付费者 作者

    大纲是可选显示项，不是所有文档都需要大纲。而二级文档树在文档管理上的效率，是不可替代的。

    另外，文档树的设计肯定也会兼顾到大纲，我的想法是——左侧 folder，右侧上方是大纲（如果需要显示的话），大纲下方是子文档。思源有一个设计我觉得特别强，就是其中很多小部件可以根据自己的心意放在不同的地方，大纲也可以拖动到左侧，放置在 folder 下方。这些都是可选项模块，与二级文件数的界面设计并不存在“有你无我”的设计冲突。

    好像大纲这个界面是不是可以调整宽度大小？文档树也可以调整大小的啊，这样的话，主编辑器应该没那么窄了

  • nulide2333 •
    付费者

    我也不清楚为什么没有二级目录，真的是很需要这个功能。

  • JeffreyChen •
    付费者 支持者 捐赠者

    这个对思源来说应该没什么用，因为思源只有一层笔记本。

    p.s. 还是为了能够关闭部分文档才设计的一层笔记本，否则会跟 Notion 一样一层都没有

    1 回复
  • zxhd86 •
    订阅者 先知

    第一个问题是不够直观，但我挺好奇在这种情况下——指笔记很多的情况下，onenote 有何优势呢？就是它跟你不创建子文档，笔记本作为一级，笔记内容直接就是二级，它的区别在哪？

    第二个问题，同上，二级文档树的优势在哪？就是 onenote 会快吗？思源我记得是可以直接文档树右键选择移动进行移动的，对于你的问题，实际上可以先移动移动到指定的文档下，然后再移出来，变为它的上方或下方，OneNote 有什么更简单的方案吗？

    你在提出一个颠覆性的要求，虽然在构架上并不是不可能实现，但是你的理由目前在我看来还不是很充足。

    1 回复
  • Floria233 •
    付费者 作者

    思源又不是纯粹的类 notion，不知你是如何看待思源，我最开始选用思源，不是用它来替代 notion，而是用它来替代 obsidian。

    • 我选笔记软件的原则是，只看它的长板。如果我需要 notion 那类的 database，我更倾向于直接用 notion 或者 remnote 或 flouws 类似
    • 如果只是一款笔记记录软件，思源在我这里的主要优势，只能和 obsidian 的文本编辑这个功能相比较，即，在类 ob 设计架构下，在大文本编辑处理这种使用场景下，思源是比 ob 好用太多的国产软件。
    • 而作为一款笔记文档管理软件，思源较之 ob 的不足处，就是差了一个二级文档树架构。ob 本体也没有二级目录，但它有一个 filetree 插件，可以勉强凑活使用。而思源明明具有和 ob 一样的潜质和实力来管理大量 page，却因为它目前的这种一层文档树结构设计，硬生生限制了这个方向的发展——一层文档树在管理 page 方面，就是比不上二层文档树，传统的树形目录至少在“管理大量文档”这个层面，绝对是经受住了使用者的考验，否则印象笔记也不会在市面上活这么多年了。
    • 类 notion 的软件，我不认为其是文档管理软件，它最重要的，还是将各种原子数据以不同维度来呈现，说来说去都是在描绘一个东西。而且它即便可以用来管理文档，有一个非常严重的问题也必须注意，那就是这种笔记软件迄今为止都没有很好的离线本地方案，所以无法让人安心投入大量笔记，即便有 anytype，它也不是很好用。思源在 database 的易用性方面并比不上 notion，我不认为这是缺点，思源作为本地笔记软件，有一个简易的数据库，也可以用来辅助文档管理，这就够了。
    2 回复
  • JeffreyChen •
    付费者 支持者 捐赠者

    思源的设计很多参考了 Notion ，事实上就是作为 Notion 替代品，也抛弃了 .md 和传统的文件夹成为父子结构的块编辑器。

    架构应该是不能变的了，你的需求只能通过制作插件来满足。

    p.s. Obsidian 能实现是因为它基于文件夹和 .md ，跟思源的父子文档结构有本质不同

    不过话又说回来，思源管理文档是真的麻烦，我觉得需要有更合理的解决方案。

    2 回复
    2 操作
    JeffreyChen 在 2024-08-24 23:27:51 更新了该回帖
    JeffreyChen 在 2024-08-24 23:27:18 更新了该回帖
  • Floria233 •
    付费者 作者

    2024 年 8 月 24 日 23:08:20

    • 二层文档树这个设计本身其实是很好的。有问题的是那些上代笔记，它们只是提供了笔记的“储存”功能，没有想出或者提供一个很好的“如何利用笔记”这个功能，使得记笔记只是一种静态活动，一旦收藏就会吃灰。
    • 现在这一代的 ob 思源 flowus 等等，让笔记连接起来，增加笔记的活跃度，这主要的卖点不就是加上一个“双链”，供以弥补上代树形笔记软件在“利用笔记”层面的短板吗？专注“双链”固然不错，但创新的同时有必要把过去的东西一棒子打死吗？
    • 新一代的笔记软件，似乎都对“文档树架构”这个东西，避之不及，好像用了这个架构就会使笔记体系僵化，其实怎么可能呢？既然已经有了“双链”这个功能，笔记如何利用的问题已经解决，双链加上目录树架构，完美解决了笔记在“管理”+“使用”两个方面的问题，然而现在的笔记软件却忽然集体砍掉文档树功能，使得 page 管理变得非常困难，让人不得不把一部分笔记继续放在传统的笔记软件里。
    • 其实就是，有很多人像我这样，很喜欢记录各种乱七八糟的玩意儿，这些东西在当下这个时刻或许根本就不重要，只是一种吐槽或者简单备忘，不是那种可以直接打印出来写成书的正式 note，这种不正式的笔记条儿（不是碎碎念啊）或许在未来才需要整理甚至删掉，在这种情况下，双链是不必要的，文档树把它存在一个固定位置是很有必要的。如果只用一层文档树，那么后续这种乱七八糟的笔记，其调整位置，其查看位置，就是用鼠标爬天梯般的痛苦。
    • 甚至于，即便对于正式 note，双链固然可以很方便引用文档，但如果 page 太多了，引用跳出来的链接也会非常非常多，这种时候，与其用【【这种来引用，还不如直接去文档树里面复制一个链接再跳回来插入呢。在这种场景下，二级文档树，也比一级文档树要方便多了。
    • 只有双链而无文档树，这还会导致另一个问题，即如果文档太多，你自己都不记得什么是什么的情况下，只用【【来引用，看似是可以唤起记忆，也有可能造成记忆负担。毕竟不是每个人都擅长文档编码，或者一开始就能规划好一辈子的笔记体系架构，那么引用跳出来的内容，实际也可能乱七八糟。再说一遍，还不如去文档树复制链接。
    • 没有文档树辅助管理文档，双链用到最后，会使得整个库的文档笔记彻底乱掉，这时候继续仅靠一级文档树来管理 page，其困难度也远远大于二级文档树。如果有二级文档树这种比较简洁管理 page 的界面，有可能大家在记笔记时顺手就把 page 给整理了，而不是堆积成一座笔记山再来整理。
    • 双链可以用于处理特定的重要的项目文档（精细化处理），文档树可以作为仓库管理所有文档（粗放式管理），双链对应着新一代的笔记软件，文档树对应着上一代的笔记软件，这两者本可以相得益彰，完美解决笔记在“管理”+“使用”两个方面的问题。现在的笔记软件，则强行要求大家只用“双链”来管理文档，一旦碰上千位级别的文档，实在是小牛拉大车，心有余而力不足。（就说一句话，那个闪闪发光的网球图，真会比文档树直观好用么？）
    1 回复
  • JeffreyChen •
    付费者 支持者 捐赠者

    我跟你的情况有点不同，我很不习惯用纯 Markdown ，我是把思源当本地版 Notion 用的

  • JeffreyChen •
    付费者 支持者 捐赠者

    我感觉双链不如文档树结构稳定，也不容易迁移，所以我主要也是用文档树来管理文档的。隔一段时间就要重新整理一遍文档树。

  • Floria233 •
    付费者 作者

    因为思源可以分库，所以我有好几种用法，最常用的是 moc 这种数据库，我认为它是最好用的。

    其次用思源来替代 obsidian，即当做树形文档仓库，这种时候，二级文档树的需求就无比强烈了。

    其实也可以用 notion 形式来管理文档，估计我强迫症太严重，经常会对文档本身删除移动，所以对我而言，notion 的数据库架构只是一种用来描绘笔记的方式，区别于 moc。😄

    但无论哪种情况，那个【【引用链接，总感觉只能用于少量 page，一旦 page 太多，这功能就有点废。

  • Floria233 •
    付费者 作者

    不懂就问。

    OneNote 和 evernote 甚至于有道云，似乎也不是文件夹，它们有些倒是可以导出 MD。那么思源这种，究竟是底层架构代码来决定目录树呢？还是 UI 设计决定目录树呢？既然都能做一层，那么二层的话，改 UI（估计挺费活）难道不可以吗？

    参考之前我提到的文档树气泡问题，D 大也是没解决，最后还是靠插件大佬给搞定的，头疼。

    1 回复
  • Imuvux •
    订阅者 付费者

    赞同帖主，二级文档树对于依靠文档树进行笔记管理的用法确实是点睛之笔。个人理解，二级文档树的核心特质其实是增加了文档层级的“上下文信息”，能够同时展示子层文档和上层文档的相邻文档，在文档树中翻阅文档时可以同时查看目录和目录的目录。这个功能和大纲面板相似的地方在于，有了大纲面板既能在编辑器看到当前内容的上下文，又能在大纲中看到当前内容所属大纲层级的上下文。但是大纲层级与正文是非同质的所以做二级面板没有意义，而文档和子文档是同质可嵌套的，增加二级面板有利于快速切换观察视野，所以二级文档树确实能为文档检阅体验带来本质跃升。

    遗憾的是思源本身没有鼓励使用者用文档树做笔记管理，很多人倾向于用链接 MOC 管理笔记文档，可能不太会把二级文档树功能给做出来了，毕竟采用「正向引用」组织目录结构确实可以解决很多问题。题外话，与其他软件相比感觉思源笔记其实也只是比毛坯房好一点而已，可能也就是不那么毛坯的毛坯房，怎么用都得各种将就。

    1 回复
  • JeffreyChen •
    付费者 支持者 捐赠者

    思源这个文档树是后端和前端代码共同决定的，要改的话只能全改了，而且没法保证改了代码之后不出错。

    当然了，思源没有文件夹本身就是底层设计来的，所以这一块是不能动的，动了就不能兼容不同版本的数据了，有可能损坏用户的工作空间并且无法恢复，破坏力太大。

  • Floria233 •
    付费者 作者

    没有二级文档树，思源就是个飞不起来的火箭，十全十美的软件固然没有，但在 21 世纪还要用马拉汽车也着实让人心痛。

    如果有二级文档树这种设计，思源的使用潜力瞬间可以暴涨 n 倍，就我看来，有二级文档树加持的思源，大概可以轻松干掉所有传统笔记软件，又在新一代笔记软件里，占据独一无二的生态位——文档管理 + 数据链接 + 文本编辑。目前来说，市面大多数软件只能取其二。

  • fang1234 •

    我也觉得二级文档树挺需要的，目前也是用第一级父文档存放子文档的链接目录，勉强接近二级文档树的功能。好在每一层文档笔记都不算太多，最多也没超过 100 个。勉强够用。

    1 回复
  • Floria233 •
    付费者 作者

    就是说，没有二级文档树，就从物理上让人必须自我限制大数量文档啊，哈哈 😂 所以我才说思源自我限制了潜力。

    二级文档最重要的功能，其实就是方便自由拖动文档，这个是目录功能没法替代的。so……

  • Floria233 •
    付费者 作者

    其实暗戳戳说一点，既然 D 大他们开始最开始是学 notion，当然恐怕也是受了 notion 的误导，这才主推双链。文档树这东西，不是大家不需要，而是一直没人做吧。这个逻辑因果不能弄混啊。我是最近深切感受到了，文档树对于管理文档多么有用啊，所以才提出来的。因为这新一代的笔记软件，基本都没有个好用的文档树，害得我一直在不断寻找文档树架构的笔记软件，大厂做的基本上都不理想，好不容易有个 joplin 其实可以凑合，然而无论如何，一看到 joplin，我就深深扼腕为啥思源没有二级文档树呢？这样我就不必把各种笔记到处分家了啊。

    1 回复
  • JeffreyChen •
    付费者 支持者 捐赠者

    我个人反而更喜欢 Notion 的这种父子文档结构，在文档树里能够直接体现父子关系。

    p.s. Notion 摒弃了传统的文件夹结构，其实应该是更现代的。以前的笔记软件基本都是有文件夹的，近几年的笔记软件很多都是这种父子文档结构了。

  • JeffreyChen •
    付费者 支持者 捐赠者

    我突然想起来，这种父子结构也不是什么新东西，网页就是这种父子结构的。

    xxx.com 是父页面，xxx.com/aaa 和 xxx.com/bbb 就是子页面。

    1 回复
  • Floria233 •
    付费者 作者

    是的。其实二级文档树，实则是更强化的父子结构，在界面设计上更直观，这种直观，在使用时就是绝大的生产力。notion 的结构，如果从双链局部来看，也挺直观，但它做不到直接对文档进行调整操作啊。二级文档树最重要的本质，我认为就是可以非常方便把文档拖来拖去，除了文档树，其他的任何结构都不太容易做到这点。

    1 回复
  • JeffreyChen •
    付费者 支持者 捐赠者

    那么在文档树的结构已经不能动的前提下，追求更好的体验就需要优化当前的文档树，让它更方便拖拽和移动

  • angriest •
    订阅者 付费者

    我也是比较习惯使用层级目录管理文档，目前把文档当做目录，整体休验还可以，主要差异是：1、习惯点击目录弹出下级菜单，但点击文档是转到文档，有些是空文档，没有跳转链接（子文档是手动从文档树中新建的，上级文档没有链接），需要再在文档树中点击箭头来展开 2、同级目录内，文档和文件夹按名称混排，不过有图标可以分清哪个文档是有子文档的。这样比起传统的二级目录也有好处，就是可以实现无限层级的子目录，不受限于只有二级。如果楼主痛点是同级目录下文档太多，是不是可以考虑把每级目录下的文档做整合，把每级目录控制在 10 个以内，太多的文档就再做分类，感觉还是可以接近目录的使用体验的。也提个建议是，如果文档包含下级文档，可以自动生成目录链接，当下级文档变化时，自动更新目录（飞书支持该功能），这样就能够更好的把文档当做目录使用。

    image.png

    image.png

    1 回复
  • angriest •
    订阅者 付费者

    image.png

    image.png

    补两张飞书的图，实话说，飞书文档，除了不能本地离线管理之外，整体体验非常好，交互简洁，功能强大，可以借鉴学习

    1 回复
  • Floria233 •
    付费者 作者

    就我对文档管理的看法，我认为文档树和文档目录还是有点区别。

    文档树更像货架，矿泉水和泡面可以摆在一起，也可以不摆在一起，而文档目录，则强制要求矿泉水和矿泉水在一起，泡面和泡面在一起。

    文档目录我是用 moc 来进行索引，即如果在需要某些笔记时，就直接创建索引笔记，将需要的笔记以 moc 的形式放进去。

    真痛点不是文档太多，而是目前的一级文档树这种设计，造成文档的增熵，只有二级文档树是最简便有效的解决方式。

    你说的这种方式，我也在用，但我感觉这种只能应对于数量不多的文档，或者内容属性相近的文档，或者目前正在频繁使用（熟悉）的文档，即项目笔记。

    而一旦达到跨学科跨门类这个层级，这种管理方式会造成一级文档树的目录非常非常长——其实还有另一种解决方式，就是分库，但分库的话，就相当于把一个房间里货架上的商品，分割放置到了不同房间的货架上，卡片笔记法我认为精华的一点是不同领域的碰撞，分库的话，就是人为阻断了领域的联系，分库可以辅助在某个学科领域的深入研究，但却不利于激发出“创新”这种东西。说起来，就是树形和网状的区别。

    现在思源的网状框架做得很好啦，但这个树状，真是一言难尽。就算卢曼是靠卡片笔记来做研究，难道没人注意到，人家的卡片笔记也是分条缕析规规矩矩放在不同的卡片盒里吗？卡片本身是网状，但管理卡片的卡片盒，放到电子笔记领域，实则应当就是树状啊。

    现在的问题是，一级文档树在管理文档层面，没有二级树方便。这种堪比物理层面的限制，不是通过目录大纲可以解决的。（就好比说，卢曼的小纸片确实是放在一个个盒子里，但人家的盒子也不是从地面堆高一排直通天花板，而是上下左右堆成一个高度合适的类似货架的排布）zettelkasten0.jpeg

    文件夹就相当于一个个小盒子，文件夹下内部的文档就是卡片，一级文档树就是天梯叠叠乐，二级文档树就是货架堆叠法，哪种更容易取用，应当是一目了然。

  • Floria233 •
    付费者 作者

    2024 年 8 月 25 日 12:31:18

    补充说明一下，为什么我觉得 OneNote 这种二级树架构非常强。

    如图所示：

    左边窗格是笔记本，大笔记本之下，还可以嵌套笔记本组

    第二张图：

    中间这一堆蓝色红色绿色小窗格，是左边某个具体笔记本窗格的横向展示，即如果左边笔记本也超级多，那么在左边选定某个特定笔记本后，其下 page 有两种同时呈现方式。

    第一种就是画面中央这些横向小窗格，第二种就是右边这种小 page

    第三张图：

    右边窗格，呈现的是某个具体笔记本下的 page，这些 page 之间还能够继续降级 + 折叠

    捕获.PNG

    so，OneNote 通过二级文档树的排布，加上对每级文档的自由缩进与拖动管理，实现了非常高效的文档管理。

    我不深度使用用它，主要原因就是它没法自由导出，只能困在.one 这种笔记格式里。

    这种架构要是能和思源的双链功能结合起来，记笔记和用笔记的体验感，简直要起飞了，哈哈哈

    2 引用
  • Floria233 •
    付费者 作者

    飞书感觉还是太公务化了，除了办公室的用得上，有很多普通人要的小功能，它并不具备。

    飞书的这种管理方式，我感觉是不是在思源有“子目录文档”这个可以替代？只是不够详尽。

    而且，不能本地就是“硬伤啊”，不能本地没有安全感 😂

    真要说文档管理，没有二级树直观，也没有二级树取用方便——拖来拖去的那种随心所欲

  • Floria233 •
    付费者 作者

    非常非常想要二级文档树 - Floria233 的回帖

    您好，这个回答我觉得应该可以回复您的问题。

    二级文档树，将父级 folder 和子级 page 切分成为两块。

    这种设计，在信息层面，确保了在最小范围内尽可能呈现了更多的信息（父子层级 + 父子各自文本内容），信息密度最高。（同一块屏幕，二级树就是比一级树呈现的信息多啊）

    在操作层面，folder 可以在父级界面自由上下拖动，page 可以在子界面上下自由拖动，也可以从所属的父级 A 直接拖动到父级 B，或者更远的父级 Z，这个操作下，鼠标的操作动作最少，鼠标的滑动长度最短，滚轮使用频率最低。

    如果是一级文档树的话，这种超长距离的文档整理，就只能依靠您说的“移动”功能达成，如果有 50 个文件夹，每个文件夹下 100 个文档，“移动”选择目的地时，这个“文档选项”同样非常长，容易误操，也很增加心智负担（毕竟文档太多，层级太复杂，需要仔细看），更不用说移动之后还得有后续操作。而二级文档树是一步到位，直接从原位置拖动到目的地。

    这种二级树状结构，是改进一级文档树对文档的管理方式，双链是另一种以数据库形式来管理文档，两种方式应该自由选用，而不是非此即彼，两者结合应该是锦上添花。

    我猜想您说的“颠覆”，是否是认为，文档树的出现，可能使思源这种数据库笔记软件，回退到传统的印象有道云那种树形笔记软件领域内？

    我的想法是，“双链”功能已经被证明在“利用”笔记方面的可取之处，现在诸如有道云笔记这种老牌笔记软件，也在添加类似“双链”的功能，同时还保留了二级文档树。

    那么文档树出现在思源中，实则也不会影响双链这种新型管理方式的发展。

    不过经由昨天有答主给我的科普，您说的“颠覆”，可能也仅仅是软件层面的设计和不兼容，这种颠覆？😄

    1 回复
    1 引用
  • science •

    大家好不容易才摆脱树状文档的束缚，怎么可能又开倒车回去呢？这么跟你说吧，未来的笔记软件和笔记方法会越来越靠近维基百科

    1 回复
  • Floria233 • • 3 赞同
    付费者 作者

    双链就可以辅助摆脱树形的僵化，维基只不过是大型的聚合双链，并不比文档树先进多少。

    甚至于，维基这种形式，最大的应用层面不就是用于“浏览”笔记吗？之所以在网页上看各种百科看得很爽，只是因为“百科”有众多网友一起参与维护数据，也不需要你个人去管理底层文档。管理成本主要是众人一起分摊，也有管理员在背后维护啊，这点你是不是没考虑？

    而 wiki 应用于个人笔记，所有的东西都要自己维护，自己链接，应用于海量数据时，这个管理难度也是海啸级别。光靠文档树都没法单独搞定，所以需要两者结合。

    也有一点是，wiki 这种强调笔记浓缩，写非常干货，写非常有用的东西，笔记被 link，才有意义，而笔记被作为树状组织，难道就没意义了吗？。

    如图，真 wiki 也是有文档树的，这还仅仅只是浏览就需要这种层级文档。

    那么作为个人笔记，一级文档树帮助浏览没问题， 二级文档树来辅助管理文档，这难道没必要？

    维基百科这种索引式，嵌套过度之后--一般到七层，就会非常消耗人的心智。管理成本和回顾成本是指数级别的上升。

    文档树也没有妨碍维基形式啊，作为一个辅助手段，文档树的文档跳跃，比纯粹的 moc 索引高效太多。

    1 回复
  • Imuvux • • 2 • 2 赞同
    订阅者 付费者

    稍微整理了一下。

    二级文档树的功能

    两个面板分别罗列本级文档的相邻文档和本级文档上方父文档的相邻文档。

    • 不需要增加三级、四级文档树，二级文档树的《本层 + 上层》足够产生质变
    • 与父子文档的理念并不冲突
      • 原本文档树的展开变成：将本文档(和同层文档)放到一级面板，其子层文档展开放到二级面板
      • 原本的折叠变成：将本文档(和同层文档)放到二级面板，其父层文档(和父层的同层文档)放到一级面板
      • 进一步优化操作的话可以 Ctrl+左键 展开文档子层，Ctrl+右键 展开文档父层
    二级文档树的作用
    检索文档时增加信息密度
    • 两级文档树可以增加文档上层的上下文信息展示。因为屏幕纵向高度有限，若某一层级文档较多，则单列文档树难以同时查看本文档相邻文档、上层文档相邻文档，而后者具有更宏观的分类视角
    • 文档级别的检索浏览是一个宏观操作，需要有足够大的全局视野在不同笔记分区上快速切换
      • 与文档树 + 大纲的差异：
        文档树 + 大纲 + 编辑器可以实现 文档层次上下文+大纲层次上下文+内容上下文，看上去是并列的不过后两者的作用域更加精细。而二级文档树关注的是更上层的 同层文档上下文+父层结构上下文，具有更高层次的观察视野，并不需要与大纲同时长期显示。
    • 同理，如果需要在某个层级上切换文档时观察其子层文档，不使用二级文档树就需要不断地展开折叠
    • 这一点可以采用文档层级导航插件稍作弥补，但显示效率仍然不如二级文档树；且还是不能解决文档过多时难以用文档树检索的问题
    • 采用文档链接组织 MOC 可以代替文档树的分类功能，但同样存在问题
      • MOC 的文档天然可分屏虽然有利于多视角检索，但不同页签缺乏二级文档树的联动性，还是要手动展开折叠
      • 此外，文档数量较大时 MOC 目录也会变得极其巨大，而拆分 MOC 目录页同样会损失全局预览能力
    移动文档时简化操作
    • 高效的文档切换使二级文档树能大幅提升文档移动体验，参考 MT 文件管理器的双窗口操作
    • 右键移动时同样面临只能查看单列文档树的问题，除非同时显示同层文档和子层文档；此外批量移动时手感同样较差
    • MOC 文档的链接移动起来更方便，但是：
      • 完全不移动文档本体，意味着文档数量不断增加会出现拖累性能的风险，而且不能采用关闭笔记本的方式缓解。而个人笔记这种超长使用周期的工具，即便是潜在的性能问题也会严重挫伤使用动力

    只要想移动文档，二级文档树几乎就是最优解决方案。

    1 回复
    1 引用
    1 操作
    Imuvux 在 2024-08-25 19:11:49 更新了该回帖
  • science • • 1 评论

    要做到你设想的二级文档树很难吗？看看我在 wolai 中搭建的。完全不需要所谓的“二级文档树”

    image.png

    这个不是二级文档树吧！右边那个不是叫“标题目录”吗？思源里被叫做“大纲”。文档树，指的是文档本身可以自由拖动。我放的这张图里，OneNote 右边窗格的文件，可以被自由拖到左边任何一个文件夹里。
    Floria233 •
  • Floria233 •
    付费者 作者

    木错儿。堪称全文总结。

    树形可以以最小成本存放文档，二级树形，可以以最小成本管理文档。

    wiki 也好，moc 也好，还有建主页 homepage 也好，这些以 link 为主导的数据管理方式，都需要高昂的维护成本。不是不能用，只有应用于重要项目时，性价比最高。

    树形与 link 搭配使用，应当是如虎添翼，目前的一级树形，实则是拖累了 link 功能的全部发挥。

  • zxhd86 •
    订阅者 先知

    我对于功能理念之类都是无所谓的，毕竟大家记笔记的习惯各不相同，所以各有所好。只是说这个东西实现起来并不简单，所以才说是颠覆。

    关于移动……这个东西是可以直接搜索过滤的，我觉得这无论怎么说也不能说慢吧。

    图片.png

  • EmberSky • • 4
    付费者

    我简单想了一下代码逻辑, 覆盖的场景肯定不全, 不过感觉有搞头

    显示二级文档树

    在一级文档树旁边插入一列, 用来显示二级文档树, 大概类似于这样

    image.png

    事件监听

    监听一级文档树点击事件

    1. 获取点击的笔记本 id 和文档 id (可行)
    2. 通过以下 api, 获取子文档列表 (未验证) 
      http://127.0.0.1:59401/api/filetree/listDocsByPath
{
    "notebook": "20240309142729-wq6qzz8",
    "path": "/20240403091024-c8fa15f.sy"
}
    3. 在二级文档树里显示文档列表 (未验证)

    监听二级文档树点击事件

    1. 获取点击的 笔记本 id, 文档父节点 id, 文档 id (可行)
    2. 在一级文档树里找到文档父节点 (可行)
    3. 点击折叠按钮, 让文档父节点展开 (可行)
    4. 点击文档节点 (可行)
    1 回复
    1 引用
  • wilsons •
    付费者 捐赠者

    👍 期待大作

    这个搞成了，绝对很多支持者，💪

    1 回复
  • EmberSky •
    付费者

    话说, 我一个后台菜狗, 感觉得做好久 😂

    1 回复
  • wilsons •
    付费者 捐赠者

    好菜不怕等，你可以的。💪

    感觉思源对插件开发者的激励不够，大佬们没有动力。

    况且中国人没有老外那闲功夫。

    插件开发者们是生态的重要参与者，我觉得应该足够重视。

    1 回复
  • EmberSky •
    付费者

    况且中国人没有老外那闲功夫。

    这个深有同感, 每天加班累成狗, 平时根本不想动

    话说, 本来我准备去研究插件来着, 总感觉直接上 js 代码不优雅

    f9913dbea29fe58f4818fc9aa3d3289b.jpg

    1 回复
  • wilsons •
    付费者 捐赠者

    是的，所以，中国人能业余写插件，写开源的才是真爱，那些整天鼓吹老外的也不看看国情，如果国内有那福利和大环境，生产力也不比老外差。

    相信每个人都是有情怀的，但大多数人都被现实打败，好的环境，能让这种情怀者更多，更持久。

    我觉得插件其实和 js 差别不大，无非多了一些有限的 API 而已。在某些操作上可能使用内置方式更方便，不易冲突，兼容性更好，更优雅。

    1 回复
  • EmberSky • • 1 赞同
    付费者

    更优雅说服我了

    我想搞插件唯一的原因就是, 配置可视化

    现在想想, 管他黑猫白猫, 有用的才是好猫

    非专业的去搞插件, 肯定要花好多时间, 有这些时间, 不如多搞几个 js 代码片段

    2 回复
  • Floria233 •
    付费者 作者

    赞同。二级文档树最重要的，还是其本身界面架构的重设，至于“配置可视化”，目前插件市场有个大佬所做的“文档树”插件，实则已经对目前的一级文档树有了很多配置，可以与之联动，这样就可以减少不少功夫。

  • wilsons •
    付费者 捐赠者

    哈哈哈，插件远没有你想象的那么难，反而比 js 更方便些，虽然我还没用过思源的插件 API 去开发，但看过文档和示例，感觉和 ob 等其他系统的插件差不多。

    如果仅仅可视化不用插件也可以实现，之前我分享了这个帖子 js 代码片段模拟 window.prompt 函数 ，这个功能就是为可视化配置服务的，之前有个 js 需要用到界面配置又不想搞插件就用的这个。

    我之所以不用插件就是不想动不动安装几百 m 的 node 模块，我之前用 ob 完全无 node 环境下开发插件，思源也可以，只是还没人总结一套完整的方法，空了再研究，等搞好了再用插件，不过感觉现在用 js 已经实现了自己需要的大部分功能，感觉这个还得延后了，😄。

请输入回帖内容 ...
Floria233
回帖
120
 帖子
27
 积分
1521