微信会话功能调研
简书上有很多从产品或使用体验角度分析APP的文章，很少有分享产品细节的东西。
正巧现在的项目要做私信、群聊的功能，把微信的会话、群聊仔细的研究了一下。
设想自己接到这个需求，如何一步步完成功能的设计。用这种带入的方式，拆解微信会话功能。
1、根据需求确认方案目标，明确边界限制
会话定义：两名微信好友通过会话完成即时信息交流。
边界：会话必须是好友关系、限定两人，信息交流的形式包括文字、语音等。
方案确认过程中，获得方案设计的必要信息。
比如添加好友后才能发起会话，不允许陌生人私信；超出两人的处理方式——会话转为群聊；最初版本可能只允许文字、语音交流，但要考虑为后续迭代的其他形式（表情、图片...）留下入口等。
2、描述用户使用流程，提取主要页面、功能入口等信息
用户使用流程，
· 当两个人首次添加为好友，在 首页消息列表 中自动生成两人的会话
· 在 首页消息列表 中展示会话简介，点击进入会话页面
· 在【通讯录】选择已添加好友——进入好友资料——点击【发消息】——进入会话页面
· 在 会话页面 查看会话记录，发送消息
主要页面、功能入口，
· 会话列表：提示会话主要信息，消息列表中展示，点击进入会话页面；添加为好友后自动生成
· 会话页面：支持文字、语音等多种信息交流，展示会话内容和历史记录
· 通讯录好友详情页增加【发消息】按钮，点击进入会话页面
3、页面布局、交互设计
设计思路：明确页面任务，多任务划分区域完成；任务过大时分成小任务，直到分解为最小的元素。
————————————————
会话列表
任务：会话详情入口、展示会话好友信息、提示未读、会话预览
确认页面元素：好友【头像】【昵称】、【未读icon】、最后会话内容【时间】、【状态提示icon】。
组织元素布局，细节设计（考虑用户的使用情境，各元素在极限情况下的处理方式）：
· 好友【昵称】长度限制，超长省略为“...”
· 【未读icon】显示未读信息数目
· 【时间】显示规则：当天只显示时间，如“09:00”；昨天发送显示文本“昨天”；本周内显示“星期X”；超出本周或跨月显示年月日“15/3/20”
“星期X”不是按照自然周（比如每周日为节点）计算的，而是当日前推7天。比如今天是星期一，上周二的消息显示“星期二”；到本周三后，上周二的消息显示为年月日。
年月日显示为了节省空间，进行了缩写。
· 会话在列表中显示规则：最新消息排列在最上方
· 会话列表提供的快捷操作：【标记为已读/未读】、【删除】
不同使用情景下功能处理方式：
列表提示有多条未读消息，【标记为已读】后，未读icon和条数消失；再次【标记为未读】，只会显示未读icon，不显示条数。
【删除】后，会话在列表中消失；再次会话后，删除操作的用户无法看到之前的记录，未删除的用户仍然可以看到之前的记录。
这些处理方式应该是技术和体验协调的结果（以下仅仅是个人推论）：
· 会话消息统一记录，根据用户状态分别标注，展示对应信息；
· 用户阅读后对消息进行标记，未读消息是标记点后产生的新内容，方便计数、定位；
· 用户打开会话或操作【标记为已读】后，清空记录中未读标记节点。
用户【标记为未读】后，想找回之前的节点代价过大。
再者，【标记为已读】后再次【标记为未读】，用户应该只是想提醒一下，不太需要再提示详细的数目。
【删除】、【清空历史记录】，对当前节点之前内容标记隐藏。操作【删除】的用户查看会话时，只展示删除以后的内容。未作删除的用户，没有删除节点，会话完整展示。
列表中【删除】会话，我理解的用户期望是：不希望看到或被别人看到这条消息了（查水表、猫腻、鱼腥...），清除历史记录顺理成章；或者，仅仅是不想会话占据屏幕位置，对历史记录无所谓；既【删除】又想保留记录的可能性不高。
综合考虑，采用现有方案。
在新功能开发时，对受影响元素进行相应调整。
（比如会话设置为【免打扰模式】后：【未读icon】不显示条数，转移到在会话内容前提示数目，同时加入免打扰状态icon。）
左：正常会话；右：免打扰模式会话
————————————————
会话详情页
任务：页面跳转、信息发送、会话内容时间展示、信息记录查看、设置入口
任务较多，划分区域：
标题栏——页面跳转、当前页面提示、会话设置入口
主界面——消息内容、时间、发送人展示，系统提示
信息输入区域——信息输入、发送
功能逻辑、交互设计：
1）标题栏
包含元素：返回按钮、标题好友昵称、会话设置按钮
返回按钮的设定，要结合当前页面在产品架构中的层级、入口等因素考虑：
任何入口进入会话详情页，点击返回按钮跳转到消息列表。
手Q采用了同样的设定，而手Q国际版的设定是【从哪里来回哪里去】。
（比如，同样是从通讯录好友详情页点击“发消息”，微信、手Q返回消息列表，手Q国际版返回好友详情页。）
微信作为层级结构相对简单的产品，很适合现在的处理方式；
手Q国际版的处理方式，更适合浏览式任务为主的产品。
参考阅读：知乎：怎样理解信息架构？—尤文文的回答
2）信息输入、发送
· 确认发送消息类别：文本、语音、表情、图片等...
· 不同类别信息输入的入口、发送消息的交互方式
· 不同类别消息在界面中的展示形式
· 发送、展示消息在极限、错误情况的处理方式
（这些内容太多，单开一篇文章分析也不一定说得完...）
3）主界面信息展示，考虑两种情境
a 聊天进行中：
· 消息在点击发送后，立即显示在聊天界面中；
网络有问题，会提示正在发送、发送失败（列表中显示相应图标）；
发送失败提供再次发送选项；
发送成功后，显示在对方会话页面中。
如果发送消息时对方删除了你，好友关系解除：按照只允许好友间会话的限制条件，发送内容提示失败；进一步引导、提供快捷方式再次添加对方为好友。
左：删除好友后发送消息，系统提示、引导；右：重新添加好友后，系统提示
· 时间显示格式和列表中一致；
发送消息间隔小于2分钟，不出现时间提示。
b 查看记录（离开当前会话后再次进入）：
· 分段加载历史消息；
超过10条未读，提供定位到新消息开始位置的快捷操作，点击后出现临时性新消息分割线（再次查看消失）；
左：新消息提示；右：快速定位后，新消息分割线
自己的会话显示包括发送失败的全部消息，对方会话只显示发送成功消息。
· 时间格式不变；
两条消息超过2分钟间隔、消息分段处显示时间。
4）对已发送消息的操作
· 文字：长按后复制、转发、收藏、翻译（英译汉）、批量操作，双击预览；
· 图片：长按后复制、转发、收藏、批量操作，单击预览（提供查看对话所有图片入口）；
· 语音：长按后听筒播放、收藏、转文字、批量操作，单击播放；
· 动画：长按转发、批量操作，单击预览、引导去表情商店下载。
这些功能大部分应该是后期迭代，慢慢积累的过程。（如，发送2分钟内撤回，对方收到撤回提示。）
——————————————————
考虑ios、Android系统区别，对部分功能区别处理
· 列表操作：ios——手势横滑，Android——长按弹菜单
· 发送消息：ios——调用带有【发送】按钮键盘，Android——界面设置【发送】按钮替换发送文件【添加】按钮
原因：Android设备不能保证所有版本和机型都可以调用有【发送】按钮的键盘
左：ios调用键盘；右：【发送】按钮替换【添加】按钮
以上
