形式追隨功能
Form follows function
https://www.youtube.com/watch?v=DaxODmFnN6U
偉大的創作的外在形式（外顯表現）都是由內部運作邏輯所驅動
底層系統只由四個基本操作組成：讀取、寫入、分配、釋放
當你理順底層系統時，UI就會自然而然形成
你不能憑空想像出一種形式，而應該先攻克問題，搞清楚它的功能
當功能（內在邏輯、一致性、數學結構）確立，形式便會自然而然形成
功能的三種面向
內在邏輯
每種設計都嵌入於形塑其內在屬性的環境中
當我們理解一設計良好的事物所處的環境，就能明白為和它呈現出此樣貌
一致性
重複的對稱性
在設計選擇上，會盡可能在不同情境下重複使用相同元素
數學結構
如何組合設計元件的規則
功能代表無形的結構，決定設計內部元件的關係、互動和環境適應性
形式無法脫離功能而獨立存在，功能受到環境影響
我們可以直接觀察並與形式互動，但我們無法感知功能，必須額外努力推理
如果沒有功能作為支柱，形式塑造就完全取決於設計者的主觀喜好
功能讓設計者在塑造形式時保持誠實：形式的目的是為功能服務
當然我們可以獨立於功能之外，探索而玩耍形式，但這是屬於藝術，而非設計的範疇 容易犯下的錯
只關注形式，而忽略功能
你必須先忽略形式，專注於弄清除功能
因為我們在與任何事物互動時，首先接觸到的就是介面，這是我們最熟悉的部分
以及功能會比形式更抽象、更難以掌握
關鍵是不要停留在具體案例，退一步思考：「這些案例背後的共通邏輯或抽象原則是什麼？」
只關注功能，而忽略使用者
即使要確立功能，也不能完全忽略最終的使用者
許多後端工程師誤解「形式追隨功能」的意義，認為可隨意設計資料庫結構或API
導致糟糕的使用者介面，使用者必須理解內部的資料模型，才能有效使用系統
視覺化程式設計的問題則仍然屬於第一類，過於專注形式
視覺化程式設計不只是「節點與連線」
絕大多數的視覺化程式設計都採用了「節點與連線」的模型，主要有兩種變體
1. 節點代表資料，連線代表函式
2. 節點代表函式，連線代表函式間傳遞的資料
「節點與連線」之所以流行，是因為設計者普遍假設程式設計的內在邏輯和傳統的文本程式設計相同
那麼你會自然認為目標是替現有的文本語言結構找到對應的視覺呈現方式
這就是為什麼「節點與連線」形式最後會是純函式對應的概念
「節點與連線」乍看不錯，但是
函式的「定義」和「調用」的差異為何？
如何傳遞函式作為變數？
在數十年的嘗試後，大多數純函式程式設計仍然使用文本
例如LabVIEW將一連串指令以電路圖式的圖表呈現，也無法協助開發者理解狀態變化和組合爆炸 「節點與連線」真正發揮優勢的是在某些特定領域
1. 需要頻繁檢查中間的資料和轉換結果
2. 對於中間的資料和數據已經有成熟的視覺化呈現方式
例如
Unreal Engine的Blueprint，用於shader
音樂的聲音合成的Max/MSP
但在通用領域仍未找到立足點
建模問題
我們應該如何建模問題，才能發揮人類視覺皮質的計算能力？
人類的視覺皮質是一個強大的模式識別機制
它能迅速比較長度、區分前景與背景、辨識空間模式，以及執行許多驚人的感知能力
我們已經在資料視覺化利用這種能力，但還沒能利用它來理解計算系統 文字不也是一種視覺語言？
我們要如何建模問題？
實體與關係
無論哪種系統，都有兩種主要層面：
1. 視覺化呈現問題領域的實體
2. 視覺化呈現實體之間的關係
不管是命令式、物件導向、函式、邏輯式程式設計，都涉及 實體：結構、物件、複合值、術語
它們的關係：命令式過程、訊息、函式、規則和謂詞
視覺化屬性
不存在單一的「屬性對應視覺化」的映射，因為這取決於使用者的意圖和目標
視覺化關係
計算是找出下一個狀態
將問題建模為實體和關係只解決了一半問題
我們早已能在沒有電腦的情況下做到這點
問題是：我們應該如何用視覺呈現系統狀態怎麽隨時間演變，或對外部輸入作出回應
規則集做為當前狀態和下一狀態的純函式轉換
在CellPond的演講中也指到，更複雜的行為的規則集會有爆炸性的組合規則
CellPond的創新之一就是允許規則集代表或生成一組規則集，讓視覺化仍能被人類處理
但純函式只是映射
純函式可以被一個對等的無限鍵值表格取代
規則集也是輸入對應到輸出的精密映射
因此我們不止需要表達單一狀態如何映射到下一狀態，還有整組狀態如何映射到下一狀態
文字程式設計已有許多我們熟悉的機制表達「狀態選擇」
boolean、map/filter、SQL的SELECT和WHERE 但我們缺乏通用且可組合的方式表達「選擇前一狀態，映射到下一狀態」
也無法將這種狀態映射應用到網格或細胞之外的其他狀態類型
另一條可能的道路