logo标签列表

开发者文档：Sharepoint文档管理与ScrewTurn Wiki

sharepointdocumentationmosswiki
18

背景介绍

我正在为公司的开发人员建立一种方法，以共享有关我们各种内部系统的文档和信息。这将涉及到对新员工有用的信息，以及描述用户与系统遇到的常见问题及其解决方案。

在我看来，这似乎是一个理想的维基任务，由于我们公司只能托管ASP.NET应用程序，因此我开始研究可用的ASP.NET维基。 ScrewTurn Wiki似乎是最合适的选择，它非常全面，并且有几个插件可用于我的情况，包括语法高亮和AD集成。

然而，在开始将ScrewTurn部署到我们的Intranet时，突然想起，嘿，Sharepoint 2007也有一个维基，既然我们已经设置了Sharepoint，那么我们不能使用它吗？我对Sharepoint“维基”进行了一些评估（在引号中，因为它几乎不合格），并能够证明由于其许多缺陷，它不适合使用，这里不列举。

现在在这个点上，已经有人建议也许我根本不需要维基，我们可以只使用Word文档，并使用Sharepoint的文档管理功能，而不是使用ScrewTurn维基。

实际问题

因此，我正在寻找一些其他的有价值的建议，最好来自有经验的人。在内部开发人员文档的上下文中，使用Sharepoint会遇到哪些困难或不可能完成的任务？维基比Sharepoint更好吗？嘿，我很开明，Sharepoint更擅长哪些方面？

与仅使用现有工具相比，部署维基将带来哪些好处？

1
至少列出这些缺陷似乎非常重要。如果你在寻找的是弹药而不是客观、事实性的评估，那么你来到了错误的网站。 - reinierpost
11个回答
19

我希望这篇文章能有所帮助 - 不管是否给予额外的积分 :)

如果你需要处理办公文档，那么SharePoint Server (SPS) 或 Windows SharePoint Services (WSS)非常好用 - 你可以进行版本控制、检入/检出、共享、搜索等操作。我认为市场上没有其他东西能够达到这个功能（它也很擅长处理自定义列表等事项）。

但正如你所指出的，它的WIKI功能相当糟糕。

对于开发人员文档来说，wiki要好得多，因为你可以轻松地链接文档，即使仅仅因为开发人员喜欢wiki标记! 这让写作感觉像是在写代码，而不是文件。好吧，我喜欢这样。Word文档？无尽的挫败感，特别是对于代码片段和API之类的东西。Wiki通常非常擅长处理代码和结构化格式。

但以下才是我发布这篇文章的主要原因：

如果你能够托管ASP.NET，并且如果你已经拥有SPS，那么只需安装两者即可。新建一个IIS虚拟主机，在其中放置STW（因为SPS将在其自己的虚拟主机中）。稍作DNS调整（这样你就可以通过http://wiki之类的方式进行访问），然后开始使用。

由于它们都是在公司内部，而且STW具有Windows安全性和版本控制，因此安全性不是一个很大的问题。每个页面都可以从任何地方链接 - 毕竟这只是一个HTML页面 - 因此，如果你确实想要这样做，可以从SPS wiki链接到它。我猜有些锁定，但并不是很多。

在BBC Worldwide，我们使用了许多技术：

  • Atlassian Confluence (WIKI) 用于某些项目。我很喜欢这个wiki，但它确实是一种大型企业系统。
  • Screw Turn 用于某些部门内部事项。
  • Trac 用于其他一些事项（有人在我们的源代码库上设置了SVN，所以稍微用了一下- 它很好，我相当喜欢它，但设置起来比较麻烦）
  • SPS/WSS用于文档管理。
  • STW、Trac和SPS之间存在联系 - 例如，我们尽量不要在Trac中作为附件存储文档，而是链接到SPS中。
  • 效果很好。
  • 至于弹药：如果SPS适合您想要做的事情（或者您可以适应它所做的事情），那么它就很好用。如果不能，那么您要么完蛋了，要么需要进行大量开发，这基本上是一回事 :)
  • 但除了管理人员有些奇怪之外，我看不出安装两者会有什么问题。毕竟STW是免费的。您拥有服务器。
  • 并且它可以让开发人员编写文档，这很少是坏事。嗯，如果真正的人类必须阅读它，那就是一件坏事了，但是其他开发人员的文档呢？都是好的。
  • *注意：虚拟主机。不是虚拟目录。
9

我既用过Sharepoint也用过Screwturn，下面是我的建议：

  • 如果你需要所见即所得的编辑器，并且不在意Sharepoint庞大和缺乏功能（wiki虽然简单，但具有wiki所需的主要功能），那么就选择它。它作为wiki工作，并且当业务人员需要使用wiki时会帮助他们--这样教他们使用它的时间就少了很多。
  • 如果你只需要一个快速灵活的简单的wiki，那么你无法打败screwturn。

