Smashing Podcast 第 37 集與 Adam Argyle：什麼是 VisBug？

在本集中，我們將討論 VisBug。 它是什麼，它與 Chrome DevTools 中已有的一系列選項有何不同？ 德魯麥克萊倫與它的創造者亞當阿蓋爾交談以找出答案。

顯示註釋

• VisBug 沙箱和遊樂場
• 亞當在推特上
• 亞當的個人網站
• YouTube 上的 VisBug
• 可視錯誤 101

每週更新

• 我們用於在線活動的會議平台：Amanda Annandale 的 Hopin
• CSS 容器查詢入門 Stephanie Eckles
• 需要修復的令人沮喪的設計模式：Vitaly Friedman 的生日選擇器
• 搖樹：Átila Fassina 的參考指南
• Beau Hartshorne 如何改進我們的核心 Web Vitals

成績單

Drew McLellan：他是一位聰明、熱情、朋克工程師，熱愛網絡，他更喜歡利用自己的技能打造一流的 UI 和 UX，並為周圍的人賦能。 他曾在大大小小的公司工作過，目前是在谷歌 Chrome 上工作的開發者倡導者。 他是 CSS 工作組的成員，也是設計調試工具 VisBug 的創建者。 所以我們知道他對設計和用戶體驗瞭如指掌，但你知道他擁有的人字拖比任何活著的兩足動物都多嗎？ 我的粉碎朋友，請歡迎亞當·阿蓋爾。

亞當·阿蓋爾：你好。

德魯：嗨，亞當，你好嗎？

亞當：哦，我很厲害，你知道的。

德魯：很高興聽到這個消息。 所以我今天想和你談談你的項目，VisBug，一般來說，關於設計調試背後的概念以及它如何適應項目工作流程。 我的意思是，我們已經擁有以開發人員為中心的瀏覽器調試工具已經有很長一段時間了，我的意思是，現在可能已經有十多年了。 但這些顯然非常關注代碼。 那麼 VisBug 有什麼不同呢？ 它試圖解決的問題是什麼？

亞當：太棒了。 是的，它根源的主要問題是，作為一名前端工程師，我一直與設計師合作，我總是喜歡我們坐下來的那一刻，我會說，“好吧。 我正在做最後的潤色。 在我們部署之前，我們還有一兩天的時間。 所以設計師，坐下來，你會批評這個嗎？ 我希望你在瀏覽器和手機上打開我的本地主機版本，或者其他什麼，然後和我談談你所看到的。”

亞當：在做了很多年並且一直喜歡這種互動之後，一段時間後我開始感到內疚，因為這些任務是多麼的普通和簡單。 他們會說，“這裡有一個像素。 這裡有五個像素的邊距。” 它總是對間距和類型的微調和微調。 我的意思是，很少有這樣的情況，“哦，等一下，我花 30 分鐘來改變一些角度，或者其他什麼，來調整我的 DOM，以便 DOM 可以支持你的請求，”或者其他什麼。

亞當：通常是很小的東西。 最後我做了一個調查，調查了谷歌的所有這些設計師。 我當時想，“當你打開 DevTools 時，你會做什麼？” 他們只需要基礎知識，這聽起來很響亮。 所以它誕生於，我想，“這應該更容易。 您不必為了改變汽車座椅的顏色而打開法拉利的引擎蓋、移動一大塊發動機。 這不公平。 你應該能夠觸摸汽車座椅並改變顏色，就像一個設計工具一樣。” 我當時想，“有些東西可以促進這個工作流程。” 我當時想，“好吧，我想我會破解一些東西，看看我是否能創造出解決方案。”

亞當：這就是一切的開始。 它真的從間距開始，然後是排版。 一旦我有了一個模擬設計工具的選擇機制，就像，“我還能做什麼？” 它只是從那裡開始。 但是，是的，出生在那一刻。

Drew：所以這個想法是客戶要求您將徽標放大，而 VisBug 幫助瀏覽器表現得更像是進行此類調整的設計工具。 如此接近於 Illustrator、Photoshop、Figma 或任何這些類型的東西。

亞當：是的。 該用例也是一個很好的用例。 因為你可能是一個客戶，他們說，“哦，我們喜歡這個，”這太經典了，“我們喜歡這個設計，但是藍色對我們來說很難。” 你就像，“真的嗎？” 這就像，人們可以提交表格，你可以賺錢，但你現在想和我談談藍色嗎？ 通常它會創建一個完整的循環。 PM 會說：“好的，我們會記下您的請求，然後將其發送給設計人員。”

亞當：但如果設計師在場，並且是他們的瀏覽器顯示它，他們會說，“好吧。 好吧，我只需單擊該東西並更改顏色即可。” 您可以通過在瀏覽器中對更改進行原型設計來完成整個工作週期。 就是這樣。 它對現有產品最有效，對吧？ 因為它是一個調試工具。 它不一定是生成工具。 它不會為您創建網站。 可以，但是有點尷尬。

Drew：所以從技術上講，它是您在 Chrome 瀏覽器中安裝的擴展程序。 那正確嗎？

亞當：是的。 這是一個擴展。 當你啟動它時，它會下載一個 JavaScript 文件，上面寫著“這是一個名為 VisBug 的自定義元素”。 然後你把 DOM 元素，vis-bug 放在頁面上。 噗，我只是把它變成一個工具欄，然後開始監聽頁面上的事件。 我聽你的懸停事件，我聽你的點擊事件。 而且我會盡力攔截它們，而不是與您的主頁競爭。

亞當：但是，是的，這就是……它是擴展的唯一原因是它很容易放在你的頁面上。 儘管此時它確實有一些跨瀏覽器的設置。 但它仍然大部分（99.9%）是一個沒有依賴關係的自定義元素。 我想我喜歡我使用的顏色庫，否則它只是香草。 是的。

