四窗格的系統瀏覽器（System Browser）塑造了 Smalltalk 開發四十餘年。它在提供上下文方面依然出色。但真正的問題可能不在於瀏覽器本身——而在於圍繞它的工具之間缺乏組合性。
Smalltalk 是那些看似「老舊」卻常常是「第一」的系統之一。我們在現代 IDE 中習以為常的許多功能——即時檢視、緊密的迴圈回饋、強大的導航——早在數十年前就已是 Smalltalk 文化的一部分。
然而，在 Smalltalk 中工作的日常體驗仍然被一個四十多年來幾乎未曾改變的隱喻所主導：四窗格的系統瀏覽器。它在提供上下文方面非常出色。但這也是更廣泛使用者體驗問題的開端。
看看這張 Smalltalk-80 的截圖——你可以清楚看到系統瀏覽器正在運作：
系統瀏覽器（也稱為類別瀏覽器）旨在探索系統的類別結構。實際上，它也是大多數 Smalltalk IDE 中的主要程式設計介面。
這裡有兩個現代的實例——不同的時代，不同的 UI 風格，相同的底層隱喻：
你會發現結構到處都一樣：無論外觀上的差異如何，模型都是穩定的。這就是我們內部稱之為四窗格瀏覽器的東西。
這個隱喻存在於幾乎所有擁有完整 IDE 的 Smalltalk 系統中（是的：也有沒有傳統 IDE 的 Smalltalk 系統，例如 GemStone 或 GNU Smalltalk）。它既獲得讚譽也受到批評。令人驚訝的是，它從未被取代。
為什麼這個隱喻如此強大？為什麼四窗格瀏覽器能長期存在而不被更新（可能更好）的隱喻所取代？
因為 Smalltalk 中的程式設計是關於訊息傳遞的，所以很容易將程式碼窗格——方法編輯器——視為「主要」元件：
從這個角度來看，顯然的「替代方案」將會是某種訊息流檢視：一個讓你能夠以路徑而非階層來導航行為的工具。
這個想法很有吸引力。但即使原型存在，它們也很少成為人們工作的預設方式。而解剖其原因，實作上的限制會被歸咎（UI 工具包、圖形層、效能），其中一些確實是真實的——但我認為更深層次的原因更簡單：
如果你將訊息視為一個孤立的元素，你就會失去有效工作所需的上下文。
訊息是一個方法，而方法存在於一個結構中。
類別對於訊息傳遞並非嚴格必需（Self 早已證明這一點），但它們的存在是為了創造結構：將行為分組在一個連貫的上下文中。所以當你查看瀏覽器時，你也應該這樣看待它：
你正在編輯一個將在類別上下文中被理解的訊息，它位於其他類別附近，並透過命名、階層和協作相關聯。
上下文是系統瀏覽器難以被超越的原因。
然而，我們許多人仍然覺得瀏覽器應該被超越。並非因為瀏覽器不好——而是因為實際的程式設計工作很快就會超出瀏覽器本身所能代表的範圍。
例如，這是我在回答一個簡單問題時得到的結果：新的設定瀏覽器中是如何建立一個設定標籤的？（而且我已經知道答案了——這意味著這是「快速路徑」。）
面對這麼多視窗的瀑布，你該如何理解真正解決你問題的訊息流？
作為物件導向程式設計師，我們需要追蹤訊息流來理解行為。這也是為什麼除錯如此重要。
我典型的操作流程如下：
系統瀏覽器顯示一個框架，但我們也需要理解整個場景。框架包含寶貴的上下文——但它無法捕捉跨多個工具和多次跳躍而產生的行為的動態「故事」。
人們常提到的「瀏覽器問題」實際上並不是瀏覽器本身的問題。這是 IDE 的問題。
系統瀏覽器只是更大環境中的一個工具：訊息瀏覽器（傳送者/實作者）、遊樂場、檢查器、除錯器——每一個都是一個獨立的世界。
在 Pharo（以及我所知的幾乎所有 Smalltalk 系統）中，這些工具並存卻無法順暢地組合。它們放在一起，但感覺上並不像「IDE」所暗示的那樣真正整合。結果是工作流程可能變得混亂：工具減少了複雜性（因為它們很強大），卻又增加了複雜性（因為工作集很難保持連貫）。
我們都意識到這個問題。幾年前，Santiago Viana 拜訪了我們的團隊，並進行了一項關於 Pharo 的小型可用性研究（當時他正在學習 UX）。樣本量不足以得出結論性的科學數據，但他指出的摩擦點感覺非常真實：
很難不同意這些觀察。我想補充一些經常出現的模式：
數十年來，工具累積了功能。願景改變。在沒有重新設計整體架構的情況下添加了新概念。結果是一個功能極其強大——但越來越難以掌握的工具。
在 Pharo（以及許多 Smalltalk 系統）中，我們有時認為「身處同一個世界」就足夠整合了。但工具之間的移動不夠流暢，上下文也不會跟著你走。很多時候，每個工具都像一座孤島。
Smalltalk 被設計成一個一切都在 Image 中建構的環境。這種哲學很強大——但它也與現代工作流程和作業系統慣例（視窗管理、選單、快捷鍵、外部工具）產生了摩擦。有些差異是 Smalltalk 體驗的本質；有些則只是無謂的不相容。
（我沒有圖片，但 Iceberg，我正在看著你）
隨著 Pharo 的演進，系統在規模和複雜性上都在成長。早期的 Smalltalk 系統相比之下非常小。例如，Smalltalk-80 V2 只有 223 個類別。一個「標準」的 Pharo 14 Image 則包含約 10,750 個類別。
無論確切的計算方法如何，數量級的差異改變了探索的經濟學：導航、可發現性、訊號與雜訊比，以及「隨便搜尋一下」的心理成本。
人們常說的「瀏覽器問題」實際上並不是瀏覽器問題。這是 IDE 的問題。
要解決它，沒有什麼靈丹妙藥。事實上，可能沒有完美的解決方案。Pharo 傾向於透過加強和打磨現有工具來逐步改進。這是很有價值的——例如 Pharo 13 中的 Cavrois Organic Window Manager 等功能顯然旨在減少摩擦並改善日常生活。
但很難避免一種感覺，那就是漸進式的改進無法完全解決導致日常工作變得混亂的原因：不是缺乏靜態上下文（瀏覽器在這方面非常出色），而是工具之間缺乏組合性和動態上下文。
也許真正缺失的部分不是一個「更好的瀏覽器」，而是更好的工作表徵方式。
當我試圖理解行為時，我並不是真的「在瀏覽器」或「在除錯器」裡。我處於一個「調查線索」中：一連串的導航步驟、實驗、檢查的物件、探索的堆疊框架，以及做出的決定。
所以我想留下的問題是這樣的：
將工作空間視為一個圍繞該線索組織起來的相關工具圖，而不是一組碰巧共存的獨立視窗，這意味著什麼？
我還沒有答案。但我越來越懷疑，如果我們有一天「解決了瀏覽器問題」，那也不是透過取代四個窗格。而是透過讓場景變得可導航：讓程式設計師能夠追蹤他們是如何到達某個地方的，他們嘗試了什麼，他們學到了什麼，以及所有涉及的工具如何相互關聯。
系統瀏覽器仍然是一個出色的框架。懸而未決的問題是，我們能否讓 IDE 的其餘部分同樣強大地掌握整個場景。