我在隔离期间的产品思考
过年从邮轮下来直接被“押”到宾馆隔离，每天一日三餐两检查的规律生活突然有了一种桃花源般的生活。在游轮上每天望着海水发呆，已经有些思绪在脑子里萌芽了，择日不如撞日正好趁着有空把这段时间的思路整理下。
下龙湾的早晨
一、工作能像海水一样顺畅吗？
大洋深处的海，湛蓝一片，随着邮轮驶过，卷起一簇簇白色的泡沫。
壁纸般的海水
坐船旅游有个好处，就是每天不用安排太多，但是当你去参加任何一个活动甚至坐在甲板发呆都精彩无比。对比在日常工作中，不得不在众多上下文中来回切换，效率差异显而易见。
举个例子，当你走到四楼大剧院时，你所做的选择就那么几个：
- 看当前的舞台表演
- 获取下一场表演时间
- 预定付费表演
如果你做了任何一个选择，那么后续的所有动作也都是和这个选择相关的。例如你向工作人员预约了付费的表演，那么你可能会面对：
- 选择表演座位席和酒水
- 支付费用
- 为表演准备好出席服装
而当你在数日后想起了这场表演，你估计会：
- 去领取现场拍摄的照片
- 复核下账单
- 把拍摄的照片发布到社交网络上
- ...
而如果把这一切搬到现有的系统设计中，估计会长成这样：
数据模型
线框示意图
这一切的原因，在于桌面操作系统的沙箱系统设计。
浅析桌面沙箱系统和链接方式
在现在的桌面系统或者浏览器体系下的，为了让上层应用稳定运行，系统需要解决每个应用的存储、数据读写、网络传输、安全验证等问题。而应用的顶层使用入口都是由操作系统定义的，就像这样：
沙箱系统简图
因为安全性的问题，各个应用逻辑上是隔离的，由系统为应用分配沙箱运行环境来解决。苹果做到了高隔离性，而安卓采用了高开放性。不管哪种方式，如果需要进行应用间的通信，系统就会提供在顶层定义好的通信方式，比如：
- 数据文件读写权限
- 应用的互相唤醒
- 超链接
- ...
当我们使用各个应用来进行办公、学习时，所产生的割裂感其实就是由于顶层上下文的来回切换，好用是因为不用来回切换，不好用是因为切换太频繁。为了解决这个问题，越来越多的链接方式产生了：
- 应用的deeplink
- 苹果的3D Touch
- 第三方的类RPA应用，例如Workflow（更名为捷径）
- 锤子的One Step
这种新链接方式的产生，的确带来了一定的便利性，但是本质上还是一种应用方式，让用户增加了更多的学习成本。
在系统层面的思考
如果不能在应用层面解决割裂感的问题，那么回过头来想想系统层面的问题。
- 是否存在一个万能的系统？
- 现在的系统都是如何产生的？
- 系统的问题来自于哪？
回顾下我所能想到的系统，诸如：DOS、Win、MacOS、iOS、Android、ChromeOS等等。这些系统大多是为了解决一些特定问题而产生的：
- DOS为了解决人和计算机基础通信的问题
- Win、MacOS解决了基于文件存储的管理问题
- iOS、Android解决了移动应用管理的问题
- ChromeOS解决了Web应用管理的问题
不同系统产生的背景不同，解决的问题不同，带来的问题自然也就不同。所以，系统必须有边界和背景，边界越窄的系统在解决特定问题时一定更高效。
高效办公所需的系统
假设我们做一个办公专用的系统，足够窄的问题边界能够让我们更加聚焦。回顾下我们的办公场景，每天的工作基本是这样一种模式：
工作模式简图
- 明确工作目标
- 开展工作
- 遇到问题，找到协同的资源
- 进行工作协同
- 工作总结回顾
有趣的是，这和目前主流办公软件都要去开发的三件套是相吻合的：日历、IM和网盘。日历管计划，IM管协同，网盘管工作成果。典型的PDCA。
虽然诸如钉钉、飞书等都做了这三件套，但是本质上还是在应用层面去解决办公问题的。
当我们进行工作时，如果保证尽量不做顶层上下文的切换，那么流畅度一定是最高的。所以，核心问题在于我们的顶层上下文到底是什么？以及在一个工作循环里如何保证各个功能能够流畅的链接在一起？
海水系统设计
我还没想好这个系统的名字，也许以后也不会面世，但是我还是决定把自己的思路完整的复现出来。暂定叫“海水系统”的。
系统的设计背景和趋势
在得力这一年多，我们一直在研究物联网，也深信物联和人工智能的浪潮终将来到。那么在这个背景和趋势下，各个处理单元或者说子系统，更加像是一个完整的生命体。例如一个应用、一个终端设备、一个人，都是在做最简单直接的沟通，而把复杂处理尽量的内聚消化掉。
系统原子单元的定义
依据上述思考，系统的最小单元应该是高内聚，对话式通信的表现形式。
参考之前的这篇文章，场景化服务设计，考虑到自然语言处理的发展，系统的原子单元应该是有一定处理能力，有主题，能对话的单元。
回到上面剧场表演的例子，剧场、演出、演员、船卡等实体就是系统的原子单元，和传统设计不同的是：原子单元不会直接把原子性服务提供给使用者。比如：先去找是哪个剧场，再看这个剧场的表演时间表，再刷船卡预约。如果让用户自己去判断去选择，还是会产生很多上下文的切换。取而代之的，是让原子单元的串联工作由用户动机来触发，简单的通过一张图来理解：
原子单元服务示意图
名词 + 动词 体现了原子单元的服务能力，动词 + 名词 体现了原子单元的调用能力，形容词 体现了原子单元的服务粒度，而副词等体现了原子单元的链接能力。
如何保证原子单元能够解决用户问题
在传统交互中，大家肯定都用过Wizard向导。一个有限步骤的向导在设计不出错的情况下基本上都能解决用户特定的问题。基于这种模式，我为原子单元也设计一个流，一条直线的流来保证用户的特定问题能在这个流上得到解决。
流的设计
所有的流的产生，都由用户的动机发起，比如：“我要和下场秀的主角们一起拍照”。那么整个流的路径是：
（剧场）的表演时间表 -> （下一场表演）的演员表 -> （演员）的拍照预约 -> （预约）的费用支付。
拍照是用户的动机，他不必关心剧场、演员等主题，系统会将动机直接解释为链条的起点，引导用户去发现。这和我们做DUI设计的方法很类似。
如果原子单元变多了怎么办？
一个人一天要做很多事，一年会有365天，系统如何承载这些日积月累的记录？
举个例子：当你看过了N场表演，你需要去查看总花费和明细时，你可能会在信用卡账单里去看交易记录，也可能通过剧场服务来获取你个人账号下的观影记录。
但是在海水系统里，你只需和平时一样，重新向系统表达下你的动机：“过去几天我都看了哪些表演，花了多少钱？”。这个对话，和你之前发出的其他指令一样，并没有任何区别。这句话里唯一隐含的两个要素，一个是时间，一个是剧院这个空间。
解决系统历史记录的问题，在时间上可以用时间线来解决，因为时间是多维空间里恒定的维度；在局部上下文中，可以加入自定义的维度来进行管理，比如上文中剧场这个空间维度。
系统就是这样，易用性和全面性永远是矛盾的，加入的维度越多，使用就会更复杂，因此在自定义维度的加入，要视情况而定。
——
聊完上面的几个要点，整个海水系统如果比较具像化可能就长这个样子：
海水系统示意图
三、结束语
这个系统还有很多没考虑的地方，比如：原子单元的服务谁来构建，载体的鼠标操作体验如何等。但我相信随着这波科技浪潮的到来，现行的系统设计一定有它改进的空间，诸如锤子科技等也给我们做出了一些示范，即便不可行也纯当疫期个人的一些YY吧。至于如何把办公产品融入到这个系统设计中，如果大家耐心看完全文估计也有自己的答案了。
最后，祝武汉、祝全国早点恢复健康，安好。
武汉加油
