注意2011/09/20：Jeff标记了此
status-completed。我（提出请求的人）不同意所做的事情（实际上是另一个请求的实现）满足了此请求，并认为status-declined会更正确。新的自动完成器很好，但是不一样。但这是杰夫（Jeff）的网站，我不会说出重点。在“不要删除我的评论的@部分”中引发的问题引起了很多关注，但是我们反对与之相关的变更，并未做出提供可行替代方案的建设性工作。这篇文章解决了这一遗漏。
非常简短地回顾一下：最近的更改是，系统现在从注释中删除了
@postowner，这在技术上是不必要触发通知的，而没有其他人对此进行注释。杰夫认为他们是噪音。绝大多数情况下，链接问题的反馈意见是，出于各种原因应撤消更改。 Jeff对此更改有一个特定的目标，即人们不要无缘无故地在评论的开头添加
@postowner。他正在尝试保护和改善SE网络上的信噪比。因此，这是一种替代方法的建议，我认为这种方法不会引起当前变化引起的大规模负面反应：事先明确告知谁将被通知，方法是在用户打开注释时在注释字段下放置一个指示符（请参见问题末尾的书签，让您实时尝试一下）：
这也为您在与其他人打交道时弄清楚了门。例如，如果我要评论Jeff对Siva问题的回答：
当然，我们还将介绍其他时候用户得到通知的时间，例如Jeff是否回复了Siva的评论。系统会自动检测到两个人正在聊天的时间，Jeff不必在此处放置
@Siva即可通知Siva。 （您知道吗？直到Jeff在链接的问题中提到它之前，我才知道。）因此，Jeff立刻打开了注释框，它会说“ Siva将收到此注释的通知”，而Jeff知道他可以键入离开。这会通知用户而不会引起干扰。用户获得了一个非常明确的指导，他们不必在请求所有者上放置
@postowner即可获得通知，因此，仅这样做以触发通知的任何人都将学会不这样做。如果用户仍然出于某种原因感到自己想要这样做，很显然，他们出于非技术原因做出了有意的决定。显然，该措辞可以被修改，但是这个想法是，Jeff的降低噪音的目标可以通过一种有用的，吸引人的方式实现，而不会引发围绕当前变化提出的反对意见。而且它比
@postowner更进一步，可以在不需要指导的任何时间指导人们，因此，如果您考虑这些方向的噪声，甚至可以进一步减少噪声。 br /> 文本的一部分可以链接到现有的帮助框，以进行评论（不是单独的链接，但是例如“将收到通知”之类的东西。不想让它跳转）就像帮助链接一样，但它仍然可以在那里链接。
如果您担心人们不会阅读，可以将其与间歇性提醒弹出窗口结合使用，如果用户确实指定了多余的方向，则该间歇性弹出窗口最多以间隔显示3-5次（间歇性变量强化）：您无需在此评论上使用@Jeff，无论如何，都会通知该用户。将其删除吗？”一旦用户看到并消除了几次，我们知道他们知道并做出了明智的具体决定，可以停止na。显示用户体验方面的情况。您可以通过使用以下URL创建书签，在自己喜欢的SE网站（可能位于meta上）上进行尝试：
javascript:(function(){var%20d=document,db=d.body||d.documentElement,elm;elm=d.createElement('script');elm.src='http://ss.crowdersoftware.com/se/se-comments.js';db.appendChild(elm);})();
这是一个书签小程序，可引导该脚本进行加载，它进入页面。拥有书签后：
使用当前引擎在任何SE网站上提问。
单击书签。
单击链接添加一条评论。 （通过书签加载脚本后，必须执行此操作。）
在常规字符计数器的下面，您将看到通知预览。要卸载脚本，只需刷新页面或转到另一页面即可。小书签的效果是短暂的，仅影响您主动加载该小书签的页面，直到刷新它为止。
这仅仅是概念证明，不是生产代码，也不是向SE提交的代码（尽管欢迎SE使用在实际版本中有用的任何SE）。它实际上并没有告诉服务器该通知谁（当然），它使用了一条简单得多的规则来确定使用
@user进行标记的人（我不认为完美复制复制所需的概念证明）比实际解决方案更长的时间，因为它是我从外面来的，它轮询了注释文本区域，在这里我们可能只想使用与字符计数器相同的事件（尽管字符计数器不了解通过鼠标粘贴），等等等等等等。请不要以为这不止于此。它纯粹是粗略的用户体验概念证明者。就是说，它确实演示了后所有者的自动通知，以及如果后所有者回复的情况下单个评论者的自动通知。#1 楼
由于大多数用户不了解评论通知的动态性（有时我仍然会忘记一些微妙之处），因此最好将其放在此处以明确说明他们正在解决的对象。#2 楼
我喜欢这个。我还认为应该有一个小的可视超链接（带有“？”或“更多信息...”），这些超链接可以链接到有关发生了什么情况的有用文档。评论
嗯...“帮助”链接有点多余。我想一个人可以在两个地方都链接它，但是链接变得有点高兴了。
– T.J.拥挤者
2011年7月21日在14:24
好的，那么示例中的文本“将在此评论中接收通知”应该是链接。这样就不会占用更多空间。至于帮助链接，您有一个要点-我刚刚尝试过-但尽管使用SO超过2年，但我之前从未注意到。
–Jason S
2011年7月21日在14:30
这就说得通了。提醒您注意“帮助”链接，希望它不适用于更大，更动态的文本，该文本将通知谁。但是，即使有人错过了它，与保持或扔掉当前的更改相比，它还是一个比您所谓的@ user-feud更好的“中等”分辨率。
– T.J.拥挤者
2011年7月21日在14:33
我记得在最近几个月才添加了评论帮助链接。绝对不超过6个月大。
–杰夫·阿特伍德
2011年7月28日在9:48
#3 楼
我们这一群人反对与之相关的变革，并未做出具有建设性意义的事情来提供可行的替代方案。这篇文章解决了这一遗漏。
-肯定是更具建设性的。
但是，这也意味着我们应该印刷... [问题负责人]将收到您的答案的通知。
...在每个答案输入表格的底部。
换句话说，如果您假设将通知问题负责人您对他们的问题的回答中，您为什么不还假设将您对他们的帖子的评论通知给帖子所有者？
我在另一个答案中说：
在典型情况下的讨论流程-注释始终会向“在领奖台上”的人（又称帖子所有者）讲话，除非另有明确说明。换句话说，每个帖子都像是写该帖子的人所拥有的一个小博客条目或演示文稿。像这样。
在演示过程中，当有人举手向观众提问并提出问题时，可以肯定地说他们没有向其他随机的观众讲话。
我反对添加一堆乱七八糟的标牌UI，而在大多数典型的注释情况下，默认设置为“合理”。请记住，Stack Overflow上的帖子评论的中位数为零，平均值为2。
（来源：hse.gov.uk）我可以支持的是动态拒绝包含@nomatch的评论无法解决任何有效评论者，编辑者或帖子所有者的字符串。至少在这种情况下，我们会在您提交评论时及时告诉您，而不是使UI混乱并使之更加嘈杂。
评论
一个人的“杂乱无章”是另一个人的有用信息。我一点都没有发现它混乱，而且显然还有很多其他人也不是。与摘要编辑人员键入的内容相比，这是获得最终结果的更好的方法。当前的方法已被社区强烈拒绝，并且这一方法得到了支持。我认为这是您需要优雅接受的情况。
– T.J.拥挤者
11年7月28日在10:18
做一个嫩鸡需要一个硬汉。
–杰夫·阿特伍德
2011年7月28日10:25
不，你知道。当他出了点问题时，需要一个强硬的人来承认，而不是面对压倒性的反馈而脚。如果我们要交流格言，就会想到匈牙利语：“如果一个人叫你一匹马，请嘲笑他。如果另一个人叫你一匹马，请微笑。但是如果第三个人称你为一匹马，照照镜子。”通常，比起棒子，更喜欢胡萝卜。您选择了棍子，严厉的威权主义方法。我建议胡萝卜，一种有教育意义的方法。
– T.J.拥挤者
2011年7月28日10:32
关于中位数为0且平均值为2的点很有趣，但是尚不清楚它是否符合您的意图。那里有很大的偏斜，因此，可能会有相当多的帖子带有大量评论。在那些复杂的Web评论讨论中，@运算符似乎很有用。
–阿里·弗里德曼（Ari B. Friedman）
2011年7月28日在10:40
@ t.j。我非常感谢代替“另一场狂奔”的建设性功能建议，但是我们现在只需要同意就这一点不同意。我敢肯定，很多人都游说史蒂夫·乔布斯（Steve Jobs）也向iPhone添加了一个按钮。
–杰夫·阿特伍德
11年7月28日在10:42
@ gsk3就是为什么只有在评论中唯一的发言者是帖子所有者和另一个人时，才删除@postowner。
–杰夫·阿特伍德
2011年7月28日在10:43
@Jeff：那是古老的樱桃采摘辩论技巧，再加上联想技巧的古老美德。如果乔布斯（Jobs）关于一个按钮是正确的（这还不是很清楚），那么无论您所做的更改还是坚持使用该按钮，对于您是否在此位置，都无话可说。您甚至可以称其为“噪音”。 ;-)但是，很认真的说，如果您将继续选择威权主义而不是民主，而是放任自流，我真的相信您最终将摧毁SE。当前的变化是主动伤害。坚持下去是双重的。
– T.J.拥挤者
11年7月28日在11:16
@Jeff：为什么您会拒绝使用与任何人都不匹配的@lerts的评论？在此注释线程中，没有什么麻烦，但是为什么我仍然选择写@lerts会很糟糕？
–亨德里克·沃格特（Hendrik Vogt）
2011年7月28日15:33
@Jeff如果人们显然没有得到通知，以及为什么（由于他们不断在评论中添加@postowner，所以TJ的提议显然不是“一堆乱七八糟的标牌UI”。如果您希望人们使用该系统以您想要的方式使用它，您必须以某种方式对其进行培训。他们显然没有阅读（或同意）FAQ对此的看法。
– JockM
2011年7月29日在18:34
@Jeff我还要指出，该系统无法“正常运行”。如果您知道它可以那样工作（这并不明显），并且同意就可以。我个人希望它的工作方式类似于Twitter或其他论坛系统（使用@定位）。@与通知无关，而与引导注意力有关。因此，我发现SO是外星人异常值而不是常态。
– JockM
2011年7月29日在18:37
@Jeff为什么您认为人们写@blah的唯一原因是为了得到通知？ @表示法早于SO，并且早于基于SO的@通知。因此，很明显，用户写信是为了指导他们正在与谁交谈。如果您不希望这样做（您不喜欢，因为我读过您的意思），那么教育他们是使人们停下来的唯一方法。否则，您将继续拍打创可贴以尝试纠正帖子中的“问题”。
– JockM
2011年8月1日下午6:56
我显然同意T.J.拥挤的人显然，将通知项发送给其他人还有更多的意义。这就是twitter如此出色的原因，自从删除我的@ ...以来，我一直讨厌它，并对谁看到我的评论和谁没有看到我感到困惑。显然，它不起作用。
– JonH
11年8月12日在19:55
@jon在Twitter上没有“父帖子”；在这里，总是有一个帖子附有评论。显然，您是在和那个人交谈，即您最初发表评论的那个人。
–杰夫·阿特伍德
11年8月12日在21:19
@杰夫：你完全错了。我之所以呼吁您使用此内容，纯粹是因为我希望该站点成为最好的站点。我认为Jock试图在这方面支持我（我不完全确定为什么，因为他很久以前就已经用脚投票了，但是我们在那里-他是朋友）。无论如何，我认为所有观点都是正确的。您显然不会公开回答其他问题，我不再询问。而且您将继续采用专制的方法。希望对您有效。我不希望如此，但希望如此。最好，
– T.J.拥挤者
2011年8月16日15:02
我支持T.J.的建议-即使有时我有时也很难弄清楚将通知谁，而且我几乎每天都在使用该系统。不必一定是一个标志-某个地方的小工具提示可能已经完成了这项工作，并且提供了清晰的提示
– Pekka
2011-09-10 18:46
#4 楼
实质上是用制表符名称完成注释，请完成！
请注意，当OP和另外1个人之间进行对话时，此功能不会自动完成名称：足够聪明，知道@提及是不必要的。
因此，如果您键入@却没有完成，则您会立即收到不需要这样做的反馈。
评论
值得注意的例外是何时通知还没有评论的帖子编辑者。
–蒂姆·斯通（Tim Stone）
2011-09-20 0:24
是的，这将需要更多的工作，并将一个简单的功能变成一个相当复杂的功能。无论如何，这是一个罕见的用例。
–杰夫·阿特伍德
2011年9月20日下午0:37
总比没有好，但是我不得不为我说，它错过了关键的教育和清晰度方面。它并不能告诉您已经通知了谁（例如，没有告诉Tim当您发表评论时您会收到通知，没有告诉您评论时您会收到Tim的通知）。实际上，为了我的钱，应将此请求标记为“状态已拒绝”足够不同。很好，但有所不同。
– T.J.拥挤者
2011-09-20 8:54
@ T.J就像答案显然会通知提出问题的人，评论显然会通知您正在评论其帖子的人。上面是关于蒂姆的观点，但是当您输入@却没有完成操作时，。相对于假设用户可以阅读我们在屏幕上显示的所有内容，这是一种出色的“及时”教育（提示：他们不会）。
–杰夫·阿特伍德
2011-09-20 9:01
@Jeff：我看不到如何生成问题“为什么'Tim'不显示自动补全？”是“优越”。顺便说一句：在我最初的建议中，我真的应该有某种形式的自动完成功能。令我惊讶的是。自动补全是一件好事，对此表示敬意。这根本不是一回事，也没有实现我的建议所要达到的目标。
– T.J.拥挤者
2011-09-20 9:13
@Jeff：我几乎不敢问这个问题，但是为什么我会自动为您完成？我注意到我的“ @Jeff”呆在那里。如果评论流中还有其他人（在本例中为Tim），您是否放宽了针对发布者的指导规则？如果是这样：好的，谢谢，不胜感激。绝对是对原始版本的改进。
– T.J.拥挤者
2011-09-20 9:20
@ T.J，完成者知道规则，并且仅在必要时完成。这里有三个人在说话（蒂姆，你，我）。我们只有在有两个时才删除，在这种情况下很明显。
–杰夫·阿特伍德
2011-09-20 9:23
@Jeff：我不会再讨论整个问题。我坚信，不过，不应将此请求标记为已完成状态。自动完成程序与此请求所请求的内容无关。但这是您的网站，我不会解决这个问题。
– T.J.拥挤者
2011-09-20 13:05
评论
绝妙的建议TJ！ -开发人员，此更改是否会使服务器负担过多的请求？您有很大的疑问
绝对是我见过的有关此新功能的最具建设性的文章。 +1是为了将您的意见转化为富有成效的内容，而不是由于这种变化而使我开始期待的大量咆哮。 （此外，这似乎似乎是个好主意。）
@Cody：谢谢。我很尴尬的是在此之前没有提出任何建议。我恳求过度劳累（只是下了很大的限期推销）。
就其本身的优点而言，这是一个绝妙的主意，无论对名称参考材料进行什么处理，都将是一个改进。
请注意，我的意思并不是说我特别批评您。在整个过程中，您一直很有礼貌。看到人们把头撞在墙上真是令人讨厌。 :-)我认为该计划具有非常好的副作用，可以教用户如何使用该系统。
@Cody：谢谢，我不是那样的。 @M。提比特：我想这将在客户端而不是服务器端完成。弄清楚通知谁的逻辑可以移到客户端，并且提交中包括（用户ID）列表。 （服务器当然会检查该区域中的用户ID是否处于活动状态，它只需要复制使@crowder和@ T.J。都起作用的逻辑即可。）
如果在我仍在键入我的信息时有人发表评论，此检测是否可靠地起作用？即。我开始输入我的评论，以为会发送给Jeff，然后其他人同时发表评论，我的评论是对该评论的回复，还是去Jeff？
@Lasse：在您的特定示例中，除非您叫喊其他人，否则仅会通知Jeff（是后所有者）。但是，与任何增强功能一样，有些边缘情况需要探索。例如，某人在自己的帖子中发表评论，例如最初最初没有人发表评论，但与此同时有人发表了评论，这使其看起来像是两人对话。但是，在那种情况下，我会说客户端确定（不通知该人）是正确的，如果我不知道他们在撰写我的意见时发表了评论，则通知另一个人没有任何意义。
我想我的问题更多是关于现在会发生什么，而不是此处提出的UI更改。即。如果我现在在这里输入此评论，您会收到通知吗？而且，如果有人同时发表评论，那么您会收到通知吗？ （使用当前的实现。）此外，只是确保您了解；我真的很喜欢建议的UI更改，目前似乎有很多隐藏的魔术正在发生，而且我真的不确定现在发布内容时会发生什么。我们的用户对系统行为的期望越确定，就越好。
反过来，这意味着，如果我们无法使系统表现得像每个人所期望的那样，则系统带来的清晰度越高越好，因为这会改变用户对系统的期望。我喜欢！
@Lasse：很高兴您喜欢这个主意！ :-)是的，我已收到上述通知，因为我是发布您要评论的项目的人（在本例中为问题）。过帐所有者（过帐Q或A的人）总是会收到通知，这是自动的。我的理解是，唯一的其他自动通知是，如果Joe对Nitin的帖子发表评论，而在其他人没有发表评论时Nitin对此发表评论，则系统会假定评论针对的是Joe并通知他。要通知其他任何人，您必须专门喊出他们。是的，我真的很喜欢这如何使所有这些变得清晰和预先。