為什么要做數(shù)據(jù)大屏?
現(xiàn)如今的大數(shù)據(jù)逐漸發(fā)揮出了它的力量,并無形的改變著我們的生活。但大數(shù)據(jù)在不是從事技術(shù)開發(fā)的人來說沒有很明顯的感受,很多人對(duì)大數(shù)據(jù)的概念只是停留在每年網(wǎng)易云音樂對(duì)個(gè)人聽歌的匯總上、知乎2017年解鎖的知識(shí)成就、微信新年的個(gè)人社交分析、支付寶的年終賬單等。其迫切的需要通過一些媒介展現(xiàn)數(shù)據(jù)的威力,而數(shù)據(jù)大屏作為大數(shù)據(jù)展示媒介的一種,廣泛運(yùn)用于各種展示廳、會(huì)展、發(fā)布會(huì)及各種狂歡節(jié)中,其中不乏一些通用的處理方案:阿里巴巴集團(tuán)的DataV產(chǎn)品。其大屏有多種主題,提供多種模版,設(shè)計(jì)的非常的震撼,DataV也用于展現(xiàn)歷年雙十一的盛況。
而公司的大數(shù)據(jù)工作組就需要通過數(shù)據(jù)大屏展示一些處理過后有價(jià)值的信息,因此需求孕育而生。下面的截圖是產(chǎn)品迭代四次之后在公司大屏展示廳的照片,第五次迭代還在開發(fā)中。
用Vue做基礎(chǔ)的框架是不是合適?
絕對(duì)合適,就現(xiàn)在運(yùn)用的情況來說,Vue適合95%的網(wǎng)頁(yè)應(yīng)用開發(fā),幾乎任何的網(wǎng)頁(yè)應(yīng)用Vue都有對(duì)應(yīng)的解決方案,而且開發(fā)效率極高,甚至由于它組件化的特性,尤其適合完成一些需求不明確、需求在應(yīng)用開發(fā)的過程中一直會(huì)發(fā)生變化、需要快速迭代出一個(gè)新版本的開發(fā)。而最終參與制作的產(chǎn)品就是一個(gè)在需求不明確的情況下慢慢變成一個(gè)產(chǎn)品的。
程序員如何產(chǎn)生想法再落實(shí)到實(shí)際開發(fā)?
眾所周知,程序員是碼代碼的,而設(shè)計(jì)產(chǎn)品不是程序員的強(qiáng)項(xiàng),很不巧的是我就是那個(gè)碼代碼,不太會(huì)設(shè)計(jì)的程序員,但通過一些訣竅,還是能夠設(shè)計(jì)出一款不錯(cuò)的大屏應(yīng)用的。下面就來介紹一下里面的一些技巧,這些技巧其實(shí)還適用于其他的產(chǎn)品設(shè)計(jì)。
數(shù)據(jù)大屏設(shè)計(jì)歸根結(jié)底就是一個(gè)在極端寬闊的屏幕上做應(yīng)用的開發(fā),因此大屏設(shè)計(jì)往往強(qiáng)調(diào)的是大數(shù)據(jù)迸發(fā)的一瞬間大量的數(shù)據(jù)信息通過一定的可視化形式瞬間沖入腦海的驚艷感。讓人感覺數(shù)據(jù)距離大家不是這么的遙遠(yuǎn),而給人一種觸手可及的感覺。
數(shù)據(jù)大屏的設(shè)計(jì)其實(shí)是有訣竅的,掌握了一些訣竅,在知道了公司大數(shù)據(jù)組大概需要展示哪些內(nèi)容之后,不需要UI,程序員自己也能配合產(chǎn)品經(jīng)理、企劃部和DBA完成一個(gè)數(shù)據(jù)大屏產(chǎn)品的設(shè)計(jì)。
步驟分為
確定基色->尋找靈感->思考實(shí)施->作出第一個(gè)原型->再次了解需求->多次修改產(chǎn)品->優(yōu)化細(xì)節(jié)
后面的步驟需要循環(huán)多次,歸根結(jié)底就是一個(gè)典型的需求不明確快速迭代的原型開發(fā)。
確定基色和尋找靈感
確定基色不是很難,由于是大屏,采用深色做背景,最重要的是要有靈感,初期的需求分析了解到了需要在大屏上存放的內(nèi)容如下:
兩塊地圖
三個(gè)大數(shù)據(jù)數(shù)值的統(tǒng)計(jì)
流程圖展示
實(shí)時(shí)提單詳細(xì)展示
收發(fā)報(bào)文統(tǒng)計(jì)展示
在確定了初期的需求之后,接下來就是思考如何把這些需求落實(shí)到頁(yè)面上。如何在頁(yè)面上展示這些內(nèi)容。而數(shù)據(jù)大屏的展示,數(shù)據(jù)大屏的核心就是數(shù)據(jù)的拼接,具體到展示層可以歸納成數(shù)據(jù)塊的拼接,由于公司大屏是8*4的32塊屏,因此起初的尋找靈感就是從分塊開始。
這樣做的好處是每個(gè)屏幕切分的很清晰,靈感也在切分中越來越清晰,到往后就是一個(gè)個(gè)模塊的排列組合,和細(xì)節(jié)的優(yōu)化,經(jīng)過初期對(duì)需求的解讀,初步劃分如下圖所示。
地圖1
標(biāo)題
實(shí)時(shí)提單展示
地圖2
全鏈路
數(shù)據(jù)統(tǒng)計(jì)
7-11:報(bào)文詳細(xì)
思考實(shí)施
在切分變的明顯之后,就開始了細(xì)節(jié)的開發(fā),前人的經(jīng)驗(yàn)是要吸取的。因此可以在UI中國(guó)上尋找優(yōu)秀的大屏設(shè)計(jì),看看哪些內(nèi)容可以被吸取到自己的產(chǎn)品內(nèi)部。
UI中國(guó) - 大數(shù)據(jù)監(jiān)控運(yùn)營(yíng)平臺(tái)
UI中國(guó) - 人口、旅游 大數(shù)據(jù)可視化大屏展示
UI中國(guó) - 數(shù)據(jù)可視化大屏
UI中國(guó) - 可視化數(shù)據(jù)展示系統(tǒng)
UI中國(guó) - 雅培活動(dòng)數(shù)據(jù)分析Dashboard
在開發(fā)上,歸功于Vue的組件化思想,當(dāng)設(shè)計(jì)出一個(gè)模塊框和些許組件之后,后面的內(nèi)容就是按照內(nèi)容劃分進(jìn)行填充,極其的快速,馬上,第一個(gè)原型孕育而生,而且出了圖標(biāo)采用開源解決方案,其他的內(nèi)容都是自己從零開始開發(fā)的,維護(hù)效率也偏高,產(chǎn)品設(shè)計(jì)也更加統(tǒng)一。
第一個(gè)原型
下圖展示了第一個(gè)原型的誕生,運(yùn)用Vue進(jìn)行開發(fā),圓環(huán)和統(tǒng)計(jì)圖采用ECharts進(jìn)行繪制,上面的實(shí)時(shí)提單展示會(huì)一直滾動(dòng),并且實(shí)時(shí)可以查看單子的詳細(xì)。
再次了解需求
下面開始就是快速迭代中比較重要的一點(diǎn):快速了解進(jìn)一步的需求,在第一個(gè)原型誕生之后,必然帶來第二稿的修改,因?yàn)槟:男枨蟛⒉荒芫_命中用戶的真實(shí)需求,而用戶的正式需求往往是設(shè)計(jì)人員在設(shè)計(jì)出第一個(gè)原型之后誕生的。
此時(shí)用戶在見到了一些內(nèi)容之后會(huì)有更加近一步的想法,甚至有些設(shè)計(jì)因?yàn)樾枨蟛幻鞔_和真實(shí)需求并不相符,不是用戶真正想要的內(nèi)容,就比如上圖那個(gè)全鏈路的圓環(huán),在進(jìn)一步了解需求之后發(fā)現(xiàn),有可能一天有多個(gè)步驟同時(shí)發(fā)生,那運(yùn)用圓環(huán)表示比率的做法就沒有任何的意義,而這些只有在第一個(gè)原型出來之后才能發(fā)現(xiàn)的。
于是配合用戶、業(yè)務(wù)部門和DBA,誕生了第二個(gè)原型,和第一個(gè)原型比更加的豐富,業(yè)務(wù)也發(fā)生了相應(yīng)的變化。
多次修改產(chǎn)品、優(yōu)化細(xì)節(jié)
經(jīng)過多次和用戶、企劃、公司大數(shù)據(jù)組人員進(jìn)行溝通后,變成了最終文章開始的展示模式,原型確定之后的具體后端接口的開發(fā)了。
這其中最方便的一點(diǎn)是開發(fā)完原型后前端應(yīng)用展示方面的內(nèi)容無需修改分毫,因此運(yùn)用假接口調(diào)用和后端確定規(guī)范就變得非常必要,只需要編寫后端數(shù)據(jù),編寫完之后直接修改HOST就能做到,由于原型開發(fā)面臨這不斷的修改,而且后端也不清楚最后能夠提供什么樣的數(shù)據(jù),這樣溝通成本就變得很大,如何降低溝通成本,制定一個(gè)規(guī)范,就是我們必須要考慮的問題。
原先會(huì)通過原型變更后端的假接口也相應(yīng)發(fā)生變化,讓前端去調(diào)用,這樣做非常低效,后端工程師的時(shí)間也浪費(fèi)了,測(cè)試也要等到后端假接口寫完之后,但得益于YAPI這個(gè)開源項(xiàng)目(這是由去哪兒的工程師開發(fā)的一套前后端開發(fā)規(guī)范管理系統(tǒng))運(yùn)用mockjs做假數(shù)據(jù)的生成,原型直接調(diào)用這套系統(tǒng)的接口。后端也無需考慮數(shù)據(jù)結(jié)構(gòu),前端把定義好的數(shù)據(jù)結(jié)構(gòu)寫成YAPI內(nèi)部對(duì)應(yīng)的一個(gè)個(gè)測(cè)試接口,當(dāng)輪到后端開發(fā)的時(shí)候直接按照這套系統(tǒng)的API規(guī)范進(jìn)行開發(fā),降低了溝通成本,對(duì)于任何一個(gè)團(tuán)隊(duì)來說都非常便捷。
YAPI - 高效、易用、功能強(qiáng)大的 api 管理平臺(tái)
代碼結(jié)構(gòu)設(shè)計(jì)
組件化拆分變的尤為重要,又是webpack打包的項(xiàng)目,因此模塊也相對(duì)比較清晰,對(duì)于后期運(yùn)維也相對(duì)好維護(hù)。
data-block:數(shù)據(jù)模塊框組件
data-link:全鏈路組件
data-map:地圖組件
data-marquee:實(shí)時(shí)滾動(dòng)組件
data-step:嵌套在data-link內(nèi)部的步驟條詳細(xì)
data-title:標(biāo)題組件
svg-circle:原型內(nèi)部鏈路圓環(huán)(已被需求淘汰)
圖表全在utils內(nèi)部的chart.js內(nèi)部維護(hù),圖標(biāo)采用SVG,和鏈路項(xiàng)的順序單獨(dú)維護(hù)在配置文件內(nèi)部,便于需求變化后的修改。樣式運(yùn)用less進(jìn)行開發(fā),統(tǒng)一配色、樣式。
來源:網(wǎng)絡(luò)整理 免責(zé)聲明:本文僅限學(xué)習(xí)分享,如產(chǎn)生版權(quán)問題,請(qǐng)聯(lián)系我們及時(shí)刪除。