UI design: post draft v1

这部分内容没看懂，主要部分应该是显示模式吧，但是却找到了表情、图片、附件等按钮。

右侧的功能区那个设置部分也不舒服。

我觉得你的意思应该是，右侧的功能区是主要内容相关的按钮啊，设置啊等等。但是发表这样的按钮还是不适合放在这个区域的。这个部分的时候放比如：关注新回复、加入收藏，还有比如管理按钮等。

这部分是发帖页面。

我希望达到的效果是发帖时的状态和发帖后的状态是一样的。所以将发帖后的比如日期之类的改为添加表情，图片，附件。左侧是对于该帖的编辑，右侧是对于该帖的操作。

但是发表这按钮放这把的确我的考虑可能也有点不合适。直观的位置应该是在内容下侧。但是假如能明确功能，“左侧是编辑，右侧是操作”的话这样看又不成问题。还和为了统一界面有关。不希望界面混乱也是原因。

在 2014年9月19日，下午5:06，James Ruan notifications@github.com 写道：

这部分内容没看懂，主要部分应该是显示模式吧，但是却找到了表情、图片、附件等按钮。

右侧的功能区那个设置部分也不舒服。

我觉得你的意思应该是，右侧的功能区是主要内容相关的按钮啊，设置啊等等。但是发表这样的按钮还是不适合放在这个区域的。这个部分的时候放比如：关注新回复、加入收藏，还有比如管理按钮等。

— Reply to this email directly or view it on GitHub.

争议比较大的是帖内的页面。我目前认为这是最好的设计但是也存在很多不足如下 1、把和用户相关的内容放在左侧的原因是为了突出内容。 2、有个颜色块的框的目的原本是为了将用户与楼的相关信息放在一起就像是下图。

3、楼主是横的下面的竖的。原因在于早先设计是下面也是横的，但是楼主左侧有两栏，一栏是标题一栏是相关信息和操作。但是回复贴就只有一栏，假如空出那么的一栏就会很丑陋，假如不空而让下面的信息上来的话排版也很丑陋。所以将下面楼做成这样。

default

这也是很多地方的一个取舍。但我不保证我的取舍是最合适的做法。只是我觉得这样是我能想到的最合适的做法。

假如你有更好的想法可以和我说。

4、快捷回复即当鼠标悬浮与该楼的的时候内容的下部分会出现快捷回复。对于楼主的回复即普通楼，对于回复的回复理解为引用并出现在下一楼。

5、设置表情栏的原因是很多用户只是用表情表示自己的一种看法。但是这样的想法来占据一楼可能太过浪费。所以我的想法是用户的单表情回复加载到该贴的表情栏而不建新楼。用户一层楼里有文章有表情的话就新建一楼。问题是：建楼是用户一个希望达到的目的来得到一些诸如“满足感”的东西，假如采用上面那种方法会导致“表情+无关内容”这样的同样没价值的信息。所以想考虑的是如何设置能避免这种单表情回复同样能让用户产生满足这样的效果。目前我唯一设计中体现的即是表情右下角的一个头像，但是这样的做法显然太单薄。希望你能就这个问题多提一些看法，我们一起想解决方案。

6、热门回复和最新回复是当帖子达到某种程度，比如超过五页了。目的即让新用户也有回复的动力，新回复也有被发掘的机会，好回复能及时呈现而不是埋没在数量庞大的回复中。

最近隔几天就会更新一下版本。等会我会给你昨天的版本。之前你的一些意见我会再考虑，一些意见已经修正了。

在 2014年9月19日，下午5:06，James Ruan notifications@github.com 写道：

这部分内容没看懂，主要部分应该是显示模式吧，但是却找到了表情、图片、附件等按钮。

右侧的功能区那个设置部分也不舒服。

我觉得你的意思应该是，右侧的功能区是主要内容相关的按钮啊，设置啊等等。但是发表这样的按钮还是不适合放在这个区域的。这个部分的时候放比如：关注新回复、加入收藏，还有比如管理按钮等。

— Reply to this email directly or view it on GitHub.

看不到图，email回复的时候传图似乎不会在github上显示的。最好还是在github上编辑，除非回复是纯文字。

P.S.github的编辑器设计的就很不错，可以借鉴。

上面几点看不到图不好说。说说下面几点：

4、引用和回复是不一样的：引用是帖子的上半部分是引文，这部分的引文可以由论坛程序生成的全文，也可以是用户手动编辑的内容。

