【转】外行杂谈论—聊聊看板 vs 大屏的区别
作者 | 羅學(xué)勇
監(jiān)制 | 向日葵
原文 | 微信搜索 ‘技術(shù)記號’
前言
In大數(shù)據(jù)時代,跟隨相關(guān)技術(shù)的日新月異與成熟,在這樣的背景下,前端和后端又能玩出什么新花樣呢?在18年的雙11活動中,天貓的可視化大屏可謂玩花了技術(shù)控們的眼睛。
時過1年的今天,正好在黑馬頭條項(xiàng)目中玩了一把大屏,在這個過程中我發(fā)現(xiàn)周邊同事和我理解的大屏定義不太一樣,于是我查閱了度娘,發(fā)現(xiàn)度娘上全是賣LED大屏的(真是太尷尬了~)。這可怎么辦,這強(qiáng)迫癥一犯,愣是一夜未眠好。
經(jīng)過一夜的思考,也對看板和大屏有了一些個人見解,在此記錄,以備它人所需。
正題
我們在做后臺系統(tǒng)時經(jīng)常會聽到一些dashboard、kanban、screen、報(bào)表、統(tǒng)計(jì)、畫像、儀表盤等名詞,不管是否還有其它名詞,這些名詞按落地的頁面來歸類分為入口和詳情兩類。今天的主角kanban和screen都屬于入口頁這類。另要說明一下,在一些企業(yè)中也經(jīng)常把kanban稱為儀表盤或者dashboard;所以依據(jù)這些信息我們可以得到下面這個公式:
dashboard(儀表盤)= kanban(看板)≠ screen(大屏)
為證明以上的等或不等式成立,下面我們從面向用戶、功能特點(diǎn)、技術(shù)實(shí)現(xiàn)等維度進(jìn)行論證。
面向用戶不同
看板,面向的核心用戶是運(yùn)營,其次才是其它內(nèi)部員工和BOSS
在后臺管理系統(tǒng)中,大部分系統(tǒng)登錄成功之后跳轉(zhuǎn)的第一個頁面就是看板頁面,比如企業(yè)辦公軟件登錄之后看板上出現(xiàn)待辦事項(xiàng)、事項(xiàng)辦理進(jìn)度、當(dāng)月績效等數(shù)據(jù);又比如電商后臺進(jìn)入后的看板上提示今日上架、成就額趨勢、新SKU數(shù)量、PV走勢、UV走勢等圖表;這些都是常規(guī)套路,那么思考一下管理系統(tǒng)誰用的最多呢?大部分情況下,個人認(rèn)為是運(yùn)營,他們依據(jù)邊看板上的數(shù)字并查看詳情分析運(yùn)營情況,并及時調(diào)整運(yùn)營策略,以完成運(yùn)營目標(biāo)。少部分情況,技術(shù)和運(yùn)維會有后臺系統(tǒng)的賬號,他們主要登錄查看系統(tǒng)監(jiān)控看板監(jiān)控系統(tǒng)。
有老鐵可能會反駁說到OA系統(tǒng)不是呀!內(nèi)部那么多員工都有賬號,人數(shù)肯定比運(yùn)營多。針對這個問題呢,我們首先要了解兩個實(shí)情,第一、企業(yè)中OA系統(tǒng)的運(yùn)營人員實(shí)則是人事或者行政。第二、企業(yè)員工都有OA賬號,但他們不可能天天登錄OA去請假是吧!但是人事和行政會基本天天登,去導(dǎo)或看員工數(shù)據(jù)。所以還是核心用戶還是系統(tǒng)的運(yùn)營者人事或行政。
那么有沒有系統(tǒng)看板不是面向運(yùn)營的呢?個人相信是有的,只是還沒碰到,等碰到了在來補(bǔ)充,老鐵們沒遇見了也可以留言告訴我。
大屏,面向的核心用戶是系統(tǒng)客戶、其次是內(nèi)部員工、BOSS
想一想大屏出現(xiàn)的地方在哪里?在公司前臺、走廊、辦公區(qū),亦或在公司食堂,還有就是發(fā)布會直播現(xiàn)場對吧!在這些區(qū)域設(shè)置大屏的目的就是給客戶一種專業(yè)、高大尚的比格、如果客戶是互聯(lián)網(wǎng)用戶,那么就開直播發(fā)布會,總之得讓客戶感受到公司的專業(yè)與強(qiáng)大。除了這個目的,還有一層意思就是,讓內(nèi)部員工看見自己努力經(jīng)營的成功而獲得成就感!
BOSS就不用多說了,看板和大屏他都看!
功能特點(diǎn)不同
看板,功能特點(diǎn)是支持頁面定制、頁面多圖表、可交互查看(點(diǎn)擊查看詳情等)、圖表數(shù)據(jù)手動刷新
比如:以下看板示例,統(tǒng)一個系統(tǒng)不同用戶可以有不同的圖表項(xiàng),每項(xiàng)圖表可點(diǎn)擊查看詳細(xì)數(shù)據(jù)和搜索。
大屏,功能特點(diǎn)是頁面展示的是數(shù)字(TOP 項(xiàng))、不可交互、自動刷新、視覺特效強(qiáng)、成就展示
比如:以黑馬頭條的大屏Demo舉例,大屏是單頁展示的模式(雙11的大屏是多頁展示模式更具視覺效果),當(dāng)某個數(shù)字指標(biāo)達(dá)到一個設(shè)定閾值時,呈現(xiàn)成就特效頁,以體現(xiàn)成就的儀式感。
技術(shù)實(shí)現(xiàn)不同
看板,后端大數(shù)據(jù)統(tǒng)計(jì)計(jì)算,前端通過Echarts進(jìn)行展示
從近幾年的看板技術(shù)來看,如拋開后端的大數(shù)據(jù)統(tǒng)計(jì)計(jì)算,其它技術(shù)還是比較常規(guī),大部分看板還是由http、vue、echarts核心三件套組成。由于是手動刷新,所以只需要提供http接口獲取數(shù)據(jù)即可;圖表頁使用開源的Vue+Echarts即可滿足大部分需求。這種模式在開發(fā)過程中也較容易實(shí)現(xiàn),處理的細(xì)節(jié)不多。當(dāng)然也有一些企業(yè)產(chǎn)品化融入了高級玩法,提供了自動刷新、圖表定制功能。
大屏,后端大數(shù)據(jù)統(tǒng)計(jì)計(jì)算、數(shù)據(jù)實(shí)時計(jì)算;前端內(nèi)容特效定制開發(fā)
以黑馬頭條的大屏技術(shù)為例(拋開大數(shù)據(jù)統(tǒng)計(jì)技術(shù)),kafkastream、websocket、http、vue、d3、jquery、svg、echarts。
先說后端,大屏要求后端支持多協(xié)議連接,常見的是ws、http協(xié)議,在一個協(xié)議不可用的情況下,自動切換另外一個協(xié)議,保證前端可實(shí)時獲取到后端數(shù)據(jù)。后端通過kafkastream實(shí)時對系統(tǒng)總線上的消息進(jìn)行監(jiān)聽和過濾處理,并轉(zhuǎn)換成前端所需的消息格式,通過WebSocket發(fā)送給前端實(shí)時刷新。對于后端ws協(xié)議需提供WebSocket服務(wù),實(shí)現(xiàn)連接權(quán)限的管理。同時還要求后端提供http數(shù)據(jù)獲取接口,可用獲取實(shí)時計(jì)算的數(shù)據(jù)。如下數(shù)據(jù)流圖:
再說前端,大屏的前端視覺效果都要求特別高。除此之外,大屏實(shí)現(xiàn)的困難點(diǎn)還體現(xiàn)在以下兩點(diǎn)點(diǎn):
算法難度:如tmall雙11的大屏效果,其中展示的特效是現(xiàn)有前端框架都沒現(xiàn)成的,所以需要自我實(shí)現(xiàn)。而在實(shí)現(xiàn)特效的過程中會涉及各種算法,如下圖品牌LOGO都圍繞地址旋轉(zhuǎn),會涉及3D 球面坐標(biāo)的算法;
數(shù)據(jù)溢出:大屏實(shí)時獲取后端數(shù)據(jù),大屏一般不會關(guān)閉,那么前端必然會接收到超量的數(shù)據(jù),如處理不好會引起大屏特效卡頓、大屏卡死等問題;
彩蛋
本想總結(jié)一下看板和大屏的區(qū)別,但是到了吃小面的時間了,彩蛋一發(fā)就各回各家吧~
看板常見分類
運(yùn)營看板:(面向運(yùn)營人員,包含系統(tǒng)各業(yè)務(wù)指標(biāo)內(nèi)容)
運(yùn)維看板:(面向運(yùn)維人員,包含系統(tǒng)硬件、容器、軟件等內(nèi)容)
監(jiān)控看板:(面向技術(shù)人員,包括系統(tǒng)自身運(yùn)行情況、異常情況、KPI指標(biāo)項(xiàng))
敏捷看板:(面向技術(shù)團(tuán)隊(duì),包括工作任務(wù)、工作方案、資源/進(jìn)度等內(nèi)容)
BOSS看板:(面向BOSS,包含BOSS關(guān)注的運(yùn)營、運(yùn)維、KPI等指標(biāo)項(xiàng))
大屏常見分類
單頁大屏:(小成本小制作)單頁展示所有的數(shù)字項(xiàng)和成就特效
多頁大屏:(大成本大制作)每頁展示獨(dú)立的數(shù)字項(xiàng)及其成就特效
————————————————
版權(quán)聲明:本文為CSDN博主「miukoo」的原創(chuàng)文章,遵循 CC 4.0 BY-SA 版權(quán)協(xié)議,轉(zhuǎn)載請附上原文出處鏈接及本聲明。
原文鏈接:https://blog.csdn.net/luoxueyong/article/details/99335922
總結(jié)
以上是生活随笔為你收集整理的【转】外行杂谈论—聊聊看板 vs 大屏的区别的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 快速止咳(夜间快速止咳的方法)
- 下一篇: CentOs MySQL数据目录迁移