SharePoint维基

以下是一些我遇到的警告,如果你使用的是wiki而不是SharePoint,这些警告就会消失。

SharePoint允许您创建大量独立的wiki,但我建议您为所有内容都创建一个大的wiki。我的公司为每个项目/功能制作了一堆小维基,但是只有管理员才能创建单独的维基,所以如果我想写一些与预先定义的类别不匹配的东西,我必须先找一个经理来创建维基。

其次,如果你使用SharePoint,确保你的员工都只使用IE,因为火狐不支持Wysiwig编辑器。这是一个 好的 对大多数维基来说都是如此,但在SharePoint中协作却很困难。想象一下,整天在一个小盒子里编辑自动生成的HTML。

第三,尝试在wiki中编写项目文档,抵制将Word文档上载到SharePoint库的诱惑。把你所有的文件写两次,看着事情变得越来越不同步,这毫无意义。

最后,SharePoint维基中的图像支持非常糟糕。您必须将文件添加到某个文档库中,然后键入URL。我的图片总是被删除,因为它们似乎没有太多意义的上下文。

我对微软的SharePoint维基有更积极的看法。在很多方面,它让我想起了FrontPage 98——这是一个不公平的恶意产品。

关于使用列表的评论是错误的。SharePoint Wiki是SharePoint列表,其中每个页面都是带有HTML附件的列表项。

确实,你不能链接到一个页面,但如果页面很短,我不认为这是一个问题。sp wiki使拥有短页面变得非常容易。

如果愿意,您可以从Access2008操作wiki属性,并可以根据需要向wiki列表项添加属性。例如——您想要类别吗?只需通过编辑列表来添加它们。想要具体的视图吗?列出项目。也创建它们。

微软在SharePoint列表上构建wiki框架的方式真是太天才了——这无疑做得很好。

Famerchris提到了SharePointwiki的真正缺点。图像管理的方法令人惊讶地糟糕。这是一个非常严重的问题,你应该考虑其他的维基,就因为这个原因。

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

1. 创建一个包含wiki中引用的图像的sp blog。
2. 使用Windows Live Writer发布到wiki图像日志。把你的图片放到wlw中,根据需要调整它的大小,等等。如果你喜欢,也可以使用wlw来写你的图片相关的wiki文本初稿。
3. 发布到wiki后,将图像和文本复制并粘贴到wiki编辑器的富文本字段中。

这只需要极少的时间,比我读过的任何其他选择都要短得多。我承认,这很复杂。

除了图像问题之外,我对产品很满意和印象深刻。如果微软更仔细地考虑图像的话…只要。。。

SharePoint中包含的默认wiki根本不支持常见的wiki功能。无法编辑页面的单个部分,也无法直接链接到其他页面上的特定部分。后端是HTML格式的,因此您将无法使用简单语法以明文进行编辑。diff功能不能跨越多个版本。所见即所得编辑的跨浏览器支持不佳。无法自动插入目录…

但是,还有其他一些用于SharePoint的wiki加载项,例如,我不能完全忽略它们。 Confluence 做一个 add-in for Sharepoint . 我自己还没有评估过这个软件,Confluence有点贵(25个用户许可证1200美元),不过如果你已经在SharePoint上,我会感觉到大公司的保险箱:p.似乎还有一些免费的加载项,比如 CKS Enhanced Wiki 但这似乎有很多和上面提到的相同的问题。

我们碰到这个话题 全部的 我问人们的第一个问题是“为什么你需要一个wiki”?几乎所有的答案都是“易于编辑”、“多个贡献者”和“重磅新闻”。 非常 很少有人问我认为是什么独特的类似wiki的功能(特殊的“魔力”标记、显示更改的细粒度版本历史记录等)。此外,他们通常希望对事物进行某种分类,而不仅仅是完全自由的页面。

在SharePoint的世界里,如果你已经用这个工具工作了一段时间,这些东西应该会对你大喊大叫。对于这些知识库风格的应用程序,基本上没有特别的理由使用wiki,特别是“易于编辑”通常与为大多数用户学习特殊标记语言的想法直接冲突。通过其中的几个富文本列,您就可以完成设置了。如果你真的不喜欢内置的富文本编辑器(是的,图片上传过程很繁琐,在火狐中也不管用),让你的组织中的某个人放下8个便雅悯,去获取 RadEditor for SharePoint . 它应该很好地处理这些问题。

一般来说,一旦我们克服了“但它必须是一个维基”的教条,我们就可以很好地接待客户,只使用列表。在某些情况下,我们转向使用Moss的WCM功能,这需要对模板进行更多的预先考虑,但对于内容片段和图像处理等方面也有更好的开箱即用体验。

因为默认实现是 不 一个维基,它是一个 HTML编辑器 .

如果你在使用wiki之前就知道了它的区别。只需看看本页底部的“你的答案”,就可以看到不同之处。在wiki中使用标记,这相对容易阅读和编辑。格式化的HTML完全掩盖了所写内容。

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

我现在正在SharePoint Wiki中编辑一个文档,因为我键入了它,它是迄今为止我遇到过的最差的编辑器。确切地说,我使用SharePoint基金会2010(以前称为WSS),使用IE 9编辑页面。

