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项目。当然，这需要优秀的发展策略和有力的执行。我认为在前期规划中应考虑制定用于提升用户参与热情的策略以及提高文档品质的策略，同时，也应该考虑盈利方面的问题，以利于网站发展的良性循环。