Drew：我想這就是 Firebug 的開始，不是嗎？ 作為當時的 Firefox 擴展。

亞當：是的。 這就是為什麼它被稱為 VisBug。 它非常受 Firebug 的啟發，但適用於視覺設計師。

德魯：啊。 我們去吧。 我的意思是，作為音頻播客，這可能不是談論視覺工具的理想格式。 但是，如果您願意，請讓我們了解 VisBug 為您提供的一些工具和選項。

亞當：當然。 這是 VisBug 所做的第一件事，如果您在家或在電腦前，您也可以訪問 visbug.web.app，嘗試不帶擴展名的 VisBug，對嗎？

德魯：啊。

Adam：這是一個 Web 組件，所以我在 visbug.web.app 為您加載了一個網頁，看起來它有一大堆藝術板，當然，還有預加載的 VisBug。 這個網站的目標是讓你玩、探索和刪除。 我認為刪除鍵是最令人滿意的工具之一。 你就像，“我可以對頁面做什麼？” 你會說，“好吧，我可以摧毀它。”

亞當：我這樣做是為了讓你可以按住刪除，它會找到下一個……這對於刪除來說是相當困難的。 你刪除一些東西，它會選擇下一個兄弟姐妹。 所以它將永遠選擇下一個兄弟姐妹。 如果你按住 delete 直到你刪除整個......無論如何，非常令人滿意。 點擊刷新，一切都回來了。 但是 VisBug 附帶的第一個工具，所以當你啟動它時，就是指南工具。 我過去常常把紙放在屏幕上，或者我會去買一個系統擴展，讓我可以對事物進行分類並創建線條。

亞當：因為，是的，對於很多設計師來說，對齊在某個時候變得非常直觀，對吧？ 他們不一定想要數學對齊，對嗎？ 這就是排版具有光學字距調整的原因。 這不是數學字距調整。 這是人為的字距調整。 因此，指南工具植根於設計師的許多細節都在放大東西，檢查對齊方式。 間距好不好？

Adam：這就是指南工具要做的第二件事。 當您啟動它並且只需將鼠標懸停在某些東西上時，您會看到您懸停的元素周圍有一個小框。 然後出現虛線指南，就像統治者通常會做的那樣。 就像在 Sketch 和 Zeplin 中懸停並獲得這些指南一樣，這是相同的概念，只是存在於您的頁面上。 如果你點擊某個東西，然後將鼠標懸停到一個新的目的地，你就會得到測量工具。 測量工具以像素為單位，它們是計算出來的……所以從視覺上看，它之間有多少像素。 不是別人說的。 它不是把所有的間距加起來，只是你點擊這個東西，它離另一個盒子這麼遠。

亞當：我認為這真的很有幫助，因為你可以按住 shift 並繼續點擊，基本上可以驗證五個圖標之間的間距是否相等。 只需點擊幾下。 不必知道代碼，只需啟動 VisBug，懸停，單擊，單擊，單擊，您就會看到，“哦，看它。 是的。 每個像素之間有 15 個像素。” 或者有時你會得到一些令人討厭的東西，你會點擊一個框，然後點擊它的父框，你會發現它的頂部距離是 9，底部距離是 8。 然後你會說，“我將如何將其居中？ 不知何故介於兩者之間。” 並握拳。

Adam：但至少您可以使用指南工具輕鬆輕鬆地看到它。 是的，這就是指南工具。

德魯：我肯定去過那裡，把紙片放在屏幕上。 而且，我會使用的另一個技巧是打開另一個瀏覽器窗口並使用窗口的邊緣來對齊項目。 然後您嘗試將所有內容保存在正確的位置，以便在您更改和刷新代碼時，所有內容仍然排成一行。 是的，這不是理想的工作方式，所以。

亞當：不是一種理想的工作方式。 是的。 還有下一個……所以，哦，第一個版本非常鬆散。 它沒有折斷，它只是豎起了一個十字準線，這是我稍後會添加的功能。 所以有些用戶會說，“嘿，我喜歡捕捉，就像我的設計工具一樣。 但是如果我想要一個鬆散的測量值怎麼辦？ 或者我想做一個信，我想測量一個信，而不是它的信箱？” 因此，這個指南工具可以很容易地更改為具有修飾鍵。

Adam：這就是 VisBug 有點不同的地方，但也希望是熟悉的，它在熱鍵修飾符上非常重。 因此，就像您觀看專業設計師一樣，他們非常精通熱鍵。 他們在這裡按熱鍵，放大，在那兒按熱鍵，然後只是在鍵盤上輕推。 所以 VisBug 在你改變事物的方式上非常以鍵盤為中心。

Adam：也是因為 VisBug 允許多選，它可以同時改變 100 個項目的間距。 它是相對的。 所以無論如何，它有一些有趣的怪癖，但修飾符概念中的鍵盤非常重要。 您可以在許多工具中保留選項、轉換或命令，並獲得不同的東西，或者在那裡獲得一種新的功能。

德魯：所以它是學習鍵盤快捷鍵真正值得的工具之一。

亞當：確實如此。 因此，當您啟動 VisBug 並將鼠標懸停在其中一個工具圖標上時，您會看到故障。 它會彈出一個小彈出菜單，顯示選擇此工具的熱鍵，並告訴您它可以做什麼，以及為了獲得它們需要進行哪些交互。 所以指南工具說，“元素指南，只需懸停。 測量一些東西，點擊，然後懸停一些新的東西。 粘性測量是移位加點擊，因此它們會持續存在。”

亞當：這些指南也非常適合截圖。 因此，如果您正在審查 PR，即使只是作為前端工程師，或者可能是設計師審查 PR，這可能是您進入那裡的一種非常有效的方式，並且，是的，進行一些高保真檢查。 哪種方式引導我們進入下一個工具。 您想了解下一個工具嗎？

