希望取消闪卡的卡包,因为文档树就是天然的卡包

本贴最后更新于 625 天前,其中的信息可能已经时移俗易

目前 2.6.3 的制卡逻辑是这样的:

Step 1. 在文档中选中文字并标记(挖空);

Step 2. 点击左侧的段落图标 -> 闪卡;

Step3. 将该段落加入某一卡包;

以上流程有这样几个缺点:① 分散用户精力,本来用户只需要专注于制卡本身,而上述机制会让用户纠结把卡放入哪个卡包。② 制卡过程繁琐,选中文字并标记(挖空)其实就已经完成制卡了,没必要再多一个选择卡包的过程。③ 上述机制中一旦用户想变更整篇文章的卡包,就要手动地一个一个修改。④ 无法直观地看出某张卡片属于哪个卡包,必须通过上述的第二个步骤才能看出。

而取消卡包后,一切将变得很自然。比如某用户的文档树结构如下:

  • 数学
    • 分析
      • 数学分析
      • 实分析
      • 复分析
      • 泛函分析
    • 代数
      • 高等代数
      • 抽象代数
    • 几何
      • 解析几何
      • 微分几何
  • 历史
    • 中国史
      • 唐史
      • 宋史
      • 元史
      • 明史
    • 世界史
      • 欧洲史
      • 阿拉伯史
      • 美国史
      • 日本史

而上述结构就是天然的卡包,用户完成挖空后,不需要再去选择该卡片属于哪一个卡包。现代化的间隔重复笔记软件 RemNote 就是这样的使用逻辑。

举个例子,比如在《高等代数》这篇文档里面有一个段落是行列式的定义,在此处完成选中文字并标记后,这张卡片很自然地属于 高等代数代数数学 这 3 个卡包,无需用户再去选择,并且在复习卡片时,不管用户想复习所有数学知识,还是只想复习高等代数的知识,都会复习到这张卡片。


为了方便描述,我将用 RemNote 进行视频( BV1VW4y1378n )演示,来看看 RemNote 是如何解决卡片多分类问题以及 DailyNote 卡片分类问题的。

视频演示:RemNote 之 DailyNote 制卡

RemNote 这款软件也是支持 DailyNote 功能的。从视频中可以看出,针对 DailyNote 爱好者,RemNote 也是提供了很优雅的卡片(多)分类解决方案。


为什么我坚持采用文档树即卡包的分类方案?因为对于文件夹爱好者,同一篇文章的卡片很自然地就应该属于同一分类,而重复进行前文中提到的 Step2 和 Step3 是毫无意义的,这一过程让人抓狂。

关于纯粹的 DailyNote 用户,我提几点疑问。既然纯粹的 DailyNote 用户在记笔记时不喜欢分类,为什么到了制卡的时候,突然就要分类了?既然最终还是有分类的需求,为什么不能在制卡之前就完成分类呢?我理解,为了减轻记录的压力,所以不分类,但知识总是需要消化吸收的,早晚还是要对部分有价值的知识进行分类整理。我提出的“文档树即卡包”的方案只不过是让你们把对卡片的分类换种方式提前一步进行而已,并没有给你们添堵。


我又考虑了一下,可以采用一种妥协的方案,使 DailyNote 用户和文件夹用户都满意,从而避免争论。

那就是提供 2 个不同的闪卡复习入口。

第一个入口就是现有方案,通过左上角闪卡图标进入。

第二个入口就是,像 RemNote 一样,在文档树的位置右键。

这样一来,DailyNote 用户无需改变现有的习惯(虽然我不是很赞同这一习惯);而文件夹用户也能实现无感分类了。


借着这个机会,我顺便把 RemNote 的优势介绍了,供开发者参考,也给大家做一个科普。

在 RemNote 中,一篇文档就是一个卡包。当然,这里并不是真正的为这篇文档创建了一个卡包,而是通过类似于查询语句的方式得到了这篇文档(及其子文档)中的所有卡片,在用户看来感觉就像是一个卡包一样。一张卡片,不仅属于当前文档的卡包,同时属于它的父文档的卡包以及祖先文档的卡包。比如“行列式的定义”这张卡片不仅属于“高等代数”卡包,同时属于“代数”、“数学”这两个卡包。思源笔记比起 obsidian、logseq 来说拥有完美的文档树,如果这一优势不被闪卡功能好好利用的话,其实是相当可惜的。

有了一篇文档就是一个卡包这一基础,进一步 RemNote 就可以实现一个标签就是一个卡包,可以简单理解为 RemNote 自动为每个标签都创建了一个页面,所有打上了这个标签的块都嵌入到了这个页面内。思源笔记的标签系统还能形成标签树,如果利用好的话也能成为独特的优势。在早些时候的讨论中我就提到过,标签是实现 DailyNote 卡片分类的一种解决方案,具体操作可以看这个视频( BV13A411o7yK):

视频:RemNote 标签制卡展示

更进一步,RemNote 甚至可以实现自由组合卡包。RemNote 提供了一个功能叫做 Search Portal,可以在文档中插入一个搜索块,将带有某一标签、某一关键字的块嵌入进来。借助 Search Portal,用户可以实现自由组合卡包,比如可以将不同标签的块、含有特定关键字的块、嵌入块放进同一篇文档中,这样就得到了一个组合卡包。思源笔记中也有类似的功能,那就是 sql 语句查询,如果利用起来的话,也可以实现类似效果,甚至更个性化的效果。具体操作看下面这个视频( BV1X84y1h7bK):

视频:RemNote 自由组合卡包演示

是否支持取消卡包,改用文档树即卡包的形式?

