第I部分       使用Wiki进行探索

为什么需要Wiki？

Bill Venners：您发明wiki的最初目的是什么？

Ward Cunningham：我创建wiki要完成几件事。第一个wiki的初衷是要建立一种环境，我们能够交流彼此的经验，从而发现编程的模式语言。我以前曾经使用过HyperCard组，它基本上也是为了类似的目标。我知道人们喜欢使用那种HyperCard组来阅读和创作，但它是单用户的。当开始PLoP（编程模式语言）系列讨论会的时候，我们认识到我们真正想要做的是开始编写一部新的作品，我认为我需要使用HyperCard组，并希望能找到一种应用于web的等价物。

对于wiki，我还有更多通用的目标。首先，人们常说“人人喜欢讲话”，我认为这里面有一种令人信服的人类本性。在创建wiki时，我希望激发每个人喜欢讲故事的天性。其次，也许是最重要的一点，我希望不经常创作的人们会发现创作非常轻松，这样就有机会发现创作的结构和方法。

Bill Venners：wiki如何使创作变得轻松？

Ward Cunningham：不熟悉写作的某个人可能有一个想法，这个想法值得写成一段。他们本来可以为杂志写一篇评论，但是一段文字太短了。为了给杂志撰写文章，他们不得不介绍一下背景，讲述某些重要的东西，而且要以多数人都能理解的方式讲述，然后结束文章。太复杂了，多数人都不愿意花费那么多的精力。

但是如果您正在阅读别人的作品，并想到“是的，但是还有一点”可以放在一段中这样说，“啊，不错，但实际上还有……”在wiki上有很多这种类似于“对，但是……”的对比想法。讨论组也作了同样的事情，但是在讨论组中这些对比都丢失了。

Bill Venners：为何在讨论组中丢失了？

Ward Cunningham：因为没有上下文，无法持续下去。讨论组往往反复围绕着同一个话题，但是人们忘记了以前说过什么。我认为，常见问题解答（FAQ）的发明就是针对这个问题的。很多时候，读一读FAQ要比参加讨论组更有意义。在一开始做wiki的时候，有一个系统叫FAQ-O-Matic，它和wiki的想法一样，只不过其真正的目的是制作FAQ。我看到它的时候就想“哦，英雄所见略同”。不过我接下来又想，“不，我更喜欢面向文档的形式而不是问答形式。”在我们的作品中想要创建的模式是某种类似FAQ的东西，但应该不止如此。现在，wiki上可能有10,000到15,000种模式，25,000页文档。

Bill Venners：您认为wiki适合做什么？wiki的高明之处在哪里？

Ward Cunningham：如果您试图回答一个不容易阐述的问题，事先不了解某种应该知道的自然结构，wiki会非常有用。对于像“项目进展如何”之类的问题，我们可以设计一个数据库。但是数据库中要放哪些字段还要归结到对项目进展问题什么是重要的。关于项目的哪方面重要这些资料是不可预见的。

Wiki页面的格式非常自由。在整个wiki中有一个超文本结构，但是在一个给定的页面上，在自然语言灵活性的许可范围之内，您可以讲任何想要述说的东西。因此，wiki是跟踪项目进展状态的一种良好方式。比方说，您可以把我的模式作品看成是一个长期进行的项目。我们不知道终点在那里，但是我们希望在进展中发现它。

此外，wiki也非常适合于想要把控制权交给系统用户的环境。在wiki中并没有多少何人何时可以做何事的逻辑，因为wiki并不真正理解您在做什么。它只是为您保留页面。关于什么是适当的用法什么是不好的用法，已经建立了大量的惯例，但这些都存在于用户的头脑中，而不是在应用程序的业务逻辑中。如果您有一个可靠的团体，不谋求通过计算机强制某种行为，wiki就可以很好地工作。比如，有人曾经问我wiki是否适用于协同环境。我认为某些公司对它们的雇员完全具备这种信赖，某些公司则没有。不信赖雇员的公司可以根据某些需要维护一个web站点而不是wiki。

把握大局

Bill Venners：读者如何把握wiki上的总体内容？

Ward Cunningham：首先要理解，因为我们使wiki更方便作者，实际上就增加了读者使用的难度。里边有某种组织方式，这种组织方式还可以改进，但它不是组织严密的。因此读者就会感到仿佛是在茫茫的一片信息片段中搜寻。偶然发现一段很好的信息，于是就想，“好极了，为什么没有人哪怕只是把那些好的片段作一个清单，我就不用再搜索其他的部分了。”换句话说，“为何没有人组织一下，让我迅速找到问题的答案？”早晚他们的想法会得到实现，“哎呀，行了！”他们花了一个月或者两个月查找所关心的东西，然后做一个页面，wiki组织成什么样子由他们自己承担。

我不是一个分类的痴迷者。如果感兴趣的事物不符合需求或者不是预期的，定义一个有用的分类方案非常困难。不过有些人认为每个页面都应该带有分类。他们带着一个分类方案，根据页面的名称，为wiki建立分类结构。这些注重分类的人负责维护它。如果某人创作了一个不能归类的页面，其他的人就会说，“哦，这应该归为wiki保留页面或者设计模式。”

Bill Venners：如何把一个页面归类为wiki保留页？

