Sharepoint Wikis好的，我看过几篇文章提到了其他一些关于不使用SP Wiki的文章，因为它们很烂。 由于我们正在寻找在SP中制作Wiki的方法，因此我需要知道为什么我们不应该让6个自动化开发人员小组记录各种自动化流程中的步骤以及必须不时进行的更改 。 如果您使用Sharepoint以外的Wiki，那么我遇到的一些警告将消失。 Sharepoint可让您创建大量独立的Wiki，但我建议为所有内容提供一个大型Wiki。我的公司为每个项目/功能制作了一堆小型Wiki，但是只有管理员才能创建单个Wiki，因此，如果我想写一些与预定义类别不匹配的内容，我必须找到一个经理首先创建Wiki。 其次，如果您使用Sharepoint，请确保员工中的每个人都只使用IE，因为Firefox不支持WYSIWIG编辑器。对于大多数Wiki而言，这是一件好事，但在Sharepoint中进行协作非常困难。想象一下整天在一个很小的盒子中编辑自动生成的HTML。 第三，尝试在Wiki中编写项目文档，并避免将Word文档上传到Sharepoint库的诱惑。编写两次所有文档并看着事情变得越来越不同步毫无意义。 最后，Sharepoint Wiki中的图像支持非常糟糕。您必须将文件添加到文档库中的某个位置，然后键入URL。我的图片被永久删除，因为它们似乎与上下文无关。 我对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支持和图像编辑功能。 这令人惊讶地花了很少的时间，远远少于我读过的任何其他选项。我承认，这令人费解。 除了图像问题外，我对产品感到满意和印象深刻。如果只有Microsoft更加认真地考虑图像... Sharepoint随附的默认Wiki完全不支持常见的Wiki功能。无法编辑页面的单个部分，也无法直接链接到另一页面上的特定部分。后端使用HTML，因此您将失去使用简单语法进行纯文本编辑的能力。差异功能不能跨多个版本。跨浏览器对所见即所得编辑的支持差。无法自动插入目录... 但是，还有一些我无法明确拒绝的Sharepoint Wiki外接程序，例如Confluence为Sharepoint提供了一个外接程序。我还没有亲自评估过该软件，Confluence有点贵(25个用户许可证的价格为1200美元)，尽管如果您已经在使用Sharepoint，我会感觉到大公司的保险箱。似乎还有一些免费的加载项，例如CKS增强的Wiki，但似乎有很多上述相同的问题。 我们一直都在讨论这个主题，而我问的第一个问题是"为什么需要维基"？答案几乎总是"易于编辑"，"多个贡献者"和"言语权重"。我们很少见到有人问过我认为独特的类似于Wiki的功能(特殊的"魔术"标记，显示更改的细粒度版本历史记录等)。而且，他们通常希望对事物进行某种分类，而不仅仅是完全自由格式的页面。 在SharePoint世界中，如果您使用该工具已有一段时间，这些事情应该会向您大喊"列出"。对于这些知识库样式的应用程序，基本上没有特别的原因使用Wiki，尤其是因为"易于编辑"通常与为大多数用户学习特殊标记语言的想法直接冲突。通过其中的几个RTF列，您已经准备就绪。如果您真的不喜欢内置的富文本编辑器(是的，图像上传过程很笨拙，并且在Firefox中不起作用)，请组织中的某人删除8个Benjamins并获取RadShare for SharePoint 。它应该几乎可以解决这些问题。 通常，一旦我们克服了"但它必须是一个Wiki"教条，我们仅使用列表就获得了相当不错的客户接待。在某些情况下，需要更多的页面模板功能，我们转向使用MOSS的WCM功能，这需要对模板进行一些前期的思考，但是对于诸如内容摘要和图像处理。 因为默认实现不是Wiki，所以它是HTML编辑器。 如果您在使用Wiki之前先了解了两者之间的区别。只需查看此页面底部的"您的答案"即可了解不同之处。您可以在Wiki中使用标记，该标记相对易于阅读和编辑。格式化的HTML完全掩盖了所写内容。 作为Wiki内容创建者和超级用户，而不是管理员或开发者，我的两分钱值得： 在键入此内容时，我目前正在Sharepoint Wiki中编辑文档，这是迄今为止我遇到过的最糟糕的编辑器。确切地说，我使用的是Sharepoint Foundation 2010(以前称为WSS)，使用IE 9编辑页面。 总结一下我所面临的问题：创建Wiki内容时，您要专注于该内容，并且Wiki引擎应该易于使用，几乎看不见。使用Sharepoint并非如此。我真的很难使用伪WYSIWYG编辑器，不得不解决常见的格式设置问题。 我估计使用Sharepoint编写Wiki内容的效率要比使用ScrewTurn或Wikimedia的效率低约15％，因为我必须处理格式问题。如果我花一天的时间来编写Wiki页面，那么尝试解决格式问题将损失大约一个小时。 作为背景：我在公司创建了四个内部Wiki-Wikimedia中的第一个，Wikipedia之后的Wiki引擎，ScrewTurn中的下两个，以及Sharepoint中的最后一个。在每个Wiki中，我写了大约50-100页。 在ScrewTurn和Wikimedia中，编辑器看起来都非常原始-纯文本编辑器，使用简单的Wiki标记代码进行格式化。每个按钮都有一排按钮，它们可以为粗体和斜体格式之类的简单事物应用标记代码，并创建链接，因此初学者无需刻意学习标记代码。尽管编辑器看上去平淡无奇，但事实证明它们的使用非常简单，尤其是对于解决格式问题。 另一方面，Sharepoint Wiki看起来很漂亮，但是编辑起来很糟糕。它没有使用带有Wiki标记的纯文本编辑器，而是提供了一个WYSIWYG编辑器，它看起来比其他Wiki编辑器更为复杂。但是它有个性，是邪恶的。它经常添加空白行或更改文本的颜色。当我选择要格式化的文本时，请转到"标记样式"下拉菜单对其进行格式化，有时从下拉列表中选择一项的操作会取消选择所选文本，因此格式化将应用于随机位置的文本。插入从Word复制的文本有时会导致编辑器在页面上其他位置的段落之间的空白行上加倍或增加三倍。除了编写HTML，似乎没有简单的方法可以创建表。 但是，有关编辑器的最大问题是，您无法轻易看到幕后情况，因此很难对其进行修复。是的，可以编辑页面的HTML，但这确实违反了Wiki的目的。 作为用户，我的总体印象是，这是一个夏季实习生敲定的Alpha级代码。我知道Foundation是免费版本，所以也许我能得到我们所付的钱，但我不敢相信专业的软件公司会推出此产品。 对于将要进行"时不时"编辑的6人一组，内置的wiki很好。 Sharepoint Wiki本质上是静态HTML页面的列表，唯一的Wiki功能是[[article]]链接。没有模板，没有类别，什么也没有。 我们最终有了一个单独的MediaWiki，仅将Sharepoint Wiki用于不需要太多布局的基于文本的内容。 不要忘记Sharepoint社区工具包-增强的Wiki版。这为现成的版本添加了一些功能。 在大声疾呼之前，这是我将SharePoint作为Wiki的整体经验。 由于缺乏对当前Wiki环境所提供内容的根本调查，因此该功能实施不佳导致失败。这就是为什么它在编辑器中失败的原因，以及为什么它在诸如标记，历史比较和生成不良的html代码之类的点上缺失的原因。 您需要跳过它，获取其他可以做得更好的东西，然后从SharePoint链接到它。 拥有这两种产品的生产经验，因此我建议您使用ScrewTurn over SharePoint。 查看rant的编辑历史记录 我还将根据作者的技术水平来调整OOB Wiki的等级及其功能性。 我同意SP Wiki仅在名称上有资格(当然，与某些更强大的产品相比)-但请记住，作为管理员，您的主要成功取决于最终用户的采用。简而言之-对于像Confluence这样的Wiki添加的每个功能，它还增加了用户培训，语法等。 虽然我希望SP Wiki具有更多"类似Wiki"的功能-当您的CIO在公司Wiki中添加条目时，您会获得一定的，难以形容的满足感-或您被一群发现新内容的行政助理所认可维基"革命"。 简而言之-内在的功能可能缺乏我们技术专业人员的疲倦之眼，但是对于天真的技术而言，它很容易接受培训，并且可以使他们接触到他们可能听说过但永远无法使用的技术(在此之前)了解或想象使用。 几个月前，我们在Sharepoint上查找了部门Wiki。即使我们主要是一家MS商店，我们还是选择了DokuWiki。开源，易于更新，功能强大的插件，以及基于文件的后端。 我的公司最近推出了sharepoint，我不得不说我的用户体验很不好。我不仅仅是说我对使用它感到不安：我以开放的心态尝试了它，许多事情似乎感觉它们并没有真正起作用。 卢克提到的原因或多或少掩盖了它。 您为什么不考虑使用Jeff不久前捐赠的其他东西呢？我自己没有使用过Screwturn，但是它是免费和开源的，并且可能是满足您需要的更快的轻量级解决方案。 也许尝试http://wordtosharepoint.codeplex.com/将您的Word内容迁移到SharePoint？它负责链接图像和大多数其他事物。 Screwturn实在是太棒了-它是C＃/ .Net。
Sharepoint 2010应该具有更好的Wiki功能，并且始终有Sharepoint社区工具包。 我使用SharePoint Wiki Plus玩过很短的时间。这是一个第三方扩展，可将功能添加到SharePoint Wiki。对于认真的Wiki用户，您可能需要的不是SharePoint提供的Wiki，而是通过扩展或专用Wiki产品。 我完全同意上述(Keng)的观点。无论SharePoint中有什么(当前使用2010)，从长远来看，它都不是Wiki。 我正在实现一个自动文档解决方案，在该解决方案中，我从源代码和XML配置文件中提取配置和其他信息(如perldoc标记)。它将信息插入到一组DokuWIKI页面中，并带有格式标记(包括表格)。它格式完美，可与几十行perl一起使用，包括指向手动编辑的静态doc页面的内部链接，并支持名称空间，因此我可以逻辑地组织我的信息。我无法在SharePoint中做到这一点(叹息-公司指导)... 我能做的最好的就是尝试使DokuWIKI模板类似于SharePoint网站(以保持外观相似)并链接到SharePoint。 :-( |
