求高手解答：Logseq 为什么不设计文件夹体系？

Feature Requests
#13

文件夹只是功能，用不用另说。

就算用，也不一定是按主题用，可以按功能用。

现在Logseq分了pages和journals两个文件夹，不也是文件夹么？如果你使用 /draw 命令，还会生成一个draws文件夹。

现在的namespace本质上也是文件夹。

我是比较赞同提供文件夹能力的，大家按需用。

1 个赞
#14

没有系统支持无限层级，想要实现无限层级就只能通过软件层面实现。思源笔记的无限层级本质上还是文件系统，所以推荐最多 6 层，超过 6 层以后就带来诸多问题：文件无法复制、移动等。真正的无限层级需要数据库，而且不是简单的查询数据库（例如 logseq 的 query）。想要无限层级，你就得做好放弃纯文本好迁移的准备。

或者，为何不去维护一个包含全部页面的 MOC 呢？笑

#15

我觉得不应该是「 Logseq 为什么不设计文件夹体系？」，而应该是「为什么选择了没有文件夹体系的 Logseq？」。如果你真看重文件夹体系这种底层结构，你就不应该选择 logseq。「使不使用文件夹体系？」是很本质的问题，若让 Logseq 有了文件夹体系，那就发生了质变，可能好也可能不好。

#16

logseq 是大纲型的双链笔记，如果喜欢文件夹体系的实在是太多选择了，就我而言，你可以用 Obsidian，思源，craft，语雀等等，上面的这些都是双链且带文件夹结构。我初次见到 obsidian 的时候眼前一亮，用了半年的obsidian，可还是像之前的evernote，notion一样弃用了，只能说术业有专攻。每次用这些树状结构，文件夹类型的笔记。写笔记之前我会在想这属于哪个分类，这条笔记双链在了什么地方，时间长了，笔记数量上来之后，都会给我一种整理的压力，无形之中就会在想文件夹怎么设计，怎么分类，笔记数量躲起来之后，最后就是弃用。
而 logseq 却让我没有了这种感觉，我打开想写什么就写什么，完成没有了整理笔记的压力，让我更能专注于事情本身，而不会被事情周围的因素去影响。所以 logseq 团队没有选择文件夹体系是很有思考和远见的。
很赞同 楼上说的一句话 「 Logseq 为什么不设计文件夹体系？」，而应该是「为什么选择了没有文件夹体系的 Logseq」

tips: 实在想要，Logseq 右侧的目录区可以变相的实现等同于文件夹的效果image

1 个赞
#17

大家一直回避一个问题啊：
设置文件夹，让需要用的人用，不需要的，可以不用啊！

分类难道不是文件整理的重要需求之一吗？
比如有10个文件都属于 文学 类，你怎么分类呢？
你把10个文件夹的页面属性里，都写上 文学？
那比直接拖到 文学 文件夹里，不是麻烦很多吗？

有文件夹，也不妨碍大家随意组合文件啊。
比如10个 文学 文件，你完全可以标上其它的标签或者面面属性，把它们同时归到其它的类里啊。
放到 文学 文件夹里，只是因为这10个文件，主要或说常用类别是 文学。

3 个赞
#18

思源有文件夹体系，难道这就妨碍你随意链接文件、随意给文件分类了？
十分不理解坚决反对文件夹的人。

1 个赞
#19
  1. 分类确实是文件整理的重要需求之一，卢曼的第一个卡片盒也是根据主题来分的。既然思源能够分类，那为何不放弃 logseq 而选择思源呢？既然如此看中文件系统，那文件系统的权重就应该很高，那为何还要选择 logseq？人选择工具，工具也会选择人。
  2. 思源很好，但是对我来说既不结构也不扁平，不符合我的理念，所以我选择 obsidian（logseq 仅用于速记，GTD 和收集的功能由其他软件代替）。为什么思源 1.2 版本让很多人退坑了？因为理念变了，思源最开始是 .md 文件，但 1.2 版本成了自己的 .sy 文件（本质上是 json），这让很多人认为数据不够安全。对于 logseq 来说，设计文件系统就是改变理念。
  3. 还有，与思源相比，logseq 是开源的，为何不自己动手丰衣足食呢？
  4. 与其说文件夹的好处，支持设计文件夹体系，不如选择合适自己的工具，或者自己动手。
3 个赞
#20

我觉得文档树的作用是方便在页面这个“宏观尺度”上对笔记进行批量操作，分类也是批量操作的一种。如果Logseq的知识图谱能批量操作节点的话。。。（比如框选一批节点建立新页面，或者拖动一个节点到另一个节点上合并页面）

