歡迎光臨
每天分享高質量文章

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

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

跨瀏覽器兼容性

無論你是需要一個圖表庫,兼容所有瀏覽器兼容,還是只兼容現代瀏覽器,這取決於你的標的受眾。如果你是為政府或企業用戶構建應用程式的話,那麼他們很有可能仍然在用舊版本的 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

原文出處:davidwalsh.name

譯文出處:伯樂在線 – shutear

鏈接:http://web.jobbole.com/82313/



赞(0)

分享創造快樂