Ward Cunningham：只需对一个叫做WikiMaintenanceCategory的页面进行引用。单击该链接时，就会转到那一页，对这种分类进行解释以及为何有这一类。因此把页面归到某一类，习惯上是增加到该类别描述页的链接。这样标记了该页。如果要了解这一类是什么，可以沿着链接到类别描述页。如果要看看这一类中有什么页面，可以搜索引用该类别页的所有页面。

Bill Venners：我猜想搜索也许是研究新wiki的一种方式。从一定意义上讲，wiki类似于一种小型的internet。 一切都分散在各处。如何发现正在寻找的内容呢？我可以从搜索关键字开始。

Ward Cunningham：是的。任何名称以“Category”结尾的wiki页都是一个值得搜索的条目。可以通过Google搜索小说，但是如果有人不把作品标记为小说，就找不到它。分类系统是一组页面，解释分类的基本原理，可以读读这些页面。它们使用了名称空间的一小部分——所有这些词都以“Category”结束——并建立了这些页面涉及其他页面分类的实例。非常棒。还在发展中。如果我要做一个解决方案，可能会非常简单，甚至同样好。我最喜欢的一点是，有一个非常积极的社区在管理这些分类。有时他们把分类搞错了，但很快就会纠正过来。

Wiki中的时间要素

Bill Venners：您所说的有点让我想起“自由讨论”。您把一些人集合起来充实那些您还不完全清楚的事物。

Ward Cunningham：Wiki有点像“自由讨论”，尽管不是交互式的。您可以做10分钟的自由讨论，用30分钟分析自由讨论的成果，然后在45分钟之内完成某件事。Wiki的脚步要慢一些。您可以就某个观点写一个页面，或者就很多想法写一个页面。然后在一周之内回来看看页面上有什么进展。但是如果在15分钟之内回来，不会发生太多的变化。Wiki上的事情是以天或者周为周期的，因为人们往往每天或每周浏览一次。

Wiki中有一个有趣的时间特性。读新闻组或者邮件列表时，会有一种感觉，当前就是您在列表中的位置。我不希望wiki中有一个时间表。当在读wiki上的某些内容时，我不希望时间会影响您，不论它是一年前写的还是一天或者一分钟前写的。这意味着我们需要通过某种方式得到上下文。

如果您正在编写一个页面，那个页面必然和其他某个页面有关。因此所要做的就是，在一个段落中说明其他页面中哪一些是关于这个上下文的。人们逐渐熟悉这些页面的名称。他们遇到一个新的页面，阅读包含对上下文页面链接的段落。如果已经度过这些页，就继续读下去。如果不知道这些页，他们就会说，“哦，这一页没有什么意思。我还得读一读其他的页。”这样如果您了解上下文的话，就不必再去看了。但是如果不了解上下文，您可以去看一看。上下文不会变。

Bill Venners：听起来似乎您必须了解wiki站点。过一段时间后您就会熟悉它了。一开始可能会令人感到困惑，也没有多少提示，您进来发现到处都是这样的内容，但不一定是根据读者的需要组织的。

Ward Cunningham：对，wiki总是在不断地组织中。每花费一个小时组织，都要花费另外两个小时来增加新的材料。因此wiki的总是处于半组织化状态。

Wiki 和可读性

Bill Venners：我确实非常喜欢wiki的思想，但是我发现阅读许多wiki页非常困难。可读性的问题是我一直没有在Artima.com上增加wiki的主要原因。Artima.com也是一种基于web的协作文档，但是更加结构化。在wiki中没有专职编辑为读者组织材料。所有的页面都是协作性的。结构是协作性的。编辑是协作性的。从wiki的协作性中有什么足以抵消可读性的损失？

Ward Cunningham：作为wiki读者，您能够获得以前没有发言的那些人的观点。听我们发言的人对于怎样编写和发布计算机程序有直觉的想法。我们这一行在发表过程中对传统保留了某些尊重。比如，如果您想为一本科学杂志投稿，应该经过同行评审。同行评审的一部分是你应该熟悉所有其他作品。而其他作品可能纠缠进某些细枝末节。关于编程的作品有时并不符合程序员的实际感触。有了wiki，没有时间学习写作并在杂志上开辟专栏的实践程序员，就有机会讲出那些对于他们来说是重要的事情。Wiki提供了一个不同的视角。事实上，您可以分辨出一个人是在wiki上根据自己的经验创作，还是转述刚刚读到的东西。

Bill Venners：那么您怎么分辨呢？

Ward Cunningham：您可以根据他们谈论事情的方式来区分，比如“Mary Ann就是做不好这一部分。”这不符合科学传统。如果有人引述某位作者的话，“某某怎么说，你这家伙怎么听不明白”，有人在赞美他所读的书。另一方面，如果有人说，“您知道，在以前的三个项目中我们都尝试过，但一次也没成功，我们只能用别的办法摆平它。”有个家伙解决了这个问题，他正在跟我谈一些深刻的问题。如何解释要靠我自己。这只是他的经验。然后您可能还会看到其他几段文字，“是的，我也遇到过，我用这种方法搞定了。”那么现在就有两种方法了。突然之间，您开始与解决了软件问题的人交流了，而不是和谈论解决软件问题的人交流，这有很大的不同。