最近由于在写一个小工具,生成一些我想要的"视图".但在编辑过程中,我感觉操作过于繁琐,"属性"能否作为一种特殊类型的块. 直接能够在正文之中编辑,而非需要一个额外的面板.这只是一个我个人的想法,可能更多属于操作习惯的问题吧.
另外想看看大家对于属性视图有什么想法.比如有哪些组织视图的方式,可以对实际知识管理起到帮助.
还有视图的呈现结果,只有"表格"这一种样式吗?他可不可以有一些其他的展示效果.
最后,视图还应该具备那些额外的功能.
[讨论] 对未来属性视图的一些疑问
本贴最后更新于 1341 天前，其中的信息可能已经东海扬尘
相关帖子
-
-
这些我都看过了.我的意思是,有没有一些实际的可参考的案例.比如下文中,用 AirTable 打造自己专属的个人数据库 · 语雀 (yuque.com)
问题解决工具 , 它涉及到了
● 名称：记录的名称；
● 类型：记录的类型，包含 问题、行动点、思路、信息源、场景 这么 5 大类；
● 描述：记录的详细说明；
● How：How 代表了这条记录可以往下推演的点，例如一个问题可以往下一层级拆解成若干个子级问题，或者直接得出行动点；
● Why How：为什么推出这几个行动点，往往是因为有一些信息输入、或者场景限制等等；
● Why This：为什么会有这个问题/思路/行动点？或者相关的场景是什么那么对于这种方式,在实际的应用场景过程中,如何去组织文档块,或者是组织属性. 在属性面板的场景下,去把这些 K-V 一个一个输入到属性面板中无疑是很影响编辑体验的.同时这些东西写到属性面板里无疑会影响实际文档内容.
而如果我在正文中写入这些信息,我需要给这些块设置一个统一的属性,那么上面的"问题解决工具",我需要对 7 个块设置一个属性.你想一想,对 7 个块,依次设置输入,哪怕是通过模板导入,也是挺麻烦的事情.
这也是我为什么说:是否可以把属性面板,作为"块"的一种,这样子它能够更好的嵌入到正文里面,同时也方便汇总.要做对比的话,logseq 那种方式是不是更平滑一些.
而 langzhou 的大佬视图挂件,我使用的实际感受:他其实也是一个项目管理工具,是对于属性视图最最简单的应用.
所以我的实际问题是,类似于"问题解决工具"这种更复杂的属性视图,怎么去更平滑的在不同的文档中创建,最后汇总到一起.
还有哪些意图解决特定问题的属性视图,大家感觉是很有帮助的.
1 回复1 操作crowds21 在 2021-10-31 10:08:33 更新了该回帖 -
nmtuan •
说几个场景, 看是不是这个意思.
- 通常的文章会有标题,作者,摘要,内容, 那创建一个文章分类 A(模板?), 基于这个 A 创建的页面(/块)是否默认就带着作者/摘要这俩自定义属性.
- 需求管理, 通常也会有描述,来源,状态,等. 那创建一个需求分类 B, 基于这个 B 再创建的东西是否就默认带着 相关字段?
AB 是否就是所谓的视图? 或者说是个类型, 也或者说是一堆自定义属性的组?
1 回复 -
是的按照思源的思路,最后的属性视图呈现的面板应该就是 很多个块所带有的共同的属性.
但是我觉得这种形式和文档内容的正文是割裂的.这些属性表示的是一个块的"特征",而非不是一个笔记正文的一部分.
我预期的效果是这样的
- 内容A - 特点 - 出处 - 一些待解决的问题 - 内容B - 特点 - 出处 - 一些待解决的问题由于内容 A 和内容 B,这个我在笔记中记录的内容,他们有一些共同之处,所以我可能会将他们作为一个"视图",用表格的形式罗列出来.
同时这些内容是和上下文有关联的,我并不想把他们放在属性面板当中.而思源目前要达到相同的效果,需要用户有一套自己的 front-matter, 然后还需要通过 SQL 和 API 来自己实现,这个过程相当麻烦,且最后也很难实现一些较为复杂的"视图",而且通用性可能不高.
如果到时候属性视图只是需要配合属性面板的话,我认为略有些鸡肋,没达到我的预期效果.
请输入回帖内容
...
欢迎来到这里！
我们正在构建一个小众社区，大家在这里相互信任，以平等 • 自由 • 奔放的价值观进行分享交流。最终，希望大家能够找到与自己志同道合的伙伴，共同成长。
注册 关于