这是一个创建于 3331 天前的主题，其中的信息可能已经有所发展或是发生改变。
平时逛的网站比较少，所以知道的形式也不多，特来请教下。
目前见过比较多的：
1.楼中楼方式[大概是这么叫的?](例:某站文章区)
2.'@'名字的方式(例:本站)
3.1 、 2 两种方式综合的(例:某度 X 吧)
==============================================================
以下是以 旁观者（非参与回复人员） 的角度来看：
对于第一种方式，可以容易的看到之前人的回复，能较快的明白之前发生了什么，但是排版显示效果实在无爱，每次都要把之前的一串回复拉一边，即使同级的能隐藏，总体还是不舒服（个人是这么觉得的反正）。
第二种方式看回复感觉整体就整洁了许多，但如果回复较多或者时间稍长，要找被'@'的人就比较麻烦而且跨度大的话，容易忘记之前说了什么，要理清整个对话有点难度。
第三种方式感觉大致和第一种差不多，不过不用多一级回复就拉一遍之前所有的，相对来说舒服了点，但整体还是不太整洁，略乱（在我个人看来），且楼中楼多了之后，'@'还要翻页一样比较难理清对话
==============================================================
最后，大家有没有什么感觉比较好的方法排版回复？欢迎分享。
有什么观点也可以讨论下
目前见过比较多的：
1.楼中楼方式[大概是这么叫的?](例:某站文章区)
2.'@'名字的方式(例:本站)
3.1 、 2 两种方式综合的(例:某度 X 吧)
==============================================================
以下是以 旁观者（非参与回复人员） 的角度来看：
对于第一种方式，可以容易的看到之前人的回复，能较快的明白之前发生了什么，但是排版显示效果实在无爱，每次都要把之前的一串回复拉一边，即使同级的能隐藏，总体还是不舒服（个人是这么觉得的反正）。
第二种方式看回复感觉整体就整洁了许多，但如果回复较多或者时间稍长，要找被'@'的人就比较麻烦而且跨度大的话，容易忘记之前说了什么，要理清整个对话有点难度。
第三种方式感觉大致和第一种差不多，不过不用多一级回复就拉一遍之前所有的，相对来说舒服了点，但整体还是不太整洁，略乱（在我个人看来），且楼中楼多了之后，'@'还要翻页一样比较难理清对话
==============================================================
最后，大家有没有什么感觉比较好的方法排版回复？欢迎分享。
有什么观点也可以讨论下
 |
1
adrianzhang 2015-10-02 15:51:39 +08:00
最清楚的就是短信 im 那样的气泡
|
 |
2
lostvincent OP @adrianzhang 只是两个人的话基本什么方式都没问题吧，人多的话气泡也会比较难搞清谁和谁说了吧一下子，除非是比较熟的人或者自己是参与回复的人
|
 |
3
233 2015-10-02 16:30:59 +08:00
第一种方式的确很方便 1v1 或类似 1v1 （两个意见群体）的交流， A 文章区经常战起来不得不说从基础设施上就提供了便利。想比 B 的评论，真是没有一点看的兴趣。
从逻辑原则上就是时间线性地展开各人评论，评论中的各楼层不分主次，只有各人观点的演进。 第三种贴吧式就完全是另一种逻辑原则。贴吧中每个回复都相当于一个子楼主，在这个子楼中，回复者是最大的目标，虽然偶尔演变成 NvN 混战，但多数还是 Nv1 的围观。 V2 这种，经常要搜名字看看前面说了什么。 ###建议：能不能做成鼠标移到 @ 上面时，浮动显示此人上一条信息。 A 岛匿名版就是这么做的。 ps ：战并非贬义，泛指一切有实质意见的交流。 |
|
4
lostvincent OP @233 文章区看讨论的确实蛮好的，但是有些太长了感觉可以多少条以上省略，点击展开（ PS ：框框看着不是很喜欢但也不讨厌）
贴吧的就比较不喜欢了，本来就算是只有 @ 找起来也不一定方便，在楼中楼里面地方更小要找起来就更加麻烦了，虽然多数 Nv1 +1 建议感觉不错但是 V2 大多楼不会很长，所以估计需求不会很大（大概？） |
 |
5
abmin521 2015-10-02 22:32:45 +08:00 via Android
这也是我最近在想的问题 本站的方式我感觉用户体验为负， x 吧感觉还行。
|
 |
6
branchzero 2015-10-03 03:32:56 +08:00
看了楼上的回复没有太大的启发。
我倾向用 @ ，但是 @ 如果看线索形式的回复内容的话很无力。 目前我认为最佳的貌似在我的印象里只有张大妈了=。= 超过三层自动折叠中间的楼层，大概是比较折中的一种做法。 不过为了防止对数据库造成压力，每次评论的时候得保存线索串的 id ，怎么存比较恰当是一个值得思考的问题。 本来我认为只要限定最多 10 个线索串 id 就行了，看到值得买的一个神回复，瞬间又没想法了，继续琢磨去。 http://haitao.smzdm.com/p/313129 |
|
7
branchzero 2015-10-03 03:48:53 +08:00
关于目前的博客的回复存储形式，都是加一个 parent_id 存储完事，不存线索串的所有 id ，总感觉在回复量大的情况下会对查询构成负担。
（根据 parent_id 一层层回溯肯定不靠谱，博客应该是把这个 topic_id 的的所有的回复都取出来，然后再根据结果来一层层整理，但如果有分页呢，也查出所有结果是否是多余呢？） 论坛的做法，只有一层引用，且把引用的内容给直接存到这个回复里面了。 目前看来适当的冗余，按顺序存下线索串然后根据值得买的样子做适当折叠，保留搭楼的形式，大概是最好的做法了。 先查出该页的所有回复内容，然后再把所有回复内容的下面的线索串 id 取出来，然后合并后去重然后和这页回复内容取差集，然后丢进去再查询一次，再构造楼层结构是最好的做法了。 |
|
8
lostvincent OP @branchzero 这样的话还是只能解决一级回复，多级还是老样子（某文章区已经去重了，隐藏中间楼层加个展开选项就是你的形式了，大概没理解错？）如果层主是 a ，回复 a 的称做 b ，那么如果有回复 b 的 c 存在以及可能有 defg 等，除了 a-b 这部分，其他的会更加混乱吧，我最想的是把没级都理清，然而并没什么思路（捶地 orz
|
|
9
branchzero 2015-10-03 11:19:23 +08:00
@lostvincent 不会有问题的说，其他的并不影响吧，每个回复他对应的线索串 id 集合都是独立的，是他上面的所有层的回复的 id 集合。
|
Select Language