问题如下图描述。
我现在的操作，都是用鼠标点击到“列表项”，然后鼠标点击复制为应用块才能达到目的，有没有更好的方式呢？或者说，这里 ctl+shift+c，优先应该是复制列表项块，而不是段落块？
如何快速复制列表项引用呢？
本贴最后更新于 754 天前，其中的信息可能已经时移世易
相关帖子
- 其他回帖
-
感谢 D 大认真反馈！没有感到冒犯，都是正常的讨论~
“不一定是其他用户的预期”，这点我承认哈，如上建议确实只能代表我自己的使用习惯，我对其他人的使用方式了解甚少，但这个毕竟不是我作为一个用户需要特别关心的，而是做产品的应该多关注的。所以如果其他用户有不同的用法，你们是比我更清楚的。
“我们正是从用户的实际使用场景出发来考虑这个问题的”，那我就放心了。思源最终交付给用户是产品，以产品的使用场景来构建产品逻辑，我认为没有任何问题。
关于我提出的这个问题，虽然我们今天还达不成一致的意见，但至少能拿出来讨论，并作为产品后续的一个关注点，我觉得还是有价值的！
-
我们理一下这个操作逻辑：
当选择一个段落块进行复制引用时，预期就是这句话，实际也是，这个符合操作逻辑；
当选择一个标题块进行复制引用时，预期是标题即标题下方块，实际也是，这个符合操作逻辑；
当选择一个列表项进行复制引用时，情况就有一些复杂：
- 如果是没有子节点的列表，那么就是这句话，实际也是，这个符合操作逻辑
- 如果是有子节点的列表，那么此时用户在这个场景下期待的操作逻辑是参考“段落”还是“标题”呢？
现在是参考段落，假设是参考标题，效果是什么呢？
- 如果是没有子节点的列表，虽然引用的是列表项块，但展示内容上并不差异，体验一致。但也是有差异的地方：当未来列表项下增加子节点后，两者引用的内容就不相同了，但我理解此时把子节点包含进来更符合用户预期。
- 如果是有子节点的列表，展示的就是此节点和子节点的内容。这也是关键所在，当我们在引用大纲有层级级别中的内容时，是想要节点这一行内容，还是这个节点下所有的内容？我理解后者才是这个场景下引用的真实目的。那么，这里的操作体验和逻辑，应该和标题的逻辑一样。
我理解 D 说的操作逻辑，更偏向于系统实现逻辑，当我们复制引用是段落块时，所有的地方都应该是段落块，否则程序逻辑上是不自洽的。但我想表达的是，一个产品，更要考虑用户的使用场景，在场景中保持操作逻辑一致性会更加的重要。（就像关于列表缩进的处理一样，保持实现逻辑的好处小于场景逻辑，前者更偏向于程序员视角，后者偏向于用户视角）
如上，一家之言，望参考，也期待更多人的讨论和探讨~
1 回复 - 查看全部回帖
欢迎来到这里！
我们正在构建一个小众社区，大家在这里相互信任，以平等 • 自由 • 奔放的价值观进行分享交流。最终，希望大家能够找到与自己志同道合的伙伴，共同成长。
注册 关于