德魯：是的，當然。 讓我們去吧。

亞當：太棒了。 下一個是檢查工具。 而這個就像......設計師通常，他們不想要所有的CSS，對吧？ 當他們期望... 我選擇了這個 H1，所以一切都回到了瀏覽器樣式表。 設計師會說，“瀏覽器是什麼？ 瀏覽器有樣式表嗎？”

德魯：在那個滾動面板的陰暗底部。

亞當：陰暗的底部，對吧？

德魯：是的。

亞當：就像你剝掉了所有的層，然後你就像，“哦，我不再喜歡這些層了。” 這裡的檢查工具說，“啊，設計師，我知道你想要什麼。 這只是邊框顏色。” 基本上，只給我一些獨特的東西，所以不要只用 CSS 屬性來覆蓋我。 我最感興趣的是顏色、排版和間距。 所以我要看看邊距、行高、字體系列真的很重要，對吧？ 有一個完整的擴展只是為了告訴您頁面上的字體系列是什麼。

Adam：在 VisBug 中，這只是檢查工具中的一個項目。 因此，您只需啟動 VisBug，點擊檢查，然後將鼠標懸停在任何版式上，它就會告訴您字體系列。 所以，是的，它試圖讓設計師專注於它所呈現的東西，是的。

Drew：所以該工具沒有顯示任何繼承的樣式。 那正確嗎？

亞當：沒錯。 除非它們是繼承的和獨特的。 所以如果他們... 文本顏色或其他東西，如果文本顏色不是字面意義上的繼承這個詞，它會告訴你這是一個計算值，它很有趣。

德魯：是的，這真的很有用……是的。 幫助您專注於真正適用於某事物的一個實例的事物，這顯然是您想要改變的。 我的意思是，我想這可能真的很有用，所有這些工具都會非常有用，就像你提到的那樣，獲得利益相關者的反饋。 並且有點與客戶互動。

Drew：我想它在屏幕共享上同樣有效，就像我們現在必須做的那樣，越來越多。 您不必與某人坐在電腦前，您可以坐在通話的另一端並共享您的瀏覽器並這樣做。 我想當客戶不能指著屏幕說——

亞當：當然。

Adam：將實時網頁變成看起來像 Zeplin 畫板的東西總是很神奇。 有人會說，“什麼……我們是不是去了新的地方？” 你會說，“不，這是你的產品。 我們只是在視覺上與它互動。” 是的，它可以非常好。

Drew：您是否見過 VisBug 的其他有趣用例或您認為可能有趣的用例？

亞當：是的。 所以，是的，有這麼多，很難開始。 哦，重要的是開發人員與開發人員之間的溝通。 VisBug 對計算值起作用。 因此，它不會查看您創建的值。 這真的很好，因為您正在測量和檢查絕對最終結果，以了解像素在屏幕上的計算方式。 這真的很好，以這種方式進行對話，因為你正在研究結果，而不是創作方面。

亞當：你可以回過頭來想，“好吧，如果這是我們在視覺上得到的，我們在創作方面是怎麼出錯的？” 下一個工具也是可訪問性檢查工具。 因此，inspect 工具可以輕鬆查看元素上的樣式，並以非常適合設計人員的方式分解它們。 可訪問性工具可幫助您檢查頁面上的所有元素，並顯示它具有的任何可訪問屬性，我希望這使得它更容易驗證某事已完成。

亞當：所以一個公關......而且事情經常被創造出來。 因此，這又是開發人員對開發人員、設計人員開發人員，您正在審查界面。 這太關鍵了。 如果您正在查看一個界面並且很好奇，VisBug 會為您提供一個用例。 還有一些用例，您可以在瀏覽器中對原型進行排序。 所以我們討論了一個，客戶想嘗試藍色。 好的，這是一個非常簡單的場景。

亞當：但還有其他的。 如果您在 VisBug 上點擊命令 D，您將復制一個元素。 它並不關心你在復制什麼。 所以你可以復制一個標題，在兩個標題之間添加一些間距，然後在瀏覽器中製作一個變體。 你雙擊標題文本，它變成一個可編輯的文本字段，你去嘗試一個新的標題，看看標題是如何適合的。 去調整一些間距，你就省去了所有這些開發人員的工作，找到一個源文件和所有那些東西，你只是……

亞當：所以是的，它可以幫助你探索和驗證。 這有點奇怪……我的意思是，這是 DevTools 所做的很多事情，對吧？ 它是在你完成之後出現的，它實際上並不經常給你源代碼，你從 DevTools 中復制代碼的頻率也不高。 您可以復制一個鍵值對。 比如，“哦，我改變了這種風格。” 但是，是的，無論如何。

德魯：嗯，嗯（肯定）。 是的。 我可以想到一些你可能想要復制項目的特別視覺案例。 您可能希望獲取頁面的整個部分並將其複制以模擬如果內容比您預期的多得多的情況。

亞當：是的。 這就是混沌測試用例。

德魯：是的。

亞當：當然。

Drew：這是我們所有人都必須處理的事情，使用基於 CMS 的系統和所有這些有趣的任務進行設計。

亞當：是的，這也是一個非常重要的用例。 因為我這樣做是為了……是的，頭條新聞，就像我說的那樣。 你只要雙擊一些文字，我就去敲擊鍵盤。 Blah，blah，blah，blah，然後打了一堆空格，blah，blah。 我想，“好吧，佈局怎麼樣？ 哦，效果不錯。 好的，好的，我可以繼續下一件事了。 如果我重複這四次會發生什麼？ 一切之間還有空間嗎？ 它會在下一個項目旁邊流動嗎？”

