事件的交互
01 背景
写这篇文章标题的时候，我挺犹豫要不要把“事件”这个字眼带上，因为我不想过早去定义这个词语，本篇文章中的事件，我希望定义为或大或小的每日每月每年发生之事，或琐屑或意义非凡，小到买一根葱，大到一笔生意，这些都是我想要包括的。
最近的设计涉及到了两个领域，一个是现场服务管理（Field Service Management），一个是销售管理（Sales Management）相关的应用，两个领域的共同之处是，里面包含了各种各样的事件，包括一个员工一天的工作，包括一个潜在需要联系的客户机会，同时我发现设计这些事件并没有我想象中那么简单，我广泛看了很多与任务，日程管理相关的应用，发现不同类型的事件，它们的管理方式，标记方式，记录方式都不同，而“事件”这个概念比我想象中更为广泛，只是以不同的概念存在着，因而让我产生了总结这些大小颗粒度的“事件”的想法，希望探讨其中的规律，以备不时之需。
02 事件类别与特点
从典型的事件管理软件中，包括销售管理软件，备忘录，现场服务管理，日历，任务管理，项目管理，我以时间为维度，归类出了几种“事件”的类别。
Fig 1 事件类型对比
1) 事件(Event)
在对比看来，事件是比较小颗粒度的存在，可能是一次会议，也可能是一次午餐。
a) 标记一个事件为完成
Fig 2 标记一个事件为完成
Fig 3 Google Calendar标记事件为完成
如何标记一个事件为完成？什么时候需要标记什么时候不需要? 我们可以看到在google日历里面，上图的左边是一个事件，右边是一个备忘，可以看到左边的事件里面是没有事件完成的标记按钮的，而右边的却有。为什么呢？我可以想到的一个解释就是，对于一个时事件，已经拥有了开始时间和结束时间，系统可能并不需要手动标记就可以知晓这个事件什么时候结束。对于备忘则不然，首先用户定义备忘的时候，由于备忘可能大多是短时间的快速事件，所以可能没有明确结束时间，如果不能手动标记完成，就可能会造成备忘录事件堆积。
b) 是什么让事件成为事件？
Fig 4事件的要素（包含地址，描述，人物）
Fig 5 Google Calendar(左)与IOS Reminder（右）事件要素对比
事件和备忘的区别在哪里？事件一般有着明确的事件地点人物，相关链接，甚至可以在事件中定义备忘提醒，而一旦这些要素定义好了，我们便可能可以将其定义为一个事件。我觉得事件和备忘这两个是相对的概念，一个完整，一个轻量，如果在app里面两个概念都包括了，向用户传递这两个概念的区别，可以帮助他们更好地运用。
2) 任务(Task)
为了更好区分概念，我将task定义为给自己的任务，这个任务是否完成是我可以定义的，比如一次购物任务。
a) 任务的起点与终点
Fig 6 标注任务完成
Fig 7 Asana(左) & Salesmate(右)任务标记
比较容易想到的是用checkbox来标记，事件的完成。但根据事件的重要度不同，也可以有不同的标记方式，比如在图中salesmate，标记的时候需要填写原因，salesmate是用来进行产品销售，联系客户的，所以可能填写原因可以帮助以后回退与追踪同一个客户。
b) 角色与任务
Fig 8 任务中的角色
如果任务中涉及多个角色，任务流可能就不只分配某个角色了，还可能要考虑到，这个任务完成之后，是否要进行多个角色的流转，那么这样对应是否要有后台角色的配置？是否要配置角色的增删查改等权限？这些可能都是可以考虑的。
Fig 9 Jobber角色与任务
3) 工作(Job)
我将工作定义成比任务更加复杂一点的存在，工作可以说是涉及到多个角色的任务，也可能涉及到分配，时间管理等概念。比如大项目里面的某一项工作。
a) 工作会包含任务
Fig 10 工作包含任务
在一些设计中，工作里面会有任务的清单，可以一条一条标记完成，是否要有这个任务的清单，我觉得也是看这个‘工作’是怎么被定义的，如果是比较长时间跨度的工作，可能就需要更小粒度的任务进行追踪。
Fig 11 ServiceM8(左)和Microsoft Planner(右)工作中包含任务
b) 标记工作的方式更多维度
Fig 12 用时间来记录任务
可以用时间来标记工作，但这也取决于，这个时间记录具体用来做什么有何意义？我所了解其中的一个用途是，帮助记录雇员的工作时间，这个时间可以用来统计工资。
Fig 13 GorillaDesk(左)和Jobber(右)用时间标记任务
4) 目标(Goal)
Fig 14 目标的标记进度
目标更多的是指想要达成的里程碑，可以是一个项目的最终目标，，也可以是某个生活中某个喝水的习惯。
a) 重复目标与单目标
在google日历中的目标，被定义成某个可以改变个人行为的目标，比如跑步，喝水等。这样的目标由于跟习惯养成相关，所以是有节奏的，建议重复出现，督促你完成的，被分散成一个个小目标。对应的另一个概念就是一次性的目标，比如某个项目的里程碑。
Fig 15 Google Calendar(左)和Jobber(右)中的重复任务
b) 标注目标的完成
Fig 16 目标标记完成，滑动或者点击
标记目标的完成的交互我觉得是值得去探究的，比如是否允许标记已经过去的目标？是否允许标记未来的任务来完成？过去，现在，未来的目标是否应该有什么关联，来帮助你衡量整体的目标完成程度？现在标记的目标对于未来的目标是否会有什么影响？这种稍微带点时间穿越感的操作，让我想起最近玩的一个rusty lake的密室逃脱游戏？里面有一个场景是把种子种下，然后去冬天场景收获，这样穿越的感觉有些相似。一共有春夏秋冬四个密室，我们猜想钥匙在花里面，但要怎么拿呢？答案是我可以回去春天种种子，然后去冬天的场景，跨越了时间，花也结果了，在那个时候收获钥匙。
Fig 17 Rusty Lake密室逃脱游戏场景
Fig 18 Productive App(左)和Google Calendar(右)标注目标的完成
c) 形成连续的感觉
Fig 19 目标完成的连续感
目标既然是激励而存在的，设计时候有时候要考虑的一个点就是连续感。最好有个月度或者周的可视化记录，便于一览目标完成的情况。
Fig 20 Productive(左)和Google Calendar(右)记录连续的习惯
5) 机会(Opportunity)
机会这个概念在crm软件里面挺常见，是指某个潜在客户或者潜在的某一个商业机会，那么为了达成这个机会，中间需要不懈努力的沟通，所以为了达成一个机会，中间可能会包含无数次的打电话，发邮件，会议，这些可以是事件或者任务。
a) 机会通常有不同的状态
Fig 21 机会与状态
与事件相比，机会包含了很多的不确定性，机会是否成功，是否有进一步沟通的可能，因此记录机会不仅仅是完成与结束，更重要的是记录机会的状态，而这个状态最好跟业务有关联，才能帮助更好的记录。那么让我想到的另外一个考虑点就是，也许不同的业务，对于状态的定义不同，所以一套状态还不一定使用于不同的业务，可能需要提供定制。平衡定制与预先定义的关系，我觉得还是挺重要，定制固然好，但是过多的定制又会带来产品使用的复杂度。
Fig 22 Salesforce App机会与状态
b) 机会包含了各种事件
Fig 23 机会与事件包含
当拥有了一个机会之后，我们需要进行不同的活动去抓住这个机会，打电话，发邮件，安排会面，所以机会中包含了大大小小的事件。可能这是为什么很多机会的详情页面里面，都包含了不同的事件，按照时间线进行记录。
Fig 24 Tubular(左)，Zendesk Sell(中)和Hubspot(右)机会与事件
6) 项目(Project)
项目指的是会长期持续某个时间段的事件。
a) 为什么不直接把项目标记完成
Fig 25 项目的状态标记
在开始与结束的中间，会发生很多事情，例如项目终止，项目搁置，项目超前完成等，所以也许对于机会，项目等时间跨度比较长的类型，都是要包含多个状态。
Fig 26 Asana App项目的不同状态
b) 项目的状态，任务的状态
Fig 27 项目与任务的状态标记
当然状态也不一定是项目，机会专属的，某些app中定义的‘任务’也可以有自己的状态，比如Microsoft Planner，再次想说，设计或者了解竞品的时候，我尝试把对于各种事件的了解，跟它本身的名字剥离出来，来进行思考。Planner中的任务包含了状态，所以我理解。它更偏向于长时间跨度的项目记录。
Fig 28 Microsoft Planner中的状态
03 我的一些感想
1) 或大或小的事件，存在于从小到大的系统中
2) 他们可以互相转化，取决于用户的需要
3) 事件，活动，任务？叫什么不要紧，但需要从用户本身的行为出发来定义事件
04 小结
如果说每天都有在发生的事情，app产生的意义也许就是帮我们去处理或者管控这些事件吧？如果假设今天是一个什么事情都没有发生的日子，天很蓝，冰箱很满，我不需要去购物，不需要联系客户，不需要去跑步，我只想看着天花板，那么也许我就不会需要任何app甚至手机了吧。那么一旦事情发生了，我们便开始打开手机来应对，这个角度看，app又何尝不能定义成，发生着事件化学反应的容器呢？
标题的灵感来源于最近想看的一部英剧，一切伟大而渺小。
原文：https://mp.weixin.qq.com/s/y9g5xKmhn8-2UsgrjabZXQ
既然来了，说些什么？