【文档协同编辑】 协同编辑引论
来历
协同编辑是什么?顾名思义就是多人的编辑。当然也不是这么简单,还要加上有规律的、有先后的定语修饰。
为什么会有这个东西?我们先从场景分析入手:
对于使用git的程序员来说,以下场景再熟悉不过:从主干fork一个分支修改代码,花了半天修复之后准备合入到主分支,发现主分支已经被B修改了,此时如果历史中已经修改了相同的文件,则会出现冲突。此时需要自动或通过手工合并。
在此过程中,git服务器充当了集中管理的角色,但是冲突一般是在本地解决后再push上去的。如果在解决的时候又有新的合并,可能又要合并,解决冲突,合并。。。尽管这并不太可能在一个好的团队发生。
而对于其他场景,例如产品、运营团队修改产品页面,美工、策划在设计文案图画,会计在对账的时候如果他们足够有经验,可能会使用共享的文档,而不是使用一份文件拷来拷去做修改。
还有一个人的:打开A文档的草稿,长时间不用;重新打开A文档,修改,记为A2保存;此时在A文档的草稿中再改一下,保存,便会出现冲突。
以上种种,都是编辑冲突。而要解决这种问题,就需要协同编辑的技术。当然,协同编辑的门槛从简单到复杂有很多层级,需要的技术能力也不完全相同,但是核心的总是涉及到数据格式、网络编程、页面UI。如果是复杂的文档和超大规模的共享文档,还需要更加苛刻的技术能力要求。但是在目前业界的情况下,普通的场景仅涉及几十个人,极端场景本来在共享文档中就很难出现,属于边界情况,性价比极低,也可以放弃设计。
显然,在网络不发达的20世纪,协同文档是没什么需求的。尽管如此,1989年已经有了微软的Office,协同编辑理论就此出现在论文中。
若干年过去,虽然共享文档软件已经有了很多的应用,但是还没有达到完美。协同编辑功能仅仅是办公软件中小小的一环,自然不会引起人们的太多关注。而在文档软件中,国外的产品是Google Docs/Notion/Adobe,国内有语雀、腾讯文档、钉钉文档、飞书、WPS等等你能想到的大部分的支持在线文档的软件。
尽管如此,协同文档编辑仍然作为一个基础的技术在文档编辑中发挥着作用。而到目前为止,并不是所有的公司都把这个功能做到最好。更多的情况是像有道云笔记一样出了冲突就给出提示,让你自己决定要保留哪些文本(当然在这种场景下是合理的,只是冲突本身经常是由于误操作)。
同时,还有其他一些应用,例如共享的WebIDE,也需要Collaborative Editing的支持。
应用场景
企业内各种形式文档的交互,公共文档(附加权限)的编辑;共享电子表格;
实现的功能:冲突合并;光标回显;撤销与重做;富文本编辑;
草稿冲突解决;WebIDE;各种共享软件,包括图形设计,思维导图;
数据的转换与冲突解决算法
如何实现冲突解决?其实这个是一个产品体验问题,需要我们定义什么是冲突解决。如果两个操作冲突,其实可以按顺序合并,但是需要让人感知到编辑的流程,即你不能看到文档的突变。
数据的转换:协同编辑不仅要处理文本,还有各种附加在文本上的数据和结构,包括各种文件格式,文字排版格式;可能还有矢量图;
解决其他问题
协同编辑可能会遇到网络问题、跨端编辑、数据传输;
冲突解决算法OT是中心式的,服务器压力;而CRDT是去中心化的;
其他软件的领域知识,包括富文档编辑,不同的文档格式和patch的方法;
云存储与本地存储;