雖然已經決定這個項目用Wyn來作了，可是，瞭解一下如何從頭開始寫一個數據大屏仍是挺有好玩的。html
-------------前端
爲何要作數據大屏？
現現在的大數據逐漸發揮出了它的力量，並沒有形的改變着咱們的生活。但大數據在不是從事技術開發的人來講沒有很明顯的感覺，不少人對大數據的概念只是停留在每一年網易雲音樂對我的聽歌的彙總上、知乎2017年解鎖的知識成就、微信新年的我的社交分析、支付寶的年終帳單等。其迫切的須要經過一些媒介展示數據的威力，而數據大屏做爲大數據展現媒介的一種，普遍運用於各類展現廳、會展、發佈會及各類狂歡節中，其中不乏一些通用的處理方案：阿里巴巴集團的DataV產品。其大屏有多種主題，提供多種模版，設計的很是的震撼，DataV也用於展示歷年雙十一的盛況。webpack
而公司的大數據工做組就須要經過數據大屏展現一些處理事後有價值的信息，所以需求孕育而生。下面的截圖是產品迭代四次以後在公司大屏展現廳的照片，第五次迭代還在開發中。程序員
用Vue作基礎的框架是否是合適？
絕對合適，就如今運用的狀況來講，Vue適合95%的網頁應用開發，幾乎任何的網頁應用Vue都有對應的解決方案，並且開發效率極高，甚至因爲它組件化的特性，尤爲適合完成一些需求不明確、需求在應用開發的過程當中一直會發生變化、須要快速迭代出一個新版本的開發。而最終參與制做的產品就是一個在需求不明確的狀況下慢慢變成一個產品的。web
程序員如何產生想法再落實到實際開發？
衆所周知，程序員是碼代碼的，而設計產品不是程序員的強項，很不巧的是我就是那個碼代碼，不太會設計的程序員，但經過一些訣竅，仍是可以設計出一款不錯的大屏應用的。下面就來介紹一下里面的一些技巧，這些技巧其實還適用於其餘的產品設計。後端
數據大屏設計歸根結底就是一個在極端寬闊的屏幕上作應用的開發，所以大屏設計每每強調的是大數據迸發的一瞬間大量的數據信息經過必定的可視化形式瞬間衝入腦海的驚豔感。讓人感受數據距離你們不是這麼的遙遠，而給人一種觸手可及的感受。api
數據大屏的設計實際上是有訣竅的，掌握了一些訣竅，在知道了公司大數據組大概須要展現哪些內容以後，不須要UI，程序員本身也能配合產品經理、企劃部和DBA完成一個數據大屏產品的設計。微信
步驟分爲
肯定基色->尋找靈感->思考實施->做出第一個原型->再次瞭解需求->屢次修改產品->優化細節
後面的步驟須要循環屢次，歸根結底就是一個典型的需求不明確快速迭代的原型開發。數據結構
- 肯定基色和尋找靈感
肯定基色不是很難，因爲是大屏，採用深色作背景，最重要的是要有靈感，初期的需求分析瞭解到了須要在大屏上存放的內容以下：
- 兩塊地圖
- 三個大數據數值的統計
- 流程圖展現
- 實時提單詳細展現
- 收發報文統計展現
在肯定了初期的需求以後，接下來就是思考如何把這些需求落實到頁面上。如何在頁面上展現這些內容。而數據大屏的展現，數據大屏的核心就是數據的拼接，具體到展現層能夠概括成數據塊的拼接，因爲公司大屏是8*4的32塊屏，所以起初的尋找靈感就是從分塊開始。框架
這樣作的好處是每一個屏幕切分的很清晰，靈感也在切分中愈來愈清晰，到日後就是一個個模塊的排列組合，和細節的優化，通過初期對需求的解讀，初步劃分以下圖所示。
- 地圖1
- 標題
- 實時提單展現
- 地圖2
- 全鏈路
- 數據統計
7-11：報文詳細
- 思考實施
在切分變的明顯以後，就開始了細節的開發，前人的經驗是要吸收的。所以能夠在UI中國上尋找優秀的大屏設計，看看哪些內容能夠被吸收到本身的產品內部。
UI中國 - 大數據監控運營平臺
UI中國 - 人口、旅遊 大數據可視化大屏展現
UI中國 - 數據可視化大屏
UI中國 - 可視化數據展現系統
UI中國 - 雅培活動數據分析Dashboard
在開發上，歸功於Vue的組件化思想，當設計出一個模塊框和些許組件以後，後面的內容就是按照內容劃分進行填充，極其的快速，立刻，第一個原型孕育而生，並且出了圖標採用開源解決方案，其餘的內容都是本身從零開始開發的，維護效率也偏高，產品設計也更加統一。
- 第一個原型
下圖展現了第一個原型的誕生，運用Vue進行開發，圓環和統計圖採用ECharts進行繪製，上面的實時提單展現會一直滾動，而且實時能夠查看單子的詳細。
- 再次瞭解需求
下面開始就是快速迭代中比較重要的一點：快速瞭解進一步的需求，在第一個原型誕生以後，必然帶來第二稿的修改，由於模糊的需求並不能精確命中用戶的真實需求，而用戶的正式需求每每是設計人員在設計出第一個原型以後誕生的。
此時用戶在見到了一些內容以後會有更加近一步的想法，甚至有些設計由於需求不明確和真實需求並不相符，不是用戶真正想要的內容，就好比上圖那個全鏈路的圓環，在進一步瞭解需求以後發現，有可能一天有多個步驟同時發生，那運用圓環表示比率的作法就沒有任何的意義，而這些只有在第一個原型出來以後才能發現的。
因而配合用戶、業務部門和DBA，誕生了第二個原型，和第一個原型比更加的豐富，業務也發生了相應的變化。
- 屢次修改產品、優化細節
通過屢次和用戶、企劃、公司大數據組人員進行溝通後，變成了最終文章開始的展現模式，原型肯定以後的具體後端接口的開發了。
這其中最方便的一點是開發完原型後前端應用展現方面的內容無需修改分毫，所以運用假接口調用和後端肯定規範就變得很是必要，只須要編寫後端數據，編寫完以後直接修改HOST就能作到，因爲原型開發面臨這不斷的修改，並且後端也不清楚最後可以提供什麼樣的數據，這樣溝通成本就變得很大，如何下降溝通成本，制定一個規範，就是咱們必需要考慮的問題。
原先會經過原型變動後端的假接口也相應發生變化，讓前端去調用，這樣作很是低效，後端工程師的時間也浪費了，測試也要等到後端假接口寫完以後，但得益於YAPI這個開源項目（這是由去哪兒的工程師開發的一套先後端開發規範管理系統）運用mockjs作假數據的生成，原型直接調用這套系統的接口。後端也無需考慮數據結構，前端把定義好的數據結構寫成YAPI內部對應的一個個測試接口，當輪到後端開發的時候直接按照這套系統的API規範進行開發，下降了溝通成本，對於任何一個團隊來講都很是便捷。
代碼結構設計
組件化拆分變的尤其重要，又是webpack打包的項目，所以模塊也相對比較清晰，對於後期運維也相對好維護。
- data-block：數據模塊框組件
- data-link：全鏈路組件
- data-map：地圖組件
- data-marquee：實時滾動組件
- data-step：嵌套在data-link內部的步驟條詳細
- data-title：標題組件
- svg-circle：原型內部鏈路圓環（已被需求淘汰）
圖表全在utils內部的chart.js內部維護，圖標採用SVG，和鏈路項的順序單獨維護在配置文件內部，便於需求變化後的修改。樣式運用less進行開發，統一配色、樣式。
PS：用戶就是領導😂