单选 公开 永不结束 40 票
支持
67% 27 票
不支持
32% 13 票

  • 思源笔记

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

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

    22346 引用 • 89411 回帖 • 1 关注

相关帖子

优质回帖
  • zxhd86 2 赞同

    看了楼上 @pipa 的发言,我才意识到思源的用法确实不是只有使用文件夹的方式,而我在日常生活中明明没有怎么建立分类的文件夹,在讨论问题时却忘了,这确实挺好笑的。

    那么最大的问题就是:思源不是 RemNote,思源的使用者并不会像 RemNote 的使用者一样使用思源,照搬 RemNote 的闪卡机制对思源是没有意义的。

    之前体验过一段 RemNote 的我不得不承认,RemNote 的制卡效果在各个方面都优于思源,但是考虑到思源的用户实际上分别实践着 daily note 和文件夹分类以及其他奇奇怪怪的笔记用法,照搬 RemNote 的效果只能方便到文件夹分类的用户,这实际上是不公平的。

    而思源的魅力之一不就是不限制你记笔记的方式吗?大纲笔记可以,daily 可以,用文件夹分类也可以……考虑到不限制用户的目的,我收回前言,认为还是目前的制卡方式最合适,只不过需要稍微改进一下,如可以设置个快捷键和默认制卡卡包之类的。

  • openAI 1 赞同

    改进效果是巨大的,因为当前的制卡体验真的很不好,就像我上面总结的,需要 3 个步骤。这么说吧,我是建议思源引入间隔重复功能的用户之一,但如果是现在这样的制卡逻辑的话,我是不想使用的;换句话说就是,真正需要这个功能的用户不太想使用当前这一功能。

  • i1356 1 赞同

    应该是自动生成跟文档树一样结构的卡包吧

欢迎来到这里!

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