总结一下我所面临的问题:当你创建wiki内容时,你想把注意力集中在内容上,而wiki引擎应该很容易使用,以至于几乎看不见。与SharePoint不同。我真的很难使用伪所见即所得编辑器,必须解决频繁出现的格式问题。

我估计我在SharePoint上写wiki内容的效率要比在screkturn或wikimedia上低15%,因为我必须处理格式问题。 如果我花一天的时间写维基网页,我会损失大约一个小时来解决格式问题。

背景:我在我们公司创建了四个内部维基——第一个是维基媒体,维基百科背后的维基引擎,接下来的两个是螺旋形的,最后一个是SharePoint。在每个wiki中,我写了大约50-100页。

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

另一方面,SharePoint Wiki看起来很圆滑,但是 可怕的 用于编辑。它没有使用带wiki标记的纯文本编辑器,而是有一个wysiwyg编辑器,看起来比其他wiki编辑器复杂得多。但是它有个性,是邪恶的。它经常添加空行或更改文本颜色。当我选择要设置格式的文本,然后转到“标记样式”下拉列表以设置其格式时,有时从下拉列表中选择项目的操作会取消选择所选文本,因此格式适用于随机位置的文本。插入从Word中复制的文本有时会导致编辑器在页面上其他位置段落之间的空行上翻倍或三倍。除了编写HTML之外,似乎没有一种简单的创建表的方法。

然而,编辑最大的问题是,你不容易看到幕后发生的事情,所以很难解决。是的,编辑网页的HTML是可能的,但这确实破坏了wiki的目的。

作为一个用户,我的总体印象是,这是一个由一个暑期实习生编写的alpha级代码。我知道基金会是免费版本,所以也许我得到了我们所付出的,但我不能相信一个专业的软件公司推出这个产品。

对于一个由6个人组成的小组,他们将“时不时”进行编辑,内置的wiki将会很好。

SharePointwiki本质上是一个静态HTML页面的列表,唯一的wiki功能是[[文章]]链接。没有模板,没有类别,什么都没有。

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

别忘了社区工具包 Sharepoint - Enhanced Wiki Edition . 这为开箱即用版本添加了一些功能。

在咆哮之前,这里是我作为wiki使用SharePoint的总体经验。

这是一个执行得不好的功能,但失败了,因为对当前wiki环境提供的功能缺乏基本的调查。这就是它在编辑器中失败的原因,也是它在标记、历史比较和生成不良的HTML代码等方面遗漏的原因。

你需要跳过它,得到一些能更好地完成工作的东西,并从SharePoint链接到它。

有 生产 有两种产品的经验,我建议您使用ScrewTurn-over SharePoint。

参见编辑RANT历史

我的公司最近推出了SharePoint,我不得不说我的用户体验是 非常糟糕 . 我不仅仅是说我担心使用它:我以开放的心态进入并尝试了它,很多事情都觉得它们没有真正发挥作用。

卢克或多或少提到的原因掩盖了这一点。

你为什么不考虑用其他的 Screwturn Wiki 哪一个 Jeff donated 不久前?我自己还没有使用screwturn,但它是免费和开源的,可能是一个更快、更轻的解决方案,满足您的需要。

几个月前,我们在一个部门wiki上查看了SharePoint。尽管我们主要是一家女士用品店,但我们还是 DokuWiki . 开放源码,所以易于保持最新,伟大的插件,和一个基于文件的后端。

我也会调整OOB wiki的评级,以及它在技术层面上缺乏作者的功能。

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

虽然我希望sp wiki有更多“类似wiki”的功能——当您的首席信息官在公司wiki中添加条目时,您可以获得某种无法描述的满足感——或者,您会被一群发现新wiki“革命性”的行政助理所认可。

简而言之,美国技术专业人士对内置功能的看法可能不太满意,但对于技术上幼稚的人来说,它很容易接受培训,并且可以让他们接触到他们可能听说过但从未(在此之前)理解或想象过使用的技术。

我玩得很简单 SharePoint Wiki Plus . 它是第三方扩展,用于向SharePoint Wiki添加功能。对于真正的wiki用户,您可能需要的不仅仅是SharePoint提供的wiki——通过扩展或专用的wiki产品。

也许试试 http://wordtosharepoint.codeplex.com/ 是否将Word内容迁移到SharePoint?它负责链接图像和大多数其他东西。

螺丝刀真是太棒了-而且是C/.NET。

SharePoint2010应该有更好的wiki功能,而且总是有SharePoint的社区工具包。 如果您能够将SharePoint Wiki留在后面-您可以随时访问 http://www.wikimatrix.org 找到适合你的wiki。

我完全同意上述观点(Keng)。不管SharePoint中有什么东西(目前正在使用2010年),从长远来看,它不是一个wiki。

我正在实现一个自动化的文档解决方案,从源代码和XML配置文件中提取配置和其他信息(如Perldoc标记)。它将信息插入到一组dokuwiki页面中,并带有格式化标记(包括表)。它的格式非常完美,可以与几十行Perl一起使用,包括到手动编辑的静态文档页的内部链接,以及对名称空间的支持,这样我就可以合理地组织信息。我无法在SharePoint中做到这一点(叹息-公司指导)

我能做的最好的事情就是让dokuwiki模板类似于SharePoint网站(保持外观和感觉相似),并且链接到SharePoint之外。: