好的，我看过几篇文章提到了其他一些关于不使用SP Wiki的帖子，因为它们很烂。

由于我们正在考虑在SP中制作Wiki，因此我需要知道为什么我们不应该让6个自动化开发人员小组记录各种自动化流程中的步骤以及不时进行的更改。

解决方案

回答

Sharepoint随附的默认Wiki完全不支持常见的Wiki功能。无法编辑页面的单个部分，也无法直接链接到另一页面上的特定部分。后端使用HTML，因此我们将失去使用简单语法进行纯文本编辑的能力。差异功能不能跨多个版本。跨浏览器对所见即所得编辑的支持差。无法自动插入目录...

但是，还有一些我无法明确拒绝的Sharepoint Wiki外接程序，例如Confluence为Sharepoint提供了一个外接程序。我自己还没有评估过该软件，Confluence有点贵(25个用户许可证的价格为1200美元)，尽管如果我们已经在使用Sharepoint，我会感觉到大公司的保险箱：P。还似乎有一些免费的加载项，例如CKS增强的Wiki，但似乎有很多上述相同的问题。

回答

我的公司最近推出了sharepoint，我不得不说我的用户体验很不好。我不仅仅是说我对使用它感到不安：我以开放的胸怀走进去并尝试了它，许多事情似乎都感觉它们并没有真正起作用。

卢克提到的原因或者多或者少掩盖了它。

我们为什么不考虑使用Jeff不久前捐赠的其他东西，例如Screwturn Wiki？我自己还没有使用过Screwturn，但是它是免费和开源的，并且可能是满足我们需要的更快的轻量级解决方案。

回答

对于将要进行"时不时进行"编辑的6人一组，内置的wiki很好。

回答

如果我们使用Sharepoint以外的Wiki，以下是我遇到的警告，这些警告将消失。

Sharepoint可让我们创建大量独立的Wiki，但我建议为所有内容提供一个大型Wiki。我的公司为每个项目/功能制作了一堆小小的Wiki，但是只有管理员才能创建单个Wiki，因此，如果我想写一些与预定义类别之一不符的内容，我必须找到一个经理首先创建Wiki。

其次，如果我们使用Sharepoint，请确保员工中的每个人都只使用IE，因为Firefox不支持WYSIWIG编辑器。对于大多数Wiki而言，这是一件好事，但在Sharepoint中进行协作非常困难。想象一下，整天在一个很小的盒子中编辑自动生成的HTML。

第三，尝试在Wiki中编写项目文档，并避免将Word文档上载到Sharepoint库的诱惑。编写两次所有文档并看着事情变得越来越不同步毫无意义。

最后，Sharepoint Wiki中的图像支持非常糟糕。我们必须将文件添加到文档库中的某个位置，然后键入URL。我的图片被永久删除，因为它们似乎与上下文无关。

回答

Sharepoint Wiki本质上是静态HTML页面的列表，唯一的Wiki功能是article链接。没有模板，没有类别，什么也没有。

我们最终有了一个单独的MediaWiki，仅将Sharepoint Wiki用于不需要太多布局的基于文本的内容。

回答

我使用SharePoint Wiki Plus玩过很短的时间。这是一个第三方扩展，可将功能添加到SharePoint Wiki。对于认真的Wiki用户，我们可能需要的不仅仅是SharePoint通过扩展或者专用Wiki产品提供的Wiki。

回答

几个月前，我们在Sharepoint上查找了部门Wiki。即使我们主要是一家MS商店，我们还是选择了DokuWiki。开源，易于更新，出色的插件和基于文件的后端。

回答

我们一直都在讨论这个主题，而我问的第一个问题是"我们为什么需要维基"？答案几乎总是"易于编辑"，"多个贡献者"和"言语权重"。我们很少见到有人问过我认为与Wiki类似的功能(特殊的"魔术"标记，显示更改的细粒度版本历史记录等)。而且，他们通常希望对事物进行某种分类，而不仅仅是完全自由格式的页面。

在SharePoint世界中，如果我们使用该工具已有一段时间，这些事情应该会向我们大喊"列出"。对于这些知识库样式的应用程序，基本上没有特别的理由使用Wiki，尤其是因为"易于编辑"通常与为大多数用户学习特殊标记语言的想法直接冲突。通过其中的几个RTF列，我们已经准备就绪。如果我们真的不喜欢内置的富文本编辑器(是的，图像上传过程很笨拙，并且在Firefox中不起作用)，请组织中的某人删除8个Benjamins并获取RadShare for SharePoint 。它应该几乎可以解决这些问题。

