设计Wiki，设计考虑和反馈[关闭]

Question

在设计wiki应用程序时，我应该考虑哪些事项？

到目前为止，我有：

1. 修订
2. 解析某种标记文本
3. 跟踪wiki中的链接以及链接到其他页面的页面。
4. 相关wiki，即wiki与其他人有关。

构建Wiki还有什么其他内容？

Answer 1

如果它有用，这里是维基百科的数据库架构（实际上是MediaWiki，维基百科背后的引擎）：

http://upload.wikimedia.org/wikipedia/commons/4/41/Mediawiki-database-schema.png?

Answer 2

在过去的几年里，我做了大量的研究和wiki工作，供我自己使用，并为我的各种客户/雇主支持技术团队。

我得出结论，维基最重要的标准是让它变得透明，就像http://c2.com/的原始维基一样。应该很容易做出贡献，用户永远不会质疑他们是否应该这么做。编辑器必须易于访问，它应该使用传统的纯文本（NO WYSIWYG !!!）wiki格式，它应该很容易添加新页面，它应该很容易链接到外部页面（其他维基或常规网页） ，它应该有反向链接。模仿原始wiki，你会没事的。

如果一个用户怀疑他们是否应该费心去做，因为它太痛苦了，不管怎样，那么维基会失速并失败。我看到它一次又一次地发生。 WYSIWYG是一种常见的故障模式，混合了大量文件，多媒体等“丰富”内容，是另一种，无法备份/恢复是一个很大的问题。如果您想要“精彩”的内容，请使用托管在“附近”的标准Web服务器，wiki用户可以链接到该服务器。请记住，维基是关于沟通的，它不是关于漂亮的。

Answer 3

看看TiddlyWiki。我认为它具有我在任何维基中看到的最佳功能组合。 （对于下面的“页面”，请阅读“items”，因为TiddlyWiki是一个单页的wiki。但我认为这些功能也适用于带有页面的wiki）：

• 所有“缺失”页面的列表（没有页面的WikiWords）
• 孤立页面列表（没有链接的页面）
• 大多数格式化都是通过编辑Wiki页面完成的
• 您无法搞砸格式化，因为如果您删除自定义格式，则会出现默认设置
• 您可以标记页面
• 您可以在其他页面中包含页面

还有更多我没有提到的。我认为格式化可能是许多优秀功能中最好的，因为它很容易编辑，所以很难搞砸。

Answer 4

经常被忽视：

• 好搜索
• 层次结构。 Redmine的wiki中我最想念的一件事。

如果你找到一个很好的方法来实现一个易于重新组织的wiki，那也很棒（即重命名一个页面，或将两个页面合并为一个并且不会破坏万亿的wiki链接）。

Answer 5

用户界面 - 用户最令人沮丧的事情之一是他们必须学习一个用于MediaWiki的用户界面，一个用于TikiWiki，一个用于任何其他无数的wiki。

维基最重要的部分不是技术可行性 - 它让用户以方便有效的方式进行贡献和编辑。你可以拥有世界上技术最强大的wiki，但是如果它不容易使用，那么作为wiki应该是的社区工具将毫无用处。

要么复制现有的和熟悉的wiki语法（例如MediaWiki），要么准备投入大量资金来创建WYSIWYG编辑器。

Answer 6

我不会开始一个新的wiki引擎，它具有与每个人相同的功能，其中有很多这样的功能。

我只会提供一个提供不同/独特的东西，远远超过标准的wiki。

一些想法包括（也许一些维基已经有这个）：

• 能够将wiki与VCS合并，讨论修订/更改并能够进行代码审查（任何提交的内容会自动创建修订页面），将其链接到提交者以及讨论和发送中的任何人他们的电子邮件提醒会很好。
• 维基的API，允许第三方应用程序进行mashup样式的集成。
• 维基式多媒体（文本，图像，音频和视频），包含指向其他媒体的链接。
• 多语言并排编辑和翻译。
• 客户端编辑器/查看器（不基于Web），以实现更快的响应和真正的WYSIWYG编辑。
• ...

Answer 7

确保你指甲Ward Cunningham的原始Wiki Design Principles。

Answer 8

确保对人们为防止XSS所做的所有编辑执行输入验证。没有什么能像人们被黑客一样破坏一个好的维基。

Answer 9

每当我试图让非开发人员使用维基时，编写文本的难度就是最大的障碍。与StackOverflow一样的WYSIWYG编辑器对我来说似乎是一个好主意。它仍然在框中显示标记，因此有动力的用户最终会学习使用它（从而变得更有效率），但它也会显示实时预览，以便用户获得关于他们的文本是否正确的即时反馈。

沿着这些相同的路线，另一个烦恼是每个维基似乎使用略有不同的标记。我想每个设计师都认为他们可以做得比之前更好。我建议使用MediaWiki的语法，或类似MarkDown的标准，以便高级用户可以更轻松地完成任务。

最后，考虑一下你的wiki会将它与众多许多其他wiki分开，以及你的设计将如何影响它。