第一次参加好未来培优产品的需求评审会，和产品、测试、ui、开发、动效等各位老师的交流，收获颇多。相关需求有以下几个。
投屏
投屏流程是教师在app上上传一张图片，图片上传oss后的地址以及课次和学生的信息会被发送到教师端app服务端之后传给its服务端，its服务端会保存相关数据，并且通过和its客户端建立的长连接把数据推送给对应课次的客户端。
客户端接收到通过长连接推送过来的数据显示，这时候可能处在两种状态，一种是抢红包、答题之类的不可中断状态，一种是可中断的状态。可中断的情况下直接弹框显示，不可中断的情况下如何处理还没有一个定论，是不管，是中断，是保存下来结束后显示，是静默失败，还是通知教师端app当前its状态（通过its服务端到app服务端再推送app）等，方案很多。
此外之后可能会考虑在its客户端菜单添加投屏入口，可以查看历史投屏。
感想：http部分的和之前做的很多文件上传，数据上传类似，单向的传数据。但数据推送是我之前很少涉及到的，需要考虑推送时的客户端状态，进行各种处理，甚至还要传数据回来，双向通信。
设备管理“进入课程”按钮
这里因为功能重复决定把“进入课程”按钮去掉，但是有人觉得这个更常用。最终没有去掉，但决定加埋点，靠数据说话要不要改。
感想：数据驱动产品迭代是增长模型的理论，通过用户行为数据统计分析，进行最正确的决策。
秋季皮肤
这里之前的代码没有考虑到切换的情况，决定把代码做下重构，变成可配置式的。
感想
云课堂系列产品的需求主要涉及到教师端app、its客户端以及各自的服务端4个对象之间的交互、通信，当然也包括一些其他外部对象比如oss、基础平台等。具体通信方式主要是http和ws，以及服务端之间的rpc、消息队列等。任何一个功能的实现，都要理清数据的流动过程，什么逻辑应该在哪一端做，之间如何通信、通信内容和格式是什么等。
具体的数据显示和交互需要ui那边配合，因为我们的产品界面面向的对象有很多小朋友，所以界面也相对绚丽一些，ui老师必要时会做一些手绘。
除了数据流程和ui设计之外，各端对数据处理逻辑的整体架构也很重要，这影响代码是不是易读，以后的迭代是不是好扩展、好维护。
总之，我们首先要对上下文、对我们的项目运行和交互的环境有清晰的认识，然后优化ui显示和用户交互体验，更重要的式要设计出更清晰易读、松散耦合、易于复用的代码。
此外，产品整体功能的设计要根据用户行为数据的统计结果来取舍，经过分析埋点数据，进行功能的优化，产品的调整和迭代，数据驱动决策。
网友评论