Group: 忙友沙龙

D I S C U S S I O N
聊聊个人理想中的协作平台

张骋
01/14/2008 21:38 ... 352hits
首先,平台不应该仅仅是一个功能的集合。所谓工具决定方法,不包含方法的一盘散沙的工具集合并不能称为一个良好的平台。其次呢,因为个人原因,比较宅,所以在网上协作的大多是一些和数字内容创作有关的东西,譬如一段CG片段,一款独立游戏等等。所以和很多人常用的安排聚会之类的功能吻合度不高。不过尽管如此,还是按照个人的使用需求坦诚的说说理想中的平台好了

项目-群组-用户的结构

在以往的经验中,在网络上成就一个项目的难度是最大的,而不是组织一个群组。因此把金字塔的最顶端,也就是吧最高目标定位项目是必须的。以群组为单位进行项目参与,这样有利于专业分工的实现……毕竟一般的网络群组都是针对某个特殊兴趣或目标的群体。但是要完成一个项目往往需要数个专业的人才携手才能最终完成(相信大家都不缺少满网络找专业论坛的经历)。一个群组可以支持若干个项目,同时一个群组也可以拆分成若干个更小的小组。单一的用户作为一个独立个体,明确的自身价值定位是在网络协作项目中贡献力量最直接的向导。通过加入群组进而加入项目可以免除很多以往被无谓消耗掉的沟通时间成本。同时在群组中还可以认识很多同道中人。同样如同群组和项目的关系,一个用户也可以加入多个群组。

项目 拥有 任务管理,文档,里程碑,黑板报 和参与群组

群组 拥有 Wiki,讨论版,项目任务 和参与用户

用户 拥有 笔记本,行事历,任务列表,留言板 和友邻

用户层主要提供的是PIM的功能和社会化网络。而群组层则提供一般论坛或更先进一步的交流平台。项目层则是由群组发起的大型或多。其实纵观网络上的各种自发性的项目,大抵也是按照这样的规律支撑起来的。

NameSpace 命名空间 

以前有过一年的 DokuWiki 的使用经验,其方便程度还是令人满意的。FXCarl觉得 namespace 的方式很方便精确的定位文档的位置。而如果能够把 namespace 的功能再进一步就更加有趣了。譬如说给一个文档加入多个 namespace,将会带来更大的自由度,这种体验就好像如今 Vista 等操作系统提供的虚拟文件夹或者说更常见的大家用的媒体播放器的媒体库。譬如说我们有一个讨论会——既可以在 [project:项目名称:meeting:会议分类:会议名称] 这样的地方找到论题,也可以在 [group:群组名称:discuss:讨论分类:会议名称] 中找到这个论题。 

由于 NameSpace 的精确定位特性,文档之间的动态引用关系也能够得以实现。就像<iframe>一样而不再需要为了保持若干文档的部分内容始终一致而反复来回修改。

文档处理工具集 

强大的引用功能是必要的,无论是文字还是表格的单元格。

笔记本这个东西很多产品都有提供,但大多数更像一个富文本编辑器,而不是很随意。作为笔记本,可以往里面塞的东西自然越多越好。而且最好可以是像 Office Onenote 那样可以随意涂鸦的……这一点似乎连很多人说和 OneNote 相似的 EverNote 都没有这么做。或许这样太过于类似白板了?

行事历没有太多好说的,Google的行事历就是最高的代表。自然的,除了事件之外,还有别人给你的行事历事件,以及自己任务的截止日期等。iCal 似乎是个比较完美的行事历工具。TodoList这个待完成任务列表很多PIM都有提供,和任务管理同步,以及可以自己添加项目。不过前文说到过基于 Namespace的动态引用, 最好任务可以和文档的完成度捆绑。

FXCarl觉得留言板和悄悄话应该是一个相同的东西。如果别人觉得这个留言只可以留言板主人可见,则就成为了悄悄话了嘛。而回复留言板的内容会自动反馈到留言用户的留言板上,这和 Gmail 的会话原理是一致的。

友邻的关联模式还用说么,有的话最好,没有的话也无碍,反正是个社会化网络的东西。豆瓣这个东西做的不错。