插入说一个功能上的细节：论坛里的引文大多是全文引用某回复，这样的原因是原来的回复是单线性的，不引用的话别人很难找到上下文，是用户“发明”出来的一个丑陋的补丁模式。而现在重新设计了，有机会把这部分功能做得更好，不需要引用全文，就能达到引用全文的效果。一部分是我们的现在的设计中，回复是双线性的，有主线和分支线，反复的讨论会优先集中在分支线上出现，其次才是按时间排序，这样可以大大减少全文引用的使用。另一部分，凡事点击回复中的回复按钮的，发言的时候前面会给出一个原来那个回复的链接，对上下文不清楚的可以通过那个链接看到原文。这两部分的设计都不能解决上下文关联问题的时候才会用的全文引用。旧版的98有两个UBBCode，quote和quotex，前者是普通的引文标签，后者是专门发明出来用于解决引用全文过于丑陋的问题的（可以去看看他们的区别）。新版中，quotex应该消失，凡事用点击“引用全文”按钮生成的引文的，都按照类似quotex的引用方式呈现（似乎现在的98已经这样做了，默认就是quotex）。而quote依然需要保留。

点击回复时，可以这样现实：（头像）之前说道：（前20个字）...

然后这个部分是一个链接，点击后可以跳到原回复，这样的和引用全文的感觉很像，但是后端实现上是不一样的：引用的内容，后端不能判断是上下文；回复的内容，后端可以判断为上下文。一旦判断为上下文，就可以实现所谓：只看该作者相关讨论这样的功能，过滤其他回复，之显示本贴作者回复的回复贴，和回复本贴作者其他贴的回复贴。（比原来的只看该作者发言要更进一步）。

5、这部分我之前的设计是一个叫“短评论”的东西，不占楼，直接显示在原贴边上（或者在原帖下面显示一个折叠的短评区），里面只有xxx说：xxx这样的内容，没有头像。回复的部分可以设定一个标准，比如篇幅不足25个字的（未来可以使用机器学习算法，根据大家水的内容自动分辨是否在水）自动变为短评论。这样做，长评论的部分会视觉上凸显出来，鼓励读者仔细看；而短评论的部分显示的比较密集，方便读者迅速的刷过。

6、这部分会有算法推荐的，不需要人工设立过于细的标准判断的。

前面几点的图可以到我给你昨天发的文件里看。

我觉得很多短的评论的确是需要考虑的地方。但是对于“短评论”这一点我不太认可。我一直对一种内容两种展示方式不太认可。会混乱。

其次假如把度放到多少才算是短评论？似乎超过百分之九十的回复都是十个字以内的。

然后我希望展示的方式最简，用户可操作方式最简。只有两种。1、对楼主的回复是新楼。2、对非楼主的回复是引用。假如能更简单就更好了。

所以就没了比如直接引用楼主之类的方式。也没了单表情引用回复等。

全文引用的确是个问题。会占很大的篇幅。但是怎么说呢。可能折叠这样的方式比较好。但是跳转的方式不太好。

我觉得好的设计一定是能一句话讲清楚的。但也我很多地方也做不到。

非资深论坛使用者，所以我不懂98各种奇奇怪怪的回复方式和操作。但是我希望新版一出来，所有人一看就明白98有什么操作。

在 2014年9月20日，下午9:27，James Ruan notifications@github.com 写道：

上面几点看不到图不好说。说说下面几点：

4、引用和回复是不一样的：引用是帖子的上半部分是引文，这部分的引文可以由论坛程序生成的全文，也可以是用户手动编辑的内容。

插入说一个功能上的细节：论坛里的引文大多是全文引用某回复，这样的原因是原来的回复是单线性的，不引用的话别人很难找到上下文，是用户“发明”出来的一个丑陋的补丁模式。而现在重新设计了，有机会把这部分功能做得更好，不需要引用全文，就能达到引用全文的效果。一部分是我们的现在的设计中，回复是双线性的，有主线和分支线，反复的讨论会优先集中在分支线上出现，其次才是按时间排序，这样可以大大减少全文引用的使用。另一部分，凡事点击回复中的回复按钮的，发言的时候前面会给出一个原来那个回复的链接，对上下文不清楚的可以通过那个链接看到原文。这两部分的设计都不能解决上下文关联问题的时候才会用的全文引用。旧版的98有两个UBBCode，quote和quotex，前者是普通的引文标签，后者是专门发明出来用于解决引用全文过于丑陋的问题的（可以去看看他们的区别）。新版中，quotex应该消失，凡事用点击“引用全文”按钮生成的引文的，都按照类似quotex的引用方式呈现（似乎现在的98已经这样做了，默认就是quotex）。而quote依然需要保留。

点击回复时，可以这样现实：（头像）之前说道：（前20个字）...

然后这个部分是一个链接，点击后可以跳到原回复，这样的和引用全文的感觉很像，但是后端实现上是不一样的：引用的内容，后端不能判断是上下文；回复的内容，后端可以判断为上下文。一旦判断为上下文，就可以实现所谓：只看该作者相关讨论这样的功能，过滤其他回复，之显示本贴作者回复的回复贴，和回复本贴作者其他贴的回复贴。（比原来的只看该作者发言要更进一步）。

