不久前,資料科學的話題火熱,為了讓資料有效地傳達與溝通訊息,各種資料視覺化的工具,也如雨後春筍般出現。

事實上,資料視覺化有多種角度可以切入討論,對對開發者來說,在技術面上,也並不僅止於瞭解視覺化程式庫的API。

似曾相識的D3.js

這一陣子老沉浸在3D程式建模的領域,除了享受其中樂趣,另一個好處是,就算看著技術圈子裏的熱門話題,心裡仍是老神在在,看著它們換過一個又一個,只是無論是在Maker圈或者是程式圈子裡,使用程式設計來建模,都算是非主流的課題,儘管在國外論譠裡會有與同好交流的機會,然而,在國內少了些人共同討論,有時難免覺得寂寞一些。

於是最近想到了,有沒有辦法將3D程式建模的經驗,轉化到資料視覺化上呢?一方面可以浮出水面來接觸一下熱門話題的空氣,二方面這仍是我熱愛的圖形創作領域,似乎是個一舉兩得的方式,3D程式建模本身其實就可以做資料視覺化,若能將資料視覺化的結果列印出來,感覺是也滿酷的。

不過,能把視覺化結果放到網頁?有的,OpenJSCAD(https://openjscad.org/)是OpenSCAD的JavaScript移植版本,若想用JavaScript來程式建模,而且實際列印出來,可以玩玩看。

除了OpenJSCAD之外,在3D世界想要做資料視覺化,three.js(https://threejs.org/)是一個選擇,雖然也是有興趣,然而在經過一番搜尋之後,在資料視覺化這話題下,D3.js是更多人在討論的,因為我的目的是接觸主流的空氣,就決定來玩玩D3.js。

D3.js相關資料非常多,在閱覽相關文件的過程中,我覺得相對於3D來說,D3算是簡單得多,只不過程式庫的內容非常地龐大,許多文件最後都只是在解釋API介面、可以繪製的圖案等枝微末節,看久還滿令人生厭的。

不過,某種似曾相識的感覺越來越強烈,是因為操作模式類似於jQuery?不對,玩得越久,越覺得它跟jQuery沒有關係,而熟悉感似乎是來自那種,先思考需要的資料結果,以及專注在轉換的模式!

D3.js的Enter、Exit、Update

幾乎所有D3.js的文件,開始示範程式寫作時,都是固定模式。舉例來說,如果頁面中目前完全沒有<div>元素,而有個清單data為[38,69,72,42,58,87],底下的程式碼是製作簡單長條圖的方式:

d3.select('body').selectAll('div').data(data)
.enter().append('div')
.text(datum => datum)
.style('width', datum => datum + 'px');

select('body').selectAll('div')看來像是jQuery的選擇器模式,接著,使用data(data)似乎是綁定資料,字面上看來,enter()似乎是開始輸入資料,然後加入一個<div>,文字設為datum,寬度設為datum + 'px'。如果開發者覺得這是jQuery的模式,那麼,就該發出疑問:「enter()感覺很多餘?」而且拿掉enter()一拿掉,就什麼事也不會發生!

實際上,enter()並不是輸入資料的概念,而是表示選取的元素與資料結合(join)的結果之一:「沒有元素對應的資料」。如果頁面目前完全沒有<div>元素,那麼,enter()後「沒有元素對應的資料」,就會是data清單中的全部內容,因此會加入六個<div>;如果頁面中已有兩個<div>元素,enter()後「沒有元素對應的資料」只剩下[72,42,58,87],也就只會加入四個<div>。

另一個常見的exit(),是與enter()相對立的操作,表示選取元素與資料結合的結果為「沒有資料對應的元素」,常見的是在exit()之後接上remove(),表示沒有資料對應的元素就移除吧!那麼,如果頁面中已有八個<div>,d3.select('body').selectAll('div').data(data)之後,想將「沒有資料對應的元素」文字設為0該怎麼做?接上exit().text(d => 0)就是了。

對於D3.js,在資料結合之後,除了Enter與Exit結果之外,實際上還有個Update結果,也就是d3.select('body').selectAll('div').data(…)的結果,這時,會是「有元素對應的資料」,因此,若頁面中已有六個<div>,而如果想要用[30,60,70]來更新前三個<div>,只要d3.select('body').selectAll('div').data([30,60,70]).text(d => d)就可以了。

告訴D3.js想要什麼

有不少的文件中都談到,D3.js使用上很像是更好用的jQuery,因為它將許多頁面元素的操作又做了封裝,在底層D3.js確實有這方面的動作。

然而,若使用jQuery的心智模型來撰寫D3.js,那就是個被誤導的結果了。因為,D3.js對頁面元素操作做了封裝,目的並不是模仿jQuery,而是想要開發者告訴它「想要什麼(What)」,而不是「怎麼做(How)」。

就d3.select('body').selectAll('div').data(…)這個操作來說,其實就是告訴D3.js,想要「有元素對應的資料」,如果想要進一步取得「沒有元素對應的資料」或者是「沒有資料對應的元素」,才需要分別接上enter()或者是exit(),也就是一開始,開發者就得告訴D3.js,選取的元素與資料進行結合之後,想要的結果是什麼(需要元素還是資料呢?),而在〈Thinking with Joins〉(https://goo.gl/ATtKFG)中,有兩個圓構成的圖,就非常清楚地視覺化了D3.js的三個結合結果。

一旦知道想要的結合結果之後,接下來繼續要做的,也還是告知D3.js,「資料轉換後的結果是什麼」。也就是開發者得先想清楚,在原始資料與最後底層的圖形繪製之間,到底需要哪些與多少轉換過程,無論這個過程是從說出資料的故事這方面來考量,或者是從轉換為底層技術這方面來考量。

就這邊的長條圖範例來說,沒什麼說故事的考量,由於D3.js是基於HTML元素與SVG來繪製圖形,所以,必須考量到,最後想要的是HTML?或者SVG元素是什麼?它們需要的屬性又是什麼,中間轉換過程產生的資料又是什麼?

使用D3.js的心智模型就是,考量的除了資料、資料,還是資料。有哪些原始資料?在考量這方面時,別忘了,頁面中已經用來呈現資料的元素,也算是原始資料的一部份!接著,需要哪些頁面元素及屬性來呈現圖形,元素與屬性也是資料,從原始資料到最終資料之間,又需要轉換出哪些資料?

知道D3的全名是什麼嗎?官方網站的首頁就寫明了Data-Driven Documents,使用資料驅動文件,因而若不能掌握資料、搞懂需要什麼資料,那麼,很容易就會迷失在D3.js龐雜的API之中,未先思考、研究資料之前就著手編寫程式,就容易迷失方向。

使用資料來驅動

資料不是就在我手上嗎?怎麼會還需要搞懂需要什麼資料呢?

在從事3D程式建模時,我曾有多次建模失敗經驗,這往往是因為沒能思考清楚目標模型需要的資料是什麼,然而,一旦想透了這裡需要的資料,中間需要的資料也逐一找出,目標模型就自然而然地呈現,彷彿一開始的困難與失敗都像是假的。

這就是我後來覺得D3.js的心智模型,會有種熟悉感的原因。對3D程式建模來說,乍看似乎不乏是交集、減集、聯集,只不過當這些動作出現重複時,可以用程式來解決,實際上,不只有也不該只有這樣,唯獨在能清楚知道目標模型,需要哪些座標、網格(Mesh)構造等資料的情況下,才能逐步知道,從原始資料到最終模型之間,需要什麼轉換。

轉換的結果也都會是資料,而資料又驅動另一個轉換,直到最後交給底層呈現圖形的那一刻為止,對3D程式建模是如此,對D3或者其他資料視覺化工具來說,我想也是如此。

作者簡介


Advertisement

更多 iThome相關內容