存储用于共享访问的项目文档的建议? [英] Recommendations for storing project documents for shared access?

查看:96
本文介绍了存储用于共享访问的项目文档的建议?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我目前正在使用Microsoft Word编写项目所需的各种文件 - 操作概念,要求,测试计划等。这些文档放在网络共享上供他人查看。如果有人想要编辑文档,他们必须将这个事实传达给任何可能修改它的人。偶尔,我保存一个副本,并将日期作为粗略的备份和版本控制系统放在文件名中。



我想要一个更好的方法来创建和维护这些文档!一些所需功能:


  1. 轻松访问其他人。

  2. 协作编辑。 >
  3. 版本控制,历史记录,回滚功能。

  4. 易于使用,特别所见即所得编辑。

  5. 格式化格式功能,例如插入图像或以其他方式制作梦幻般的文档的能力,

  6. 在合同义务需要时,轻松创建印刷版。

  7. 轻松同时创建/编辑文档的多个部分。

  8. 搜索

我有尝试使用Subversion和TortoiseSVN获得对这些Word文档的版本控制,但是许多用户发现Subversion(和版本控制)尴尬学习和抵制这种方法。



维基



我正在考虑使用维基,但我有疑虑。需要完全所见即所得的编辑才能获得其他作者的支持,并且能够产生可交付成果(理想地是每个文档的专业看起来很好的副本)是必须具备的。



我怀疑那里有比我使用的更好的维基,但不知道他们是否够强大。也许我正在讨论这个问题,错误的方法和一些其他工具或技术更好?



所以,两部分问题:


  1. 什么类型的工具最适合我的需要?

  2. 你会推荐什么具体的工具? li>

更新:我想感谢所有对此问题做出贡献的人。花了我一段时间才能完成所有的建议,我学到了很多。现在,我将继续像往常一样。



Aaron对MoinMoin的建议引导了我对维基软件的长期评估,最终缩小到MoinMoin,DokuWiki,和MediaWiki。只有MoinMoin支持我认为可以使用的WYSIWYG编辑器 - 另外两个有我发现尴尬的插件选项。



我的评价让我终于放松了WYSIWYG的要求。这是更好的现在。



我完全同意那些说你想要的文件生活的人。但是,我也不能给客户的CD的CD。我会继续研究其他选项。

解决方案

我发现Word最常用于WORN文档(写一次,从不读)



让我们面对它:Word文档只是一大堆文字,搜索可怜,除了部分之外,还有很少的结构,你没有版本历史。浏览器有一个历史,Word不会:你不能回到你刚刚的地方。虽然它有一个UI(我不想说不错),而最近的版本崩溃的频率更低,这个问题仍然是你想要实现的?为垃圾填埋场创造一个文字的沙漠?或者你想创建一个生活文件,其中可以跟踪所有的更改,任何人都可以修复错误或发表评论,图像保留在哪里,而没有傻瓜可以毁掉你的工作(和那个傻瓜不必在你的公司工作)。此外,您不需要任何特殊的软件来帮助。来自内部网任何地方的任何网络浏览器都会做(请注意这个 Firefox中的错误 ,但是)。



所以从我过去的经验来看,我推荐一个维基。它们使用简单,学习简单,甚至可以扩展它们(例如,如果需要图形)。我已经使用了MoinMoin和MediaWiki的目的。



我喜欢MoinMoin更多:




  • 更快

  • 使用起来更容易

  • 设置起来更简单

  • 使用WYSIWYG编辑器(但请务必尝试最新版本)

  • 您可以通过将页面数据保存在Subversion存储库中,通过MoinMoin创建分布式wiki。合并有点棘手(您需要重新命名文件或手动合并并添加最终结果作为新版本)

  • 扩展MoinMoin(如果没有一个500+插件适用于您)很简单



维基的主要问题不在于他们没有完成任务,而是让人们皱眉。他们习惯了Word:如果你只知道一把锤子,你会把所有东西都当作钉子。但是,当你轻轻地介绍他们并设定一些坚定的规则(所以他们不会感到浮动在空白中),他们很快就会爱上维基做什么。



如果你真的需要,你甚至可以保存Word文档(或其他任何东西,不像Word)。



现在为了您的关注:




  • 打印:维基不打算打印。期。那会违背他们的目的。所以解决方案是将wiki转储到CD上(作为完全链接的HTML或作为一个完整的wiki),并将其交给客户。虽然维基的UI与Word不符,但是,简单的说是更好的这个案例。此外,每个人都知道如何使用浏览器,所以没有必要的培训使用维基,所有酷的功能的在线帮助只需点击一下。

  • 格式化选项在Word中,您必须自己格式化一切。在Wiki中,您可以定义一个解析器(例如代码块),为您进行格式化。这里的关键是要明白,使用UI中的粗体/斜体/字体名称按钮实际上是一件坏事。您使用的字体越多,您的文档看起来越混乱。专业文字处理软件将始终限制模板中可用的格式化选项的数量,原因如下:编写文本的人不知道什么样子。



