Javaeye-Wiki 测试有感

引子：wiki（知识库）的目标是实现真正内容结构化，是对松散型内容组织方式（如：论坛、博客、新闻等）的一种有益补充（见“关于JavaEye网站未来发展的思考”）。

 

我的测试页面

 

我的问题：

 

1、“实现内容结构化”设计的合理性；

 

wiki实现内容结构化通常采用两种内容组织方式：树状结构和网状结构（或松散型树形结构）。 目前javaeye-wiki采用的是树状结构。

 

以树形结构来组织结构化信息是一种简单而高效的方式，其特点是：除根单元外，每一个内容单元有且只有一个父类，同时，该内容单元可以有多个子类。这种结构清晰、严谨、简洁，易于理解和把握。但是，树形结构也有一个问题，那就是过于严谨，易流于呆板，不适合组织复杂信息集合，所以，这种内容组织方式往往适用于像“企业产品知识库”这种内容有限且领域比较单一的专业知识体系。相关软件产品的代表作是Atlassian Confluence，从产品的title就能明显地了解到该产品的市场定位：The Enterpries Wiki。

 

而另外一种方式是采用网状结构（或松散型树形结构），其特点是：除根单元外，每一个内容单元至少有一个父类，同时，该内容单元可以有多个子类。这种结构复杂、松散、不利于把握。但是，它也有自己的优点，那就是自由、强大，而最为重要的是，它更接近庞杂的大型知识体系结构化特征，也更善于组织管理复杂信息集合。相关软件产品的代表作是 Mediawiki 。

 

javaeye要“做最棒的软件开发交流社区”，而“软件开发”涉及领域十分宽泛，知识体系相当庞杂，以严谨的树形结构来组织内容，其合理性值得思考。举个简单的例子：假如有个页面，name为“configure-clustering-in-Tomcat ”，标题为“Tomcat集群配置”，那么其space或parent page有几种可能呢？如果你能想到多个相当合理的可能性，那么以严谨的树形结构来组织内容显然是不合理的。同时，系统中很有可能还会出现“配置tomcat集群”、“tomcat的集群配置”等等相似的页面，而组织结构化内容体系的重要原则之一就是避免内容重复，同时，这也是协同写作系统的基本需求之一。

建议：

 

I、采用“网状结构”；

II、制定并推广命名规范和分类规范；

III、用户创建页面过程分两步，先输入标题，然后系统检索，给出“智能提示”，如：系统中已经存在相似的文档---“Tomcat集群配置”，你可以...

VI、强调内容唯一性，取消“名称”（url），保留“标题”；

 

2、“页面卡片”设计的合理性；

 

测试后，我的理解：页面就是一篇文档或文章，卡片是这篇文章的章节。

 

如果我理解的没什么问题，那么在编辑过程中就会有一个非常严重的问题：我无法在一个流程中创建或编辑整个页面，如果运气不好，我可能要经历七八次流程化操作才能达到我的目的，太痛苦了！

 

建议：去掉卡片，采用标准wiki标签，或增加可视化编辑界面功能按钮。

 

*********************************************************************

 

没有看到全部功能和开发计划，所以只能凭自己的测试来评价了，希望能有机会了解一下javaeye-wiki的规划方案。

 

前两年做过一个wiki项目，当时研究了一些常见的开源项目的设计思路，所以也算有一些实践经验。感觉社区wiki的开发设计应该是一种挑战，其难度并不在技术，而是在于设计前必须深入研究结构化内容体系的特性、协作写作系统的特性以及如何经营管理和维护等等问题，因为一个wiki项目成功与否的衡量标准只有两个，一个是条目品质，另一个是知识体系的完整性，也就是全而精！而做到这两点都不容，也正因为如此，除了“wiki-pedia”外，互联网上成功的wiki项目寥寥无几。

 

javaeye社区群体是以专业兴趣为导向的，也聚集了大批社区领袖级别的人物，这就意味着，用户不仅仅可以满足自身爱好需求，更可以通过交流提升自身的职场竞争力，所以社区用户很爽很忠诚，像我，连续三年穿着潜水服来，后背都闷出了脚气，仍乐此不疲。也许正因为这种粘性，javaeye-wiki才最有希望成为一个成功的wiki项目。当然，这需要优秀的发展策略和有力的执行。我认为在前期规划中应考虑制定用于提升用户参与热情的策略以及提高文档品质的策略，同时，也应该考虑盈利方面的问题，以利于网站发展的良性循环。

 

 

 

我觉得意见提的很好！我们会认真考虑和改进。