注册 关于
请输入回帖内容 ...
  • 你说的对,但是与目前的闪卡机制区别过大,我认为工程量会很大,会引入很多 bug,而改进效果相比并不大。我认为你这是合理的改进方向,但不应该是现在。

    2 回复
  • openAI 1 赞同

    改进效果是巨大的,因为当前的制卡体验真的很不好,就像我上面总结的,需要 3 个步骤。这么说吧,我是建议思源引入间隔重复功能的用户之一,但如果是现在这样的制卡逻辑的话,我是不想使用的;换句话说就是,真正需要这个功能的用户不太想使用当前这一功能。

  • 改进越早越好,因为拖得越久,不管是开发者还是用户投入的沉没成本就会越高。对于开发者来说,改进越晚,代码量就越大,越不易改进。对于用户来说,改进越晚,潜在的 bug 影响到的卡片就会越多。

  • 不知道我理解对楼主的意思没。

    我感觉思源虽然有文档树,但有很多人是用作双链笔记的,文档树不一定梳理得很到位,甚至没有什么目录结构。这样的话用文档树即卡包当然不太合适。

    1 回复
  • i1356

    支持一个。

  • i1356 1 赞同

    应该是自动生成跟文档树一样结构的卡包吧

  • 这个真的很不错哎,就是对 dailynote 用户不是很友好,是不是可以加入一个设置选项,让用户可以选择在制卡的时候是否根据文档树,自动生成相应卡包

    1 回复
  • 这里还是有传统的分类问题: 如果有一个名为 数学史 的项目, 应该同时在 历史数学 下级, 此时应该怎么分类呢 ❓

    1 回复
  • 关于纯 dailynote 用户的这个问题,我把我在 github 上给 D 大的回复复制过来:

    Dailynote 的话,其实不需要太担心。比如具有 dailynote 的文档树如下:

    • 历史
      • Dailynote(历史)
        • 2023.01.12
        • 2023.01.11
      • 中国史
        • 唐史
        • 宋史
        • 元史
        • 明史
      • 世界史
        • 欧洲史
        • 阿拉伯史
        • 美国史
        • 日本史

    方案一:就按照文档树即卡包的逻辑,不做任何调整,保持使用逻辑一致。比如 2023.01.12 这篇文档中产生的卡片同时属于 2023.01.12Dailynote(历史)历史 这 3 个卡包。

    方案二:考虑到 dailynote 中的文档可能较多,可取消最后一级卡包。比如 2023.01.12 这篇文档中产生的卡片同时属于 Dailynote(历史)历史 这 2 个卡包。

    方案三:如果用户甚至只有一个笔记本,连一级分类都没有,所有的笔记都是未分类的日记,那么可以采用标签机制来对卡片分类。比如,2023.01.12 这篇文章是关于中日战争的,那么可对里面的段落打上 历史/中国史历史/日本史 两个二级标签,自然地,相关的卡片就属于 中国史日本史历史 这 3 个卡包。这样同时也就克服了我上面提到的第 ④ 个缺点,可以直观地看出卡片属于哪个卡包。(文档树即卡包、标签树即卡包这两种机制是可以同时存在的,是兼容的)

  • Bard

    有很多用户,比如我,是不用文档树的来管理文档的,用 MoC

    文档树对很多人来说,最大的问题是难以应对“一对多的分类”

  • Bard

    很多像我放弃“文档树”的人来说文档树是种“可能落后”“可能低效”“可能繁琐”“分类压力大”等的使用方式

  • Bard

    一个小点:

    利用文档树分类,很容易导致文档路径过长

    文档路径过长,在某些系统中会有限制

    这也是设置选项中有个大致叫“文档路径不能超过 7 层”选项的原因

    这是也我在整理用文档树管理的“老文档”的时候遇见的问题

  • 这个没什么好纠结的,用户已经主动在文档树中给出分类了。如果在文档树中把 数学史 归为 数学 一类是可接受的,那为什么在卡包中把 数学史 归为 数学 一类就是不可接受的了呢?

    如果一定要把 数学史 同时归为 数学历史,也不是没有办法,我简单提几个方案。

    方案一,给 数学史 这篇文档加上 历史 标签,同时引入标签树即卡包的机制。

    方案二,在 历史 笔记本的某篇文档里,粘贴 数学史 为嵌入块。

  • Bard

    举个小栗子:

    假如一个闪卡“唐朝建立于公元 618 年”

    想要分别放到“唐朝历史知识”,“关键历史事件节点”,“上次考试错题”等卡包时候

    文档树管理的卡包就很难去实现

  • Bard

    回复了之前几条,我明白了核心分歧在哪里

    当前建议的是按照“文档树”的使用方式建议的

    而思源有相当一部分人是按照“没有文档树”的方式使用的,与当前建议难以兼容

    或者可以说“建议兼容文档树卡包,但绝不能取消原来的闪卡卡包”

  • Bard

    闪卡的制作本身就需要问题有一定的原子性

    而思源也是基于“块”的笔记,块的原子性更好

    因此我认为:把“块”当作闪卡,比把“文档”当作闪卡是更合适的选择

  • Bard 1 赞同

    关于“如何提建议”的感悟:

    推荐“建议自己需要的功能”

    不推荐“建议取消自己用不上,且不知道别人是否在用的功能”


    @openAI 可以考虑一下这条评论的观点

    如果认为我说的没有问题,建议是改一下标题

    如果坚持的自己原有的观点,也不妨进一步详细的阐述一下

    1 操作
    Bard 在 2023-01-12 23:38:06 更新了该回帖
  • 我录了个视频,可以看看 RemNote 是如何运行的。RemNote 的制卡只需要挖空,而不需要对卡片进行分类,因为文档树就是卡片的分类。

    视频:RemNote 文档树即卡包特性演示

    1 回复
  • zxhd86 2 赞同

    看了楼上 @pipa 的发言,我才意识到思源的用法确实不是只有使用文件夹的方式,而我在日常生活中明明没有怎么建立分类的文件夹,在讨论问题时却忘了,这确实挺好笑的。

    那么最大的问题就是:思源不是 RemNote,思源的使用者并不会像 RemNote 的使用者一样使用思源,照搬 RemNote 的闪卡机制对思源是没有意义的。

    之前体验过一段 RemNote 的我不得不承认,RemNote 的制卡效果在各个方面都优于思源,但是考虑到思源的用户实际上分别实践着 daily note 和文件夹分类以及其他奇奇怪怪的笔记用法,照搬 RemNote 的效果只能方便到文件夹分类的用户,这实际上是不公平的。

    而思源的魅力之一不就是不限制你记笔记的方式吗?大纲笔记可以,daily 可以,用文件夹分类也可以……考虑到不限制用户的目的,我收回前言,认为还是目前的制卡方式最合适,只不过需要稍微改进一下,如可以设置个快捷键和默认制卡卡包之类的。

  • Bard 1 赞同 2 评论
    1. RemNote 在用,并不代表就是优秀的设计,一个软件有这样的功能,并不代表另一个软件也需要有,就算增加这个功能也是因为“这个功能足够好”,推荐从这样的做有着“无以复加的好处”的角度开始论述
    2. RN 依然无法优雅解决一张闪卡位于多个卡包的问题,
    3. 文档树分类无法“一对多”的特性,会导致难以实现十分具体的卡包,比如“文科综合错题知识点”的卡包,而实际使用中是可能面对这样场景的
    我没具体深度使用过 RN,只是刚才看了楼主的视频总结出来的,因此对观点 2 持保留意见,也欢迎朋友反驳这个观点
    Bard
    RemNote 也是有 DailyNote 功能的哈,刚刚录了个视频,看看 RemNote 是如何实现对日记中卡片的分类的。往上翻。
    openAI
  • Bard

    方案三:如果用户甚至只有一个笔记本,连一级分类都没有,所有的笔记都是未分类的日记,那么可以采用标签机制来对卡片分类。比如,2023.01.12 这篇文章是关于中日战争的,那么可对里面的段落打上 历史/中国史历史/日本史 两个二级标签,自然地,相关的卡片就属于 中国史日本史历史 这 3 个卡包。这样同时也就克服了我上面提到的第 ④ 个缺点,可以直观地看出卡片属于哪个卡包。(文档树即卡包、标签树即卡包这两种机制是可以同时存在的,是兼容的)

    作者:openAI
    链接: 希望取消闪卡的卡包,因为文档树就是天然的卡包 - openAI 的回帖
    来源:链滴
    协议:CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0/

    这个方案是不符合现有思源的理念的,现在实现不了,或者要实现是很难的

    因为思源的标签和文档(也就是双链)是还没有统一的

    我盲猜这是常用 RN 的思维惯性,因为我也听闻“RN 的统一性是十分好的”(对本句持谨慎观点)

  • openAI 2 评论

    @pipa@zxhd86@shuoying

    多说无疑,直接看视频演示。来看看 RemNote 是如何解决 DailyNote 卡片分类问题,以及一张卡片属于多个分类的问题。

    视频演示:RemNote 之 DailyDoc 制卡

    我在 RemNote 里添加了一篇日记,当然这篇日记的标题是日期,没有任何分类。日记中我编辑好了一张卡片,内容是“床前明月光,???。举头望明月,低头思故乡”。
    那如何对日记里的卡片分类呢?利用 RemNote 的“复制嵌入块”功能,分别把卡片对应的段落粘贴到“语文/唐诗”以及“历史人物/李白”这两个目录中,然后,这张卡片便具有了这两个分类。

    1 回复
    @pipa
    openAI
    openAI
  • Bard 1 评论

    这个没什么好纠结的,用户已经主动在文档树中给出分类了。如果在文档树中把 数学史 归为 数学 一类是可接受的,那为什么在卡包中把 数学史 归为 数学 一类就是不可接受的了呢?

    如果一定要把 数学史 同时归为 数学历史,也不是没有办法,我简单提几个方案。

    方案一,给 数学史 这篇文档加上 历史 标签,同时引入标签树即卡包的机制。

    方案二,在 历史 笔记本的某篇文档里,粘贴 数学史 为嵌入块。

    作者:openAI
    链接: 希望取消闪卡的卡包,因为文档树就是天然的卡包 - openAI 的回帖
    来源:链滴
    协议:CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0/

    这两个方案依旧是没有明白

    在思源中的“标签”和“双链”是没有统一的

    方案二也难以经得起细致的思考和推敲,比如以下我认为不是“抬杠”的思考

    1. 在 历史 笔记本的哪篇文档呢
    2. 这篇文档应该叫什么名字呢
    3. 要不要跟原文档重名呢
    4. 不重名的话如何命名区分呢
    5. 以后还有别的卡要用这样的方式放到 历史 笔记本中,是继续新建文档,还是放这个文档呢
    6. 还是统一叫类似“历史 - 其他卡片”
    7. 就算确定了解决的统一方案,会比原来的添加卡包更加优雅吗
    8. 思考创建分类的时间成本合算吗
    看你楼下的视频哈,看看 RemNote 是如何优雅地进行卡片多分类以及 DailyNote 卡片分类的
    openAI
  • someone 2 评论

    思源的嵌入块和 RemNote 有区别的,做不到你演示视频里这种做法的……

    其实经过我的实验,思源目前的嵌入块还真能做的,当然我也不同意楼主的看法就是了
    zxhd86
    除此之外,目前的机制根本不需要使用到嵌入块制卡,所以这一点也没有多大用处就是了
    zxhd86
  • Bard 1 评论

    不建议用 “RN 如何如何…怎样怎样…”来证明“思源也需要如此”

    需要的是“这样很有用,这样很方便,这样设计足够优秀,比之前设计的还要优秀”

    是的。RN 在制卡方面是先进的,为了方便描述功能所以我用了 RN 来做演示。
    openAI
  • zxhd86 2 评论

    我不得不承认目前的制卡功能完善程度比我想象中好很多,虽然感觉还是有点繁琐,但无伤大雅。

    但是我提出的问题的关键在于,为什么要为了制卡牺牲一部分用户的记笔记习惯?就算一部分用户崇尚使用文件夹分类的方式来管理笔记体系,假如一个块需要在多个分类下出现,可以不厌其烦地将这些块一个一个地复制嵌入块到指定的分类下,那么那些喜欢 daily note 流程的用户就应该被迫转变自己的记笔记习惯吗?

    考虑到公平性,最高的要求也只能是在现有的制卡机制中再加入支持文档树的制卡体系,但是考虑到维护的复杂度,我不认为这是一个好选项。

    重复进行我正文中提到的 Step2 和 Step3 才是繁琐的,并且这一繁琐过程是面向所有用户的,不针对文件夹用户。而 RemNote 那种通过嵌入块实现多分类的繁琐程度和我正文中提到的 Step2 及 Step3 的繁琐程度我认为是不相上下的。
    openAI
    关于纯粹的 DailyNote 用户,我提几点疑问。既然纯粹的 DailyNote 用户在记笔记时不喜欢分类,为什么到了制卡的时候,突然就要分类了?既然最终还是有分类的需求,为什么不能在制卡之前就完成分类呢?我理解,为了减轻记录的压力,所以不分类,但知识总是需要消化吸收的,早晚还是要对部分有价值的知识进行分类整理。我提出的“文档树即卡包”的方案只不过是让你们把对卡片的分类换种方式提前一步进行而已,并没有给你们添堵。
    openAI
  • Bard 1 评论

    我的部分理念是这样的

    1. 写的清楚,才算想的清楚,就像卢曼说的:不写,就无法思考
    2. 优秀的设计也是可以说清楚的,尤其是体验如此深刻的功能

    不妨稍微耐心一点,或许可以

    1. 将理想中的功能描述的更加翔实一些,证明其优秀,无关 RN
    2. 把我和别人观点中的谬误,不理解你的地方指出来,阐述明白,继续探讨
    2 回复
    重复进行我正文中提到的 Step2 和 Step3 才是繁琐的,并且这一繁琐过程是面向所有用户的,不针对文件夹用户。
    openAI
  • 我理想中的制卡就是不需要重复正文中提到的 Step2 和 Step3。因为同一篇文章的卡片很自然地应该属于同一分类,因此重复进行 Step2 和 Step3 是无意义的,并且这一过程让人抓狂。

    1 回复
  • zxhd86 2 评论

    等等,假设现在一共有 3 个文章、每个文章中有 10 个块,你的痛点是在于需要对这三个文章分别操作,总共进行 3 次操作,还是在于对于每个块都要进行一遍操作、总共 30 次操作?

    如果只是后者,那么我建议可以试试多选后批量制卡。

    刚刚试了下,确实可以多选后批量制卡。这在一定程度上缓解了我的焦虑。
    openAI
    但我还是认为 RemNote 的方案更先进,也就是完全不需要手动分类是最好的。为什么呢?因为我对一个段落挖空后,很自然地就会想到及时更新卡包,所以还是不可避免地会多次进行 Step2+Step3 的操作。
    openAI
  • 关于纯粹的 DailyNote 用户,我提几点疑问。既然纯粹的 DailyNote 用户在记笔记时不喜欢分类,为什么到了制卡的时候,突然就要分类了?既然最终还是有分类的需求,为什么不能在制卡之前就完成分类呢?我理解,为了减轻记录的压力,所以不分类,但知识总是需要消化吸收的,早晚还是要对部分有价值的知识进行分类整理。我提出的“文档树即卡包”的方案只不过是让你们把对卡片的分类提前一步进行而已,并没有给你们添堵。

    RemNote 这款软件也支持 DailyNote 功能,它给出了一个很好的解决方案,具体演示见我正文中的视频。该方案也在很大程度上克服了我正文中提到的第 ④ 个缺点,可以较直观地看出卡片属于哪个卡包,如图:

    Snipaste20230113002537.png

    1 回复
  • Bard 1 评论

    我理想中的制卡就是不需要重复正文中提到的 Step2 和 Step3。因为同一篇文章的卡片很自然地应该属于同一分类,因此重复进行 Step2 和 Step3 是无意义的,并且这一过程让人抓狂。

    这是个很主观,想当然,思维保守,目光狭隘的观点

    • 对于“一元笔记”用户来说,这不够“自然”
    • 对于 Daily Notes 的用户来说,也不够“自然”
    • 对于笔记关系复杂的用户来说,也不够“自然”

    而思源笔记的优点之一就是包容不同的使用方式

    所谓的“抓狂”,可能是思源的包容,也可能只是自己的“倔强”

    因此思源不能因小失大,往路窄的地方发展

    关于纯粹的 DailyNote 用户,我提几点疑问。既然纯粹的 DailyNote 用户在记笔记时不喜欢分类,为什么到了制卡的时候,突然就要分类了?既然最终还是有分类的需求,为什么不能在制卡之前就完成分类呢?我理解,为了减轻记录的压力,所以不分类,但知识总是需要消化吸收的,早晚还是要对部分有价值的知识进行分类整理。我提出的“文档树即卡包”的方案只不过是让你们把对卡片的分类换种方式提前一步进行而已,并没有给你们添堵。
    openAI
  • Bard 1 赞同

    为什么我坚持采用文档树即卡包的分类方案?因为对于文件夹爱好者,同一篇文章的卡片很自然地就应该属于同一分类,而重复进行前文中提到的 Step2 和 Step3 是毫无意义的,这一过程让人抓狂。

    自己不喜欢就取消,也不考虑其他人,那这也的确有点“肆意妄为”了

    既然都是“肆意妄为”,“非文件夹爱好者”提议“取消文件树”说不定也可以提上日程了

    如果“肆意妄为”是不可取的,那我希望回归:

    己所不欲,勿施于人

    1 操作
    Bard 在 2023-01-13 01:05:07 更新了该回帖
  • Bard 1 评论

    关于纯粹的 DailyNote 用户,我提几点疑问。既然纯粹的 DailyNote 用户在记笔记时不喜欢分类,为什么到了制卡的时候,突然就要分类了?既然最终还是有分类的需求,为什么不能在制卡之前就完成分类呢?

    既然纯粹的 DailyNote 用户在记笔记时不喜欢分类,为什么到了制卡的时候,突然就要分类了?

    记录不分类为了减轻压力,制卡分类是为了相关知识一起为了提高记忆关联度,记忆效果好

    既然最终还是有分类的需求,为什么不能在制卡之前就完成分类呢?

    制卡是笔记,笔记在制卡前是不确定有制卡需求的,也无法全部“为了制卡而做笔记”,于是就有了先笔记,再制卡,再放卡包的需求

    受此问题启发,我也有个疑问:

    既然 RemNote 的制卡流程如此便捷,如此符合使用要求,为何不继续使用 RemNote,而让思源重复的造轮子,各美其美,岂不美哉?

    RemNote 自然有它不好的一面,比如不是纯粹的离线,加载慢,以及一些 bug,所以弃用。但 RemNote 的制卡理念是相当先进的,是我认为值得所有笔记软件学习的。
    openAI
  • Bard 4 评论

    提出的“文档树即卡包”的方案只不过是让你们把对卡片的分类换种方式提前一步进行而已,并没有给你们添堵。

    这的确是“添堵”

    在“无压力笔记”流程中,“分类”即“压力”

    提前分类得话就会将分类压力放到笔记之前,会对笔记意向造成严重损害

    因此“无压力笔记”是坚决不能在笔记之前进行分类的

    1 回复
    既然分类有压力,为什么要对卡片分类呢?你并没有理解我的意思,建议你再看看我正文里的那个视频。
    openAI
    而现有方案对不使用 DailyNote 的用户带来的不方便却是实实在在的。
    openAI
    @openAI 分类压力是分在笔记“前后”的,避免的是“笔记前的分类压力”,不是笔记后的压力,所谓压力后置,毕竟整理笔记也是压力
    Bard
    你可以看下我正文里的视频。视频中体现的过程完全就是对卡片分类,而不是整理笔记,不存在你所说的整理笔记的压力。
    openAI
  • 刚刚考虑了一下,可以采用一种妥协的方案,使 DailyNote 用户和文件夹用户都满意,从而避免争论。

    那就是提供 2 个不同的闪卡复习入口。

    第一个入口就是现有方案,通过左上角闪卡图标进入。

    第二个入口就是,像 RemNote 一样,在文档树的位置右键。

    这样一来,DailyNote 用户无需改变现有的习惯(虽然我不是很赞同这一习惯);而文件夹用户也能实现无感分类了。

  • 我感觉 logseq 那种卡片灵活度是最大的, 通过[[card]] 标签, 你是自己重新做卡片也好,还是直接在原文的基础上利用也好,灵活度比较大. 并且能够通过所在的文档或者通过大纲父级指定的标签来"自动归档", 两种用户的习惯都能满足.

    而且只能在块标上选中略微有些繁琐. 多个卡片每次都得手动选中块标,然后再去选择牌组. 主要是第一步,每次选中块标有些麻烦.

  • teacherQ

    我来回答你这个问题,我是 dailynote 实践用户。为什么我要在制作卡包的时候,要求增加一个分类。这里就搞清楚一点不是所有的笔记都值得我去制卡的。以我为例,我在复习法考,我会每天用 daiy note 的方式把我每天的错题扔进软件里去,然后我去抽个时间,选择具有高价值的题目放入卡包(所以在这里面就会存在一个分类问题,而我扔题目是不需要分类)我们 daily note 用户不是绝对排斥分类的,我们只是不想大部分时间浪费在分类上。最后如果我通过法考,我会把法考那个卡包给删掉。闪卡在我看来他的功能就是起到一个临时提醒的作用,用完就删。

    2 回复
  • Bard

    卡尔萨根:超乎寻常的论断,需要超乎寻常的证据

    费孝通:各美其美,美人之美,美美与共,天下大同

    子曰:己所不欲,勿施于人

  • 了解,我看了下你的使用习惯,其实思源现有方案对你这种使用习惯有一点不友好,就是我正文中提到的,无法直观地看出哪些卡片加入了“高价值错题”卡包。而 RemNote 提供的标签机制可以很好地克服这一问题,我一会儿录一个视频。

  • RemNote 可以通过标签来制卡,也就是标签也可以当作卡包来使用。

    视频:RemNote 标签制卡展示

  • Bard

    超乎寻常的论断,请一定要

    重度使用思源笔记三天以上

    重度使用思源笔记三天以上

    重度使用思源笔记三天以上

  • Bard 1 评论

    没有多余的步骤固然是好

    总是觉得在这之前还要实现

    “标签和双链的统一”

    看我最新的回复,我又更新了一个视频。主要是为了普及 RemNote 的理念,RN 不仅可以做到一个文档就是一个卡包、一个标签就是一个卡包,甚至还可以做到自由组合卡包。
    openAI
  • teacherQ 2 评论

    看了老哥给的视频演示,如果存在标签制卡的可能,那么我觉得 dailynote 用户按文件树来分,影响也不大,主要一个问题,思源得为我们这此 dailynote 用户提供一个闪卡入口,让我们用标签来进行分类的复习,毕竟 dailynote 用户是不会去大量的点击文档树这个东西的。最后还是提醒下思源的开发,如果做,就早点下决心,我已经习惯的操作又给我改是真的想骂人的。

    看我最新的回复,又更新了一个视频。RemNote 甚至可以做到自由组合卡包。
    openAI
    是的,要早点下决心。因为现在闪卡这个功能还没出来多久,所以有什么建议我想着赶紧提了,越拖到后面越难改进。
    openAI
  • openAI 1 赞同

    借着这个机会,我顺便把 RemNote 的优势介绍了,供开发者参考,也给大家做一个科普。

    在 RemNote 中,一篇文档就是一个卡包。当然,这里并不是真正的为这篇文档创建了一个卡包,而是通过类似于查询语句的方式得到了这篇文档(及其子文档)中的所有卡片,在用户看来感觉就像是一个卡包一样。一张卡片,不仅属于当前文档的卡包,同时属于它的父文档的卡包以及祖先文档的卡包。比如“行列式的定义”这张卡片不仅属于“高等代数”卡包,同时属于“代数”、“数学”这两个卡包。思源笔记比起 obsidian、logseq 来说拥有完美的文档树,如果这一优势不被闪卡功能好好利用的话,其实是相当可惜的。

    有了一篇文档就是一个卡包这一基础,进一步 RemNote 就可以实现一个标签就是一个卡包,可以简单理解为 RemNote 自动为每个标签都创建了一个页面,所有打上了这个标签的块都嵌入到了这个页面内。思源笔记的标签系统还能形成标签树,如果利用好的话也能成为独特的优势。在早些时候的讨论中我就提到过,标签是实现 DailyNote 卡片分类的一种解决方案,具体操作可以看这个视频: BV13A411o7yK

    更进一步,RemNote 甚至可以实现自由组合卡包。RemNote 提供了一个功能叫做 Search Portal,可以在文档中插入一个搜索块,将带有某一标签、某一关键字的块嵌入进来。借助 Search Portal,用户可以实现自由组合卡包,比如可以将不同标签的块、含有特定关键字的块、嵌入块放进同一篇文档中,这样就得到了一个组合卡包。思源笔记中也有类似的功能,那就是 sql 语句查询,如果利用起来的话,也可以实现类似效果,甚至更个性化的效果。具体操作看下面这个视频:

    视频:RemNote 自由组合卡包演示

    此外,RemNote 提供了丰富的卡片类型,有挖空卡、问答卡、列表卡、图片遮挡卡。其中,问答卡可以是单向的也可以是双向的,并且单向不仅可以是从左到右,还可以是从右到左;

    image.png

    挖空卡如果有多个空,可以选择对各个空进行组合,并且还可以选择是否 hide all, test one;

    image.png

    image.png

    image.png

    列表卡可以选择是逐行显示答案,还是一口气显示所有答案;

    image.png

    图片遮挡卡和挖空卡类似,支持遮挡块组合,可以设置是否 hide all, test one。我这里出了点 bug,图片遮挡卡用不了,我就用官方 gif 来展示了:

  • zxhd86 5 评论

    关于闪卡机制的进一步思考

    在之前对于闪卡机制的讨论中,我总结到我不支持文档树卡包的原因是,这样不公平。文档树卡包的机制对于习惯于使用文档树管理笔记的用户来说可谓得心应手,但却相当于牺牲使用其他管理笔记方式的用户,因为他们将不得不使用文档树才能管理卡包。

    经过进一步的思考,我认为论点还能在加一个,那就是不值得。

    首先是不公平。

    • 楼主后来举出了很多例子来论证文档树卡包对 daily note 的支持程度,但是就楼主举的例子而言,这只能说 RemNote 对于 daily note 支持尚可,与思源的卡包机制不相上下。
    • 但 daily note 只是众多记笔记方式中的一种,过去的、未来的笔记方式数不胜数。
    • RemNote 是内置对 daily note 的支持的,但在这种情况下,RemNote 对 daily note 的支持尚不能胜过卡包机制,又怎么能让人对于这种明显特化于结构化知识库的机制保有信心?
    • 也许对于大多数的记笔记方式方式而言,卡包机制并不是最好的制卡方式,但它绝对是一视同仁、最不坏的方式。哪怕是文档树的形式,卡包机制配合多选也是差强人意的。

    接着是不值得。

    • RemNote 的文档树卡包与思源的卡包机制,其实两边的制卡这一步流程的总体繁琐程度都差不多。

      • RemNote 需要预先建立层层的文档树,才能找到录入卡片的位置。以后每次录入知识,都要经历一遍找位置的过程。
      • 思源需要每一次都选择卡片,经过 3 步后将卡片录入卡包。
    • RemNote 前期累一点,后期简单一点,思源的卡包机制则是从头到尾都很平稳,一样的压力。你可以崇尚一劳永逸,也可以赞同平稳无压记录。但是,在这一步,是很难辨出胜负的。

    • RemNote 的最大优势,在我看来,就是在制成卡片后,能实现卡包的继承机制,也就是

      一张卡片,不仅属于当前文档的卡包,同时属于它的父文档的卡包以及祖先文档的卡包

      但是,有没有可能,这种特性,只需要对于思源现在的卡包机制进行改进,让它能支持嵌套卡包就能实现呢?

      • 同样是改进,嵌套卡包只需要对相当于官方插件的卡包机制进行少许改造,就能实现同样的功能,而且这种改进完全是帕累托最优的,不会有人因这个改进而体验改变甚至变差。

      • 而如果是实现文档树卡包,那就相当于:

        • 废掉目前的卡包机制
        • 同时还需要对思源的本体动手脚,实现类似于 RemNote 的一堆特性,如多选嵌入
        • 还要实现因为软件差异、不知道 RemNote 有没有实现的特性,如页面克隆

        否则不要说其他笔记方式了,连 daily note 都要深受影响。这过程必然伴随一大堆的 bug,漫长的升级过程,长期对于其他笔记用户相当于废掉的闪卡机制,而换来的只是对他们而言并不太可能显著优于目前机制的文档树卡包。

    综上所述,基于不公平和不值得两个点,我认为不应该废除目前的卡包机制,有一定精力的情况下,建议开发者加入快捷键制卡和默认卡包机制。在精力足够的情况下,建议开发者可以尝试加入嵌套卡包特性。而在目前卡包改进走到尽头后,再考虑文档树卡包机制。

    看我这个视频,RN 甚至提供了标签制卡的功能,更加优雅: https://www.bilibili.com/video/BV13A411o7yK
    openAI
    你如果看完我录的 RN 如何通过标签制卡的视频的话,你不会觉得不公平的,甚至会觉得 RN 的方式更好。
    openAI
    不赞同你所说的嵌套卡包方式,那样只会在不正确的方向上越走越远,尾大不掉。尽早面向更先进、更现代化的制卡方式才是正道。
    openAI
    我再说简单一点,标签是可以替代卡包的,效果一样,并且更加直观。
    openAI
    反驳你关于“不值得”的观点,思源的闪卡开发期也不过一个月,上线也不过才三个星期,现在正处于船小好调头的阶段。
    openAI