PS:确保您的用户了解维基通过关键字而不是文件夹。在我的最后一份工作中,我一天早上回来,发现有人将所有的页面,如项目/事物/关键字重新命名为给他们结构。是的,所有链接被破坏:(



如果所有其他的失败,你应该能够以某种方式导出维基对于MoinMoin,这应该有助于: href =http://moinmo.in/4ct10n/show/ActionMarket/PdfAction =nofollow noreferrer> http://moinmo.in/4ct10n/show/ActionMarket/PdfAction (文档为非常令人困惑,但是)


I am currently using Microsoft Word to write the various documents required for a project - concept of operations, requirements, test plans, etc. These documents are placed on a network share for others to view. If someone wants to edit the document, they must communicate this fact somehow to anyone else who is likely to be modifying it. Occasionally, I save off a copy and put the date in the file name as a crude backup and versioning system.

I want a better way to create and maintain these documents! Some desired features:

  1. Easy for others to access documentation.
  2. Collaborative editing.
  3. Version control, history, rollback capabilities.
  4. Easy-to-use, particular WYSIWYG editing.
  5. Great formatting capabilities, such as the ability to insert images and otherwise produce fantastic looking documentation,
  6. Easy to create printed version for when contractual obligations require it.
  7. Easy to simultaneously create/edit multiple parts of a document.
  8. Searching.

I have tried using Subversion and TortoiseSVN to gain version control over these Word documents, but many users find Subversion (and version control) awkward to learn and resist this method.

Wikis

I am considering the use of a wiki, but I have concerns. It would need full WYSIWYG editing to gain the support of other authors, and the ability to produce a deliverable (ideally a professional looking hard copy of each document) is a must have requirement.

I suspect that there are some better wikis out there than the ones I have used, but do not know if they are powerful enough. Maybe I am going about this problem the wrong way and some other tool or technique is better?

So, the two part question:

  1. What types of tool(s) are most appropriate for my needs?
  2. What specific tool(s) would you recommend?

UPDATE: I want to thank everyone who contributed to this question. It took me quite a while to get through all the suggestions and I learned a lot. For now, I will continue business as usual.

Aaron's suggestion to look at MoinMoin led me into a long evaluation of wiki software which I eventually narrowed down to MoinMoin, DokuWiki, and MediaWiki. Only MoinMoin supports what I considered a usable WYSIWYG editor--the other two had plug-in options that I found awkward.

My evaluation led me to eventually relax the WYSIWYG requirement. It is more of a nice-to-have now.

I completely agree with those who say you want the documentation to be living. However, I also cannot give a CD of the wiki to customers either. I will continue looking into other options.

解决方案

I found that Word is most often used for WORN documentation (write once, read never).

Let's face it: Word documents are just a big jumble of text, searching is pitiful, there is little structure besides sections and you have no version history. Browsers have a history, Word doesn't: You can't go back to where you just were. While it has a UI (I'd rather not say "nice") and the recent versions crash much less often, the question remains what you want to achieve? Create a desert of words for the landfill? Or do you want to create a living documentation where all changes can be tracked, where anyone can fix mistakes or make comments, where images stay where they are put, and where no fool can ruin your work (and that fool doesn't have to work at your company). Plus you don't need any special software to help. Any web browser from anywhere in the intranet will do (mind this bug in Firefox, though).

So from my experience in the past, I recommend a wiki. They are simple to use, simple to learn and you can even extend them (if you need graphs, for example). I've used both MoinMoin and MediaWiki for the purpose.

I like MoinMoin more:

  • It's faster
  • It's easier to use
  • It's way easier to setup
  • It comes with a WYSIWYG editor (but be sure to try the latest version)
  • You can create a distributed wiki with MoinMoin by saving the page data in a subversion repository. Merging is a bit tricky (you either need to rename files or merge manually and add the final result as a new version)
  • Extending MoinMoin (if none of the 500+ plugins works for you) is very easy

The main issue with Wikis is not that they don't get the job done but that people frown upon it. They are used to Word: If you only know a hammer, you try to treat everything as a nail. But when you gently introduce them and set some firm rules (so they won't feel floating in the void), they will quickly come to love what wikis can do.

And if you really have to, you can even save Word documents in it (or anything else, unlike Word).

Now for your concerns:

  • Printing: Wiki's are not meant to be printed. Period. That would defy their very purpose. So the solution is to dump the wiki on a CD (either as fully linked HTML or as a fully working wiki) and hand that to the customer. 100% power at no extra cost.
  • UI While the "UI" of Wikis is not at par with Word, I'd say that simple is better in this case. Also, everyone knows how to use a browser, so there is no training necessary to use the wiki and the online help for all the cool features is just one click away.
  • Formatting options In Word, you have to format everything yourself. In a Wiki, you can define a parser (for example for code blocks) which does the formatting for you. The key here is to understand that having to use the bold/italic/font-name buttons in the UI is actually a bad thing. The more different fonts you use, the more confusing your document looks. Professional word processing software will always limit the number of available formatting options in the template for this very reason: People that write text just don't know what looks good.

PS: Make sure your users understand that wikis work by keyword, not by folder. In my last job, I came back one morning to find that someone had renamed all pages like "project/something/keyword" to "give them structure". Yeah, all links were broken :(

[EDIT] If all else fails, you should be able to export the wiki somehow. For MoinMoin, this should help: http://moinmo.in/4ct10n/show/ActionMarket/PdfAction (the docs are very confusing, though).

这篇关于存储用于共享访问的项目文档的建议?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