第一次结对作业
作业描述
| 问题 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2020春丨W班 |
| 结对学号 | 221701237、221701206 |
| 这个作业要求在哪里 | 结对第一次 |
| 这个作业的目标 | 疫情统计可视化 |
| 作业正文 | 见正文 |
| 其他参考文献 | ... |
设计过程
- 遇到的困难
- 如何展示一张各省份相互独立的中国地图
- 地图高亮部分如何实现
- 原型设计工具使用不熟练
- 如何发布成网页提交
- 解决困难
- 困难一已解决，通过学习发现可以之间导入SVG类型的图片，来实现省跟省之间的分离。刚刚开始的时候是使用echarts的插件画一张地图，后导入到Axure后面发现，导入之后又得导出成HTML文件才能正常显示，故放弃，留到实现阶段去使用。
- 困难一与困难二其实是一个问题，在学习了Axure的简单使用方法后，便知道可以通过添加交互的方式来实现高亮。
- 困难四，本想租用一个服务器将原型导出成HTML文件，最后发现，租用服务器三月起租，才能申请报备，最后只能发布到Axure云上提交，也算是解决了吧。
- 收获
- 学习了原型工具的使用
- 发现设计阶段原来也不简单，需要考虑的东西很多
- 一个好的设计能对将来的编程带来巨大的好处
- 边学边做，加强了自己的学习能力跟抗压能力
NABCD模型描述
N（Need，需求):
目前全国的新型冠状病毒肺炎已经到了防控的决胜时期，全国人民都异常关心每日疫情的发展情况。
- 在全国地图上使用不同的颜色来代表各省份的感染程度
- 地图的颜色越深代表着感染情况愈发严重。
- 鼠标移动至相应的省份，该省份高亮显示。
- 省份高亮显示的同时会悬浮窗提示具体的感染人数信息。
- 鼠标点击该省份就跳转相应的详情页面。
- 点击某个省份的详细情况页表
- 设计一个折线图用来直观的反映疫情的变法趋势。
- 折线图采用每日一更新的方式展示数据。
- 折线图共计四条折现分别代码累计确诊、累计疑似、累计治愈、累计死亡。
- 为了防止线与线之间粘连，鼠标移动是会有悬浮窗提示具体类容。
- 四条线用不同的颜色标明，以防错乱。
A（Approach，做法）
关于这次疫情统计可视化，百度公司已经为我们提供了非常实用且精美的蓝图，本着学习的态度大部分的页面设计跟交互都参考了百度公司的设计。
| 功能 | 说明 |
|---|---|
| 全国数据统计表格 | 表单中数据包含有全国现有确诊、疑似，重症以及累计确诊，治愈，死亡 |
| 全国疫情地图 | 根据颜色的深浅来区别严重程度 |
| 全国各省份统计表 | 按省份显示各个省份的确诊、死亡、治愈人数 |
| 具体单个省份疫情统计折线图 | 折线图中包含有具体省份新增确诊，累计确诊以及累计治愈、死亡趋势折线 |
B（Benefit，好处)
- 直观。以图片跟表格形式给出数据便于用以简单明了的找到自己需要的数据。
- 操作简单。无需繁琐的操作即可完成对需求信息的检索。
- 使用方便。以web的形式发布，无需下载相应的App，仅需访问相应的网站即可。
C（Competitors，竞争）
优势
- 无需下载和注册，点击即可访问，减少了大量不必要的麻烦。
- 无繁琐操作，上手简单，覆盖各年龄层。
- 保持持续更新，倘若可以稳定获得新的有关疫情的数据，将着手开发新的功能模块，力求达到最好的服务。
劣势
- 市面上同类产品较多，倘若没有自己的特色不容易吸引用户
- 团队开发水平有限，可能仅仅能满足数据的展示，并不能完成其他的高大上功能。
- 产品寿命较短，一旦疫情过去将无人问津。
- 数据来自于非官方渠道，并不能做到实时更新。
D（Delivery，推广）
- 微信宣传，作为现在最为流行的社交软件之一，我们不能忽视它的重要性，通过亲朋好友发布朋友圈等方式可以可以吸引到一定的用户。
- 口头宣传，拉拢身边好友，再希望他拉拢他的好友，以求人传人，达到用户扩增的目的。
- 微博，微博是疫情讨论的重要地，抓住微博用户关心疫情的特点，宣传自家成品，达到精确打击。
采用的原型开发工具
工具：Axure RP
原型地址
（这是我们团队使用Axure做交互的极限了（自己太菜了)，将来实现时使用Echarts效果会更好）
结队过程与讨论
讨论过程截图
PSP表格
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟）| 实际耗时（分钟）
| :-----| :----| :-----| :----| :-----| :---- |
| Planning | 计划 | 30 | 40
| Estimate | 估计这个任务需要多少时间 | 20 | 30
| Development | 开发 | 300 | 420
| Analysis | 需求分析(包括学习新技术) | 120 | 180
| Design Spec | 生成设计文档 | 30 | 30
| Design Review | 设计复审 | 30 | 60
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | - | -
| Design | 具体设计 | 60 | 120
| Coding | 具体编码 | - | -
| Code Review | 代码复审 | - | -
| Test | 测试（自我测试，修改代码，提交修改） | - | -
| Reporting | 报告 | 60 | 120
| Test Report | 测试报告 | 60 | 120
| Size Measurement | 计算工作量 | 30 | 20
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 30 | 30
| 合计 | | 770 | 1170
心得体会
体会最深的就是原来设计也很累人，各种的交互都要认真的考虑，力求达到用户满意的效果。题目给的需求都很简单易于理解，但是一旦到手上来，这里也要考虑那里也要考虑，真的花费精力。最后还好有各大互联网公司的模型作为参考设计出了自己的东西。想想那些前端设计师，啥都没有都能设计的这么美观，肃然起敬！
本想着扩展一些题目没有的功能，但是考虑到后面要编程实现，倘若找不到相应的数据源，设计了也白搭，如果接下来的任务中，除了给定人数日志外还有给其他的数据，可能会考虑在现在的基础上添加一些新的功能模块。（说到底还是太懒了）
