sharepoint - 共享点维基

Question

好的，我看到一些帖子提到了其他一些关于不使用 SP wiki 因为它们很烂的帖子。

既然我们正在考虑在SP中做我们的 wiki ，我需要知道为什么我们不应该为 6 名自动化开发人员组来记录各种自动化流程中的步骤以及必须不时进行的更改.

score 20 · Accepted Answer

以下是我遇到的一些警告，如果您使用 Sharepoint 以外的 wiki，这些警告将会消失。

Sharepoint 可让您创建大量独立的 wiki，但我建议您为所有内容创建一个大型 wiki。我的公司为每个项目/功能制作了一堆小 wiki，但只有管理员可以创建单独的 wiki，所以如果我想写一些与预定义类别不匹配的东西，我必须找到一个经理首先创建 wiki。

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

第三，尝试在 wiki 中编写您的项目文档，并抵制将 Word 文档上传到 Sharepoint 库的诱惑。将所有文档写两次并看着事情越来越不同步是没有意义的。

最后，Sharepoint wiki 中的图像支持很糟糕。您必须在某处将文件添加到文档库并输入 URL。我的图像永远被删除，因为它们似乎没有多大意义脱离上下文。

score 16 · Accepted Answer

我对微软的 Sharepoint Wiki 有更积极的看法。在很多方面它让我想起了 FrontPage 98——那是一个受到不公平诽谤的产品。

关于使用列表的评论是错误的。Sharepoint Wiki 是 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 编辑器富文本字段中。

这花费的时间非常少，远远少于我读过的任何其他选项。我承认，这很复杂。

除了图像问题，我对产品感到满意和印象深刻。如果微软在图像问题上更加努力……如果只是……

score 14 · Accepted Answer

Sharepoint 附带的默认 wiki 根本不支持常见的 wiki 功能。无法编辑页面的单个部分，也无法直接链接到另一个页面上的特定部分。后端是 HTML，因此您无法使用简单的语法以纯文本形式进行编辑。差异功能不能跨越多个版本。所见即所得编辑的跨浏览器支持较差。无法自动插入目录...

但是，我无法断然拒绝 Sharepoint 的其他 wiki 插件，例如Confluence为 Sharepoint制作了插件。我自己还没有评估过这个软件，而且 Confluence 有点贵（25 个用户许可证需要 1,200 美元），尽管如果你已经在 Sharepoint 上，我会感觉到大公司的金库：P。似乎也有一些免费的加载项，如CKS Enhanced Wiki，但似乎有很多上面提到的相同问题。

score 10 · Accepted Answer

我们总是遇到这个话题，我问人们的第一个问题是“你为什么需要一个 wiki”？几乎总是答案是“易于编辑”、“多个贡献者”和“Word 是重量级的”。 我们很少看到有人询问我认为独特的类似 wiki 的功能（特殊的“神奇”标记、显示更改的细粒度版本历史记录等）。此外，他们通常希望对事物进行某种分类，而不仅仅是完全自由格式的页面。

在 SharePoint 世界中，如果您已经使用该工具一段时间，这些东西应该会向您发出“列表”的声音。基本上没有特别的理由为这些知识库风格的应用程序使用 wiki，特别是因为“易于编辑”通常与大多数用户学习特殊标记语言的想法直接冲突。通过其中的几个富文本列，您就完成了。如果您真的不喜欢内置的富文本编辑器（是的，图像上传过程很笨拙，并且在 Firefox 中不起作用），请让您的组织中的某个人放弃 8 Benjamins 并获取RadEditor for SharePoint . 它应该几乎可以解决这些问题。

一般来说，一旦我们克服了“但它必须是一个 wiki”的教条，我们就已经有了很好的客户接待，只使用列表。在某些情况下，如果需要更多的页面模板工具，我们会转向使用 MOSS 的 WCM 功能，这需要对模板进行更多的前期思考，但也有更好的开箱即用体验，例如内容片段和图像处理。

score 10 · Accepted Answer

因为默认实现不是wiki，它是一个HTML 编辑器。

如果您使用过 wiki，您就会知道其中的区别。只需查看本页底部的“您的答案”即可了解不同之处。您在 wiki 中使用标记，这相对容易阅读和编辑。格式化的 HTML 完全掩盖了所写的内容。

score 7 · Accepted Answer

作为 wiki 内容创建者和超级用户，而不是管理员或开发人员，我的两分钱价值：

我目前正在在 Sharepoint Wiki 中编辑一个文档，因为我输入了这个，它是迄今为止我遇到过的最糟糕的编辑器。准确地说，我使用的是 Sharepoint Foundation 2010（以前称为 WSS），使用 IE 9 编辑页面。

总结一下我所面临的问题：创建 wiki 内容时，您希望专注于内容，并且 wiki 引擎应该易于使用，几乎不可见。对于 Sharepoint，情况并非如此。我真的与伪所见即所得编辑器作斗争，不得不修复频繁的格式问题。

我估计我使用 Sharepoint 编写 wiki 内容的效率比使用ScrewTurn 或 Wikimedia 低 15%，因为我必须处理格式问题。 如果我花一天时间写 wiki 页面，我会浪费大约一个小时来尝试修复格式问题。

背景：我在我们公司创建了四个内部 wiki——第一个在 Wikimedia 中，Wikipedia 背后的 wiki 引擎，接下来的两个在螺丝转，最后一个在 Sharepoint。在每个 wiki 中，我写了大约 50-100 页。

