登录 注册

非常非常想要二级文档树

感谢“二级文档列表”的插件大大 @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，试过了，还是思源好用，所以希望思源更好用一点 😄

  • 思源笔记

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

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

    22020 引用 • 87823 回帖 • 3 关注
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
942 611 325 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 回帖
非常非常想要二级文档树

欢迎来到这里！

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

注册 关于
请输入回帖内容 ...
  • 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 引用
  • 其他回帖
  • Floria233 •
    付费者 作者

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

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

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

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

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

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

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

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

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

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

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

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

    稍微整理了一下。

    二级文档树的功能

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

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

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

    1 回复
    1 引用
    1 操作
    Imuvux 在 2024-08-25 19:11:49 更新了该回帖
  • Floria233 •
    付费者 作者

    默哀一下难兄难弟，来自 logseq 论坛的吐槽。一个文件夹体系的折衷方案，求大佬考虑开发相关插件 - 插件 - Logseq 中文社区

    logseq 话说不知为何，我也经常感觉一言难尽，简言之，就是将其当做一个思维大纲的草稿软件，其他的酷炫设计，一个也没用过。

    看了这个帖子，我再度意识到，文件夹这个需求根本就不是伪需求（膨胀）。很多人有着与我类似的使用体验——没有文件夹就不行，没有文件夹，做笔记就很艰难。

    现在的笔记软件一个个为什么非得去掉文件夹功能呢？

    之前看到过一篇大概意思为“笔记软件应该是什么工具？”的公众号，其中讲到——

    世上没有 all in one 的笔记软件。

    即便世上有某种可以指导 all in one 的笔记理念。

    理念层面的问题是——

    用来指导的理念，总有时效性，不能完全覆盖时空。

    用来指导开发者的理念，实则经常是开发者自己的二次解读。

    所开发的工具，与其说是适配原作“all in one”的理念，不如说是迫使使用者，逐渐熟悉且适应开发者所理解的“理念”。

    能适应，就能愉快得用下去，适应不了，水土不服就只能逃。

    现在市面的情况是——

    各家的设计理念互相借鉴。

    像素级别的借鉴会被称为抄袭，形似的借鉴总不能发挥原作的神髓，神似的借鉴则经常在形式的功能上埋着滔天巨坑。

    目前我所看到的，最有独创想法且坚持一套自我理念的，居然是 lattics！！！（这就是商业软件的从容吗哈哈哈）也有可能因为它有之前做过 zine 的相关经验，它的使用体验对小白来说应该是最好的，这就是商业软件的从容吧。

    最能支持我上述说法的一个例子，我目前想到的，就是各家厂商参考“GTD”所涉及的，五花八门的日程日历软件。

    logseq 如果设计得更易用一点，潜力应该更大吧，只可惜太难用了。

  • 查看全部回帖
Floria233
回帖
119
 帖子
27
 积分
961