引用转发链式传播

魏武挥 — Thu, 29 Apr 2010 11:04:05 +0000

不知道今天还有多少人知道blog的引用这个功能，早年关于这个功能讨论很多，其中有一个重点就是：这个英文被称为trackback（TB）的玩意儿，究竟应该翻译成什么。

在BBS中，当张三这个用户发了一个帖子A后，李四进行评论B。评论被很形象地称为“跟帖”，所谓跟，就代表着一个从属关系。一旦张三把帖子A删除后，李四的评论B就消失不见了。

但在blog基于TB上的机制不是这样的。当张三发表了一篇博文A后，李四可以在自己的博客上写博文B，并在提交的时候，顺便再提交张三博文A的TB地址。这样做的效果有二：其一、张三的博文A后多出一条很像评论的东西，并带有指向博文B的超链接地址；其二、张三将自己的博文A删除，并不会影响到李四的博文B的存在。故而，基于TB机制的互动，是不能称为“跟帖”的。

PingBack，是wordpress博客的一项功能，简称PB，PB是TB的升级版。因为利用TB，李四还需要附上博文A的TB地址，有些罗嗦。而利用PB，李四只要在博文B中出现博文A的地址，理论上（注意理论上），博文A后面就会多出一条指向博文B地址的评论。显然方便很多。但是，经过我实践发现，PB是时灵时不灵的。

TB或者PB，最大的优点在于blog（即使是不同平台的亦可）之间得以产生互动。也就是借助TB或者PB，李四可以在自己的博客上和张三的博客（有可能不是同一个平台，比如一个新浪，一个搜狐）进行互动，而且完全不用担心张三删除博文A后评论的存在与否。但这种机制有两个问题。

第一个问题是TB其实是一个单向链条。如果使用TB，李四的博文中是不会出现张三的博文地址的。网民可以通过访问张三的博客顺藤摸瓜到李四的博客，但反过来不行。PB这个机制后来修正了这个问题。让传播链条呈现出双向的可能。故而，这个问题不算太大。

第二个问题是TB或者PB的翻译。一直没有太好的翻译方法，最后还是用了“引用”了事：估计这是一个最不坏的翻译方法。的确，是有点像在写学术论文时候，做个注释一样的引用。但问题在于，写一篇博客本来就是很随意的事，还中规中矩地照写论文的方法搞注释引用，会让人觉得很麻烦。更何况，当点击博文下方的引用时，弹出来一个很长很古怪的链接，很多人并不知道怎么回事。

从传播原理上，我是很看好这种跨平台互动的机制的。我甚至还一本正经地写过一篇学术论文，专门谈博客的链式传播问题，发表在一本核心期刊上。我过去服务过的那家BSP，在对外做BD的时候，我经常会拿这个出来讲解，以表明社会化推广的传播链条可能很长。当时我举的例子就是“怪癖游戏”和博客圈中对于“长尾理论”这本书的讨论最终导致中文版一面试就立刻成为当当畅销书这两个案例。

但是，原理归原理，操作起来实在不便以及对引用二字的无法理解，使得TB这个功能被使用得很少。而PB虽然带有自动化色彩，但不知道是技术上的什么原因，始终不是每次都能准确无误地返回一条对于博文A的评论。产品设计上的问题，最终导致这个功能几乎成了Blog的摆设。我在商业实践中，想了很久，没有太好的方法让这个本来是不错的东西至少在我那个BSP中得以发扬光大。

微博出现后，中国人把retweet（音译为锐推）翻译成转发，一下子打开了局面。在我混迹的微博中，转发是非常常见的应用，形成了无数条传播链条（有的还很长）。但我细细一琢磨，转发和引用，其实在机理上是完全一样的！

至少，我在新浪微博上做过测试，我发了一条微博，张三加了几个字予以转发。我后来删除了这条微博，但我发现李四对张三的转发依然可以再转发。我推测是这样的，除非站方干预，这条微博只要一旦被张三转发，其实质就属于张三发的新微博。我已经无法控制。就像我能控制我自己的博文以及下方的评论，但我不能控制TB过来的博文一样。

我开始有点后悔，当初为什么没有想到把tb翻译成转发。引用多拗口啊，转发是如此得容易理解：在自己的博客将这篇博文转贴嘛，还能再加几句自己的话。我琢磨了一下原因（原因在后），然后又意识到一个问题。

还是以新浪微博为例。转发和发微博其实是有些区别的。创建一条微博可以插入很多东西，图片音乐视频都可以，但转发不行，转发可以插入自己的文字，但无法插入多媒体。于是我又后悔了一下，当初在设计Blogbus的tb时，为什么一定要坚持点击“继续话题”（我把引用改成了这四个字）后调用出整个写博客的后台呢？其实完全可以简化那个编辑器：只保留输入文字，其它一概皆可省略。似乎省略那么多的功能，并不会影响用户的转发使用频率。