请输入回帖内容 ...

推荐标签 标签

  • JavaScript

    JavaScript 一种动态类型、弱类型、基于原型的直译式脚本语言,内置支持类型。它的解释器被称为 JavaScript 引擎,为浏览器的一部分,广泛用于客户端的脚本语言,最早是在 HTML 网页上使用,用来给 HTML 网页增加动态功能。

    729 引用 • 1327 回帖
  • Hprose

    Hprose 是一款先进的轻量级、跨语言、跨平台、无侵入式、高性能动态远程对象调用引擎库。它不仅简单易用,而且功能强大。你无需专门学习,只需看上几眼,就能用它轻松构建分布式应用系统。

    9 引用 • 17 回帖 • 611 关注
  • 爬虫

    网络爬虫(Spider、Crawler),是一种按照一定的规则,自动地抓取万维网信息的程序。

    106 引用 • 275 回帖
  • 旅游

    希望你我能在旅途中找到人生的下一站。

    90 引用 • 899 回帖
  • Solidity

    Solidity 是一种智能合约高级语言,运行在 [以太坊] 虚拟机(EVM)之上。它的语法接近于 JavaScript,是一种面向对象的语言。

    3 引用 • 18 回帖 • 399 关注
  • JRebel

    JRebel 是一款 Java 虚拟机插件,它使得 Java 程序员能在不进行重部署的情况下,即时看到代码的改变对一个应用程序带来的影响。

    26 引用 • 78 回帖 • 664 关注
  • Firefox

    Mozilla Firefox 中文俗称“火狐”(正式缩写为 Fx 或 fx,非正式缩写为 FF),是一个开源的网页浏览器,使用 Gecko 排版引擎,支持多种操作系统,如 Windows、OSX 及 Linux 等。

    8 引用 • 30 回帖 • 407 关注
  • MongoDB

    MongoDB(来自于英文单词“Humongous”,中文含义为“庞大”)是一个基于分布式文件存储的数据库,由 C++ 语言编写。旨在为应用提供可扩展的高性能数据存储解决方案。MongoDB 是一个介于关系数据库和非关系数据库之间的产品,是非关系数据库当中功能最丰富,最像关系数据库的。它支持的数据结构非常松散,是类似 JSON 的 BSON 格式,因此可以存储比较复杂的数据类型。

    90 引用 • 59 回帖 • 1 关注
  • Maven

    Maven 是基于项目对象模型(POM)、通过一小段描述信息来管理项目的构建、报告和文档的软件项目管理工具。

    186 引用 • 318 回帖 • 303 关注
  • 微信

    腾讯公司 2011 年 1 月 21 日推出的一款手机通讯软件。用户可以通过摇一摇、搜索号码、扫描二维码等添加好友和关注公众平台,同时可以将自己看到的精彩内容分享到微信朋友圈。

    130 引用 • 793 回帖
  • RESTful

    一种软件架构设计风格而不是标准,提供了一组设计原则和约束条件,主要用于客户端和服务器交互类的软件。基于这个风格设计的软件可以更简洁,更有层次,更易于实现缓存等机制。

    30 引用 • 114 回帖 • 1 关注
  • JSON

    JSON (JavaScript Object Notation)是一种轻量级的数据交换格式。易于人类阅读和编写。同时也易于机器解析和生成。

    52 引用 • 190 回帖
  • 小薇

    小薇是一个用 Java 写的 QQ 聊天机器人 Web 服务,可以用于社群互动。

    由于 Smart QQ 从 2019 年 1 月 1 日起停止服务,所以该项目也已经停止维护了!

    34 引用 • 467 回帖 • 742 关注
  • IDEA

    IDEA 全称 IntelliJ IDEA,是一款 Java 语言开发的集成环境,在业界被公认为最好的 Java 开发工具之一。IDEA 是 JetBrains 公司的产品,这家公司总部位于捷克共和国的首都布拉格,开发人员以严谨著称的东欧程序员为主。

    180 引用 • 400 回帖
  • CSS

    CSS(Cascading Style Sheet)“层叠样式表”是用于控制网页样式并允许将样式信息与网页内容分离的一种标记性语言。

    198 引用 • 550 回帖
  • VirtualBox

    VirtualBox 是一款开源虚拟机软件,最早由德国 Innotek 公司开发,由 Sun Microsystems 公司出品的软件,使用 Qt 编写,在 Sun 被 Oracle 收购后正式更名成 Oracle VM VirtualBox。

    10 引用 • 2 回帖 • 6 关注
  • 黑曜石

    黑曜石是一款强大的知识库工具,支持本地 Markdown 文件编辑,支持双向链接和关系图。

    A second brain, for you, forever.

    15 引用 • 122 回帖
  • CSDN

    CSDN (Chinese Software Developer Network) 创立于 1999 年,是中国的 IT 社区和服务平台,为中国的软件开发者和 IT 从业者提供知识传播、职业发展、软件开发等全生命周期服务,满足他们在职业发展中学习及共享知识和信息、建立职业发展社交圈、通过软件开发实现技术商业化等刚性需求。

    14 引用 • 155 回帖
  • ZooKeeper

    ZooKeeper 是一个分布式的,开放源码的分布式应用程序协调服务,是 Google 的 Chubby 一个开源的实现,是 Hadoop 和 HBase 的重要组件。它是一个为分布式应用提供一致性服务的软件,提供的功能包括:配置维护、域名服务、分布式同步、组服务等。

    59 引用 • 29 回帖 • 5 关注
  • LeetCode

    LeetCode(力扣)是一个全球极客挚爱的高质量技术成长平台,想要学习和提升专业能力从这里开始,充足技术干货等你来啃,轻松拿下 Dream Offer!

    209 引用 • 72 回帖
  • Ruby

    Ruby 是一种开源的面向对象程序设计的服务器端脚本语言,在 20 世纪 90 年代中期由日本的松本行弘(まつもとゆきひろ/Yukihiro Matsumoto)设计并开发。在 Ruby 社区,松本也被称为马茨(Matz)。

    7 引用 • 31 回帖 • 211 关注
  • 宕机

    宕机,多指一些网站、游戏、网络应用等服务器一种区别于正常运行的状态,也叫“Down 机”、“当机”或“死机”。宕机状态不仅仅是指服务器“挂掉了”、“死机了”状态,也包括服务器假死、停用、关闭等一些原因而导致出现的不能够正常运行的状态。

    13 引用 • 82 回帖 • 53 关注
  • Redis

    Redis 是一个开源的使用 ANSI C 语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value 数据库,并提供多种语言的 API。从 2010 年 3 月 15 日起,Redis 的开发工作由 VMware 主持。从 2013 年 5 月开始,Redis 的开发由 Pivotal 赞助。

    286 引用 • 248 回帖 • 62 关注
  • 大数据

    大数据(big data)是指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合,是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。

    93 引用 • 113 回帖
  • 音乐

    你听到信仰的声音了么?

    60 引用 • 511 回帖
  • Sublime

    Sublime Text 是一款可以用来写代码、写文章的文本编辑器。支持代码高亮、自动完成,还支持通过插件进行扩展。

    10 引用 • 5 回帖
  • 学习

    “梦想从学习开始,事业从实践起步” —— 习近平

    169 引用 • 506 回帖