亞當：對那種內容混亂的模擬來說真的很棒。 很短的標題，很長的標題，沒有朋友，有一百萬個朋友。 您如何在 UI 中處理這些用例？ 是的。

Drew：所以它適用於任何基於瀏覽器的內容。 那麼 PWA 和常規網頁一樣嗎？

亞當：是的，確實如此。 所以如果你安裝了 Spotify，我一直都這樣做，我已經安裝了 Spotify，我會說，“Spotify，你看起來像是一個不可能檢查的應用程序。” 但猜猜怎麼了？ VisBug 不在乎。 VisBug 覆蓋你所有的東西，檢查所有的排版。 我為...製作了一個輕主題...哦，我在某處發布了一條推文，其中我製作了 Spotify 的輕主題。

亞當：哦，這是另一個用例，抱歉，用於原型顏色。 我可以在產品本身上創建一個淺色主題，而不必弄亂一堆貼紙，對嗎？ 所以有一個重要的平衡心態，我希望 VisBug 幫助人們進入其中，將您的產品用作遊樂場。 把它當作……它是如此真實。 它比您的設計組合更真實。 所以多花點時間在裡面。 我想你會發現你可以在你的實際產品上做出更有效的設計決策。

Drew：可訪問性的案例也特別有趣，因為通常，尤其是這些天，我們在組件庫中進行了大量工作，並查看頁面的小組件。 並且花費更少的時間來查看所有集成在一起的視圖，以創建客戶實際與之交互的那種視圖。 並且很難關注那些在頁面上不可見的更精細的細節，例如可訪問性事物、屬性。

德魯：關注不可見的事物是非常困難的。 所以這就是工具可以真正幫助檢查某些東西並看到它的地方，是的，它有正確的角色，它 -

亞當：確實如此。 這就是確切的用例。 我希望 PM 能夠去驗證這些東西。 我希望設計師能夠查看可訪問性，而不必打開工具，找到 DOM 節點，所有這些都在元素面板中被壓縮並且看起來很奇怪。 它只是說，“這是區域屬性，如果存在的話，這是標題。” 還有一些其他可訪問性工具。 VisBug 附帶搜索圖標。 搜索圖標有多種與之交互的方式。

Adam：所以首先它會查詢頁面。 因此，如果您知道想要的元素類型或元素類名稱，您只需搜索即可，無需使用鼠標查找。 但這也有斜杠命令。 所以 VisBug 中有插件，它們會在頁面上執行腳本。 所以如果你曾經有一個書籤，你已經保存了三四個……你會說，“我要使用這個，因為它突出了所有的邊框，並顯示了我的盒子。” 這就像一個調試技巧或其他東西。

Adam：它可能是一個 VisBug 插件。 所以你啟動 VisBug，點擊斜線，你會得到自動完成，它會向你展示所有不同的插件。 還有一些可訪問性非常好，可以覆蓋錯誤以及各種類似的東西。 所以我同意。 可訪問性應該更易於訪問。 這麼說簡直是蹩腳。 但它需要更靠近工具帶。 而且我認為有時它太遠了，也許這就是它被錯過的原因。 所以我希望它是否更前面、更中心、更容易得到更多檢查。 是的。

Drew：有趣的是，你說 VisBug 可以處理事物的計算值，比如顏色。 這是否意味著，如果您有幾個具有不同不透明度級別的分層元素，您將能夠測量屏幕上呈現的確切顏色，而不是 -

亞當：哦。

德魯： ……查看單個元素並嘗試以某種方式解決？

亞當：這是一個非常好的問題。 所以我想，如果我理解正確的問題，這是前端的一個典型困難是，是的，你怎麼知道你是否有一個半不透明的文本單詞，它的顏色是灰色還是白色? 你怎麼知道它的對比？ 目前，我們不知道。 所以 VisBug 知道顏色，它會說“50% 灰色”，或者任何你有的顏色。 但它不知道比這更聰明的事情。 它無法…

亞當：我認為在這種情況下你必須做的是創建一個畫布，在上面繪製所有圖層，然後使用吸管或...所以你將它渲染到畫布上，讓它們全部粉碎成一個單個繪製層，然後將單個像素值取出，以查看其實際最終計算的灰度在它被分層到其他東西之後是什麼。

亞當：我認為有人指定了它，或者我把它作為一個 GitHub 問題，它會很好。 因為 VisBug 可以 100% 促進這一點。 VisBug，在幕後，我已經完成了文本指標，您將鼠標懸停在事物上，它會為您提供有關字體的瘋狂信息。 這幾乎是太多的信息，比如 x 高度和上限高度，但它甚至更多。 就像，“哦，我在某個時候有點被關閉了。” 所以我必須弄清楚如何在那裡找到信號與噪聲。

亞當：但是，是的，我喜歡這個思考過程，因為我們應該有一個工具來做到這一點。 如果我們知道如何計算它，我們可以教 VisBug 去做，這將是一個非常酷的功能，與不透明度相關的計算顏色。 愛它。

Drew：是的，我的意思是，這是一種標準情況，即在您不確定對比度是否足以通過可訪問性要求的背景下放置文本。 也許不是，也許是對比度太低，然後您想調整值，直到達到對比度良好的程度，但它與客戶最初想要的品牌顏色並沒有相差太遠和東西。

亞當：我稱之為碰撞，碰撞直到你通過。

德魯：是的。

亞當：因為這就是它的感覺。 我想，“哦，我的分數有點短。” 所以就像，我會去我的 HSL 亮度，我會顛簸，顛簸，顛簸，然後看著小數字滴答作響，直到“叮”，我得到一個綠色的複選標記。 我想，“好吧，很酷。” 是的，有時，有些顏色並不酷。 那麼，您是否研究過正在進行的大部分 3.0 感知可訪問性工作？ 所以我們將不再有 AA 或 AAA，我們將有數字，它包括字體細度之類的東西。 因此，如果它是細字體，它會得到較低的分數，如果它是一個粗字體，它就會……因為有很多對比。

