好的,我看过一些帖子提到了一些关于不使用SP wiki的帖子,因为它们很糟糕.
由于我们正在考虑在 SP 中执行我们的wiki ,因此我需要知道为什么我们不应该为6个自动化开发人员执行此操作来记录各种自动化流程中的步骤以及必须不时进行的更改.
以下是我遇到的一些警告,如果您使用除Sharepoint之外的维基,它将会消失.
Sharepoint让你可以创建大量单独的wiki,但我建议你拥有一个大wiki.我的公司为每个项目/功能制作了一堆小wiki,但只有管理员可以创建单独的wiki,所以如果我想写一些不符合预定义类别的东西,我必须找到一个经理先创建wiki.
其次,如果您使用Sharepoint,请确保您的员工中的每个人都只使用IE,因为Firefox不支持WYSIWIG编辑器.这是一个很好的大多数维基的事情,但让在Sharepoint协作困难.想象一下,整天在一个小小的盒子里编辑自动生成的HTML.
第三,尝试在wiki中编写项目文档,并抵制将Word文档上传到Sharepoint库的诱惑.写两次所有文档并观察事物变得越来越不同步毫无意义.
最后,Sharepoint wiki中的图像支持非常糟糕.您必须将文件添加到某个文档库并输入URL.我的图像永远被删除了,因为它们在上下文中似乎没有多大意义.
我对微软的Sharepoint Wiki有更积极的看法.在很多方面它让我想起了FrontPage 98--这是一个不公平的恶意产品.
关于使用列表的评论是错误的.Sharepoint Wikis ARE Sharepoint列表,其中每个页面都是带有HTML附件的列表项.
确实,你无法链接到一个页面,但如果页面很短,我不认为这是一个问题.SP Wiki使得短页很容易.
如果愿意,您可以从access 2008操作Wiki属性,并且可以根据需要向Wiki列表项添加属性.例如 - 你想要类别吗？只需通过编辑列表即可添加它们.想要具体的看法？列表项.也创建它们.
微软在Sharepoint列表上建立他们的Wiki框架的方式真的很天才 - 这是无可挑剔的.
famerchris提到了Sharepoint Wiki的真正缺点.图像管理的方法非常糟糕.这是一个严重的问题,你应该仅仅因为这个原因考虑其他的Wiki.
我使用了一个复杂的解决方法.它利用了与Windows Live Writer集成的卓越的Sharepoint支持和图像编辑功能.
创建一个SP博客,其中包含将在Wiki中引用的图像.
使用Windows Live Writer发布到wiki-image-blog.将图像放入WLW,根据需要调整大小等.如果您愿意,也可以使用WLW编写与wiki文本初稿相关的图像.
发布到Wiki后,将图像和文本复制并粘贴到Wiki编辑器富文本字段中.
这花费了惊人的时间,远远低于我读过的任何其他选项.我承认,这是令人费解的.
除了图像问题,我很高兴和对产品印象深刻.如果只有微软认为图像更难......如果只是......
Sharepoint附带的默认wiki根本不支持常见的wiki功能.无法编辑页面的单个部分,也无法直接链接到另一个页面上的特定部分.后端是HTML格式,因此您无法使用简单的语法以纯文本进行编辑.diff功能不能跨越多个版本.WYSIWYG编辑的跨浏览器支持不佳.无法自动插入目录...
但是,Sharepoint还有其他wiki插件,我不能断然拒绝,例如Confluence 为Sharepoint创建了一个插件.我自己没有评估这个软件,Confluence有点贵(25个用户许可证为1,200美元),但如果你已经在Sharepoint我感觉大公司的金库:P.似乎还有一些免费的插件,如CKS Enhanced Wiki,但似乎有很多相同的问题.
我们碰上这个话题所有的时间,第一个问题我已经采取措施来问的人是"你为什么需要一个wiki"？几乎总是答案是"易于编辑","多个贡献者"和"Word是重量级"的事情. 非常很少有我们见过有人问什么,我认为是唯一的wiki样特征(特殊的"神奇"的标记,细粒度的版本历史记录显示的变化等).此外,他们通常需要某种事物的分类,而不仅仅是完全自由形式的页面.
在SharePoint世界中,如果您已经使用该工具一段时间,这些内容应该尖叫"列出"给您.基本上没有特别的理由将wiki用于这些知识库样式的应用程序,特别是因为"易于编辑"通常直接与为大多数用户学习特殊标记语言的想法相冲突.通过那里的几个富文本列,你们都已经完成了.如果你真的不喜欢内置的富文本编辑器(是的,图像上传过程很笨,而且在Firefox中不起作用),请让组织中的某个人放弃8 Benjamins并获取RadEditor for SharePoint.它几乎应该处理这些问题.
一般来说,一旦我们已经克服了"但它需要成为一个维基"的教条,我们就可以很好地接受使用列表的客户接收.在某些情况下,如果需要更多的页面模板工具,我们转向使用MOSS的WCM功能,这需要更多关于模板的前期思考,但也有更好的开箱即用体验内容片段和图像处理.
因为默认实现不是 wiki,所以它是HTML编辑器.
如果您在知道差异之前使用过维基.只需查看本页底部的"您的答案"即可看到差异.您在Wiki中使用标记,这相对容易阅读和编辑.格式化的HTML完全掩盖了所写的内容.
作为维基内容创建者和超级用户,我的两分钱,而不是管理员或开发者:
我正在编辑Sharepoint Wiki中的文档,因为我输入了这个,这是迄今为止我遇到的最糟糕的编辑器.确切地说,我使用的是Sharepoint Foundation 2010(以前称为WSS),使用IE 9编辑页面.
总结我遇到的问题:在创建维基内容时,你要专注于内容,维基引擎应该很容易使用,几乎看不见.使用Sharepoint并非如此.我真的很难与伪WYSIWYG编辑器,不得不修复频繁的格式化问题.
我估计,使用Sharepoint编写wiki内容的效率比使用ScrewTurn或维基媒体时低15%,因为我必须处理格式化问题. 如果我花一天时间编写维基页面,我会在一小时内尝试修复格式问题.
为了背景:我在我们公司创建了四个内部维基 - 维基媒体中的第一个,维基百科背后的维基引擎,下一个在ScrewTurn中,以及最后一个在Sharepoint中.在每个维基中,我写了大约50-100页.
在ScrewTurn和Wikimedia中,编辑器看起来相当原始 - 纯文本编辑器使用简单的wiki标记代码进行格式化.每个按钮都有一排按钮,可以为粗体和斜体格式等简单的事物应用标记代码,并创建链接,因此初学者不需要刻意学习标记代码.虽然编辑看起来很简单,但结果却非常简单,特别是在修复格式问题方面.
另一方面,Sharepoint Wiki看起来很光滑,但编辑很糟糕.它没有使用带有wiki标记的纯文本编辑器,而是拥有一个WYSIWYG编辑器,它看起来比其他wiki编辑器更复杂.然而,它具有个性,一个邪恶的个性.它经常添加空行或更改文本的颜色.当我选择要格式化的文本然后转到标记样式下拉列表进行格式化时,有时从下拉列表中选择项目的行为将取消选择所选文本,以便格式应用于随机位置的文本.插入从Word复制的文本有时会导致编辑器在页面上其他位置的段落之间的空行上加倍或加倍.除了编写HTML之外,似乎没有简单的方法来创建表.
然而,关于编辑器的最大问题是你无法轻易看到幕后发生的事情,因此很难修复它.是的,可以编辑页面的HTML,但这实际上违背了维基的目的.
我作为用户得到的整体印象是,这是一个被夏季实习生打倒的alpha级代码.我知道基金会是免费版本,所以也许我得到了我们付出的代价,但我不相信一家专业的软件公司推出了这款产品.
对于将要进行"时不时"编辑的6人小组,内置维基将会很好.
Sharepoint Wiki本质上是静态HTML页面的列表,唯一的Wiki功能是[[article]]链接.没有模板,没有类别,没有.
我们最终拥有一个单独的MediaWiki,并且只使用Sharepoint wiki来获取不需要太多布局的基于文本的内容.
不要忘记Sharepoint社区工具包- 增强版Wiki.这为开箱即用版本增加了一些功能.
京公网安备 11010802040832号 | 京ICP备19059560号-6 