通常，一旦我们克服了"但它必须是一个Wiki"教条，我们仅使用列表就获得了很好的客户接待。在某些情况下，需要更多的页面模板功能，我们转向使用MOSS的WCM功能，这需要对模板进行更多的前期思考，但对于诸如内容摘要和图像处理。

回答

不要忘记Sharepoint Enhanced Wiki Edition的社区工具包。这为现成的版本增加了一些功能。

回答

我对Microsoft的Sharepoint Wiki有更积极的看法。从许多方面来看，它让我想起FrontPage 98-那是一种不公平的产品。

有关使用列表的评论是错误的。 Sharepoint Wiki是ARE Sharepoint列表，其中每个页面都是带有HTML附件的列表项。

的确，我们不能链接到页面，但是如果页面短，我认为这不是问题。 SP Wiki使拥有短页面变得非常容易。

我们可以根据需要在Access 2008中操作Wiki属性，也可以根据需要将属性添加到Wiki列表项。例如-我们要分类吗？只需通过编辑列表添加它们即可。想要特定的意见吗？列表项。也创建它们。

微软在Sharepoint列表上构建其Wiki框架的方式确实有天才-的确做得很好。

famerchris提到了Sharepoint Wiki的真正缺点。图像管理的方法令人惊讶。这是一个严重的问题，我们仅出于这个原因就应该考虑其他Wiki。

我使用了一个复杂的解决方法。它利用了Windows Live Writer集成的出色Sharepoint支持和图像编辑功能。

• 创建一个SP博客，该博客将保存将在Wiki中引用的图像。
• 使用Windows Live Writer发布到wiki-image-blog。将图像放入WLW中，根据需要调整大小，依此类推。如果愿意，也可以使用WLW编写与图像相关的Wiki文本初稿。
• 发布到Wiki后，将图像和文本复制并粘贴到Wiki编辑器的RTF文本字段中。

这花费的时间令人惊讶，几乎比我读过的其他任何选项都要少。我承认，这是令人费解的。

除了图像问题外，我对产品感到满意和印象深刻。如果只有Microsoft更加认真地考虑图像...

回答

我还要根据作者的技术水平来调整OOB Wiki的等级及其功能性。

我同意，与某些更强大的产品相比，SP Wiki仅在名称上可以肯定地合格，但是请记住，作为管理员，主要成功取决于最终用户的采用。简而言之，对于像Confluence这样的Wiki添加的每个功能，它还增加了用户培训，语法等。

虽然我希望SP Wiki具有更多"类似Wiki的形式"，但是当CIO在公司Wiki中添加条目时，或者我们被一群发现新Wiki的管理助手所认可时，我们可以获得一定的，难以描述的满足感革命性的"。

简而言之，我们的专业技术人员可能缺乏内置功能，但是对于天真的技术人员而言，它很容易接受培训，并且可以使他们接触到他们可能听说过但永远无法使用的技术(在此之前)了解或者想象使用。

回答

因为默认实现不是Wiki，所以它是HTML编辑器。

如果我们在使用Wiki之前先了解了两者之间的区别。只需查看此页面底部的"答案"即可了解不同之处。我们可以在Wiki中使用标记，该标记相对易于阅读和编辑。格式化的HTML完全掩盖了所写内容。

回答

也许尝试http://wordtosharepoint.codeplex.com/将Word内容迁移到SharePoint？它负责链接图像和大多数其他事情。

回答

Screwturn实在是太棒了，它是C / .Net。

Sharepoint 2010应该具有更好的Wiki功能，并且始终有Sharepoint社区工具包。
如果我们可以抛弃Sharepoint Wiki，则可以随时访问http://www.wikimatrix.org以找到适合Wiki。

回答

在大声疾呼之前，这是我将SharePoint作为Wiki的整体经验。

由于缺乏对当前Wiki环境所提供内容的根本调查，因此该功能实施不佳导致失败。这就是为什么它在编辑器中失败的原因，以及为什么它在诸如标记，历史比较和生成不良的html代码之类的点上缺失的原因。

我们需要跳过它，并获得其他可以做得更好的东西，然后从SharePoint链接到它。

拥有这两种产品的生产经验，因此我建议我们使用ScrewTurn over SharePoint。

查看rant的编辑历史记录