ACM通信
实践
既然我们可以同时写作，我们该如何利用这一点呢?
图片来源:Andrij Borys Associates / Shutterstock
现代的文字处理器，如Microsoft word OneDrive、SharePoint和谷歌Docs，允许人们在同一时间处理同一份文档。虽然允许同步写入的系统已经在实验室中演示了一段时间，但直到相对较近的时间，这种系统才可以在商业上广泛使用。例如，谷歌Docs允许人们在随意添加、删除和移动文本时处于文档中的同一位置。谷歌Docs非常受欢迎(例如，谷歌教育应用程序在全球有超过6000万用户，200万企业使用谷歌工作应用程序)，许多人将同步写作功能视为一项巨大的资产。
例如，当我们详细分析参加大学高级项目管理课程的本科生的写作模式时，95%的文件显示同步写作。三个文件只有同时写。9
我们，这篇文章的四位共同作者，经历过多次同时写作带来显著好处的会议。既然我们现在可以同时工作，我们如何利用这种能力来提高工作效率呢?同步写作能做些什么?你什么时候会不想同时写作吗?
为了回答这些问题，我们收集了我们的故事，将它们分组，并注意它们之间的模式。每一个故事都是用其中一个作者的声音讲述的，除了最后一个，它是我们四个人共同写的，因为它反映了我们的写作方式这篇文章。随后，我们注意到我们的故事之间的异同，并以“多元统一”创造了六种模式和两种现象的方案。我们相信这些故事将激励读者以新的、有益的方式工作。
谷歌Docs相对较新，虽然我们的一些故事提到了Docs的使用，但也有一些故事涉及研究原型或早期的商业系统，有些甚至可以追溯到20世纪80年代。在我们进入故事之前，我们首先提供这些系统的特征的简要描述，按创建顺序列出。
我们所提及的系统
IDE，教学设计环境，10是一种通过帮助设计师快速组织和创建材料来创建教学内容的工具。IDE是建立在Notecards超媒体系统之上的。5，6IDE的特色是“卡片”，在文本部分之间有不同类型的链接。虽然IDE最初并不打算作为多人协作系统，但人们很快意识到他们可以在多个作者之间划分工作，并通过同时处理不同的卡片来更快地完成工作。当有人在处理一张卡片时，它被锁定在其他卡片上。虽然这在技术上不是其他工具所具有的那种同步编辑，但将其用于并行同步编辑的故事具有一些有价值的经验教训。
ShrEdit是1990年建立的协作写作工具。7，8共享文档驻留在服务器上，个人可以从同一本地网络上的客户机访问它。该体系结构允许多人同时在同一文档中编写内容。ShrEdit具有“选择锁定”，这意味着可以在一个字符中同时写入另一个字符。
方面是20世纪90年代的商业产品。4像ShrEdit一样，人们可以同时在彼此的一个字符内进行编辑。ShrEdit只支持文本，而Aspects除了支持文本外还支持电子表格、绘图和演示文稿，类似于谷歌应用程序，但运行在本地网络上，而且只适用于macintosh。
中心研讨会是一个商业系统，允许音频和视频会议以及共享一个对象，如文件或演示文稿。可以允许其他人编辑共享对象。
谷歌文档是谷歌从2006年开始提供的一个商业的、多用户的共享文档编辑系统。Docs允许多人同时编辑文档，查看文档的修订历史，并与特定的人或在开放的互联网上广泛共享文档。
同时写作的力量
现在，我们开始讲述同时写作的力量如何显著地提高工作效率的故事。下面的故事分为五类:
- 编写大型文档(故事1-3)
- 为课堂作业写简短的文档(故事4)
- 展示和协作创建会议记录(故事5-6)
- 通过共享文档进行教学(故事7)
- 写这个文档。(8)的故事
故事1:使用谷歌文档构建文档，李嘉图告诉我们。为了对他人有用，软件需要文档化。很多时候，软件需要从头开始重写，因为找不到原始的软件，或者找到后无法理解。不幸的是，许多软件开发人员讨厌编写文档。尽管像我这样的技术写手可以胜任这份工作，但我们这样的人太少了，而且理解一项技术并编写适当文档的过程可能需要数年时间。因此，只记录核心技术。
为了解决这个问题，我开发了一种名为Doc Build-It的文档编制方法。文档构建—这是一个为期一天的活动，一小群工程师聚集在一起，同时编写关于特定技术的文档。Doc Build-It是一种受约束的活动，经过精心设计，使工程师能够以一种对他们来说似乎很自然的方式传授他们的专业知识。
文档构建有三个阶段:准备、合成和编辑。在准备阶段，作者与技术主管会面，以获得要记录的技术的详细概述。然后，作者为最终文档生成一个预期的大纲。大纲是细粒度的，每个主题都有两到三个项目符号，这些项目符号表明主题中应该出现什么内容。
合成阶段是一个为期一天的活动。作者要求技术主管从团队中邀请三到五名关键工程师参加活动。在活动中，作者首先要求工程师对技术进行口头解释，以使他们进入一种教学心态，一种适合文档的心态。然后，作者根据所提供的解释调整预期的大纲。一旦Build-It团队同意了大纲，作者就会邀请工程师对他们认为自己最擅长的主题负责。他们的任务只是抓住在解释阶段所说的话中的意思。然后它们都在同一个文档中同时写入。事实上，他们可以看到对方，因为他们生产的部分，使他们的风格(如细节水平)，交叉参考和双重检查的准确性。
作者鼓励工程师避免关注措辞、拼写、标点符号、语法或结构。他们对这份文件的贡献是他们的知识。相对简单的话题通常需要3个小时，更深入的话题则需要7个小时。
在组成阶段之后，技术作者独自润色文档。因为编辑过程可能引入语义错误，所以作者将编辑过的文档分发给工程团队进行检查。
Build-It方法对生产力产生了巨大的影响。我运行的一个Build-It的成本比传统的文档方法的成本要小一个数量级，估计成本为1900美元，而不是18000美元。其他Build-Its也会产生类似的结果，并具有诸如识别技术中微妙bug之类的辅助好处。这些发现是可能的，因为该事件抓住了对某个主题最了解的人的注意力，他们在创建文档的过程中密切关注软件的设计。
的见解。明确工作阶段，明确了角色，简化了整个过程。技术作者创建了一个大纲;在解释之后，大纲被编辑了。然后专家们尽可能多地写下他们的知识。然后，技术作者对这些知识进行了清理，并对其准确性进行了检查。下面的许多故事都有类似的异步和同步工作的混合。
故事2:丹讲述的使用IDE编写教科书。1988年夏天，我组织了一个由斯坦福大学教育学院的10名研究生组成的团队，帮助编写一本高中代数教科书，以满足有课程设计经验的要求。他们的目标是在不到10周的时间内与团队一起编写完整的教科书。该团队使用IDE编写了此文本。
在10名学生中，有两名担任首席设计师，并创建了最初的大纲，将每一章分配给学生作者创建。为了“写”一个章节，作者必须在IDE中创建一个节点网络，每个节点链接到其他节点，表明链接到的节点是抽象概念、概念细节、细化、实践问题还是依赖关系。
在写作过程中，作者必须确定他们在写材料时需要假设的任何先决条件。例如，关于三角函数的那一章依赖于毕达哥拉斯定理的介绍，这一章是由另一位作者写的。对于这种依赖关系，将创建一个显式的先决条件链接，以表明这个概念(在一个章节中)依赖于另一个章节(通常在前面)中的另一个概念。
然后，生成的网络可以按图走(通过遵循指定类型的链接)，生成一个单一的、线性的、像书一样的输出，包含来自每个节点的图表和文本。
每周一，我们会开会回顾上一周完成的工作。团队讨论并解决了所有主要问题，并澄清了各部分之间的交互。因为每个作者都可以或多或少地独立工作(除非他们必须一起并排编辑一个节点)，所以问题可以相当容易地解决。团队需要解决的最常见问题是关于风格、语气、语言和概念框架的问题。
在每周例会之前，我们会打印出迄今为止所有工作的图表，贴在墙上，让整个小组的人都能看到。这张海报展示了每个团队成员每周所做的工作，以及各部分和各个子部分之间的链接。这张图表不仅有助于发现可能出现的问题，而且还能有力地激励其他团队成员跟上进度。
在任何一个星期，作者都可以独立地并行工作，根据需要编写节点和创建任何子结构。当他们发现新的先决条件时，他们负责根据需要在节点之间创建那些显式链接。当然，其他作者也可以创建新的前提链接到他们的领域。对于交叉链接，作者有时会选择一起同步工作，其中一人充当讨论的抄写员。
八周后，项目完成了——所有章节都有了完整的文本，所有的截面前提问题都得到了解决。打印结果是一本220页的教科书。
的见解。这本书主要是在平行的、单独的作者会议中完成的，在出现问题和需要达成解决方案时，有一些短暂的、关键的同时工作的时刻。这本书花了8周的时间完成，与之形成鲜明对比的是，Build-It需要准备工作、一整天的倾倒材料和几天的清理工作。阿特拉斯,O ' reilly (atlas.oreilly.com)和booksprintts (www.booksprints.net)支持一个类似于这个故事的过程。
这个故事也类似于Boellstorf等人所讲的故事，2其中四位作者详细介绍了他们在谷歌Docs中合著的书的创作过程。它讲述了最初的职责交接和要写的部分。后来，他们利用了同时写作的能力，找到谁在写作，他们在哪里写作，并通过语音或相关的聊天功能发起对话。他们说，这对快速解决问题和鼓励他人都很有用。他们还会报道一个人在打字，另一个人在听写，第三个人紧随其后，做些小的编辑，类似于即将发布的关于会议记录的故事5。
故事3:使用ShrEdit创建一份委员会报告，由Judy讲述。一所重点大学的计算机科学系每隔几年就会进行一次外部评审。来自校外的一个约八人的咨询委员会来校园待几天，听取不同的研究人员在做什么，审查课程，听取招生、安置等方面的统计数据。通常情况下，在两天的报告之后，委员会将计划如何写他们的报告，写他们的部分，然后在接下来的四周异步阅读和评论其他人。
发现ShrEdit在我们自己的工作中很有用后，我们组织了类似于Doc Build-It的东西，但有一些有趣的区别。我们把咨询委员会的人带到一个特别的房间，里面有很多电脑。
我们有一个单独的ShrEdit文档，上面有我写的一个大纲，它反映了两天前提出的主题。所有八个人都开始写他们对话题的反应和评价。委员会成员阅读了其他人的意见，并加入了自己的意见。他们选择写任何他们想写的地方，经常为别人的写作添加内容，偶尔也会进行基于文本的辩论。
委员会工作了一个多小时，所有人都在同时打字。他们起草了一份11页的文件;风格粗糙，但内容丰富。最后，一个委员会成员问道:“清理按钮在哪里?”所有人都笑了。团队的领导者自愿接受这个粗略的草案，并将其变成好的文本，扮演了一个非常像Ricardo在Build-It故事中的角色。领导很感激有这么多的原材料可以在上面建造。这些材料比讨论记录要丰富得多。当他们回家的时候，委员会的所有成员都结束了，除了领导。
的见解。这个故事的有趣之处在于，它的写作不像前两个故事那样分而治之，而是我们可能称之为“蜂群”的写作，因为大量的合著者参与了这个过程，但没有一个结构化的过程。每个人都对每个部分进行了随意的贡献，有时输入的内容与另一个人当前输入的内容非常接近。除了偶尔的笑声，整个房间安静了一个小时，只有按键的轻叩声。
故事4:朱迪讲述的学生们在课堂上使用谷歌文档写作业。在项目管理课程上，我的学生在学期期间以小组的形式做了一个小项目。他们必须提交在正式项目管理实践中常见的各种文档，例如业务案例、范围说明等等。学生被要求使用谷歌Docs，并与我分享他们的最终文件，以便评分。
在他们的允许下，我们分析了三年的文件价值——总共96份。我们检查了他们的协作写作风格和工作模式，并将一些关键特征与最终文档的质量相关联。工作模式是通过一个名为DocuViz的工具揭示的11它显示了修改历史的图片，并按时间切片显示了谁在什么时候写了什么。附图显示了一个组的风格的DocuViz时间轴可视化。学生用不同的颜色表示，条纹的大小表示贡献的长度，不同的切片表示贡献产生的时间。这个团队在接近尾声的时候有很多同时进行的工作。
数字一个团队的DocuViz可视化显示了临近结束的同时进行的工作。
大约95%的文件显示了同时写作的证据，我们将“同时”定义为在最后一个动作后7分钟内的写作活动，而不关闭和打开文件。有人可能会认为这些同时工作的会议是“分而治之”的风格。虽然有近三分之一是这样的，但其中很大一部分是由几个人在同一段，甚至是在表格的同一单元格中编辑的。
的见解。在这个故事中，我们对学生们如何设法创建、编辑和审查他们的作品没有太多的细节。但是，修订历史的痕迹不仅显示了明确的项目管理，即分配人员到各个部分，而且还显示了对他们自己的条目，更重要的是，对其他人的条目的自由编辑。还有大量同时进行的工作。
故事5:使用ShrEdit显示和协作创建会议记录，由Gary讲述。除了使用ShrEdit进行研究，8我用它在研究会议上做记录。在这些会议中，ShrEdit文档在每个人的工作站上共享和打开，我们经常将它投影在房间前面的一个大屏幕上。一个人，通常是我，带头，但每个人都可以编辑。
与会者通常会修复我或其他抄写员在快速打字时造成的打字错误和其他错误(比如纠正某人名字的拼写)。我们经常评论说，这个文件看起来就像吃豆人在记录者后面啃东西一样。分享笔记的观点(无论是从投射的观点还是个人在自己电脑上的观点)有助于保持小组的注意力，并确保正确地捕捉要点。该工具使会议更高效，记录更准确。
通常情况下，会议的抄写员都很忙，他们不容易参与谈话。但是当我们使用ShrEdit时，当主要抄写员发言时，其他人会接管抄写员的角色。这让主要的记录员成为会议的完整贡献者。
在一次与企业赞助商的重要会议上，我们将会议记录投影在一个屏幕上，房间里的每个人都能看到。整个下午的会议有9个议程项目。经过几个小时的讨论和大量的笔记，会议协调员注意到我们只讨论了前两个项目，还有7个项目有待讨论。我们必须继续前进。其中一名提案国说，他不参与其他任何项目，但他对目前的议题有很多话要说。因此，我们其余的人继续开会，而他继续在适当的部分写东西，不让我们看到。他将自己的章节命名为“你还没见过这个”。他花了一个小时写下自己的想法，以便能够参考会议记录的前面部分，而我们其他人则完成了自己的议程。他的时间没有浪费，我们完成了任务。这是一份单独的文件(而不是他的想法从另一份文件的附加内容)，这使得他的附加内容更容易在上下文中阅读。
见解:像故事1-4一样，共享的文档有一个准备好的形式(议程)。之前的三个故事划分了工作，给参与者分配了具体的任务，而在故事5中，一个人是主要抄写员。其他与会者可以默默地并行地增加细节、纠正错误，在这种情况下，当其他与会者继续处理他没有参与的议程项目时，他们可以继续贡献自己的力量。时间没有浪费。
故事6:加里在谷歌文档中协作并远程创建会议记录。ACM SIGCHI执行委员会有持续2-3天的定期会议。议程会提前分发，并在新项目出现时通过电子邮件进行修改。我们使用谷歌Docs来记录会议记录，通过从电子邮件中粘贴议程来添加文档种子。议程经常是在忙碌中调整和修改的。
与前面的故事一样，一个成员被指定为主要抄写员，但我们中的任何一个人都可以在任何时候编辑，当抄写员发言时，其他人会暂时接替他的角色。
有时，一些成员远程参加部分甚至整个会议。我们经常会就议程上的特定项目打电话给远程成员，但他们也会观察会议的其他部分。有些人甚至加入了没有有音频或视频连接的。在这种情况下，谷歌Doc是穷人的一种会议工具。文档中极低的更改率非常适合远程参与者，他们可以在适当的时间切换任务。我们还注意到，非英语母语人士从这种“封闭字幕”形式的会议记录中获益良多。
委员会成员经常在报告中使用PowerPoint幻灯片;这些几乎总是直接粘贴到共享的谷歌文档中。偶尔，其他种类的材料也会被粘贴到文档中，比如与我们正在讨论的内容相关的一些网页材料的链接。
在另一场研究小组的常规会议上，会议记录从未被删除，只是往下推，新的议程和注释出现在顶部。这个存档已经被证明在许多情况下是有用的，人们可以复活一个被遗忘的“表格”项目。
的见解。这个故事与故事5分享了协作记录的功能，但增加了将新兴文档用作低带宽会议和封闭标题的功能。
故事7:通过使用Aspects在同时工作中注意事物进行教学，由Judy讲述。我以前的一个博士生刚刚毕业，现在在另一所大学工作，他计划在即将举行的一次会议上介绍我们的合作成果。我请这位前学生在Aspects的演示工具中准备他的演讲，并与我分享。
在一个我们双方都能在电话中看到演示的环节中，这位前学生进行了不间断的演示，以计时为目的。最后，我给出了关于时间和顺序的一般反馈。我还建议在书中加入他选择的人物以外的其他人物。当他寻找新的图表并在演示文稿中替换它们时，我从接近幻灯片末尾开始对一些幻灯片的格式做了一些小的修改。当那个以前的学生完成替换数字回来时，他说:“哦，我知道你在做什么了。”然后他修改了之前的幻灯片，以适应我所做的更改的风格。我们又讨论了一些措辞上的变化。当我们都对结果感到满意时，他又一次没有打断地做了报告。再经过两个小的修改，我们就完成了。
Gary在使用Centra屏幕共享功能时也有类似的体验。他们浏览演示文稿的草稿，讨论它，并实时进行修改。共同的观点集中在讨论上;同步编辑加快了修改的速度。
的见解。通常需要几个小时或几天来回的工作只花了一个小时。建模我想要的变化类型使以前的学生无需讨论就能“理解”。可能会有反对和讨论，但在这种情况下，他只是复制了我的风格变化，没有任何。
故事8:与谷歌文档一起撰写此文档:我们是如何做到的。在发现我们四个人都有关于同时写作的故事后，Ricardo建议我们用Build-It写一篇关于这个主题的文章。我们都很高兴地同意了，既想写这篇文章，又想体验Build-It。在第一次见面大约一个月后，我们安排了一天进行写作，我们三个人安排在一起，丹远程参与。
在这一天到来之前，我们召开了一个视频会议，讨论了这篇文章的总体框架和我们将使用的故事类型。这些都记录在我们共同编写的谷歌文档中。里卡多根据这次讨论创建了一个初步大纲。当我们在一起的时候，第一个小时我们讨论了想法和方向。最初，我们因为不清楚文章的内容而受到了阻碍。构建——它是为分而治之的策略而设计的，而不是为了我们必须发现我们想说什么的阶段。里卡多提出的大纲并没有抓住我们正在进行的讨论，所以我们放弃了它。
最终，我们决定接下来最好的做法是简单地编写一组故事，作为原始素材。我们可以在别人写字的时候看书。我们经常阅读别人写的东西，然后回去添加或修改我们自己的贡献。当每个人都写完后，我们就会根据上下文阅读它们，然后讨论文章的更好组织方式。
的确，在写细节和阅读彼此故事的过程中，我们发现了一些相似之处和不同点。我们直接在文档中制作了一个工作表，用来比较和对比故事。我们希望这将有助于以合理的方式排列故事，然后支持讨论部分的发展。
在创建这个表格的过程中，我们每个人都意识到我们在故事中遗漏了一些东西。注意到这些突现的相似之处后，我们在自己的记忆中梳理更多的例子。我们将这些聚集的额外点命名为“副现象”。
经过大约6个小时的谈话、写作和谈话，我们都筋疲力尽了，但我们必须决定下一步该怎么做。必须有人先对这些故事进行排序，使它们在风格上更加相似，然后以这个表格为指导编写讨论的草稿。朱迪自愿。
下一个阶段需要有人暂时“拥有”文档，而不需要其他人编辑，因为重新组织和讨论的初稿需要理解整个文档，以便建立适当的连接。朱迪讲完后，她提醒了其他人。但我们不希望所有人都同时编辑。我们首先标记Ricardo(技术作者)执行更细粒度的复制编辑。他试图协调写作的语气和节奏，找出或解决文件中似乎打破流程的特征。
然后我们开了一个视频会议，讨论了几个重要的问题，列出了要做的事情的清单。我们让Judy和Gary先浏览他们的部分，然后让Ricardo和Dan进行编辑或进一步评论。同样，注意谁在掌控局面很重要。
我们还没有讨论我们将如何管理编辑，我们是否只进行修改，并依靠修订历史来撤销我们不同意的内容，使用Docs的“建议”模式(类似于Word的跟踪更改)，还是使用注释来讨论和建议更改。Judy和Ricardo直接做出了改变。然后丹用评论说，例如，“这需要说清楚。”丹后来澄清说，他不想编辑别人的作品。这些例子表明，对于谁有权或有责任更改内容，人们使用文档时会有不同的想法。作为Birnholtz和Ibara1研究发现，修改他人的文字是一种社会行为，其结果与信任和人际关系有关。
作者鼓励工程师避免关注措辞、拼写、标点符号、语法或结构。他们对这份文件的贡献是他们的知识。
这次合作的最后阶段涉及到将谷歌文档放入Word中，以适应本杂志所要求的两列格式。从那时起，编辑工作就完全移交了，明确提到了职责和时间安排。
的见解。与Build-It不同，本文的大纲出现了后这些故事被写下来，分享和讨论。这篇文章还涉及到使用文档作为“保存场所”来保存可能有助于写作的东西(如表格)，或最终被删除的材料。有时候同时分而治之是合适的;有时，当她掌握新文章的组织结构时，必须有一个人负责;有时，为了编辑而进行的连续切换是合适的。我们意识到，我们应该明确地讨论是否只编辑、建议或评论更改。
讨论
在共享文档中同时写入的能力是一项强大的技术进步。然而，文献很少提及利用同步写作的技术进步为用户带来真正利益的社会过程。这些故事试图阐明这一社会过程。
在几乎所有这些故事中，都有人通过构建某种结构来领导工作:IDE中的树，ShrEdit和Docs中的大纲，会议中的议程，Aspects和Centra中的演示文稿草稿。唯一的例外是这篇文章的写作。我们是在写完自己的故事并互相读过对方的故事后讨论的。结构出现。
同时写作有几个好处，包括生产力的提高，对所花时间的更深层次的满足感，以及通过模仿合作者的风格进行的实际训练。在战术层面上，参与者可以快速获得高质量的文档，因为参与者可以看到并模仿其他人在做什么。当人们加入写作时，他们可以查看最近的工作，以便使他们的贡献符合整体愿景。同时处理会议记录的能力除了记录和更正内容外，还有其他好处。每个人都“在同一页上”。
当然，并不是所有的合作都能从同步工作中受益。当有人改变你的写作时，你会感到很敏感。当别人可以看到你的写作过程时(例如，如果你写得很慢或拼写不好)，你就会很敏感。有些人可能会发现，当他们在写作或编辑时，看到别人的编辑会让他们分心。如果你不信任你的同事，同时工作是不合适的，要么因为这是一个竞争的氛围，要么因为他们的专业知识和能力比不上你。在一些竞争文化中，可能会有破坏行为。此外，我们列出的许多同步工作的会议是粗略的工作，而不是最终草案(尽管故事7包含了最终报告的协作重新格式化)。
而且，可能会有技术上的困难，比如编辑战，因为直接编辑，人们看不到什么东西被修改了。此外，如果两个人在同一点上，一个增加一个删除，这可能会非常混乱。而且，要同时写，就必须在网络上，必须依赖服务器连接。此外，如果使用云服务，有些人可能会担心隐私问题。
使用同步写作的模式。当我们研究这些故事时，令人惊讶的是，这些故事的体验并没有更多的多样性，而只是几种不同的写作模式结合在一起。故事集中成两组:四种同时工作的模式和两种伴随异步移交的模式。
前四个故事和写这篇文章的叙述采用了同步的方式分治法策略。在文档创建的某些时候，所有的合著者都是同时编写的。大多数情况下，他们会在文件的不同部分进行写作。
故事5和6雇佣了一个主要的抄写员，第二个或第三个抄写员要么在主要抄写员发言时立即接管，要么做辅助的补充或编辑。我们称之为旋转的抄写员模式。
故事5雇佣了一个分支模式，即当一个人不参与直接的对话时，他们会有效地利用这段时间写更多的东西供其他人稍后阅读。从本质上说，一个人在会议记录中创建了一个新的分支，而其他人则继续进行。这种模式是分治法的变体。
第四种模式在故事3中得到了例证，我们称之为群。在这种模式下，每个人都在文档中撰写自己的部分，阅读其他人的部分，并对其进行评论或更正。没有人被分配到一个区域;他们都对整个文件负责。这也类似于教学故事，“老师”示范“学生”要模仿什么，他们共同完成文档。
第五个模式清理，是一个独唱类型的作品，出现在许多故事中。例如，在我们自己的写作中，有一个大型的同步会议，然后Judy接管，将故事重新组织成集群，并编写代表表格中捕获的讨论的文本。在委员会的报告中，主席承担了清理粗糙文本和综合内容的角色。在《BuildIt》中，Ricardo负责清理文本并协调基调，将粗糙的文本变成优秀的散文。
第六种模式，也经常出现在很多故事中，是传球给队友在这种情况下，不同的作者在一段时间内“负责”重组、事实核查和更简单的编辑。这通常伴随着同时进行的工作。
我们还注意到，同步写作的搭配很重要，但不是必须的。搭配提供了对其他参与者的即时访问，例如澄清、看到人们的表情、表示想要发言等等。然而，许多故事都有来自远程人员的成功贡献，即使没有音频或视频连接。在一种情况下，远程参与者只有看到了进化中的谷歌博士。就某些目的而言，这种程度的参与已经足够了。
附带现象。在我们讨论这些故事之间的异同时，我们注意到一些附带现象——由于作品的创作是同步进行的，因此产生了一些不寻常的行为。
一个附带现象涉及幽默这通常是高强度工作的重要社交组成部分。例如，作为会议纪要的抄写员，加里经常会对与会者的发言打上略带讽刺意味的评论，然后迅速擦掉。例如，如果有人讲得太久，加里就会在说话人的视线之外用大字写上:“现在是吃午饭的时间了吗?”然后迅速擦掉。
当我们审视这些故事时，令人惊讶的是，故事的体验并没有更多的多样性，而是只有几种不同的写作模式。
一个项目管理团队的学生在一个长时间的同步编辑会议中深入讨论他们的客户时，粘贴了一张有趣的图片，上面是一个戴着熊帽的灰熊人，并附上了“这个家伙!”这张照片在文档中出现了大约一分钟，然后被删除了。访问委员会阅读了报告中出现的争论，偶尔会引起笑声。最后，一位委员还幽默地问道:“‘清理’按钮在哪里?”大家的笑声是一种赞赏和宽慰，会议结束了。
我们注意到的第二个附带现象是，能见度具有激励作用。在使用IDE编写教科书时，书中进度的可见表示激励了人们。类似地，当文档是实时的和同时进行的，人们可以看到活动在哪里，并被激励仔细阅读，通过文本聊天或语音对话讨论任何出现的问题。当存在可见的活动时，人们会被迫将注意力集中在正在创建的文档上。一个关注“地震活动”。我们认为，在同步工作期间粘贴搞笑图片的学生是用幽默来激发继续工作的动力。另一个小组的一个学生贴了一张铲子的图片，并写道:“努力吧!”
结论
同时编写是一种非常强大的功能，现在在商业软件中广泛使用。它通常成功地与一些交接写作和一些由一个人负责整合材料和声音的会议混合在一起。但技术本身并不能提高生产率和满意度，而是人。我们在这里提供的是一些故事和评论，是什么使这种写作如此强大。
我们遵循故事的六种写作模式，当同时工作是可能的。团队成员现在需要计划适合手头目标的工作风格(其中一些将包括同步写作)。正如Glushko所概述的3.一些整体的协作将是预先计划的(他称之为分层协作)，由作者共同开发的(他称之为共识协作)，或者是所有人的免费(他称之为开放协作)。每种方法都有其优缺点，因此为手头的任务选择适当的方法非常重要。正如前面提到的，并不是所有的团队和场合都能从中受益;合作和信任是必不可少的。
我们已经提供了一组例子，在这些例子中，我们以非常富有成效的新方式工作，因此令人满意。下一步是分析你每天所处的协作写作情况，并制定出最适合你的方法。可能性非常大。
致谢这项工作的部分由国家科学基金会ACI-1322304拨款和谷歌重点研究奖朱迪和加里奥尔森支持。Tom Boellstorf、Bonnie Nardi和Bob Glushko以及匿名审稿人对早期草稿提供了有益的评论。
参考文献
1.Birnholtz, J.和Ibara, S.跟踪协同写作的变化:编辑、可见性和团队维护。在程序对CSCW的12, 2012, 809 - 818。
2.T. Boellstorff，纳迪，B.皮尔斯，C.泰勒，T.L.《与朋友的文字:在线协作写作》。交互205 (Sept.-Oct。2013), 58 - 61。
3.“跨学科”教科书的协同创作、进化和个性化。在OpenSim 2015会议记录。
4.集团技术。方面:第一个麦金塔同步会议软件，版本1。手册,(1991)。集团技术公司，阿灵顿，弗吉尼亚州。
5.哈拉斯，f.g.，莫兰，t.p.，和特里格，R.H.简而言之，就是记事卡。在计算机系统和图形界面中人为因素的SIGCHI-GI会议记录(1987), 45-52。
6.支持超媒体合作:问题和经验。美国信息科学学会， 3(1989)， 192-199。
7.施莱德:一个共享的电子工作空间。CSMIL技术报告，1992。密歇根大学，安娜堡，密歇根州。
8.奥尔森，j.s.，奥尔森，g.m.，斯托罗斯滕，M.和卡特，M.《群体工作特写:有和没有简单的群体编辑器的群体设计过程的比较》。ACM反式。有关资讯系统11， 4(1993)， 321-348。
9.奥尔森，j.s.，王，D，张，j和奥尔森，通用，现在人们是如何一起写作的。反式。人机交互24， 1(2017)， 1 - 40。
10.罗素，d.m.，伯顿，r.r.，乔丹，d.s.，詹森，A-M。，Rogers, R.A., and Cohen, J.R. Creating instruction with IDE: Tools for instructional designers.智能辅导媒体1， 1(2009)， 3-16。
11.王丹，奥尔森，j.s.，张俊，阮，t，奥尔森，G.M.。在计算机系统中的人为因素会议论文集,(2015), 1865 - 1874。
数字图书馆是由计算机协会出版的。版权所有©2017 ACM, Inc.
没有发现记录