PKM#3:竞争目标

这个模型反映了一些有趣的结构决策,我认为自从我一年多前开始此PKM系列以来,这是对某些思想的总结:

  • 文件和摘要并存。 文档是类似于Wiki的文章,它们是“有组织的”注释:它们旨在用作您引用和编辑的文档。 另一方面,摘要可以是临时记录,平凡的书籍条目,或者实际上只是不需要文档的任何内容。 这些是您放入Apple Notes或Simplenote或便利贴中的东西。 在这次迭代中,我们可以看到片段可以存在于类别中,我认为这很有用; 人们还可以通过在书名下的类别中插入摘录来构建一本普通的书。
  • 实现双重类别/标签系统。 这里的主要组织系统是类别,并且每个项目还可以具有与其关联的标签。
  • 跨类别的文档复制。 在“设计思路”标签的左侧,有一个指示符,指示正在将文档复制到另一个类别中。 这解决了我在PKM#1中遇到的一个关键问题,甚至根本不需要标记系统:

“但是我的最初感觉是:分类系统已经显示出它的缺点。 我想在第二天与两个人共进晚餐时添加会议笔记,但是分类系统使我可以在将笔记添加到一个人或另一个人之间进行选择。 标记系统可以让我将其标记为两个人。”

  • 一切都是笔记。 在这里,类别为“ PKM”,但我们也可以在该类别中添加内容,从本质上讲,它是一个带有子注释的注释。 寻找一种显示子注释的方法可能是一项艰巨的设计任务。
  • 两级分类视图。 我一直在努力找出如何最好地允许类别之间的遍历。 这是我在PKM#2的模型中玩过的事情之一。 我关注的是非笨拙的能力,确定性地知道单击哪里可以返回到先前级别的能力(而不是一直更改),可以轻松地在同级之间切换以及其他一些我不记得的功能。 我认为这是一种特别好的方法,因为它允许遍历封闭的文件夹,也可以遍历该文件夹中的所有兄弟姐妹(也可以使用键盘快捷键来遍历),并且比常规的文件夹钻取更麻烦。

其他想法

  • 为了获得最大的灵活性和覆盖不同种类信息的能力,最好是系统不要自以为是,并且可以支持各种不同的观点。 例如,上面的模型可能是默认的,但应该有一些选项以更像Finder窗口,或更像图形或类似的方式进行浏览。
  • 一个主要困难是将图形表示为分类系统。 通过将注释/文档称为节点,将子注释称为给定节点指向的节点,我们可能会更接近于此。 从图形的角度来看,这是有道理的,尽管拥有有向图系统(如果A指向B,则B不一定指向A)可能是非常规的,尤其是从UI / UX角度来看。 也许一些聪明的设计可以解决此问题,并使将项目连接到其他项目更加容易。
  • 我仍然认为片段需要某种“收件箱”,以便将来可以将其添加到层次结构中或进行存档。 不过,我不喜欢收件箱的想法 ,我认为它会像工作一样。 因此,也许最近的摘要流是正确的想法。 我也非常喜欢从最近的观点“归档”片段的想法,例如Google Keep如何做到这一点,但我不知道它在分层结构中将如何发挥作用。 是将“归档的”摘要隐藏在层次结构中,还是仅当它们被废弃时才会发生?
  • 我真的很喜欢新手iPhone笔记应用程序Better。 它的简洁界面和添加主题标签的简单方法非常出色,并且使用起来很有趣。 希望它已同步。
  • Notion.so是绝对出色的Wiki /知识基础产品,尽管其组织功能使用起来有些困难,并且它并不真正支持快速记笔记。
  • 对于我来说,一本普通的书本一直是片段的主要用例考虑因素:您可以在其中存储您认为重要的片段的地方。 (对此应用OCR也将有助于搜索;元数据也将有所帮助。)

一个家庭屏幕的概念。 可以轻松访问顶级元素,但是层次结构也可以访问。

单个页面的概念。 有一种方法可以使子页面显示在页面下方或页面的侧面,这取决于页面及其连接应具有的“重力”类型。 (如果该页面只是用于存储有关项目的信息或元数据的页面,则该页面应位于上方,并应显示标准浏览器UI;如果该页面是常规页面,则子页面的重要性会降低。)

用于添加新项目的概念。 我们需要一种简单的方法,在创建新文档时将新页面附加到现有的“文件夹”,而无需执行整个向下钻取过程,因此,根据先前页面进行自动匹配似乎是正确的主意。