在ScrewTurn 和Wikimedia 中，编辑器看起来相当原始——一个使用简单的wiki 标记代码进行格式化的纯文本编辑器。每个都有一排按钮，可以将标记代码应用于粗体和斜体格式等简单的事情，并创建链接，因此初学者不需要记住标记代码。虽然编辑器看起来很简单，但实际上使用起来非常简单，尤其是在修复格式问题时。

另一方面，Sharepoint Wiki 看起来很漂亮，但编辑起来很糟糕。与使用带有 wiki 标记的纯文本编辑器不同，它有一个 WYSIWYG 编辑器，看起来比其他 wiki 编辑器复杂得多。然而它有个性，一种邪恶的个性。它经常添加空行或更改文本颜色。当我选择要格式化的文本然后转到标记样式下拉菜单来格式化它时，有时从下拉列表中选择一个项目的行为会取消选择选定的文本，因此格式会应用于随机位置的文本。插入从 Word 复制的文本有时会导致编辑器在页面其他位置的段落之间的空白行上加倍或加倍。除了编写 HTML 之外，似乎没有简单的方法来创建表格。

然而，编辑器最大的问题是你不能轻易看到幕后发生的事情，因此很难修复它。是的，可以编辑页面的 HTML，但这确实违背了 wiki 的目的。

作为用户，我得到的总体印象是，这是由暑期实习生敲出的 alpha 级代码。我知道 Foundation 是免费版本，所以也许我得到了我们付出的代价，但我无法相信一家专业的软件公司推出了这个产品。

score 6 · Accepted Answer

6

对于将“不时”进行编辑的 6 人小组，内置 wiki 就可以了。

于 2008-08-14T19:31:49.163 回答

score 5 · Accepted Answer

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

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

score 5 · Accepted Answer

不要忘记Sharepoint 增强版 Wiki 版的社区工具包。这为开箱即用的版本添加了一些功能。

score 4 · Accepted Answer

在咆哮之前，这是我将 SharePoint 作为 wiki 的总体经验。

这是一个实施不佳的功能，但由于根本上缺乏对当前 wiki 环境提供的内容的调查而失败。这就是它在编辑器中失败的原因，以及它在以下方面遗漏的原因：标记、历史比较和生成不良的 html 代码。

您需要跳过它并获取其他可以更好地完成工作并从 SharePoint 链接到它的东西。

拥有这两种产品的生产经验，我会推荐ScrewTurn over SharePoint。

查看 rant 的编辑历史

score 3 · Accepted Answer

我的公司最近推出了 sharepoint，我不得不说我的用户体验非常糟糕。而且我不只是说我对使用它感到担心：我以开放的心态进入并尝试了它，许多事情只是觉得它们并没有真正正常工作。

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

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

score 3 · Accepted Answer

几个月前，我们查看了 Sharepoint 的部门 wiki。尽管我们主要是一家 MS 商店，但我们还是选择了DokuWiki。开源，很容易保持最新，很棒的插件和基于文件的后端。

score 3 · Accepted Answer

我还会根据此处作者的技术水平调整 OOB wiki 的评级及其缺乏功能的程度。

我同意 SP wiki 可能只是名义上的资格 - 当然与一些更强大的产品相比 - 但请记住，作为管理员 - 您的主要成功取决于最终用户的采用。简而言之 - 对于像 Confluence 这样的 wiki 添加的每个功能，它还添加了用户教育、语法等。

虽然我希望 SP wiki 有更多的“类似 wiki”——当你的 CIO 在公司 wiki 中添加条目时，你可以获得某种难以形容的满足——或者你被一群发现新的行政助理认可维基“革命”。

简而言之 - 内置功能可能对我们这些技术专业人士厌倦的眼睛来说是缺乏的，但对于技术天真的人来说，它很容易训练，并且可以让他们接触到他们可能听说过但从未听说过的技术（在此之前) 理解或想象使用。

score 2 · Accepted Answer

我已经简单地玩过SharePoint Wiki Plus。它是向 SharePoint Wiki 添加功能的第三方扩展。对于认真的 Wiki 用户，您可能需要的不仅仅是 SharePoint 提供的 Wiki - 通过扩展或专用 Wiki 产品。

score 2 · Accepted Answer

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

score 2 · Accepted Answer

Screwturn 非常棒 - 它是 C# / .Net。

Sharepoint 2010 应该有更好的 wiki 功能，并且总是有 sharepoint 的社区工具包。如果您能够放弃 Sharepoint Wiki - 您可以随时前往http://www.wikimatrix.org找到适合您的 wiki。

score 2 · Accepted Answer

我完全同意上述（Keng）。无论 SharePoint（当前使用 2010）中的内容是什么，它都不是 Wiki。

我正在实现一个自动化文档解决方案，我从源代码和 XML 配置文件中提取配置和其他信息（如 perldoc 标记）。它将信息插入到一组 DokuWIKI 页面中，并带有格式标记（包括表格）。它的格式完美，可以使用几十行 perl，包括手动编辑的静态文档页面的内部链接，以及对命名空间的支持，这样我就可以有逻辑地组织我的信息。我无法在 SharePoint 中做到这一点（叹气 - 公司方向）......

我能做的最好的事情是尝试使 DokuWIKI 模板类似于 SharePoint 网站（以保持外观和感觉相似）并链接到 SharePoint。:-(

sharepoint - 共享点维基

17 回答 17

Related

Reference