现在来看看为什么没有想到trackback翻译成“转发”——这不是仅仅我没想到，在我视野所及中，所有关于tb的译法讨论，都没有想到过这个看上去很普通的词。我认为原因在于：立场问题。

blog是有强的以“我”为立场的情景的，我写什么东西，别人的东西都只能作为附件出现。转发则有一些以别人的东西为主要部分，而我加入的几个字只是附带而已。在这种以“我”为中心的前置理念下，真得是想破头也想不出以“别人”为中心的产品设计思路。基本上，一个思维框就形成了，在这个框之下，那是孙悟空怎么翻都翻不出如来佛的手心了。再加上我本人总有点blog原教旨主义的痕迹：不原创，叫什么blog？

产品设计有时候就会出现这样的矛盾：对产品浸淫不够就没法设计出更好的功能，但对产品一旦用多了，就顺大便给自己加了思维框。又在其中又不在其中，那是一个多么高的境界啊！

最后说一下，今天blog下方的那个引用改成转发行不行？时过境迁，已有拾人牙慧之嫌。

可惜了，blog的链式传播。但又不可惜的是，链式传播，其实，是成立的。

Copyleft © 2010 知识共享署名-非商业性使用-禁止演绎注意：转载勿改标题！
ItTalks -- 魏武挥的Blog (digitalfingerprint:fc4f8fc31f70097eea4b780b13146415)

欢迎 follow我的微博分享我的分享

与本日志可能相关的文章有：

加法，还是减法？

魏武挥 — Thu, 28 Dec 2006 07:09:21 +0000

有一种说法：企业在经营活动中，要学会做减法，而不是一味做加法（这话在网上流传甚广，出处我就懒得找了）。

大抵的意思就是：在产品和功能开发上，不要面面俱到。要学会有些东西砍掉而不做。

这话没什么大错。但显得有点简单。不分场合不考究具体情况下的一路减法，也不见得是对的。

产品products和功能Features，是两回事。洪波最近一篇日志，就这个问题谈得很清楚了。主要是如下一段话：

微软是做操作系统起家的，30多年来，它不断地为操作系统增加特性，而不是去开发一大堆彼此不相干的产品。所以，互联网的访问成为操作系统的一个特性，浏览器成为操作系统的一个特性，媒体播放也成为操作系统的一个特性。微软所遭受的垄断非议，主要就来自这里：features，not products。微软一直梦想把搜索也变成操作系统的一个特性，而不是一个有独立价值的产品。

通用在韦尔奇上台前，有着大大小小不同的很多事业部或者子公司，运营着各种各样千奇百怪的产品。韦氏上台后，大肆做减法，把不能位居行业前三的子公司、事业部纷纷出售或者关闭。经过这段减法之后，通用这头大象重新焕发了活力。这是一个做减法的经典版本。

所以，第一个结论就是：在产品设计上，要学会做减法。有些产品，本来就不该做，砍掉拉倒。

但放在某个产品的功能上，未必。我甚至认为，要多多做加法。

在《IT大败局》这本不怎么样的书里，作者倒是提到过去曾经的一个案例，某公司（名字俺忘记了）有一款软件，十分之受人欢迎。该公司后来推出一款简易版，也就是取消了部分功能的该软件，来面向低端用户，不料折戟沉沙，饮恨而归。

可见，用户对于产品的功能，要求甚高。用户希望一个产品能够提供多种功能，而他的出发心理状态则是：我有，未必我要。

这很重要。

我经常用的是windows自带的记事本，包括写blog。但我装了office，而且还是2003版。如果不是因为2007版的模块式界面不太适应的话，我就换2007版了。我在安装office的时候，我会去掉outlook这个产品，因为我不需要。但我在选word、excel、powerpoint的时候，一定是全选。因为我需要满足“我有”。

这就是第二个结论：对一个单个产品而言，要尽量去做加法。这个加法未必一定是自己动用人来开发，也可以考虑合作。比如在vox.com中，要在blog里植入一本书，它就是和amzon进行API式的合作，倒不是自己建一套书籍数据库。

不过，事情不是到此为止。还需要再往下走一步：功能开发做了加法之后，这道算术题还没做完。接下来，该用户做了。

我向来提倡这四个字：用户自决。

提供了各种各样的功能之后，由用户来决定，哪些功能我需要用，哪些功能我不想用。这一点，space很聪明。在它的后台中，几乎每个项你都可以砍掉（当然，最难看的顶端的banner貌似砍不掉）。

所以结论就是：

产品开发可以做减法
功能开发要做加法
功能使用要让用户做加减法

与本日志可能相关的文章有：

引用转发链式传播 (30)

It Talks--上海魏武挥的博客 » 产品设计

引用 转发 链式传播

与本日志可能相关的文章有：

加法，还是减法？

与本日志可能相关的文章有：

引用转发链式传播