其实知识库的功能开发很早就做好了，但是一直没有正式发布，其中一个比较重要的原因就是，我们还在寻找对知识库的感觉，在没有找到感觉之前，不会贸然推出这个频道。另外即使推出，功能的完善也需要很长时间，比方说JavaEye的新闻频道也是上线以后反复修改和调整了半年左右才达到比较满意的程度。

谢谢你的宝贵意见，下面是部分答复，有一些问题我们还没有想好怎么处理，可能要随着整个知识库的内容建设不断改进了。

1. 内容组织方式：树状结构 和 网状结构
正如你所说，JavaEye Wiki目前的设计是树状结构，而且也从Confluence参考了很多元素，比如空间和页面(space/page)，而卡片(card)是参考Wagn的设计。将来JavaEye Wiki内容主体将会是软件文档和专题文集，目的是能够帮助用户掌握某个具体领域的知识，对于解决遇到的问题提供帮助，我们觉得用户会比较适应以传统书籍的目录方式进行阅读，所以采用了树状结构进行构建。
我们会采用自动的全文检索来显示相关页面在右边的这一块，这样能够弥补树状结构的部分缺点，目前这块功能还没有在测试环境上展现。

2. 制定并推广命名规范和分类规范
其他用户也有过这个建议，我们会对这个规范进行制定，但是Wiki是很自由的，它只能起到一个引导作用，如何能够让这个规范很好地在各个空间执行，需要空间管理员的支持。

3. “页面卡片”设计的合理性
在一个页面的多个卡片可以视为章节，不过在我们原先的设想中，需要多个卡片的复杂页面是少数的：比方说论坛上的一篇帖子或者一篇专栏里面的文章经过整理变成了Wiki上的一个页面，就不需要多个卡片。只有在创建结构相对复杂的页面，多个卡片才有它的用途。
另外卡片的作用不仅仅在于页面章节的组织，我们还设计有特殊类型的卡片，它的内容是自动生成的：比方说自动抓取相关新闻的卡片，自动显示论坛相关讨论的卡片，能够将其他页面或者卡片内容进行摘要的卡片。通过自动抓取来弥补人工编辑的滞后性等缺点。这一块的功能也只是设想而已，需要进行不断的调整。


这一块我不明白你的意思，能否详细说明一下？

这儿有两篇文章，可供参考

Blog.Wiki和开放式知识社区

 

Wiki Design Principles  中文

 

如果将Javaeye wiki定位在软件文档和专题文集，那么它将失去其最该持守的特性---结构化和系统化的知识库。其实，现在的“精华文章分类”和“专栏推荐”基本上也就是定位在软件文档和专题文集上。我个人的理解，软件文档和专题文集可以作为wiki的有益补充，但不是主体。
另外，全文检索（包括tag）实现的内容关联在性质上和wiki完全不同，它们是随意的、松散的，而非规则性的。甚至我个人的偏见，tag其实是对wiki条目品质不自信的的表现



你说的很对，wiki是很强调开放和自由的，但其实不管是哪个领域，自由和约束或民主和集中都不是绝对的。当然，要使他们轻松自然地体现在系统中，需要更多的智慧投入，这也是wiki系统设计的一个难点。

一篇文章包含多个章节是普遍现象，而不应该是特殊现象，这是我与你的理解差异。

另外，知识库在成长过程中，很可能会有这种现象，比如我准备写篇文章，但不会（或没有能力）一下子准备好所有内容，那么，我会事先先把章节标题以及章节层次关系理清，然后慢慢补充（也可能有一部分希望让别人来补充）。当然，别人也很有可能觉得我设计的章节内容或层次有问题，那么他有可能会改写章节结构，甚至完全推翻。在这种情况下，需要先copy原文和章节内容，然后删除章节，再逐步添加章节，是不是流程很繁琐？现在您应该很清楚，我所指的“整个页面”是包括“卡片”的。

我能大概理解你的动机，你们希望让历史资源（论坛精华等内容）很方便地融入的wiki中，一方面对历史资源有充分的利用，另一方面也可以迅速填充知识库，再有就是避免站点内容模块间产生断层。这些想法本身都没有问题，但使用“卡片”来实现这些目标就有可能产生问题了，为什么这麽说呢？因为“卡片”作为文章“章节”是页面的核心元素之一，应该侧重于表现结构化内容，而非随意内容...暂停！我感觉这么说下去交流效率很低，组织语言越来越困难，换一种方式，我直接说我的理想方案：

第一，一篇文章可以包含多个章节，可以同时编辑，卡片和章节无关；

第二，卡片不作为页面的主体元素，它用来实现内容关联等附属功能；

 

其实说到这儿，我很想明确一下我所理解（或期望）的javaeye-wiki的根本目标：让用户有机会全面系统地学习某个领域（如javascript）甚至整个领域（软件开发）的知识。