德魯：是的，不，我什麼都沒見過，但聽起來——

亞當：無論如何，這是一件很酷的探索。

德魯：這聽起來很迷人，是的。 我得找個人談談這件事。 那是另一集。 所以，我的意思是，我敢肯定，一些開發人員可能會爭辯說，VisBug 所做的所有事情都可以通過 DevTools 中的 CSS 面板來完成。 而且我認為這有點公平，但可能沒有抓住重點，是的，你在進行更改時正在操縱 CSS，但它會將一種以設計者為中心的用戶界面放在頂部，而不是以開發者為中心的界面。 這是對它的公平描述嗎？

亞當：這真的很公平。 老實說，最好的想法都是從 VisBug 畢業的，然後進入 DevTools。 他們已經有了。 所以 VisBug，如果你在任何元素上點擊命令選項 C，它會採用每個計算的樣式，至少這是唯一的。 再說一次，就像，我們會做一些我們不只是給你所有這些繼承屬性的事情。 但是將它們全部放在剪貼板上，然後您可以將該樣式粘貼到其他地方、樣式表、CodePen 中，然後單擊幾下即可重新創建元素。

Adam：這些交互已經進入了 DevTools，進入了元素面板。 但是，還有其他一些東西沒有，那就是 DevTools 是一個單節點檢查工具。 VisBug 遵循設計工具的原則，不，我應該能夠多選。 我需要能夠批量編輯、批量檢查。 所以我一直使用 VisBug 來設置間距。 因為我可以突出顯示多個元素並看到邊距折疊。

Adam：在 DevTools 中你永遠看不到它，因為大多數時候你一次只能看到一個節點，雖然有顯示多個邊距的方法，但不一樣。 所以，是的，它有這些非常有趣的小眾用例。 另一個是，如果你突出顯示一個……假設你有一個排版系統，並且你有 H1 到 H7，就像在故事書或類似的東西中，你可以在 VisBug 中突出顯示所有這些，按住 shift，只需單擊所有它們。 Boop，boop，boop，boop，轉到排版工具並向上或向下敲擊，它會對它們中的每一個進行相對更改。

亞當：所以他們每個人都會向上推或向下推。 而這並不是 DevTools 可以輕鬆實現的。 所以，是的，它有一些像這樣的超級大國，因為它有點不可知論。 並且它準備始終在數組上進行迭代。 是的。

Drew：那麼 VisBug 的起源是什麼？ 現在它只是一個個人項目嗎？ 或者它是一個谷歌項目？ 或者它的狀態如何？

亞當：是的。 首先，狀態是，它是一個谷歌項目。 它的主要目標是在進入 DevTools 之前成為原型和探索的地方。 至少從谷歌方面來說。 但從我個人的角度來看，我仍然認為它是一個可以完成常見任務的地方，或者可以進行一些優化以完成常見任務。 並且只是為了給更廣泛的受眾一種查看 DOM 的方式。

Adam：我真的認為 DevTools 非常強大，但也很嚇人。 只需其中的一個標籤就可以花費一生的時間來學習。 我仍然在 DevTools 中學習東西，並且一直在使用它們。 所以，是的，這在某些方面是一種不同的觀眾。 更多的是初學者，進來的人，或者甚至像 PM、經理這樣的人，他們從不打算編碼，但對輸出感興趣。 所以它給了他們，是的，只是輕巧的工具可以進入那裡。

Drew：這是你提出的一個有趣的觀點，因為我個人經常發現我很難找到一個舒適的工作流程來管理所有這些 DevTools。 你有所有這些幽閉的小面板，你可以將它們分離到另一個窗口，但是你必須跟踪兩個不同的窗口。 一旦你打開了幾個瀏覽器窗口，你就不能……你只關註一個，你不知道哪個 DevTools 屬於它。

Drew：然後在面板本身中，它有點像狂野西部的用戶界面約定。 你會滾動，事情會開始做你沒想到的奇怪的事情。 而就用戶體驗而言，我覺得這一切都是一團糟。

亞當：是的。 是的。

德魯：你認為這是不可避免的嗎？ 可以更好嗎？

亞當：我在這里肯定有想法。 是的，我認為這很好......所以假設你現在有一個聽眾，就像，“我對 DevTools 非常精通。 我不認為他們那麼瘋狂。” 我會說，“好吧，打開 Android Studio 或 Xcode。 開始一個項目，然後去看看 DevTools，去看看輸出。 你現在感覺有多熟悉？” 應該是很陌生吧。 你會看到，“這是垃圾。 他們為什麼這樣做呢？ 為什麼這個面板在這裡？” 你的頭腦開始思考所有這些問題，為什麼和困惑。

Adam：就像，這就是每個人第一次打開 DevTools 時的感受。 所以你必須真正理解這一點。

德魯：這是不可避免的……我們能做得更好嗎？ 或者這只是事物的自然秩序？

亞當：所以這是我目前對此的看法，我認為複雜性真的很容易讓自己陷入。 DevTools 就是其中之一，它們天生就很複雜。 沒有好的 UI 可以促進很多這些事情。 很多這些東西都是由開發人員構建的。 而且我認為開發人員為開發人員構建工具很好，因為你將擁有......如果這是唯一的方法，或者即使它是一個好方法，你會學習它，你會擅長它，你會覺得舒服的。