至于为什么要使用wiki，无论是screwturn还是sharepoint -- 它都比Sharepoint中的Word文档更胜一筹。要使用Sharepoint，首先你必须下载文档，然后进行编辑、上传，或者使用Office集成，而这种方法最好情况下也不太靠谱。Wiki消除了所有的摩擦，使更新变得非常简单。消除摩擦是关键，因为当你必须使用Word文档时，你会发现自己并没有像应该那样经常更新它们。对于wiki来说，这是一个2秒钟的进入/编辑/保存交易。而对于Word文档，加载Word、打开文档、编辑、担心格式、保存等操作需要花费几分钟的时间。

我们这里使用的是 MOSS 2007 标准版，与 Office 2007 的集成非常可靠。没有任何风险。从 SharePoint 中加载文件所需的时间与从我们的文件服务器加载时间相同。顺便说一下。 - MrChrister
这是本地的还是互联网的？我可以看到内部网络，但每次尝试通过互联网访问Sharepoint都很烦人。经常出现奇怪的减速问题，出现问题，只能使用IE浏览器，并且必须安装Office。 - Chris Hynes
使用非常好的硬件在本地网络上运行Office和/或Sharepoint的速度将比位于世界另一端的平均维基慢一个数量级！ - TFD
6

嘿，我在这方面有经验。我们开始使用ScrewTurn工作，但因为公司已经购买了SharePoint而被要求切换。文档质量下降了，因为Word文档无法与wiki相匹配，正如其他人所指出的那样，SharePoint的质量也不够好。

在我看来，没有什么比维基更适合用于文档编写。主要是因为它能够创建链接到尚不存在的页面。这样，我就可以为文档编写草稿，并根据需要填充其余部分。这使得文档更加简明易读。

对于Word文档，超链接不太可能被使用，但它对于文档的可读性非常有帮助。我还可以继续说下去...

你是否已经转移到了SharePoint的Wiki功能或SharePoint社区工具包的Wiki版本？ - Nat
我们又回到使用Word文档等了。我们尝试过Wiki功能，但它从未流行起来。它并不是那么好用。我们中有些人曾经使用ScrewTurn，希望能够回到那个时候，但这不是我们的选择。 - Dan
4
作为一般性的描述，Word 对于技术文档而言相当糟糕。由于它对于大型结构化文档的支持非常差，它鼓励产生许多没有文档间交叉引用的小型文档。如果将其扩展到任何重要的规模，您将会发现很难找到与您正在调查的问题有关的文档。随着时间的推移，您会发现人们浪费了越来越多的时间在混乱的 Word 文档、电子表格、Visio 图表甚至 PowerPoint 演示文稿中寻找可能记录或未记录的信息。

将它们放入 SharePoint 只会迫使您通过浏览器进行搜索。

任何技术文档工具都必须支持文档间交叉引用以避免丢失这些引用。Wiki 比 Word 更能实现这一点。此外，将生成的内容（如数据字典或 API 文档）合并到 Wiki 中要容易得多，并且可以使 XRef 目标稳定。

3
1
是的，加强版的CKS Wiki是比较维基的唯一方式。SharePoint开箱即用更像是一个“威”。 - Nat
2
首先，查看这个StackOverflow线程。有人问了关于Sharepoint维基的类似问题，那里的答案都很有用，说明了你问题中“在Sharepoint中不可能”的部分。
我现在正在尝试在Sharepoint中实现一个团队维基，几乎和你的需求一样，在使用Sharepoint进行团队文档管理几年后。我的观察如下：

Sharepoint文档库

我的经验是，对于文档，Sharepoint表现还不错。它有时会出现故障或性能问题，但是一个好的Sharepoint支持团队可以帮助解决其中的一些问题。我发现Sharepoint文档库比将文件存储在网络上要好。它使得文档和库易于链接。谨慎使用元数据属性可以使Sharepoint列表视图非常有用，以便在一眼看到文档是什么、它是用来干什么的以及它的状态是什么时，我们的分析师、项目经理、开发人员等都知道谁在掌握主动权以及何时需要等待某些事情。这是几年前为一个项目启动的；今天，Sharepoint 2007的工作流可能提供通知。
文档也有版本控制。但是，正如其他一些人所指出的，文档编写、下载和共享中涉及的开销和缺陷是有问题的。文档的签出可以帮助，但是松散的开发人员可以下载文档、编辑它们，然后将它们存储在其他地方，从而破坏版本控制。这种情况曾经发生过，但这是一个纪律问题，不是Sharepoint的问题。

Sharepoint维基