#21
  1. 因为文件夹体系，文档是最小的粒度单位，而logseq下，block是最小的粒度单位
  2. block向上可以基于标签（文档标签、tag标签）汇总，并且可以通过查询语法与搜索，快速的定位同汇总

更进一步，可以看Roam的白皮书： https://roamresearch.com/#/app/help/page/dZ72V0Ig6

3 个赞
#22

文件夹体系没有意义，但我不是说分类学研究没有意义。对知识的分类学研究应该后置进行，而不是在输入知识时就给它划定分类，而且像如果有个分类可以囊括所有知识这时候还真的就把所有知识都划到这个超级分类上？对知识的分类研究我觉得最好就是新建个page进行研究，而不是建立文件夹体系或者标签,这样也有利于研究者主动梳理知识、归纳总结、进行专业的分类学研究等。
要不要进行分类，如何分类？这件事还真可以深挖专业知识进行研究。

1 个赞
#23

其实对于一个如果说特别对于文件和文件夹有那种细节要求的时候(类似于所有东西都必须通过自己来指定)的人来说，存在文件夹分层是好的，这里在下的拙见并不是说logseq这种方式不好，应为有全局搜索的功能以及标签，所以分级和分层的需求是可以变相通过这两种方式来补充的，而且个人认为文件记录的跨度一定不会只有一个文件夹(类似于java这个域就涉及的区域特别广泛)，不可能只通过一个文件夹就把这个笔记定义死了。个人认为tag+搜索要比文件夹树要强大很多，纯个人结合自己经历发言，每个人的使用场景不同，勿怼，感谢

#24

思源已经全部开源了 :smiley:

#25

还是建议有，连幕布这种上一代产品都有，要不然单个文档过于臃肿必然影响加载、查询效率

1 个赞
#26

赞成，仔细思考现在的双链软件，很多都有点过于强调双链而忽略了分类的作用了，在笔记量达到一定程度的时候，图谱就会变成一团乱麻，除了一时的观赏，其他作用并不大，相反作用更大的是页面图谱，也就是和当前页相关的节点组成的图。
一款软件做的怎么样，一方面是软件开发水平与效率，另一方面是开发团队对PKM的思考与理解了。
目前观察RemNote既有双链又有文件夹体系，在设计架构上的水平是比较高的，但是RemNote的开发迭代速度和中文支持是比较薄弱的。
相比之下logseq在开发迭代速度上是不错的，可以保证新功能的不断生成和已有功能的改进，架构上还需要多打磨和借鉴才行。
使用logseq半年了，期待后续logseq和RemNote的不断发展

1 个赞
#27

我不太清楚为什么 “文件夹系统 = 分类”, 因为文件夹系统只不过是一种多层级的表.

既然是表, 那可以使用 map of content (MOC) 代替, 它比文件夹系统更自由: 可添加描述, 无限层级. logseq 提供的 content 页就是来干这些事的. 唯一的的缺点是无法批量操作文件.

说到图谱, 自动生成的图谱是最无用的, 因为只能看到联系, 但不知道是什么联系, 完全不如出链和反链直观.

在我用过的所有的笔记软件中, 这方面做的最好的是 trilium. 它可以给页面之间添加关系. 同时也是无限层级做的最好的. 它用的是数据库, 而我更喜欢 md :upside_down_face:. 还有这方面功能的是 ob 的 juggl 插件, 此外思源画过这方面的饼 (我知道的).

此外, 单个文档臃肿导致的加载速度慢是因为 md 不是为 “块” 而生的, 至少不如思源的 json. 而软件加载慢是因为它每次加载时会为所有的块建立索引, 你文件多不代表块就少. 这本质上是 logseq 加载模式决定的, 完全采用数据库应该会有极大提升 (至少加载快了).

#28

在目录里做好层级后，可以在反链面板里看到路径导航，但是文档内容很多就没办法很容易在页面看到，所以我会建议在如果父节点只有一个可以在页面顶部也显示路径导航，另外让侧边栏也能显示反链

#29

我支持不要文件夹。

  1. 添加笔记的时候，如果有文件夹会有阻塞，会去思考这个笔记放到哪，而这个阻塞很致命。
  2. tag + 目录已经很够用了。
1 个赞
#30

可以看出，社区对不支持的功能会下意识进行排斥拒绝 :grin:，文件夹功能很好用，不爱思考放哪的你就随便放，反正几个带文件夹又有双链的软件都有全局搜索功能和tag。

2 个赞
#31