Adam：而且所有的 DevTools 都有點奇怪，因為它們是為奇怪的用例而設計的，對吧？ 發展很奇怪。 讓我們說實話。 我們製造無形的齒輪和無形的兩個四個，我們建造房屋，基本上，有無形的、虛擬的部分。 所以，是的，我們需要奇怪的工具來檢查這些東西，並告訴我們它們在輸出什麼。

Adam：現在，話雖如此，VisBug 所做的，以及我一直在慢慢將東西轉移到 DevTools 中的，是更專注的更小的工具，而不是聲稱可以做很多事情的大型工具。 我認為事情很難做得很好。 這是經典的論點，對吧？ 這是全明星，專家與通才。 兩者都不總是完美的。

Adam：但 VisBug 試圖做的是，它已經成為專家。 所以指南工具只是做指南。 而且該工具永遠不會洩漏到頁面的其他工具中。 因此，我正在嘗試使用 DevTools 來做更多的事情，DevTools 想要幫助設計師更多，這是 VisBug 幫助激發 DevTools 看到的東西。 我一直在介紹的方式是，而不是製作一個網格編輯器，例如，你可以在哪裡……“在一個疊加層中發揮網格的全部功能”，對嗎？ “你可以添加曲目，刪除曲目，等等，等等，等等。”

亞當：我想，“這聽起來很酷，也很複雜。” 我想，“網格太瘋狂了，我們不可能為此構建一個 GUI。” So I'm like, “Why don't we just handle grid template columns first, and the ability to manage the tracks in there, almost like they're chips? What if we could just add, and edit, and delete them?” They're much more physical and less of string. I'm like, “Well what we've done is, we've created a micro-experience that solves one problem really well and then doesn't leak anywhere else, and it's also really naive. It's a naive tool.”

Adam: So and a good example of that is the angel tool in DevTools. Have you seen that tool yet?

Drew: No, I haven't.

Adam: Any angle… So this is, I'm calling these type components. So their CSS is typed, and the angle is a type, and many CSS properties will take a type value of angle. And what I was like… Well, angles, those are just a wheel like a clock. Why don't we give someone a GUI so that if they click an angle they can change an angle and snap it to 45, snap it to 90, there's common interactions with just this unit of angle.

Adam: And we made a tool for it. And it's super cool. It looks great, the interaction is great, keyboard accessible the whole nine, and that's an example where I think you can make small focused things that have big impact, but don't necessarily solve some big problem. And yeah, you'll have another tool like Webflow that's trying to create entire design tool and facilitate all your CSS.

Adam: So, yeah, I don't know the right answer, but I do know that an approachability factor comes in when things do less. And so it just kind of makes it a little easier. Like VisBug, you might only know three tools on it. You only use the guides, the margin tool, and then the accessibility inspect tool. Maybe you never use the move tool or the opposition tool. 只是，是的。

Drew: I mean, talking of design tools, we've seen a big rise in the last few years of tools. Things like Figma, which are great for originating new design work in the browser. Is there overlap there with what Figma is doing and what VisBug is trying to do?

Adam: There's definitely overlap. I think they come at it from different directions. One of the things that I'm frustrated with Figma at is not something that VisBug could solve. And I think that design these days, even with the powerful tools and the Flexbox-like layouts that we have, I still think we start wrong when we draw a box on a canvas of a certain size. I'm like, “Sorry, that's just not the web. You're already not webby.”

Adam: Nothing is very content-focused. If I just drop a paragraph into Figma, it gives it some default styles and I'm like, “Why doesn't it do what the web does? Put it in one big long line.” You're like, “Contain it somehow,” right? And so I don't know. I think that Figma is empowering people to be expressive, limitless… What is the phrase I like to use? Yeah, okay, it's expression-centric. That's where I think VisBug and a lot of debug tooling is…

Adam: So yeah, one is empowering expression, and the other one is empowering inspection and augmentation. You need both, I think. I think that in one cycle of a product you're in full expression. You need to not have any limiters. You need it to feel free, create something exciting, something unique. But then as your product evolves and as more teammates get added, and just the thing grows and solidifies, you'll exit a phase of expression and into a phase of maintenance, and augmentation, and editing.

Adam: At which point your Figma files do two things, they get crusty, because your product is more… Well, it's real. Your product has made changes, and design decisions, because it's now in the medium. And so your file starts to look crusty. And then your file also just is constantly chasing production. And that's just a pain in the butt. And so VisBug is sort of waiting. So in the expression phase VisBug's like, “I can't help you very much. I'm just sort of, I'm not that powerful at expression.”

Adam: But then as you have a real product you can inspect it. And yeah, it can inspect anything. It has no limits. It goes into shadow DOM and everything. So yeah, I think they're just different mentalities for different phases of products, yeah.

Drew: So in VisBug if you have made a whole lot of changes, maybe you're sat with a client and you've tweaked some spacing, and you've changed some colors, and you've got it looking exactly how the client wants, they're happy. They obviously now think that all the work has been done.

Adam: It's done.

Drew: Which of course, it's not. 我們明白這一點。 But what is the path? What is the developer journey from that point to… I mean, I presume that it's not practical to save or export, because there's no way to map what you're doing in the browser with those source files that originated that look. But what's the journey? How do you save, or export, or is it, I guess, taking a screenshot? Or what do you do?

Adam: Yeah, there's a couple paths here. And I want to reflect quickly on what we do in DevTools. So let's say, DevTools, we made a bunch of changes, there is the changes tab in DevTools, I don't think very many people know about it, which will surface your source file changes, and some other changes in there that you could go copy paste.

Adam: And yeah, this becomes a hard thing with all these tools that are editing code output, they don't have any knowledge of source or authoring files. I mean, maybe they have source maps, but I think that's a really interesting future. If we get to something where the calculated output could be mapped all the way back to the uncompiled source, that'd be really cool. But until then, VisBug does do similar to what you do in DevTools. Where you just copy paste the sort of pieces.

