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

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

目前 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 票

  • 思源笔记

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

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

    23011 引用 • 92559 回帖

相关帖子

优质回帖
  • 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
请输入回帖内容 ...

推荐标签 标签

  • Ruby

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

    7 引用 • 31 回帖 • 216 关注
  • 以太坊

    以太坊(Ethereum)并不是一个机构,而是一款能够在区块链上实现智能合约、开源的底层系统。以太坊是一个平台和一种编程语言 Solidity,使开发人员能够建立和发布下一代去中心化应用。 以太坊可以用来编程、分散、担保和交易任何事物:投票、域名、金融交易所、众筹、公司管理、合同和知识产权等等。

    34 引用 • 367 回帖 • 1 关注
  • 爬虫

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

    106 引用 • 275 回帖 • 1 关注
  • SOHO

    为成为自由职业者在家办公而努力吧!

    7 引用 • 55 回帖 • 5 关注
  • CodeMirror
    1 引用 • 2 回帖 • 129 关注
  • Swagger

    Swagger 是一款非常流行的 API 开发工具,它遵循 OpenAPI Specification(这是一种通用的、和编程语言无关的 API 描述规范)。Swagger 贯穿整个 API 生命周期,如 API 的设计、编写文档、测试和部署。

    26 引用 • 35 回帖 • 5 关注
  • WiFiDog

    WiFiDog 是一套开源的无线热点认证管理工具,主要功能包括:位置相关的内容递送;用户认证和授权;集中式网络监控。

    1 引用 • 7 回帖 • 591 关注
  • 旅游

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

    93 引用 • 899 回帖 • 3 关注
  • FlowUs

    FlowUs.息流 个人及团队的新一代生产力工具。

    让复杂的信息管理更轻松、自由、充满创意。

    1 引用
  • Mac

    Mac 是苹果公司自 1984 年起以“Macintosh”开始开发的个人消费型计算机,如:iMac、Mac mini、Macbook Air、Macbook Pro、Macbook、Mac Pro 等计算机。

    166 引用 • 595 回帖
  • 博客

    记录并分享人生的经历。

    273 引用 • 2388 回帖 • 1 关注
  • Angular

    AngularAngularJS 的新版本。

    26 引用 • 66 回帖 • 536 关注
  • QQ

    1999 年 2 月腾讯正式推出“腾讯 QQ”,在线用户由 1999 年的 2 人(马化腾和张志东)到现在已经发展到上亿用户了,在线人数超过一亿,是目前使用最广泛的聊天软件之一。

    45 引用 • 557 回帖 • 44 关注
  • Markdown

    Markdown 是一种轻量级标记语言,用户可使用纯文本编辑器来排版文档,最终通过 Markdown 引擎将文档转换为所需格式(比如 HTML、PDF 等)。

    167 引用 • 1520 回帖 • 1 关注
  • 黑曜石

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

    A second brain, for you, forever.

    16 引用 • 130 回帖
  • Bug

    Bug 本意是指臭虫、缺陷、损坏、犯贫、窃听器、小虫等。现在人们把在程序中一些缺陷或问题统称为 bug(漏洞)。

    76 引用 • 1737 回帖
  • 数据库

    据说 99% 的性能瓶颈都在数据库。

    343 引用 • 723 回帖
  • 又拍云

    又拍云是国内领先的 CDN 服务提供商,国家工信部认证通过的“可信云”,乌云众测平台认证的“安全云”,为移动时代的创业者提供新一代的 CDN 加速服务。

    21 引用 • 37 回帖 • 548 关注
  • LeetCode

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

    209 引用 • 72 回帖
  • JWT

    JWT(JSON Web Token)是一种用于双方之间传递信息的简洁的、安全的表述性声明规范。JWT 作为一个开放的标准(RFC 7519),定义了一种简洁的,自包含的方法用于通信双方之间以 JSON 的形式安全的传递信息。

    20 引用 • 15 回帖 • 6 关注
  • 阿里巴巴

    阿里巴巴网络技术有限公司(简称:阿里巴巴集团)是以曾担任英语教师的马云为首的 18 人,于 1999 年在中国杭州创立,他们相信互联网能够创造公平的竞争环境,让小企业通过创新与科技扩展业务,并在参与国内或全球市场竞争时处于更有利的位置。

    43 引用 • 221 回帖 • 106 关注
  • Spring

    Spring 是一个开源框架,是于 2003 年兴起的一个轻量级的 Java 开发框架,由 Rod Johnson 在其著作《Expert One-On-One J2EE Development and Design》中阐述的部分理念和原型衍生而来。它是为了解决企业应用开发的复杂性而创建的。框架的主要优势之一就是其分层架构,分层架构允许使用者选择使用哪一个组件,同时为 JavaEE 应用程序开发提供集成的框架。

    943 引用 • 1460 回帖 • 3 关注
  • 微信

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

    132 引用 • 795 回帖
  • 星云链

    星云链是一个开源公链,业内简单的将其称为区块链上的谷歌。其实它不仅仅是区块链搜索引擎,一个公链的所有功能,它基本都有,比如你可以用它来开发部署你的去中心化的 APP,你可以在上面编写智能合约,发送交易等等。3 分钟快速接入星云链 (NAS) 测试网

    3 引用 • 16 回帖 • 5 关注
  • App

    App(应用程序,Application 的缩写)一般指手机软件。

    91 引用 • 384 回帖 • 2 关注
  • Node.js

    Node.js 是一个基于 Chrome JavaScript 运行时建立的平台, 用于方便地搭建响应速度快、易于扩展的网络应用。Node.js 使用事件驱动, 非阻塞 I/O 模型而得以轻量和高效。

    139 引用 • 269 回帖 • 28 关注
  • Postman

    Postman 是一款简单好用的 HTTP API 调试工具。

    4 引用 • 3 回帖 • 7 关注