Sharepoint 维基
好吧，我看过一些帖子提到还有一些关于不使用 SP wiki 的帖子，因为它们很糟糕。
由于我们正在考虑在 SP 中创建 wiki，我需要知道为什么我们不应该让 6 名自动化开发人员组成的小组来记录各种自动化流程中的步骤以及所发生的更改不时进行。
Ok, I've seen a few posts that mention a few other posts about not using SP wikis because they suck.
Since we are looking at doing our wiki in SP, I need to know why we shouldn't do it for a group of 6 automation-developers to document the steps in various automated processes and the changes that have to be made from time to time.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（17）
Screwturn 太棒了 - 而且它是 C# / .Net。
Sharepoint 2010应该有更好的wiki功能，而且总是有sharepoint的社区工具包。
如果您能够将 Sharepoint Wiki 抛在脑后 - 您可以随时访问 http://www.wikimatrix.org< /a> 查找适合您的 wiki。
Screwturn is wicked awesome - and it is C# / .Net.
Sharepoint 2010 is supposed to have better wiki features, and there is always the community kit of sharepoint.
If you are able to leave the Sharepoint Wiki behind - you could always head over to the http://www.wikimatrix.org to find the wiki that works for you.
我完全同意上述观点（Keng）。 无论 SharePoint 中的内容是什么（目前使用的是 2010），它绝对不是 Wiki。
我正在实现一个自动化文档解决方案，从源代码和 XML 配置文件中提取配置和其他信息（如 perldoc 标记）。 它将信息插入一组 DokuWIKI 页面中，并附有格式化标记（包括表格）。 它的格式完美，可与几十行 Perl 一起使用，包括手动编辑的静态文档页面的内部链接，并支持命名空间，以便我可以逻辑地组织我的信息。 我无法在 SharePoint 中做到这一点（叹气 - 公司方向）...
我能做的最好的事情就是尝试使 DokuWIKI 模板类似于 SharePoint 网站（以保持外观和感觉相似）并链接到 SharePoint 之外。 :-(
I fully concur with the above (Keng). Whatever that thing is within SharePoint (currently using 2010), it is NOT a Wiki by a long shot.
I am implementing an automated documenting solution, where I extract config and other info (like perldoc markup) from source code and XML config files. It inserts the info in a set of DokuWIKI pages, complete with formatting markup (including tables). It comes out perfectly formatted and works with a couple of tens of lines of perl, includes internal links to manually edited static doc pages, and support for namespaces so I can have my information logically organised. There is no way I could do that in SharePoint (sigh - company direction)...
The best I can do is try to make DokuWIKI template resemble sort of the SharePoint site (to keep the look and feel similar) and link out of SharePoint. :-(
也许尝试 http://wordtosharepoint.codeplex.com/ 将 Word 内容迁移到 SharePoint？ 它负责链接图像和大多数其他内容。
Maybe try http://wordtosharepoint.codeplex.com/ for migrating your Word content to SharePoint? It takes care of linking images and most other things.
我已经简单地使用了 SharePoint Wiki Plus。 它是一个第三方扩展，可为 SharePoint Wiki 添加功能。 对于认真的 Wiki 用户，您可能需要的不仅仅是 SharePoint 提供的 Wiki - 通过扩展或专用的 Wiki 产品。
I've played very briefly with SharePoint Wiki Plus. It's a third-party extension that adds features to the SharePoint Wiki. For serious wiki users then you probably need something more than the SharePoint provided Wiki - either via an extension or a dedicated Wiki product.
我还会根据作者的技术水平来调整 OOB wiki 的评级及其缺乏功能。
我同意 SP wiki 可能只是名义上的 - 当然与一些更强大的产品相比 - 但请记住，作为管理员 - 您的主要成功取决于最终用户的采用。 简而言之 - 对于像 Confluence 这样的 wiki 添加的每一项功能，它还增加了用户教育、语法等。
虽然我希望 SP wiki 有更多的“类似 wiki” - 当你CIO 在公司 wiki 中添加了一个条目，或者您被一群行政助理认可，他们发现新的 wiki 是“革命性的”。
简而言之 - 对于我们技术专业人士疲惫的眼睛来说，内置功能可能缺乏，但对于技术天真的人来说，它很容易训练，并且可以让他们接触到他们可能听说过但从未接触过的技术（在此之前） ）理解或想象使用。
I would also temper the ratings of the OOB wiki and its lack of functionality with the technical level of the authors here.
I agree that the SP wiki might qualify in name only - certainly when compared to some more robust offerings - but remember as an admin - your primary success is determined by end user adoption. In short - for every feature that a wiki like Confluence adds, it also adds user education, syntax, etc.
While I would love SP wiki to have more "wiki-like" - there is a certain, undescribable satisfaction you can take when your CIO adds an entry in the company wiki - or you are recognized by a group of administrative assistants who find the new wiki "revolutionary".
In short - the built in functionality may be lacking to the jaded eyes of us tech professionals, but to the technologically naive, its pretty easy to train on, and can expose them to a technology they may have heard of but could never (before this) understand or imagine using.
几个月前，我们查看了部门 wiki 的 Sharepoint。 尽管我们主要是一家 MS 商店，但我们还是选择了 DokuWiki。 开源，很容易保持最新状态，很棒的插件，以及基于文件的后端。
We looked at Sharepoint for a department wiki a few months ago. Even though we're primarily an MS shop, we went with DokuWiki. Open-source, so easy to keep up to date, great plugins, and a file-based back end.
我的公司最近推出了 sharepoint，我不得不说我的用户体验非常糟糕。 我并不是只是说我对使用它感到担心：我以开放的心态进入并尝试了它，但很多事情只是感觉它们并没有真正发挥作用。
路加所提到的原因或多或少都涵盖了这一点。
您为什么不考虑使用其他东西，例如 Screwturn Wiki ，它 杰夫不久前捐赠了给？ 我自己没有使用过 Screwturn，但它是免费且开源的，并且可能是满足您需求的更快的轻量级解决方案。
My company rolled out sharepoint recently, and I have to say my user experience was Very Bad. And I'm not just saying I was apprehensive to using it: I went in with an open mind and tried it, and many things just felt like they didn't really work right.
The reasons Luke mentioned more or less cover it.
Why wouldn't you consider using something else like Screwturn Wiki which Jeff donated to a short while ago? I haven't used Screwturn myself, but it is free and open source, and may be a faster lightweight solution for what you need.
在咆哮之前，以下是我使用 SharePoint 作为 wiki 的总体体验。
这是一个实施得很差的功能，之所以失败，是因为对当前 wiki 环境提供的内容缺乏根本性的调查。 这就是为什么它在编辑器中失败，以及为什么它错过了诸如标记、历史比较和生成不良的 html 代码之类的点。
您需要跳过它并获取其他可以更好地完成工作的内容并从 SharePoint 链接到它。
拥有这两种产品的生产经验，我建议使用 ScrewTurn 而不是 SharePoint。
查看咆哮的编辑历史记录
Before the rant, here is my overall experience with SharePoint as a wiki.
It is a poorly implemented feature that failed becouse there was a fundemental lack of investigation into what current wiki environments provide. That is why it failed in it's editor and why it misses on points like: tagging, history comparison, and poorly generated html code.
You need to skip it and get something else that does the job better and link to it from SharePoint.
Having production experience with both products, I'd recommend ScrewTurn over SharePoint.
see edit history for rant
不要忘记 Sharepoint 的社区工具包- 增强版维基版。 这为开箱即用版本添加了一些功能。
Don't forget the Community Kit for Sharepoint - Enhanced Wiki Edition. This adds some features to the out of the box version.
Sharepoint Wiki 本质上是静态 HTML 页面的列表，唯一的 Wiki 功能是 [[article]] 链接。 没有模板，没有类别，什么都没有。
我们最终拥有了一个单独的 MediaWiki，并且仅将 Sharepoint wiki 用于不需要太多布局的基于文本的内容。
The Sharepoint Wiki is essentially a list of Static HTML Pages, with the only Wiki-feature being [[article]] links. No Templates, No Categories, nothing.
We ended up having a separate MediaWiki and only use the Sharepoint wiki for text-based content that does not need much layout.
对于“时不时”进行编辑的 6 人小组来说，内置 wiki 就足够了。
For a group of 6 people that will be making "every now and then" edits, the built-in wiki will be fine.
因为默认实现不是 wiki，而是一个 HTML 编辑器。
如果您之前使用过维基，您就会知道其中的区别。 只需查看本页底部的“您的答案”即可了解差异。 您在 wiki 中使用标记，这相对容易阅读和编辑。 格式化的 HTML 完全掩盖了所写的内容。
Because the default implementation is not a wiki, it is an HTML editor.
If you've used a wiki before you'll know the difference. Just look at "Your answer" at the bottom of this page to see the difference. You use markup in a wiki, which is relatively easy to read and edit. Formatted HTML completely obscures what is written.
作为 wiki 内容创建者和超级用户，而不是管理员或开发人员，我的两美分价值是：
当我输入此内容时，我目前正在 Sharepoint Wiki 中编辑文档，它是迄今为止我遇到过的最糟糕的编辑器。 准确地说，我正在使用 Sharepoint Foundation 2010（以前称为 WSS），使用 IE 9 编辑页面。
总结一下我遇到的问题： 创建 wiki 内容时，您希望专注于内容，而 wiki 引擎应该使用起来非常方便，几乎看不见。 对于 Sharepoint，情况并非如此。 我真的很挣扎于伪所见即所得编辑器，必须修复频繁的格式问题。
我估计，使用 Sharepoint 编写 wiki 内容的效率比使用 ScrewTurn 或 Wikimedia 低 15%，因为我必须处理格式问题。 如果我花一天时间编写 wiki 页面，我会花费了大约一个小时来尝试修复格式问题。
作为背景：我在我们公司创建了四个内部 wiki - 第一个位于 Wikimedia，维基百科背后的 wiki 引擎，接下来的两个位于 ScrewTurn，最后一个位于 Sharepoint。 在每个 wiki 中，我编写了大约 50-100 页。
在 ScrewTurn 和 Wikimedia 中，编辑器看起来相当原始 - 一个纯文本编辑器，使用简单的 wiki 标记代码进行格式化。 每个按钮都有一排按钮，可以将标记代码应用于简单的事情，例如粗体和斜体格式，以及创建链接，因此初学者不需要记住标记代码。 虽然编辑器看起来很普通，但实际上使用起来非常简单，尤其是修复格式问题。
另一方面，Sharepoint Wiki 看起来很漂亮，但编辑起来糟糕。 它没有使用带有 wiki 标记的纯文本编辑器，而是使用所见即所得编辑器，看起来比其他 wiki 编辑器复杂得多。 但它有个性，邪恶的。 它经常添加空行或更改文本颜色。 当我选择要格式化的文本，然后转到“标记样式”下拉列表对其进行格式化时，有时从下拉列表中选择项目的操作会取消选择选定的文本，因此格式化将应用于随机位置的文本。 插入从 Word 复制的文本有时会导致编辑器在页面其他位置的段落之间的空白行上增加两倍或三倍。 除了编写 HTML 之外，似乎没有简单的方法来创建表格。
然而，编辑器最大的问题是你无法轻易看到幕后发生的事情，因此很难修复它。 是的，可以编辑页面的 HTML，但这确实违背了 wiki 的目的。
作为一名用户，我得到的总体印象是，这是由暑期实习生敲出的 alpha 级别代码。 我知道 Foundation 是免费版本，所以也许我得到了我们所支付的费用，但我不敢相信专业软件公司推出了这个产品。
My two cents worth as a wiki content creator and super-user, rather than an administrator or developer:
I am currently editing a document in Sharepoint Wiki as I type this, and it is by far the worst editor I have ever come across. To be precise, I'm using Sharepoint Foundation 2010 (previously known as WSS), editing pages using IE 9.
To sum up the problems I've faced: When creating wiki content you want to concentrate on the content and the wiki engine should be so easy to use as to be almost invisible. With Sharepoint that is not the case. I really struggle with the pseudo-WYSIWYG editor, having to fix frequent formatting problems.
I estimate that I'm about 15% less productive writing wiki content with Sharepoint than I am with ScrewTurn or Wikimedia because I have to deal with the formatting issues. If I spend a day writing wiki pages I would lose about an hour trying to fix formatting issues.
For background: I've created four internal wikis at our company - the first in Wikimedia, the wiki engine behind Wikipedia, the next two in ScrewTurn, and a final one in Sharepoint. In each wiki I've written about 50-100 pages.
In both ScrewTurn and Wikimedia the editor looks fairly primitive - a plain text editor that uses simple wiki mark-up codes for formatting. Each has a row of buttons that can apply mark-up codes for simple things like bold and italic formatting, and to create links, so beginners do not need to learn the mark-up codes by heart. While the editors look plain they turn out to be really simple to use, especially for fixing formatting problems.
Sharepoint Wiki, on the other hand, looks slick but is terrible for editing. Instead of using a plain text editor with wiki mark-up it has a WYSIWYG editor that looks much more sophisticated than other wiki editors. However it has personality, an evil one. It frequently adds blank lines or changes the colour of text. When I select text to format then go to the Markup Styles dropdown to format it, sometimes the act of selecting an item from the dropdown list deselects the selected text so the formatting applies to text at a random location. Inserting text copied from Word sometimes causes the editor to double or triple up on blank lines between paragraphs at other places on the page. There appears to be no easy way of creating a table, apart from writing HTML.
The biggest problem about the editor, however, is that you can't easily see what is going on behind the scenes so it's difficult to fix it. Yes, it's possible to edit the page's HTML but that really defeats the purpose of a wiki.
The overall impression I get as a user, is that this is alpha-level code that has been knocked up by a summer intern. I know Foundation is the free version so perhaps I get what we've paid for but I cannot believe a professional software company put out this product.
Sharepoint 附带的默认 wiki 根本不能很好地支持常见的 wiki 功能。 无法编辑页面的单个部分，也无法直接链接到另一个页面上的特定部分。 后端采用 HTML 格式，因此您无法使用简单语法以纯文本形式进行编辑。 diff 功能不能跨越多个版本。 对所见即所得编辑的跨浏览器支持较差。 无法自动插入目录...
但是，还有其他 Sharepoint 的 wiki 插件，我无法断然拒绝，例如 Confluence 为 Sharepoint 制作了一个插件。 我自己还没有评估过这个软件，而且 Confluence 有点贵（25 个用户许可证 1,200 美元），尽管如果您已经在使用 Sharepoint，我感觉企业金库很大 :P。 似乎还有一些免费的加载项，例如 CKS 增强版 Wiki 但似乎存在很多与上述相同的问题。
The default wiki included with Sharepoint doesn't support common wiki features well at all. There is no way to edit a single section of a page, and no way to link directly to a particular section on another page. The backend is in HTML so you lose the ability to edit in plaintext using simple syntax. The diff feature can't span multiple versions. Poor cross browser support of WYSIWYG editing. No way to auto-insert a table of contents...
There are, however, other wiki add-ins for Sharepoint which I can't categorically dismiss, for instance Confluence makes an add-in for Sharepoint. I haven't evaluated this software myself, and Confluence is somewhat expensive ($1,200 for 25 user license) although if you are already on Sharepoint I sense large corporate coffers :P. There also appear to be some free add-ins like CKS Enhanced Wiki but that appears to have a lot of the same problems mentioned above.
我们一直经常遇到这个话题，我问人们的第一个问题是“为什么你需要一个 wiki”？ 几乎所有的答案都是“易于编辑”、“多个贡献者”和“Word 是重量级的”。 非常我们很少看到有人询问我认为独特的类似 wiki 的功能（特殊的“神奇”标记、显示更改的细粒度版本历史记录等）。 此外，他们通常想要对事物进行某种分类，而不仅仅是完全自由格式的页面。
在 SharePoint 世界中，如果您已经使用该工具一段时间了，那么这些东西应该会向您尖叫“列出”。 对于这些知识库类型的应用程序使用 wiki 基本上没有什么特别的原因，特别是因为“易于编辑”通常与大多数用户学习特殊标记语言的想法直接冲突。 通过其中的几个富文本列，您就完成了。 如果您真的不喜欢内置的富文本编辑器（是的，图像上传过程很笨重，并且在 Firefox 中不起作用），请让您组织中的某个人放弃 8 本杰明并去获取 用于 SharePoint 的 RadEditor。 它应该可以解决这些问题。
一般来说，一旦我们克服了“但它需要是一个维基”的教条，我们就会得到很好的客户接受，只使用列表。 在某些情况下，需要更多的页面模板工具，我们转而使用 MOSS 的 WCM 功能，这需要对模板有更多的预先考虑，但也有更好的开箱即用体验，例如内容片段和图像处理。
We run into this topic all the time, and the first question I have taken to asking people is "Why do you need a wiki"? Almost always the answers are things "ease of editing", "multiple contributors", and "Word is to heavyweight". Very rarely have we seen anyone ask for what I consider to be uniquely wiki-like features (special "magic" markup, fine grained version history showing changes, etc). Also, they usually want some kind of categorization of things, not just completely free-form pages.
In the SharePoint world these things should scream "list" at you if you've been working with the tool for a while. There is basically no particular reason to use a wiki for these knowledge base-style applications, especially since "ease of editing" usually directly conflicts with the idea of learning a special markup language for most user. Through a couple of rich-text columns in there, and you're all set. If you really don't like the built-in rich-text editor (yes the image uploading process is clunky and it doesn't work in Firefox), have someone in your organization go drop the 8 Benjamins and go get the RadEditor for SharePoint. It should pretty much handle those concerns.
Generally once we've gotten over the "but it needs to be a wiki" dogma, we've had pretty good customer reception to just using lists. In some cases, where a little more of a page templating facility was required we turned to using the WCM features of MOSS, which requires a little more up-front thought about templates, but also has a better out of the box experience for things like content snippets and image handling.
以下是我遇到的一些警告，如果您使用 Sharepoint 以外的 wiki，这些警告将会消失。
Sharepoint 可以让您创建大量独立的 wiki，但我建议您为所有内容创建一个大型 wiki。 我的公司为每个项目/功能制作了一堆小 wiki，但只有管理员可以创建单独的 wiki，因此，如果我想写一些与预定义类别不匹配的内容，我必须找到一个管理员首先创建 wiki。
其次，如果您使用 Sharepoint，请确保您的员工中的每个人都只使用 IE，因为 Firefox 不支持 WYSIWIG 编辑器。 对于大多数 wiki 来说，这是一件好事，但是却使 Sharepoint 中的协作变得困难。 想象一下整天在一个小盒子里编辑自动生成的 HTML。
第三，尝试在 wiki 中编写您的项目文档，并抵制将 Word 文档上传到 Sharepoint 库的诱惑。 将所有文档写两次并看着事情变得越来越不同步是没有意义的。
最后，Sharepoint wiki 中的图像支持很糟糕。 您必须将文件添加到文档库中的某个位置并输入 URL。 我的图像永远被删除，因为它们脱离上下文似乎没有多大意义。
Here are some caveats I came across that will vanish if you use a wiki other than Sharepoint.
Sharepoint lets you create tons of separate wikis, but I'd recommend having one big wiki for everything. My company made a bunch of little wikis for each project/feature, but only admins can create the individual wikis, so if I want to write about something that isn't doesn't match one of the predefined categories, I have to find a manager to create the wiki first.
Secondly, if you use Sharepoint make sure everyone on your staff only uses IE, since Firefox doesn't support the WYSIWIG editor. This is a good thing for most wikis, but makes collaborating difficult in Sharepoint. Imagine editing auto-generated HTML in a tiny little box all day.
Third, try to write up your project documentation in the wiki and resist the temptation to upload Word docs to the Sharepoint library. No point in writing up all your docs twice and watching things get more and more out of sync.
Finally, image support in Sharepoint wikis is terrible. You have to add a file to a document library somewhere and type in the URL. My images were forever getting deleted because they don't seem to make much sense out of context.
我对 Microsoft 的 Sharepoint Wiki 有更积极的看法。 在很多方面，它让我想起了 FrontPage 98 —— 那是一个受到不公平诽谤的产品。
关于使用列表的评论是错误的。 Sharepoint Wiki 是 Sharepoint 列表，其中每个页面都是带有 HTML 附件的列表项。
确实，您无法链接到页面，但如果页面很短，我不认为这是一个问题。 SP Wiki 使得短页面变得非常容易。
如果您愿意，您可以在 access 2008 中操作 Wiki 属性，并且可以根据需要将属性添加到 wiki 列表项。 例如——您想要类别吗？ 只需通过编辑列表来添加它们即可。 想要具体观点吗？ 列表项。 也创建它们。
微软在 Sharepoint 列表之上构建 Wiki 框架的方式是真正的天才——无可否认，这做得很好。
farmerchris 提到了 Sharepoint Wiki 的真正缺点。 图像管理的方法非常糟糕。 这是一个如此严重的问题，您应该仅仅因为这个原因就考虑其他 Wiki。
我使用了一个复杂的解决方法。 它利用了出色的 Sharepoint 支持以及与 Windows Live Writer 集成的图像编辑功能。
这花费的时间少得惊人，远远少于我读过的任何其他选项。 我承认，这很复杂。
除了图像问题之外，我对该产品感到满意和印象深刻。 如果微软能更加认真地思考图像就好了……如果……
I have a much more positive view of Microsoft's Sharepoint Wiki. In many ways it reminds me of FrontPage 98 -- and that was an unfairly maligned product.
The comment about using a list is misguided. Sharepoint Wikis ARE Sharepoint lists, in which each page is a list item with an HTML attachment.
It's true that you can't link into a page, but if the pages are short I don't see that as a problem. SP Wiki makes it very easy to have short pages.
You can manipulate the Wiki attributes from access 2008 if you wish, and you can add attributes to the wiki list items as desired. For example -- do you want categories? Just add them by editing the list. Want specific views? of list items. Create them too.
There's real genius in the way Microsoft built their Wiki framework atop Sharepoint lists -- which are undeniablly well done.
The TRUE drawback of Sharepoint Wiki was mentioned by famerchris. The approach to image management is surprisingly awful. It's such a serious problem that you should consider other Wikis for this reason alone.
There is a convoluted workaround that I use. It takes advantage of the superb Sharepoint support and image editing integrated with Windows Live Writer.
This takes suprisingly little time, far less than any other option I've read of. I admit, it is convoluted.
Other than the image problems I'm pleased and impressed with the product. If only Microsoft had thought harder about images ... if only ...