Adam: But I will share some fun ways to sort of make it even better. So one thing, let's say you made a header change, color change, and a change over here. You can go to the inspect tool, and when you hover on something it will show you a delta. It'll say, “Local modifications.” And if you hold shift you can create multiple sticky pinned inspections. And so you'll go to your header, you'll click it, you'll hold shift, click your other little box, and hold shift to click another little box. And now you have tool tips showing what you changed over the actual items in the page, take a screenshot, and ship it to a dev.

Adam: And they can sort of say, “Okay, I see you changed margin top to 20 pixels. I don't use pixels or margin top in my CSS. So I'll go ahead and change to margin block start two RAM, thank you and bye bye.” And that's kind of nice, is that the editor didn't have to care or know about the system details, they just got to say something visually and screenshot it. So that workflow is nice. It's pretty hands off and creates a static asset which is fine for a lot of changes.

Adam: But if you had a lot of changes and you really changed the page and you wanted to save it, there is another extension called… Let's see. Page, single file. Single file will download the entire current page as a single file HTML element, at which point you could drag that right into Netlify and get yourself a hosted version of your prototype.

Adam: Because what VisBug does is, it writes its styles in line on the DOM notes themself. So save file comes with it all. And I've got a tweet where I went to GitHub and I made… I just totally tweaked the whole site, and it looked cool. And I was like, “All right, save file.” And I saved it, opened it up in a new tab, just dragged it into the new tab and I was like, “Well this is really cool.” Because VisBug's been wanting a feature like this for a while. But it's a whole other extension's responsibility, is taking those third party assets, dealing with all the in line… And anyway, so it's really nice that that exists.

Adam: And so you can deliver a file, if you want to, or host it somewhere, and share multiple links to multiple versions of production. You modified production and then shipped it into netlify, and someone can go inspect it, and it's still responsive at that point too, right? At that point it's not a static comp you're sharing, it's still the live, responsive… Anyway, it's exciting. I mean, there's a future here that's, I think, really, really interesting and not far away.

Adam: It's just like we're a little still stuck, as designers, in our expression land. We're just too happy expressing. And we're dipping our toes into design systems, but even those I think are starting to get a little heavy for designers. And they're like, “Ooh, maybe it's too much system now.” And like, “Ugh, I'm getting turned off. I liked making pretty stuff. And it's a whole new job if you're doing design ops,” or whatever. 所以…

Drew: I like the fact that VisBug takes an approach of not being another DevTools panel, because the interface, it embeds a toolbar on top of your page just like a design toolbar. I guess that was a deliberate move to make it more familiar to people who are familiar with design tools.

Adam: Yep. If you've used Paint or Photoshop, they all come that way. And so it was the sort universal thing, that if I put a toolbar on the left that floated over your content, almost everyone's going to be like, “Well I'll go hover on these and see what my options are. And here's my tools. And I get to go play.” And it made a really nice, seamless interaction there. I do have a really exciting almost finished enhancement to this.

Adam: So, it's so cool to me, but I don't know if everyone else is going to be as excited. And this'll be a mode that you can change in your extension settings, is how do you want to overlay the page? Because right now VisBug puts a toolbar right on the browser page, which the page is rendered normal, and I know this is going to be weird to say that, but okay, so you scroll the page, and the content, and the body is width to width in the browser, right? So it's filling the little viewport.

Adam：我有一個模組，當你啟動 VisBug 時，它會獲取整個 HTML 文檔並將其縮小到畫板中。 它看起來像一個畫板。 它漂浮在灰色空間的陰影上。 您可以無限平移它。 所以你可以從你的頁面畫布上滾動，它可以讓你做的是，看，假設你有一個很長的頁面，你想從上到下測量一些東西，你現在就可以做到，但你會在你去的時候失去上下文。

Adam：嗯，在這個新的 VisBug 縮放場景中，你按住鍵盤上的 option 或 alt，使用鼠標滾輪，或者用你的命令點擊加減號，你可以縮放你的網頁，就像它是一個畫板一樣。 我試著讓它盡可能無縫。 所以你進進出出，向下滾動，進出，從……測量……而 VisBug 根本不在乎。 它不斷繪製計算覆蓋，您可以更改間距。

亞當：因為我認為作為一名設計師，實時看到你頁面的鳥瞰圖非常重要。 動畫還在播放，你們大家。 可滾動區域仍然可以滾動，對吧？ 這個真的很酷。 你就像，“我的整個頁面在一個視圖中。” 無論如何，它幾乎完成了。 在裡面-

德魯：聽起來很迷幻。

亞當：這很迷幻。 它在裡面，我只需要確保它可以跨瀏覽器工作，因為它顯然正在做一些棘手的事情來讓你的實時頁面有這種感覺。 但是，是的。

德魯：太棒了。 是嗎……我的意思是，我認為 VisBug 會定期更新並且正在改進中。 我們可能期望在未來看到什麼？

Adam：是的，這絕對是我正在開發的功能之一。 我有一個功能……所以，當你點擊某個東西時，你會得到一個看起來像手柄的覆蓋層，對吧？ 這是一種幻覺，它應該讓你感到舒服。 目的是最終使這些手柄可拖動。 但是我必須先解決一些基本問題，例如瀏覽器中的元素沒有寬度。 因此，如果您只是開始抓住寬度，我必須努力使這種錯覺感覺正確。

亞當：你甚至可能得不到你想要的結果，因為它可能是一個塊級元素，你將寬度拉得更小，而你沒有得到它旁邊的項目的回流。 你可能想知道為什麼。 所以我有原型，你可以在其中拖動角落，拖動元素。 但我真的需要關注設計工具是如何做到這一點的。 他們總是有這個切換按鈕。 就像……看，切換開關叫什麼？