5、这部分我之前的设计是一个叫“短评论”的东西，不占楼，直接显示在原贴边上（或者在原帖下面显示一个折叠的短评区），里面只有xxx说：xxx这样的内容，没有头像。回复的部分可以设定一个标准，比如篇幅不足25个字的（未来可以使用机器学习算法，根据大家水的内容自动分辨是否在水）自动变为短评论。这样做，长评论的部分会视觉上凸显出来，鼓励读者仔细看；而短评论的部分显示的比较密集，方便读者迅速的刷过。

6、这部分会有算法推荐的，不需要人工设立过于细的标准判断的。

— Reply to this email directly or view it on GitHub.

短评论的问题的确存在，一个是你说的，界定标准的问题。

其他的论坛的系统通常这样设定：有短评论，也有回复字数限制，但没有小于多少字的转为短评论的设置。这样做的原因主要是，短评论是个后来加入的功能，但是一直缺乏一个很好的推广方式。通常短评论都是绑定到其他操作（比如说送论坛币、管理员操作等），留下来的短评论按钮也很少有人单独使用。

另一个是显示上的问题，比如说一个热门帖子，收到了100条短评论，这主贴就变得非常长；其他论坛的做法是只显示最近5-10条的短评论。

前面几个问题，我的意见是这样的：首先，讨论（thread）和回复（post）是两个东西：前者是一系列post的集合，并为这一系列post定一个形式：是话题讨论（topic）是问答（QA）还是投票（poll）。然后，楼主贴只是对这一个讨论的第一个回复。然后，根据这样的信息分层，顶部显示的应该是和这个讨论有关的内容：标题、类型、统计信息，右侧边栏则是相关的操作，关注，收藏，显示模式、管理员可见的其他操作。而主贴和其他回复贴的显示的布局是完全一样的。

关于引用的部分，另一个可取的极端是去掉全文引用按钮，没有任何形式的自动引用，只是纯手动输入内容的引用。

事实上，近年来类似微薄这样的轻评论越来越多了，大家更习惯使用@，而不是去点击“回复”按钮，习惯copy链接，而不是点击“引用”按钮。这也是设计者引导的结果：提供@自动提示功能，让使用@变得很方便；不提供“引用”按钮，只提供一个链接，引用链接明显比引用全文更加方便。

然后说一下新浪微薄一个设计上的缺陷：转发和回复时，“转发”和”回复“的文字作为用户输入的文字（同样计算回复长度），当一个东西被反复回复和反复转发的时候就出现反复嵌套的问题了。我们的论坛同样是需要“回复”功能的，“转发”似乎是不在设计中的。回复这部分逻辑应该变成metadata由后台记录，而不是变成用户输入的data。

恩，我的考虑是够用的前提下一切从简。

关于讨论和回复的理解。你的理解我觉得还是有点不太正确而地方，你的理解中每一层楼的意义是等价的，都是关于讨论的回复。但是我觉得问题在于非楼主帖的回复默认的不是针对讨论的回复，而是针对楼主帖的回复。所以楼主帖和普通帖的意义是不同的。所以我的分类是三层，一层是楼主帖包含了收藏等专属楼主操作。第二层是回复帖，也就是对于楼主的回复。第三层为多级回复帖，即是对回复帖的回复。三种帖的类型共有帖本身的操作，比如只看该用户。

关于@的，@需要，但是@还是很难代替回复的，@没法提供内容。我觉得@只要发挥它“告诉别人这而和它有关”就行了。

我的想法，局部引用需要，但是交互方式必须可以这样：像popchip。

解决办法可能有几点 1、不想给用户断章取义的的权力，也不能给用户改变引文的权力，比如起码应该将被引放在上下文中。即使这样会造成篇幅浪费。 2、默认的回复楼主为添加楼，默认回复其他楼为引用全文并添加楼，但局部引用优先。

但是目前的设计对于版聊显然没办法，你有什么好建议吗？

在 2014年9月20日，下午10:53，James Ruan notifications@github.com 写道：

关于引用的部分，另一个可取的极端是去掉全文引用按钮，没有任何形式的自动引用，只是纯手动输入内容的引用。

事实上，近年来类似微薄这样的轻评论越来越多了，大家更习惯使用@，而不是去点击“回复”按钮，习惯copy链接，而不是点击“引用”按钮。这也是设计者引导的结果：提供@自动提示功能，让使用@变得很方便；不提供“引用”按钮，只提供一个链接，引用链接明显比引用全文更加方便。

然后说一下新浪微薄一个设计上的缺陷：转发和回复时，“转发”和”回复“的文字作为用户输入的文字（同样计算回复长度），当一个东西被反复回复和反复转发的时候就出现反复嵌套的问题了。我们的论坛同样是需要“回复”功能的，“转发”似乎是不在设计中的。回复这部分逻辑应该变成metadata由后台记录，而不是变成用户输入的data。

— Reply to this email directly or view it on GitHub.

cc98-frontend-development / documents

UI design: post draft v1 #11