PDF广播消息：面向大众的消息传递
FRANK JANIA，IBM
这种强大的通信形式既有社会影响，也面临技术挑战。
“我们想要这个和那个。我们要求分享那个和大部分那个。一些这个和 - - - - 在所有那个中。他们的要求将会改变，所以 - - - - 保持清醒。”1 喜剧演员比利·康诺利说这话时并没有谈论消息传递，但我不认为有比这更恰当的引言来形容我们对信息如饥似渴的渴望，这源于我们每天视为理所当然的、支持消息传递的网络连接世界。
我们通过网络搜索可以即时访问拍字节级的存储数据。在消息传递方面，我们拥有空前数量的通信工具，可以同步和异步地访问他人。电子邮件、留言板、新闻组、IRC（Internet Relay Chat）和IM（即时消息）只是几个例子。这些工具都特别重要，因为它们已成为基本的生产力权利。它们导致了我们沟通方式的根本转变。许多读者可以证明，当邮件服务器宕机或无法访问IM时，会感到与外界脱节。对于我们中的一些人来说，网络中断现在就像停电一样不方便。
这些工具也很重要，因为它们代表了提供增强交互方式的技术。一方面，就电子邮件而言，该技术提供了比标准邮件更快的传递速度。另一方面，就IM而言，广告意识信息和进行实时文本对话的能力构成了一种新的通信形式。广播消息传递是一种介于两者之间的技术，它有几个用例突出了它的有效性，并表明它有一天也会像IM一样普及。然而，向大量受众提供广播消息传递既有社会影响，也存在构建面向此类受众的广播消息传递工具的挑战。
广播消息：定义
我们可以回顾一个现实生活中的场景，它是广播消息传递的类比。您飞往一个您从未去过的城市的会议，在那里您要向 2,000 名观众宣读论文。您计划在会议结束后多待一天，想知道这座城市的“必看”景点是什么。不妨问问观众成员。一些人开始大声喊出回应；您意识到这座城市有很多值得一看的地方。前排有一群与会者似乎非常坚持让您去城市的某个区域，因为那是最好的。您走到那里与他们交谈，以获得更多见解。您对另一组人也做了同样的事情，他们提出了自己令人信服的论点，让您去其他地方。在您的选择范围缩小到两个地方后，您要求观众举手表决选择一个地方或另一个地方。
上面的例子相当平淡，但我们应该考虑一下，如果同样的情况对您可用，并且查询类似于调试服务器问题、为客户演示寻找具有特殊技能的人或讨论可能的营销活动，那会怎么样。乍一看，这可能听起来像是IM的另一个应用，但有一个重要的区别。在广播消息传递的情况下，受众是未定义的。
在广播消息传递中，用户向主题广播消息。其他用户收听这些主题，可以选择对消息采取行动或不采取行动。消息本质上是来自部分或全部接收者的交互请求。该交互请求可以是聊天或回答投票等请求。我们将要研究的广播消息传递的实现是ICT（IBM Community Tools），其中主题称为“社区”，交互请求采用五种形式之一。
ICT：真实世界的实现
ICT是一套包含广播消息传递和IM的应用程序套件。ICT最广泛的用例是IBM的内部部署，平均每月有18,000名用户。广播消息传递有五个应用程序：w3alert、TeamRing、SkillTap、FreeJam和PollCast。用户向多个社区之一广播多种类型的请求，但最活跃的是“everyone”社区。这是每个人默认收听的社区。与“everyone”沟通的新颖之处在于，无需对您的请求进行分类，同时将其发送给大量潜在的响应者。向所有人广播的能力可能非常强大，但它也具有社会影响和技术挑战。
我将首先讨论ICT广播应用程序的具体细节，然后讨论它们的社会影响和技术挑战。
w3alert 是最简单的案例应用程序。它允许用户向社区广播信息性消息，并提供可选的URL以获取更多信息。
TeamRing 是一个用于共享Web演示文稿的应用程序。它允许用户发送Web演示文稿的邀请，然后将当前页面的URL广播给所有观看演示文稿的用户。
SkillTap 是迄今为止使用最多的应用程序。用户向社区广播帮助或信息请求。响应者将与请求者开始即时消息会话，并提供请求的信息。SkillTap 的一项附加功能允许响应用户将其响应提交到可搜索的 FAQ 数据库。
FreeJam 允许用户创建一个即时聊天室，讨论主题基于用户的广播。例如，用户可以广播一个请求，讨论安装软件包的问题。
PollCast 是一个投票应用程序。用户向用户社区广播多项选择投票，用户可以响应投票，同时实时制表和绘制结果图表。
FreeJam和PollCast是类似于SkillTap FAQ数据库的持久性形式的潜在候选者。虽然个人可以在本地存储投票或FreeJam记录的结果，但由于一些社会和技术方面的考虑，尚未为两者实施全局持久性模型。当然，存储是一个问题。随着社区的增长，配置和提供存储变得不再微不足道。出现的问题包括：数据存储多久？谁有权访问？每个人都可以访问FreeJam记录，还是只有参与讨论的人可以访问？隐私问题也随之而来：是否允许某人选择退出他们在FreeJam讨论中的部分？在SkillTap用于FAQ条目的模型中，提交由响应者酌情决定。那么当多人为讨论做出贡献时，这又如何运作呢？与部署广播消息传递系统时出现的问题相比，这些问题很容易解决。
广播消息传递的实践
允许任何用户向大量其他用户广播的社会影响是强大的，但并非没有危险。一种特殊的现象是“PollCast风暴”。这种情况的发生方式如下：用户会向所有人广播PollCast，请求对每个用户运行的操作系统进行多项选择题的回答。PollCast 的结果是一个动态更新的结果图表，一些用户，无论是新用户还是老用户，都觉得观看非常有趣。因此，另一位用户会发送他们自己的PollCast，随后又有两位或更多用户也这样做。然后会有一部分用户觉得这是对系统的不当使用，并具有讽刺意味的是，他们会发送一个PollCast来了解用户是否认为该工具应该以这种方式使用。有时，在此之后还会进行一项投票，以回应之前的投票，询问发送投票询问发送某些投票是否合适。这似乎很愚蠢，总的来说，这就是普遍的看法。但是，当您拥有庞大的人群，并且每个人都有平等的机会向整个社区发言时，一些粗心用户的沟通可能会让其他所有人不堪重负。
当向大量受众广播时，会出现许多潜在的困难。粗俗或污秽的语言通常不受欢迎；一个人最终可能会冒犯很多人。广播的内容也可能属于既不粗俗也不淫秽，但在某些方面不适当的类别。用户群体的多样性和跨国性进一步加剧了这种情况，他们对“适当”的含义有不同的看法。不适当广播的真实示例包括定向到所有人，但仅供少数人使用的消息；讨论薪资或其他私人信息；或内容琐碎或不完整的广播。这些主要是社会难题，但也存在技术难题。
到目前为止，最大的技术难题是随着用户群的增长，测试最终用户软件和服务器基础设施。有时，测试新功能的唯一有效方法是将其推广到社区。随着用户数量的增长——以及随着广播消息传递系统的病毒式增长——确保用户运行相同版本的软件成为一项挑战。实际上，即使客户端具有自动更新功能，也并非每个人都会更新到最新版本。ICT客户端进行了一些更新，这些更新要求所有用户运行相同版本的软件，以便社区中的每个人都能进行通信。这些更改是为了响应服务器负载问题，或新功能或功能的实现。
基础设施处理日常使用量的能力随着用户群的增长而增长的唯一真正测试是实时监控系统。随着病毒式增长而来的是服务器需求的增加，而这种需求只是大致可预测的。为此需求进行配置是一个迭代过程。对于广播消息传递等仍处于开发阶段的技术，拥有大量耐心的早期采用者用户群有助于证明该技术的价值。
在公司等受控环境中，社区固有地存在某些保障措施。系统上的所有广播都标有发送者的用户ID，这提供了一定程度的问责制。除了投票响应外，所有广播都不是匿名的。由于匿名通常会滋生诚实，因此用户对多项选择投票的响应是匿名的。如果用户广播的消息包含粗俗或污秽的语言，一种可能的补救措施是联系该人或其经理。但即使在这种情况下，也没有自动化，管理团队可能无法捕获每次广播，因此这取决于相关的用户是否发声。
即使在封闭环境中，个人用户对不当内容采取行动的能力也很重要，而在开放环境（例如，一般的互联网）中，必须有一种解决方案，使社区能够自我管理。这将是一种解决方案，社区成员可以实时采取行动来反对不当使用。
PollCast中实施的一种此类解决方案是在所有多项选择投票中附加一个选项，上面写着“此投票不适当”。这减少了“PollCast风暴”的频率。这是一种简单的解决方案，可以让用户表达对其他社区成员的不满，而不会直接对抗。这对于我们封闭环境中的PollCast非常有效，但仍然需要更通用的解决方案。我们正在考虑实施的选项包括允许社区成员指出用户何时滥用系统的审核形式，这将反过来禁用违规用户的广播权限。此选项存在具体的实施问题。当前的服务器基础设施使用广播引擎，该引擎从未被设想用于承担社区讨论的任务，而是快速向大量客户端分发消息。服务器不知道人员或内容，只知道连接。因此，没有用于存储特定用户的个人资料和权限数据的机制。正在开发的一种解决方案是让受众通过带外消息表达对用户的不满，这将影响违规用户的客户端在一段时间内的运行。
信息过载
即使不当广播内容或人们滥用系统的问题得到解决，仍然存在一个问题，即随着社区规模的扩大，这个问题的重要性也随之增加。一个值得特别关注的难题是“信息泛滥”。为了使向“所有人”广播在社区规模和多元化兴趣增加的情况下仍然有效，用户不能感到因广播数量的增加而感到信息泛滥。避免信息泛滥，同时保持广播机制的有效性，是首要关注的问题。ICT目前有两种处理信息泛滥的方法：过滤器和UI（用户界面）控制。速率限制是一种正在调查的可能性。
过滤向所有人广播是ICT的新颖功能之一。用户可以指定两种类型的过滤器之一，以控制从特定社区接收的任何广播应用程序的广播。关键字过滤器通过列出针对传入广播进行测试的一组关键字来配置。过滤器指定是否向用户显示或丢弃包含这些关键字的广播。这种类型过滤器的缺点显而易见：我如何有效地列出我的兴趣（或不感兴趣）？乍一看，它似乎过于局限而无法发挥作用——但请考虑用户群。提供广播功能的真正目标不是接触整个社区本身，而是接触具有代表性的人群。因此，如果您的用户群增长到数百万，那么很有可能，如果包含“How do I install MySQL on Redhat 8”的广播被仅在其过滤器集中包含“Linux”的用户过滤掉，则另一位用户将收到该广播，因为他的过滤器集包含“Redhat”和“Linux”。
众所周知，用户的偏好各不相同，对于某些人来说，错过任何百分比的相关广播都是不可接受的。因此，需要更复杂的过滤。当前可用的另一种类型的过滤器是自适应过滤器，它基于贝叶斯垃圾邮件过滤技术。如果启用自适应过滤器并由用户进行训练，则显示广播的每个窗口都包含一个按钮，用户可以通过该按钮将消息分类为他们希望看到或不希望看到的消息类型。
未来版本的ICT中过滤功能改进的计划将包括利用多种数据源来自动构建过滤器，并根据用户不断变化的兴趣动态更新过滤器。目标是提供智能功能，充当用户的代理：仅显示相关消息。聊天记录、浏览历史记录、电子邮件和其他资源可用于生成兴趣配置文件，该配置文件可以作为过滤或确定广播显示方式的基础。所有信息都将完全存储在客户端。用户决定是否与广播者互动，因此这些资源的隐私不会受到损害。
理想情况下，如果过滤器变得非常有效，则过滤可以取代大多数静态社区。代表同事团队并具有定义的成员列表的社区对于仅在该团队成员之间进行通信很重要，原因在于机密性或范围。对于“How do I install MySQL on Redhat 8？”等一般问题，让过滤器确定感兴趣的成员有可能比必须事先对查询进行分类能够接触到更多的人并产生更深入的讨论和互动。
广播的显示方式也会影响对信息泛滥的感知。即时消息的传递方式——作为一个抓取焦点并保持活动状态直到用户关闭它的窗口——不一定适合广播消息。即时消息是定向到特定用户的，而广播消息则不是。在没有仅向用户传递相关消息的保证的情况下，重要的是消息的传递应尽可能不具有侵入性，同时还要有效地显示消息。由于“尽可能不具有侵入性”和“有效”都非常主观，因此消息的显示方式必须由用户高度配置。在当前ICT的实现中，显示广播消息的默认窗口不会抓取焦点；它出现在用户显示器的右下角，并在十秒钟后自动消失。窗口的大小、显示时间长度、显示位置以及许多其他功能都是可配置的。这些设置都是为了回应大量不同的用户反馈。总的来说，以一种不令人讨厌的方式显示实时警报的用户界面问题——尤其是在这些警报可能频繁发生时——是一个有趣的挑战。
“速率限制”是解决信息泛滥问题的另一种解决方案。速率限制可以应用于发送端或接收端。在发送端，系统或客户端可以限制用户在一段时间内发送的广播数量——或者系统可以限制在一段时间内允许发送到特定社区的广播数量。这些速率限制可以由系统管理确定，也可以根据一天中的时间、历史使用情况或社区成员的实时情况动态生成。在接收端，一种特别直接且易于实施的解决方案是让用户可以选择将客户端配置为仅以预定义的速率显示广播。与之前的关键字过滤一样，当用户群足够大时——即使相当一部分用户选择每五分钟最多查看两个广播——这种类型的速率限制也不会排除接触到具有代表性的相当规模的人群的可能性。
人们互助
在我们在向大量受众部署广播消息传递应用程序时观察到的所有社会影响中，一个非常积极的影响是展示了人们互相帮助的意愿。这在SkillTap中尤其明显。迄今为止，已提出近45,000个问题，其中近20,000个问题已得到解答。当我们强调这些问题都在大约一分钟内得到解答时，广播消息传递的真正威力就变得非常明显，解答者是那些支持不是其职业的人，而且是免费的。
IBM内外的ICT
以下是IBM内部部署中当前ICT用户群的一些统计数据
- 每月 20,000 名用户（平均）
- 6,000 名峰值并发用户
- 每月向“所有人”广播 360 次（平均）
- 1,021 个对每个 ICT 用户开放的社区
- 437 个拥有 100 名或更多成员的社区
- 53 个不同国家/地区的 ICT 用户
- 80% 的社区成员担任技术职位
除了 IBM 内部部署 ICT 之外，我们还部署了一个供 IBM 外部使用的版本。该版本最初的目标是 A/S 400 专业人员社区，作为进一步建设其社区的一种手段。最近，我们还将目标对准了 alphaWorks 网站的访问者 (see http://alphaworks.ibm.com/.)
有关 ICT 的更多信息以及 ICT 下载链接，请访问 http://community.ngi.ibm.com。
参考文献
1. Eircom：参见 http://homepage.tinet.ie/~shaykelly6780/soundsfunny.htm。
FRANK JANIA 是 IBM 互联网技术团队的软件工程师。他是 ICT 客户端开发的团队负责人。
最初发表于 Queue 第 1 卷，第 8 期—
在 数字图书馆 中评论本文
更多相关文章
Eric Allman - 电子邮件身份验证：什么、为什么、如何？
互联网电子邮件是在一个与我们今天生活的世界不同的世界中构想出来的。那是一个小型、紧密结合的社区，我们真的不必太担心坏人。通常，如果有人做错了事，可以通过社会手段来解决问题；“排斥”在小型社区中非常有效。也许我们应该弄清楚当 Usenet 开始变糟时会发生什么。Usenet 基于一种名为 UUCP 的廉价网络，该网络相当容易加入，因此它让我们体验到当社区变得更大、更分散且更难管理时会发生什么。
Vipul Ved Prakash, Adam O'Donnell - 使用信誉系统打击垃圾邮件
垃圾邮件无处不在，堵塞了世界各地电子邮件用户的收件箱。它不仅令人讨厌，而且还侵蚀了信息技术进步所带来的生产力提升。每天浏览数小时合法电子邮件的工作人员还必须处理删除大量非法电子邮件的问题。自动垃圾邮件过滤器已大大减少了最终用户看到的垃圾邮件数量，但所需的培训量与无需过滤器辅助即可简单地删除垃圾邮件所需的时间相当。
John Stone, Sarah Merrion - 即时消息还是即时头痛？
这是一个现实。您的环境中有 IM（即时消息）客户端。您已经认识到它正在消耗越来越多的网络带宽，并且随着 Microsoft 将 IM 功能构建到其 XP 操作系统和应用程序中，您知道这种情况只会变得更糟。管理层也对通过此媒体进行私人对话而导致的用户生产力损失表示担忧。您已尝试阻止这些对话渠道，但这始终是一场战斗。
Joe Hildebrand - 九个 IM 帐户还在增加
即时消息传递已变得几乎与电子邮件一样普及，在某些情况下，其受欢迎程度远远超过电子邮件。但它已经远远超出了青少年封闭的世界，进入了商业领域，在那里它正成为一种有用的沟通工具。与电子邮件不同的是，问题在于 IM 没有通用标准，因此用户感到有必要维护多个帐户，例如 AOL、Jabber、Yahoo 和 MSN。
© 保留所有权利。