選擇 JS 圖表庫的 13 個考慮因素

shutear發表於2015-04-14

如果你計劃構建一個正式的應用程式,那麼在你開始尋找一個圖表庫之前,你需要知道建立好的資料視覺化是一個極大的時間投資。對於資料視覺化你究竟要實現哪些功能,將在哪些裝置上使用,以及你有多長時間來構建應用程式等問題有明確的答案,將幫助對下述指南物盡其用。

跨瀏覽器相容性

無論你是需要一個圖表庫,相容所有瀏覽器相容,還是隻相容現代瀏覽器,這取決於你的目標受眾。如果你是為政府或企業使用者構建應用程式的話,那麼他們很有可能仍然在用舊版本的 IE。所以說,那些僅能在現代瀏覽器內工作的圖表庫可能不是一個好的選擇。

處理跨瀏覽器的相容性問題是非常痛苦的,我認為你選擇的庫應該幫你解決這事。

跨裝置相容性

你的應用程式主要使用在桌面,或者說你針對手機使用者嗎?如果只是為了大屏瀏覽,那麼大多數圖表庫可用於你的視覺化;但如果你想確保在手持裝置一致的體驗,你選擇的圖表庫應該為你負責。最近,改變使用者習慣變得越來越重要。

輸入資料格式

雖然 JSON 正逐漸成為標準格式,尤其是涉及到圖表庫時,但仍有很多情況,你不得不處理 XML。如果你的視覺化需要 XML 格式的資料,那就得了解你的圖表庫是否支援 XML 了。

可定製性

可定製性,至少對於我來說,是最大的決定因素。圖表庫是足夠靈活,以便我能做我想做的事,還是在預設情況下看起來很好,定製仍需“自己動手,豐衣足食”呢?

我喜歡玩弄數以百計的東西,如新增自定義形狀、配置圖例、附加事件(點選、懸停、按鍵),利用資料鑽取(drill-down of data),以及應用主題等。如果你想建立一個漂亮的設計,有一個容易定製的庫將是很好的,這樣你可以根據你應用程式的設計去改造。

可用圖表的範圍

這是一個無需用腦的事。無論你想要建立怎樣的視覺化,它都應該是庫中的一部分。但是對於各種包含集體包(collective packages)的相簿來說,將不是那麼容易,它們將類似的圖表組在一起,如地圖(maps),小工具(widgets)和股票圖(stock charts)。因此,根據不同的使用場景,你可能只想要一個特定型別的圖表, 或者得到一個完整的包。

如果你想要根據可用的圖表範圍比較不同的相簿的話,你會發現這個資源會很有幫助。

學習曲線

一些視覺化庫,如D3.js,有一個陡峭的學習曲線。毫無疑問D3.js是非常強大的,但如果你時間緊迫或者第一次用,我不推薦它。

換句話說,如果你剛開始做資料視覺化且有大量的時間去嘗試,那麼你應該全力去嘗試那些漂亮但需要時間投資的庫。

與其他程式碼的相容性

假想你是一個對 JavaScript 不太熟悉的 PHP 或 ASP.NET 戰神,如果你可以不寫任何 JavaScript 程式碼建立圖表,豈不妙哉?一些庫有免費的外掛和封裝器,幫你生成在瀏覽器頁面上渲染圖表所需的 JavaScript 和 HTML 程式碼。例子:FusionCharts Extensions 和 Highcharts extension

效能

效能取決於很多因素,如庫的大小,渲染時記憶體使用量,垃圾回收以及瀏覽器重繪的時鐘週期數。我非常看重效能,但僅為效能的優化並不總是好的想法。這聽起來似乎自相矛盾,所以讓我用一個例子來解釋一下我的觀點。

假設你將構建一個用於區域網的儀表板(dashboard):你認為在這種情況下,使用一個最小的庫有意義嗎?在這種情況下,我會選擇一個基於這裡討論的其他因素最好的庫。節省庫的大小,將是我最不關心的事。

匯出

這一點不適用於所有使用場景,但僅適用於像報告和儀表板(dashboard)這樣的情況。如果你為商業使用者構建一個儀表板,那麼你的使用者可能會希望將圖表匯出到PDF或者圖片。你選擇支援開箱即用的匯出功能的圖表庫會更好。常見的匯出格式有JPEG、PNG、PDF 還有 SVG。

設計與互動

設計不僅僅是一個圖表的外觀,它不僅應該好看(主題、配色),而且應該有好的互動。比如,如果你建立一個扇形圖,那麼在預設情況下,當你點選一個扇形區域時,該區域應該被拉出來(或在其圓周上新增邊框)。不應該需要自定義程式碼。在多序列折線圖(multi-series line chart)上,點選一個圖例圖示時,應該切換相關資料圖。

定價和許可條款

現在,當你購買一個許可證後,絕大多數的庫會分發它們的原始碼,但這並不意味著你可以自由地做任何你想做的。重要的是要知道你專案所需的所有許可權和購買相關許可證。條款和定價取決於像使用者數量,應用型別(SaaS,intranet,web)和伺服器數量等因素。

支援

當你構建一個應用程式時,資料視覺化可能不是你的核心力量。所以當你遇到一個問題時,你可能需要藉助外面的支援來解決它。支援可以來自多種形式,如個人、論壇或者社群,如 StackOverflow。如果你日程很緊,等不了 StackOverflow的答案,那麼在這種情況下,個人支援或專門的論壇將是非常有用的。

就流行的庫而言,大多數常見問題的答案都是很容易獲得的。但是我在測試邊緣多次遇到死角。如果你認為你可能需要專門的支援的話,那麼我推薦你購買一個圖表元件,而非使用一個開源的解決方案(即便它滿足所有其他的需求)。

開源

我熱衷於開源,但我相信它不是一切問題的正確的解決方案。特別是它涉及到圖表的解決方案時,GitHub上有成千上萬小的、開源庫。但你嘗試在專案中使用其中的一個之前需小心謹慎。

我一個朋友,因為他喜歡的幾個功能,曾經在他的商業專案中使用過一個小開源庫。 一年後,當他試圖實現一些高階功能時,他卡住了。當他試圖聯絡庫的建立者時,他才知道這個專案早已被丟棄了。我確信這不會發生在大的開源庫上,如D3.js、Google Charts,morris.js,但最好是考慮這種可能性,而不是後面後悔。

這有一篇文章回答了何時一個商業庫比一個開源庫更有意義

為了做出明智的選擇,我認為知道所有這些因素是重要的。如果你認為我錯過了一些因素,請在評論中提到它們。


— Merrily

Vikas,你談及了很多重要的點 ,都考慮得不錯。還有一個要考慮的是,資料點的個數以及圖表的個數。一個庫能支撐大量資料點且保持專案所需的互動功能嗎?當一個頁面上有多個圖表時,效能又怎樣呢?

你也提到了互動功能。雖然從圖例切換資料集,點選移動扇形分片,以及深入到圖表的能力是非常重要的,但在實際應用中,這些功能都是相當基礎的。要記住對於資料視覺化應用,考慮真正發揮客戶端互動性的互動,如批註(annotations)和運算元據集,也是非常重要的。

— Merrily

相關文章