結對第一次—某次疫情統計可視化（原型設計）

#做業描述 | 問題 | 內容 | | :-----| :----| | 這個做業屬於哪一個課程 | 2020春丨W班| | 結隊學號 |22170123七、221701206| |這個做業要求在哪裏|結對第一次| |這個做業的目標|疫情統計可視化| |做業正文|疫情統計可視化| |其餘參考文獻|...|

設計過程

• 遇到的困難
  • 如何展現一張各省份相互獨立的中國地圖
  • 地圖高亮部分如何實現
  • 原型設計工具使用不熟練
  • 如何發佈成網頁提交
• 解決困難
  • 困難一已解決，經過學習發現能夠之間導入SVG類型的圖片，來實現省跟省之間的分離。剛剛開始的時候是使用echarts的插件畫一張地圖，後導入到Axure後面發現，導入以後又得導出成HTML文件才能正常顯示，故放棄，留到實現階段去使用。
  • 困難一與困難二實際上是一個問題，在學習了Axure的簡單使用方法後，便知道能夠經過添加交互的方式來實現高亮。
  • 困難四，本想租用一個服務器將原型導出成HTML文件，最後發現，租用服務器三月起租，才能申請報備，最後只能發佈到Axure雲上提交，也算是解決了吧。
• 收穫
  • 學習了原型工具的使用
  • 發現設計階段原來也不簡單，須要考慮的東西不少
  • 一個好的設計能對未來的編程帶來巨大的好處
  • 邊學邊作，增強了本身的學習能力跟抗壓能力

#NABCD模型描述 ##N（Need，需求): 目前全國的新型冠狀病毒肺炎已經到了防控的決勝時期，全國人民都異常關心每日疫情的發展狀況。

1. 在全國地圖上使用不一樣的顏色來表明各省份的感染程度
   • 地圖的顏色越深表明着感染狀況愈發嚴重。
   • 鼠標移動至相應的省份，該省份高亮顯示。
   • 省份高亮顯示的同時會懸浮窗提示具體的感染人數信息。
   • 鼠標點擊該省份就跳轉相應的詳情頁面。
2. 點擊某個省份的詳細狀況頁表
   • 設計一個折線圖用來直觀的反映疫情的變法趨勢。
   • 折線圖採用每日一更新的方式展現數據。
   • 折線圖共計四條折現分別代碼累計確診、累計疑似、累計治癒、累計死亡。
   • 爲了防止線與線之間粘連，鼠標移動是會有懸浮窗提示具體類容。
   • 四條線用不一樣的顏色標明，以防錯亂。

##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

心得體會

體會最深的就是原來設計也很累人，各類的交互都要認真的考慮，力求達到用戶滿意的效果。題目給的需求都很簡單易於理解，可是一旦到手上來，這裏也要考慮那裏也要考慮，真的花費精力。最後還好有各大互聯網公司的模型做爲參考設計出了本身的東西。想一想那些前端設計師，啥都沒有都能設計的這麼美觀，肅然起敬！ 本想着擴展一些題目沒有的功能，可是考慮到後面要編程實現，假若找不到相應的數據源，設計了也白搭，若是接下來的任務中，除了給定人很多天志外還有給其餘的數據，可能會考慮在如今的基礎上添加一些新的功能模塊。（說到底仍是太懶了）

博客PDF附件

PDF附件下載