群组工具上,Wiki将会是关键。因为不仅讨论版的发帖会有回复,每篇Wiki文章也是会有回复和讨论的,也就是说,Wiki页面只是一种特殊的帖子。基于 Wiki的特征,其实Wiki是有可能支持逐片段“迁出”的。在DokuWiki中,用户就可以单独的修改文章的某个段落进而达成多人同步修改。Wiki 也是一个广义概念,因为GoogleDocs的电子表格也是 Wiki 式的,多人可以共同在同一时间维护一张电子表格,甚至连每个人的操作步骤都可以互相看见。

在Wiki的编辑中,用户应该可以和正在同时进行编辑的用户之间交流,这个和 GoogleDocs 是一致的。也是一个很有用的功能。功能足够的 Wiki 页面时足够当一张会议白板来使用的,这在使用 DokuWiki 的时候就有体验(有一款支持涂鸦绘画的Doku插件)。

群组的项目任务将会显示出群组在所有参与项目中所被指派的整体任务列表。如果群组可以确定任务完成的时间,则上层的项目任务结束时间将可以在群组设定完成时间后的任意时间完成。群组的任务可以在群组内被进一步拆分,以及指派到群组成员。指派的任务完成时间则由任务承担人员反馈确定或强制确定。指派的任务会被添加到用户层的任务列表中。当然整个任务分发过程都是透明和可查的。

项目工具是最最高端的工具集合,文档,里程碑,和任务管理的结合是关键所在。

项目中的文档应当不允许进行编辑,而是只能由群组进行编辑和递交。而在项目文档区域,只负责版本控制。项目文档中的每一个文档都具有一定的权限,有权限的群组将会在群组Wiki中发现这个文档。当需要进行文档修改时,群组需要迁出文档的修改权,在群组内确认修改无误后可以迁入项目形成一个新的版本号。(当然如果项目只有一个群组,这个群组只有一个用户的话,是可以很快速的完成确认过程的)迁入后的文档版本经过确定有效之后(根据需要加上“需审核”标签这样子)。便可以对应完成一个任务细项。譬如某某文档的第一版,第二版之类。

里程碑工具可以直接和任务拆分工具整合。即把若干任务作为里程碑标记。同时设定里程碑时间。当任务按期完成则里程碑会自动进行调整和修改,而不再需要人工干预。以行事历的方式提供的里程碑工具固然可以满足一定的要求,但是如果支持甘特图方式,将会更有全局的把握。

黑板报是项目目前情况的一个公告栏。是Wiki形式的。只有项目管理人员才可以修改。用于项目的对外公示。群组列表则是参与项目的群组列表,可以了解到哪些群组参与了这样一个项目。

其他 

贡献度的透明化对于一个网络协作活动来说还是相当重要的……通过文档更新次数和内容数量是较为容易统计出一个参考值的。

同时尽管我们主张大家自由的匹配合作,但是没有好的管理结构,自然不能完成项目,因此这个设计中,一定的组织结构还是有的……可能很多人会不喜欢…… 

乱七八糟的说了不少,感觉自己都没有找到重点。你要是看到这句话,也真算是不容易。话说,很多东西,还是说出来舒服啊。说的差不多的,觉得 mangbar 似乎也不缺什么了。嘿嘿。
Current topic has 2 replies | Back |
#1 西瓜 01/14/2008 22:29
很强!你说的问题, 确实都是我们一直在思考的. 

mangbar群组中的文档是具有一些wiki的特性的.(有没有注意到群组的文档的编辑器和项目的文档的编辑器不同?) 
随意的笔记, 我个人感觉还是mangbar的那个firefox插件不错. 在web中总不够随意. 在随意的另外一面, 就是对随意记下的东西进行方便的整理. 这个也在考虑中.

mangbar现在努力在改善用户体验上下功夫, 不断改进操作的流畅程度.

希望多讨论..

 
#2 张骋 01/15/2008 01:27
mangbar 的 FF 插件提供的功能不是特别管用 …… 

复制网页的内容作为笔记的话,Google NoteBook 更方便一些。新建任务的话,似乎也没什么必要。FXCarl对协作平台的要求还是蛮专业的,一般用途其实也求不到mangbar。

实际上更希望mangbar的工具栏发挥像Groove的LaunchBar那样的作用……会不会违背mangbar的定位了……
Return To Top | Back