Sharepoint Wikis

Question

好的，我看过一些帖子提及其他一些关于不使用SP wiki的帖子，因为它们很糟糕。

由于我们正在考虑在 SP中执行我们的wiki ，我需要知道为什么我们不应该为一组6名自动化开发人员做这些，以记录各种自动化流程中的步骤和必须不时做出的改变。

Answer 1

如果您使用除Sharepoint之外的维基，我遇到的一些警告会消失。

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

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

第三，尝试在wiki中编写项目文档，并抵制将Word文档上传到Sharepoint库的诱惑。写两次所有文档并观察事物越来越不同步毫无意义。

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

Answer 2

我对微软的Sharepoint Wiki有更积极的看法。在许多方面它让我想起了FrontPage 98--这是一个不公平的恶意产品。

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

确实无法链接到页面，但如果页面很短，我不认为这是一个问题。 SP Wiki使得短页很容易。

如果愿意，您可以从access 2008操作Wiki属性，并且可以根据需要向Wiki列表项添加属性。例如 - 你想要类别吗？只需通过编辑列表即可添加它们。想要具体的看法？列表项。也创建它们。

微软在Sharepoint列表上建立他们的Wiki框架的方式真的很天才 - 这是不可否认的。

famerchris提到了Sharepoint Wiki的真正缺点。图像管理的方法非常糟糕。这是一个非常严重的问题，你应该仅仅考虑其他维基。

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

1. 创建一个SP博客，其中包含将在Wiki中引用的图像。
2. 使用Windows Live Writer发布到wiki-image-blog。将图像放入WLW，根据需要调整大小等。如果您愿意，也可以使用WLW编写与wiki文本初稿相关的图像。
3. 发布到Wiki后，将图像和文本复制并粘贴到Wiki编辑器富文本字段中。

这花费了惊人的时间，远远低于我读过的任何其他选项。我承认，这是令人费解的。

除了图像问题，我很高兴并对产品印象深刻。如果只有微软认为图像更难......如果只是......

Answer 3

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

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

Answer 4

由于默认实现不 wiki，因此它是 HTML编辑器。

如果您在使用wiki之前就已经知道了差异。只需查看本页底部的“您的答案”即可看到差异。您在Wiki中使用标记，这相对容易阅读和编辑。格式化的HTML完全掩盖了所写的内容。

Answer 5

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

在SharePoint世界中，如果您已经使用该工具一段时间，这些内容应该尖叫“列出”给您。基本上没有特别的理由将wiki用于这些知识库样式的应用程序，特别是因为“易于编辑”通常直接与为大多数用户学习特殊标记语言的想法相冲突。通过那里的几个富文本列，你们都已经完成了。如果你真的不喜欢内置的富文本编辑器（是的，图像上传过程很笨拙而且在Firefox中不起作用），请让你组织中的某个人放弃8 Benjamins并获得{{3 }}。它应该能够解决这些问题。

一般来说，一旦我们完成了“但它需要成为一个维基”的教条，我们就可以很好地接受使用列表的客户接待。在某些情况下，如果需要更多的页面模板工具，我们转向使用MOSS的WCM功能，这需要更多关于模板的预先考虑，但也有更好的开箱即用体验内容片段和图像处理。

Answer 6

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

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

总结我遇到的问题：在创建wiki内容时，你要专注于内容，而wiki引擎应该很容易使用，几乎看不见。使用Sharepoint并非如此。我真的很难与伪WYSIWYG编辑器，不得不修复频繁的格式化问题。

我估计使用Sharepoint编写wiki内容的效率比使用ScrewTurn或维基媒体时低15％左右，因为我必须处理格式问题。如果我花一天时间写维基页面我会在一小时内尝试修复格式问题。

背景：我在我们公司创建了四个内部维基 - 维基媒体中的第一个，维基百科背后的维基引擎，下一个在ScrewTurn中，以及最后一个在Sharepoint中。在每个wiki中，我写了大约50-100页。

在ScrewTurn和Wikimedia中，编辑器看起来相当原始 - 一个纯文本编辑器，它使用简单的wiki标记代码进行格式化。每个按钮都有一排按钮，可以为粗体和斜体格式等简单的事物应用标记代码，并创建链接，因此初学者不需要刻意学习标记代码。虽然编辑看起来很简单，但结果却非常简单，特别是在修复格式问题方面。

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

然而，关于编辑器的最大问题是，您无法轻易看到幕后发生的事情，因此很难解决问题。是的，可以编辑页面的HTML，但这实际上违背了维基的目的。

我作为用户获得的总体印象是，这是由夏季实习生打倒的alpha级代码。我知道基金会是免费版本，所以也许我得到了我们付出的代价，但我无法相信一家专业软件公司推出这款产品。

Answer 7

对于将会“不时”进行编辑的6人小组，内置维基会很好。

Answer 8

不要忘记Sharepoint - Enhanced Wiki Edition的社区套件。这为开箱即用版本增加了一些功能。

Answer 9

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

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

Answer 10

在咆哮之前，这是我作为维基的SharePoint的整体体验。

由于缺乏对当前维基环境提供的调查的缺乏调查，这是一个执行不佳的功能。这就是为什么它在它的编辑器中失败了，为什么它错过了诸如标记，历史比较和生成的html代码很差的原因。

您需要跳过它并获得更好地完成工作的其他内容并从SharePoint链接到它。

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

查看rant的编辑记录

Answer 11

几个月前，我们查看了部门维基的Sharepoint。虽然我们主要是MS商店，但我们选择DokuWiki。开源，易于更新，优秀的插件和基于文件的后端。

Answer 12

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

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

虽然我希望SP wiki能够拥有更多“类似维基”的内容 - 但当您的首席信息官在公司维基中添加条目时，您可以采取一定的，令人难以置信的满足感 - 或者您被一群行政助理认可找到新的维基“革命”。

简而言之 - 我们技术专业人士对疲惫不堪的眼睛可能缺乏内置功能，但对于技术上天真的，它很容易训练，并且可以让他们接触到他们可能听说但却永远不会的技术（在此之前）了解或想象使用。

Answer 13

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

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

为什么不考虑使用Screwturn Wiki之前的其他内容Jeff donated？我自己没有使用过Screwturn，但它是免费的开源软件，可能是一款更快速的轻量级解决方案，可满足您的需求。

Answer 14

我与SharePoint Wiki Plus进行了非常简短的比赛。这是第三方扩展，可为SharePoint Wiki添加功能。对于严肃的wiki用户，你可能需要的东西比SharePoint提供的更多 - 通过扩展或专用的Wiki产品。

Answer 15

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

Answer 16

Screwturn是邪恶的 - 它是C＃/ .Net。

Sharepoint 2010应该有更好的维基功能，并且总是有一个共享点的社区工具包。 如果您能够离开Sharepoint Wiki，您可以随时前往http://www.wikimatrix.org找到适合您的维基。

Answer 17

我完全赞同上述（Keng）。无论SharePoint中的内容是什么（目前使用的是2010），它都不是一个重要的维基。

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

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