亞當：但它基本上就像收縮……我稱之為收縮包裝。 收縮包裝我的元素，它是這個元素的寬度是它的內容的寬度，而不是我的元素的寬度，在裡面粘上一些東西。 所以我在瀏覽器中需要類似的東西，覆蓋在元素上，這樣你就可以在這些之間進行選擇，甚至可以讓你在塊和內聯之間進行選擇，這樣你就可以獲得你想要的結果。

Adam：但最終的目標是 VisBug 不希望完全由鍵盤驅動。 我希望你能夠拖動間距。 如果您在頂部看到 12 個邊距，您應該能夠伸手抓住它，而現在您必須敲擊鍵盤以指定框的頂部需要添加邊距。

亞當：所以是的，在戰略方面，我有幾個怪癖要解決。 但讓它更接近設計工具是一個非常重要的目標。 甚至我也會屈服於此。 就像，好吧，如果你想改變寬度並且你會得到一個奇怪的設計，總有辦法用 VisBug 擺脫它，就像位置工具真的讓你擺脫流程一樣。 所以流量正在破壞你的想法，定位工具讓你逃脫。

亞當：所以……如果有人真正精通 VisBug，他們會大吃一驚，因為它是無限的，就像，你能帶來什麼？ 它有一個表達式元素。 絕對有表現力的策略。 但無論如何，長話短說，幻覺是，我只想讓它越來越小。 我希望這種錯覺就像，“哇，我真的感覺自己像一個設計工具。”

亞當：然後，是的，對導出進行一些改進會很好。 而且，為 DevTools 導出的增強功能會很好，這並不能真正阻止我們。 所以我不知道。 有很多問題，一定要去投票。 我認為我想做的下一個重要功能之一是綠線。 因此，不僅僅是在懸停時顯示可訪問性疊加層，而是用綠線真正指示一些事情，並公開更多信息，並顯示更多信息，我不知道。 是的。

Drew：有點想像這樣構建一個 Chrome 擴展程序的過程，我的意思是，假設它都是用 JavaScript 實現的，它與常規 Web 開發有多少相似之處？ 構建 Chrome 擴展程序。

亞當：這是個好問題。 這是……呸，這很難。 這很古怪。 首先，您啟動代碼的環境不是瀏覽器。 他們並沒有真正讓你在那裡完全訪問。 你可以，如果你真的對它感到棘手，VisBug 不得不畢業，這個更棘手的場景。 所以現在，我曾經在……這會變得如此模糊如此之快。

Adam：因為你的擴展有多個沙箱，隱私問題。 而且它們使在實際頁面上執行腳本變得困難，對嗎？ 因為您不希望有人在您啟動事物或其他東西時提交您的表單，將其提交給他們自己或其他什麼。 它可能真的具有破壞性。 所以它有一些這樣的怪癖。 有一座橋你必須過。 其中一個一直困擾著 VisBug 的是，VisBug 曾經使用……

Adam：所以這都是自定義元素，自定義元素允許您將豐富的數據作為屬性傳遞給它們。 所以你說的是，customelement.foo=myrichobject，充滿了數組或其他什麼。 而自定義元素只是將其作為節點本身的一些數據獲取。 但是由於我處於這個奇怪的小沙盒世界中，如果我嘗試在我的對像上設置類似這樣的獨特東西，基本上它就會被過濾掉。 他們已經確定某些東西不能……所以我可以將一個字符串傳遞給我的自定義元素，但我不能將它傳遞給一個豐富的對象。

亞當：但是，是的，除了像這樣的小怪癖，一旦你把流量降下來，如果你花時間得到一個匯總場景，這將是一個小時左右的工作，以便你在你的東西中提供 LiveReload ，它可以變得很自然。 老實說，我認為 Firefox 擁有最好的擴展開發體驗，如果您精通 CLI，您可以使用一個命令啟動某些東西，然後它會安裝它，為您提供這些 LiveReload 功能，並為您提供調試工具。 它有點牽著你的手，它真的很好。

亞當：但最終，它有點古怪。 這就是為什麼我在那個看起來像一堆畫板的演示網站上做了很多工作，因為我大多數時候真的不需要真正的網頁來進行 VisBug 測試，只要我有畫板模擬各種問題，或者有可訪問的東西來查看，然後給我我需要看的內容。 我在瀏覽器中做了很多工作，就好像它只是一個普通的 Web 應用程序一樣。 所以 VisBug 的開發體驗真的很簡單，除非你試圖在瀏覽器上測試它，然後它就會變得有點混亂等等。

德魯：這是非常有趣的見解。 所以我今天一直在學習有關 VisBug 的所有信息，你最近在學習什麼，Adam？

亞當：我還在提高我的炒鍋技術。 所以我想成為一個炒鍋的人，我不是在說 90 年代的磁帶播放器。 我想翻轉蔬菜，讓它們在空氣中著火，用一些美味的香料覆蓋它們，然後把大蒜真正烤焦，讓它變得香脆可口。 然後把它放在一張小米飯上，把它滑向你，看看你的想法。

亞當：所以我現在對夏天很興奮，因為這意味著我可以拿出鍋，回到快節奏、熱的烹飪環境中，這真的很有趣。

德魯：太棒了。 聽起來很好吃。 親愛的聽眾，如果您想從 Adam 那裡聽到更多信息，您可以在 Twitter 上關注他，他是 @argyleinc，並在 nerdy.dev 上找到他的個人網站。 如果你想試試 VisBug，你可以在 Chrome Web Store 中找到它，你可以在 visbug.web.app 上試用沙盒版本。 感謝您今天加入我們，亞當。 有沒有什麼離別詞。

亞當：不，你真的很好。 這真的很甜蜜。 謝謝你邀請我，我真的很感激。