根据Chris Hynes的答案，摩擦是描述这个问题的一个好词。对于团队内部基础设施细节的快速参考，维基似乎对我们更有效。维基使数据几乎即时可见，无需先点击链接并等待Word加载。编辑也更快、更容易……虽然我仍在试验中，但Sharepoint维基具有版本控制，并允许“签出”维基文章。
正如你和其他SO线程指出的那样，与其他维基引擎相比，Sharepoint是轻量级的。它更擅长什么？好吧，我正在使用它，因为它已经存在，不需要任何特殊设置，比没有更好，而且说实话，它对于内部事务来说工作得很好，不需要很强大或面向客户。它很容易向老板推销，因为它不需要额外的费用，只需要我们已经花费的费用。维基也不太容易被我之前提到的松散炮手类型所破坏，如果必要，我们将能够查看审计跟踪或回滚。
它很容易添加和交叉链接条目，虽然如果您想嵌入图形，您必须先将它们上传到Sharepoint库中。您也可以编辑维基中的HTML，尽管我不确定其中有什么限制，并且控制CSS可能没有安全访问和Sharepoint Designer。因此，除了文本（如表格）之外的任何内容都不是非常强大。

到目前为止，我比将所有内容存储为文档更喜欢它。看到和编辑数据的即时性使维基具有真正的优势。与拉取文档并检查其是否已回传相比，它肯定更容易。对于平均不喜欢文档的开发人员来说，它有助于消除围绕更新信息的障碍。

还有一些需要考虑的问题。您是否希望您的开发人员热情并积极参与编辑维基？如果是这样，您可能需要使用不同维基引擎的讨论功能。我的开发人员与大多数人一样;他们最讨厌的两件事是测试和文档。因此，我是那个创建说明构建过程、数据库环境使用、应用程序实例、服务器映射、SOX文档清单等文章的人。其他开发人员主要会参考它并发布较小的更新。我们的版本控制和并发支持没有受到太大的压力。

2
一个Wiki比一堆Word文档更容易被使用，因为它可以更快速、更轻松地找到要编辑或创建新页面的条目，而一堆Word文档则永远不可能做到这一点！
问题的关键在于选择哪个Wiki。
几乎任何一个Wiki都比SharePoint Wiki好得多，那个简直是一个笑话。
Screwturn非常出色，拥有ACL和WYSIWYG功能，并且非常容易扩展。
例如，使用XSLT插件可以很好地嵌入服务器进程、CI构建、测试、源代码控制统计信息等输出。
例如，我们有一个OLEDB插件，可以从各种公司数据库中读取关键值，并将它们嵌入描述数据及其应该具有的值的页面。我们有一个主页面，列出所有具有规定范围之外数据的页面。这有点像FIT和系统监控工具的混合体。
如果你在“一切都必须在SharePoint中”的管理职位上，那么有Screwturn插件可以将Screwturn页面呈现为PDF、HTML、XML等格式（你可以转换为docx），并且有一个脚本每晚将更改过的Screwturn页面转储到SharePoint以供搜索和“管理”用途。
2
您可能想要查看Confluence，因为它很可能是市场上领先的企业维基。该维基也有一个SharePoint Connector。作为SharePoint Connector的贡献者之一，我有些偏见，但如果您不检查几个可用选项，则可能会自欺欺人。维基可以强大且具有感染力，但如果维基不够好，这种效果就不会出现。
1

没有人会将SharePoint wiki与其他wiki系统进行比较而感到满意。

所以，不要进行比较。它具有使wiki有用的基本功能：您可以输入（略微）格式化的文本，以及链接到其他页面，无论它们是否存在。单击指向不存在页面的链接将带您进入新的空白页面的编辑页面，允许您保存该页面。

是的，图片支持很糟糕。您必须先创建图片，然后粘贴图片的URL。因此，请花两分钟时间创建一个图片库，以发布wiki图片。

记住wiki的主要目标-不是与其他wiki工具竞争，而是快速地将想法写下来，而不需要停下来对它们进行结构化。如果需要，稍后可以添加结构。

正如其他人所说，telerik提供了富文本编辑器的替代品，还有一个CodePlex项目正在缓慢地改进，而且，这是SharePoint-如果您不喜欢它，可以自定义它。它是ASP.NET、Web服务和Windows Workflow Foundation。

我不建议任何人购买MOSS许可证来实现维基（或博客）。但是，如果您已经拥有SharePoint基础设施（可能作为Visual Studio Team System Team Foundation Server的一部分），那就去试试吧。我见过几个SharePoint维基库被用来极大地提高了大型软件开发组织内几个团队可用的开发人员文档的数量和质量。一旦我们停止讨论其他维基有多么好，相当多的文档就会自动产生，就像它应该做的那样。

0

我经常使用Sharepoint，但我发现它有点慢且令人烦恼。如果所有东西都是Office文档，并且你的公司愿意让每个人的电脑与Office版本保持同步，那么Sharepoint可以正常工作。如果你有各种Office版本（就像我们一样），那么它的效果就会差很多。我的电脑上有一些旧版本的Office组件，集成并不总是正确地工作。我已经学会了不尝试使用集成。

任何解决方案最重要的是确保你的员工知道如何使用它。我们早期遇到了一些问题（文件版本不同名而不是使用内置的Sharepoint版本控制），这实际上只是人们培训中的空白。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接