个人不支持文件夹体系，并且我也不认为这是一个简单的"不想用的可以不用，想用的可以有"的事情。
目前的"目录"对我来说完全够用。由于我是新上手的用户，不知道目录功能是不是在这跨度八九个月的讨论中间更新出来的，以下只是对这个话题的一点想法。

  • 文件夹系统可能会大幅度地改变现在存储数据的架构和检索方式
    • 在块→md的基础上变成块→md(→当前路径→父路径|父路径下其它同级路径→…→库根路径)，整体变成文件系统的树形结构
    • 目前以page和block为核心，也是一种"一切皆文件"和"一切皆文本"的做法，"文件"本身是可以参与双链的一种信息
    • 但文件夹没有"文件"属性，它只是用来放文件的收纳盒，文件夹本身失去了可以被双链的信息
    • 由于文件夹本身无法参与双链，变成强制按文件系统的树形组织文件，而不再是纯网状组织
    • 会大幅度改变数据架构和检索方式，相当于修改产品的核心设计
    • 受限于OS的文件系统（不同OS不同的文件系统又是另一个问题，产品线复杂化，运营维护和开发维护成本都升高）这种app外部硬性条件
      • 有了文件夹，猜猜会不会有人又想要导入任意位置md文件的功能，变成要跨工作区跨盘区访问文件，需求复杂度和产品复杂度进一步攀升→产品核心定位开始模糊
      • 据我观察在管理asset功能上的需求已经有这种倾向了，但这是另外一个话题（我个人是支持管好asset的）
      • 也许作为用户我很少需要去考虑1000个文档怎么分类，但作为产品设计可能真的会有100000个页面如何存储、读取和检索的问题。
    • 无数据库的情况下影响检索和加载速度
    • 但加上数据库不利于轻量化便携式的信息管理，而开放和轻量正是logseq的特点
      • 专有数据格式不利于二次开发中的解析和使用，需要额外的数据库接口
      • 封闭的数据库引发信息管理主动权不在用户自己手中的疑虑
      • 数据库同步困难，失去用户自行版本控制的意义，会过于依赖产品自己的同步功能
  • 目前面向用户的"目录"和logseq自己维护的meta文件已经基本足够
    • 这两种方式已经可以看作文本化的超轻量"数据库"
    • 让用户不用去管如何在logseq目录下管理文件，而是专注在logseq软件中管理文件中包含的"信息"
    • 层级式和树形是有必要（而且基础的）的信息管理方式
      • namespace和目录都是为此存在的一种"软"方式（区别于文件夹这种文件系统的硬方式）
      • namespace和page的title属性直接绑定导致页面名称过于繁琐这一点，确实有必要改进

以及从楼主另一个插件区的帖子来看。
也许楼主真正想要的，不是文件夹体系，而是层级结构管理方式？
比如举例的文学→古代文学→红楼梦，这是一种显著的层级式分类管理。
但大纲式笔记中的节点→子节点结构不正是层级式的吗？

因此我认为目前的目录功能已经够用的。举例我自己的目录：

我自己的目录举例

“Soul Drain"下面打算用来放近来我看的书、文章、视频、影片的记录。
但"Soul Drain"本身不需要被双链，因此没有用双方括号做成页面，有点类似不能被双链也不需要双链仅用来分类的"文件夹”（这个谜一样的名字本身就是我不知道该怎么分类概括下面子节点的内容想出来的）。
但它依然能在相关页面最下以面包屑的形式参与显示。

面包屑

再加上目录也以大纲形式呈现，本身的强层级式结构就已经满足文件夹体系分类的要求了。

而它和文件夹体系/文件夹系统的区别之处在于，您可以想象一本海纳百川的巨大书本，或者一座图书馆，使用手写的索引卡来整理其中的信息。
信息的分类取决于在使用者的脑中所在的层级，而不是取决于要找的信息在物理上处于第几章节或者第几个书架上。

一开始就不定义分类，而是让使用者自己去整理分类，我觉得是logseq相较于有文件夹的大型软件记录压力更低的原因——可以分类，也可以不分类；即使不分类，日期天然地已经是一种索引，从而同时免去记录因不分类而丢失的焦虑。

但诸如搜索页面、搜索关键词、悬浮显示页面时不能显示结果页面的面包屑（搜索功能现在其实能部分体现信息的层级结构），这大概属于一些增强功能，也许插件能解决（或者直接做进功能中），个人认为还没有上升到探讨是否需要文件夹体系这个程度。

所以比起"为什么没有xx体系"，"想要在xx地方显示yy信息"可能是更具有可操作性的需求。

3 个赞
#32

我觉得可以， 做成插件的话就既满足需要的人也满足不想要的人，自由度更高

2 个赞