アダムアーガイルとポッドキャストエピソード37を壊す：VisBugとは何ですか？

このエピソードでは、VisBugについて話します。 それは何ですか、そしてそれはChrome DevToolsにすでにあるオプションの配列とどのように異なりますか？ ドリュー・マクレランは、その作成者であるアダム・アーガイルと話をして調べます。

メモを表示

• VisBugサンドボックスと遊び場
• Twitterのアダム
• アダムの個人サイト
• YouTubeのVisBug
• VisBug 101

毎週の更新

• オンラインイベントに使用する会議プラットフォーム：Hopin by Amanda Annandale
• StephanieEcklesによるCSSコンテナクエリの入門書
• 修正が必要なイライラするデザインパターン：VitalyFriedmanによるバースデーピッカー
• Tree-Shaking：ÁtilaFassinaによるリファレンスガイド
• BeauHartshorneによるコアWebバイタルの改善方法

トランスクリプト

Drew McLellan：彼は明るく情熱的なパンクエンジニアであり、ウェブを愛しています。彼は自分のスキルをクラス最高のUIとUXに使用し、周囲の人々に力を与えることを好みます。 彼は大小の企業で働いており、現在はChromeでGoogleで働く開発者の擁護者です。 彼はCSSワーキンググループのメンバーであり、デザインデバッグツールであるVisBugの作成者です。 つまり、彼はデザインとUXの使い方を知っていますが、生きているBipedよりも多くのフリップフロップのペアを所有していることをご存知ですか？ 私の壊滅的な友人、アダムアーガイルを歓迎してください。

Adam Argyle：こんにちは。

ドリュー：こんにちはアダム、お元気ですか？

アダム：ああ、私は壊している、あなたはそれを知っています。

ドリュー：聞いて良かった。 そこで、今日はあなたのプロジェクトであるVisBugについて、そして一般的には、デザインのデバッグの背後にある概念と、それがプロジェクトのワークフローにどのように適合するかについてお話ししたいと思います。 つまり、開発者向けのブラウザデバッグツールを長い間使用してきました。つまり、おそらく10年以上になります。 しかし、それらは明らかにコードに非常に焦点を当てています。 では、VisBugの違いは何ですか？ そして、それが解決しようとしている問題の種類は何ですか？

アダム：すごい。 ええ、それが根付いている主な問題は、フロントエンドエンジニアとして常にデザイナーと仕事をしていることです。私はいつもこの瞬間が大好きで、「オーケー。 最後の仕上げをしています。 デプロイするまであと1、2日あります。 デザイナー、座って、これを批評しますか？ ブラウザや携帯電話などでローカルホストのバージョンを開いて、表示されている内容について話してほしいのです。」

アダム：そして、これを何年も続けて、常にこの相互作用を愛した後、私は、タスクがどれほど一般的で単純だったかのために、しばらくして罪悪感を感じ始めました。 「ここから1ピクセル下にあります。 ここに5ピクセルのマージンがあります。」 そして、それは常にニトとナッジであり、スペーシングとタイプにニトとナッジでした。 つまり、「ああ、30分間待って、角度を変更するなどして、DOMが要求をサポートできるようにDOMを調整する」などということはめったにありませんでした。

アダム：それは通常小さなものでした。 そして、私は最終的に調査を行い、Googleでこれらすべてのデザイナーを調査しました。 そして、私は「DevToolsを開いたとき、あなたは何をしますか？」 そして、彼らがただ基本を必要としているということは、一種の響きでした。 それで生まれたのですが、「これはもっと簡単なはずです。 チャイルドシートの色を変えるためだけに、フェラーリのボンネットを開けたり、エンジンの塊を動かしたりする必要はありません。 不公平だ。 デザインツールのように、車のシートに触れて色を変えることができるはずです。」 「何かがこのワークフローを容易にする可能性がある」と私は思っていました。 そして、私は「わかりました。ソリューションを作成できるかどうかを確認するために、何かをハックするつもりです」と言っていました。

アダム：そしてそれがすべての始まりです。 それは本当にスペーシングから始まり、次にタイポグラフィから始まりました。 そして、デザインツールをエミュレートする選択メカニズムをダウンさせると、「他に何ができるでしょうか？」のようになりました。 そして、それはそこから進み続けました。 しかし、ええ、その瞬間に生まれました。

Drew：つまり、クライアントがロゴを大きくするように要求するということです。VisBugは、ブラウザーがそのような微調整を行うためのデザインツールのように動作するのを支援します。 Illustrator、Photoshop、Figma、またはこれらのタイプのもののいずれかに非常に近いです。

アダム：うん。 そのユースケースも良い例です。 あなたがクライアントと一緒にいる可能性があり、彼らが「ああ、私たちはこれが大好きです」と言うので、これはとても古典的です、「私たちはデザインが大好きですが、その色の青は私たちにとって難しいです」。 そして、あなたは「本当に？」のようなものです。 これは、人々がフォームを提出してお金を稼ぐことができるのに、今すぐ青について私に話したいですか？ そして通常、それは全体のサイクルを作成します。 PMは、「わかりました。リクエストを削除してから、デザインに送信します」と言います。

アダム：しかし、デザイナーがそこにいて、それを表示しているのが彼らのブラウザである場合、彼らは次のようになります。 さて、物をクリックして色を変更します。」 また、ブラウザで変更のプロトタイプを作成するだけで、作業のサイクル全体を把握できます。 そうです。 既存の製品に対して最も効果的ですよね？ デバッグツールだからです。 必ずしも生成ツールではありません。 それはあなたのためのサイトを作成しません。 それは可能ですが、それはちょっと厄介です。

ドリュー：技術的には、Chromeブラウザにインストールする拡張機能です。 そうですか？

アダム：うん。 そしてそれは拡張機能です。 起動すると、「VisBugというカスタム要素があります」というJavaScriptファイルがダウンロードされます。 次に、DOM要素vis-bugをページに配置します。 そして、私はその瞬間を取り、それをツールバーに変えて、ページ上のイベントを聞き始めます。 私はあなたのホバーイベントを聞き、あなたのクリックイベントを聞きます。 そして、私はそれらを傍受するために最善を尽くし、あなたのメインページと競合しないようにしています。

アダム：しかし、そうです、それが本質です…それが拡張機能である唯一の理由は、ページに簡単に配置できるようにするためです。 この時点では、ブラウザ間で提供されるいくつかの設定がありますが。 しかし、それでもほとんどが99.9％であり、依存関係のないカスタム要素です。 私は自分が使っているカラーライブラリが好きだと思います。それ以外はすべてバニラです。 うん。

ドリュー：それがFirebugのようなものから始まったと思いますね。 当時のFirefox拡張機能として。

アダム：うん。 それがVisBugと呼ばれる理由です。 これはFirebugに非常に触発されていますが、ビジュアルデザイナー向けです。

ドリュー：ああ。 そこに行きます。 つまり、これはおそらく、ビジュアルツールについて話すのに理想的な形式ではなく、オーディオポッドキャストです。 ただし、必要に応じて、VisBugが提供するツールとオプションのいくつかを実行してください。

アダム：もちろんです。 つまり、VisBugが最初に行うことの1つであり、自宅やコンピューターにいる場合は、visbug.web.appにアクセスして、拡張機能なしでVisBugを試すこともできます。

ドリュー：ああ。

Adam：これはWebコンポーネントなので、ここvisbug.web.appにたくさんのアートボードがあるように見えるWebページをロードしました。もちろん、VisBugがプリロードされています。 そして、このサイトの目標は、あなたが遊んだり、探索したり、削除したりできるようにすることです。 削除キーは、そもそも最も満足のいくツールの1つだと思います。 あなたは「ページに何ができるの？」のようなものです。 そして、あなたは「まあ、私はそれを破壊することができます」のようなものです。

アダム：そして、私はあなたが削除を保持できるようにそれを作りました、それは次を見つけるでしょう…これは削除ではかなり難しいです。 何かを削除すると、次の兄弟が選択されます。 したがって、次の兄弟を永久に選択します。 全体を削除するまで削除を押し続けると…とにかく、とても満足です。 更新を押すと、すべてが戻ってきます。 ただし、VisBugに付属している最初のツールなので、起動したばかりの場合はガイドツールです。 そして、私は文字通り紙を画面にかざすか、システム拡張機能を入手して、マークを付けたり、線を作成したりしていました。

アダム：ええ、多くのデザイナーにとって、ある時点でアライメントが非常に光学的になるからですよね？ 彼らは、必ずしも数学的整列を望んでいませんよね？ これが、タイポグラフィに光学カーニングがある理由です。 数学のカーニングではありません。 これは人間のカーニングです。 そのため、ガイドツールは、デザイナーから発生する多くの問題が拡大して配置を確認していることに基づいています。 間隔は良いですか？

アダム：それはガイドツールが行う2番目のことです。 起動して何かにカーソルを合わせると、カーソルを合わせた要素の周りに小さなボックスが表示されます。 そして、支配者が通常行うように、破線のガイドが表示されます。 そして、SketchやZeplinのように、ホバーしてこれらのガイドを取得するのと同じように、同じ概念で、ページに表示されます。 そして、何かをクリックしてから新しい目的地にカーソルを合わせると、測定ツールが表示されます。 そして、測定ツールはピクセル単位で計算されます…視覚的には、その間にいくつのピクセルがありますか。 誰かが言ったことではありません。 すべての間隔を合計しているわけではありません。これをクリックするだけで、他のボックスからこれだけ離れています。

Adam： Shiftキーを押しながらクリックを続けることができ、基本的に5つのアイコンの間隔が等しいことを確認できるので、これは非常に役立つと思います。 そして、それはほんの数回のクリックです。 コードを知る必要はありません。VisBugを起動し、ホバー、クリック、クリック、クリックするだけで、次のように表示されます。 うん。 これらのそれぞれの間に15ピクセル。」 または、ある種の迷惑なものを取得する場合は、ボックスをクリックしてからその親ボックスをクリックすると、上部の距離が9で、下部の距離が8であることがわかります。 そして、あなたはこう言います。 どういうわけかその中間です。」 そして拳を振る。

アダム：でも、少なくともガイドツールを使えば、それを簡単に見ることができます。 そうそう、それはガイドツールです。

ドリュー：私は間違いなくそこにいて、紙片を画面にかざしていた。 また、私が使用するもう1つのトリックは、別のブラウザーウィンドウを開き、ウィンドウの端を使用してアイテムを整列させることです。 次に、コードを変更して更新してもすべてが整列するように、すべてを適切な場所に保持するようにします。 ええ、理想的な働き方ではありません。

アダム：理想的な働き方ではありません。 うん。 そして次があります…それで、ああ、そしてそれの最初のバージョンは非常に緩いものでした。 スナップしませんでした。十字線をかざしただけです。これは後で追加する機能です。 そのため、一部のユーザーは、「ねえ、私はスナップが大好きです。それは私のデザインツールのようです。 しかし、緩い測定が必要な場合はどうなりますか？ それとも、手紙をやりたいのですが、レターボックスではなく、手紙を測定したいのですか？」 したがって、このガイドツールは、修飾キーを持つように非常に簡単に変更できます。

Adam：ここで、VisBugは少し異なりますが、うまくいけばおなじみですが、ホットキー修飾子が非常に重いのです。 つまり、プロのデザイナーを見るのと同じように、彼らは非常にホットキーに精通しています。 そして、彼らはここでホットキーを押し、ズームインし、向こうのホットキーを押し、キーボードからすべてのナッジを行っています。 そのため、VisBugは、物事を変更する方法において非常にキーボード中心です。

Adam： VisBugでは複数の選択が可能であり、同時に100個のアイテムの間隔を変更できるためです。 そして、それは比較的そうです。 とにかく、いくつかの興味深い癖がありますが、修飾子の概念のキーボードは本当に重要です。 また、オプションを押したまま、シフトしたり、多くのツールでコマンドを実行したりして、別のツールを入手したり、新しい種類の機能を利用したりできます。

ドリュー：それで、キーボードショートカットを学ぶのに本当にお金がかかるツールの1つです。

アダム：そうです。 したがって、VisBugを起動し、ツールアイコンの1つにカーソルを合わせると、内訳が表示されます。 小さなフライアウトメニューが表示され、このツールを選択するためのホットキーが表示され、ツールで何ができるか、およびツールを取得するためにどのような操作を行うかが示されます。 したがって、ガイドツールは、「要素ガイド、ホバーするだけです。 何かを測定し、クリックして、新しいものにカーソルを合わせます。 スティッキーな測定値はシフトプラスクリックであるため、持続します。」

アダム：そして、これらのガイドはスクリーンショットにも本当にいいです。 したがって、PRをレビューしている場合、フロントエンドエンジニアとして、またはPRをレビューしているデザイナーとしても、これは非常に強力な方法であり、忠実度の高い検査を受けることができます。 どのような種類が私たちを次のツールに導きます。 次のツールについて聞きたいですか？

ドリュー：ええ、確かに。 行きましょう。

アダム：すごい。 次は検査ツールです。 そしてこれは次のようなものです…デザイナーは通常、CSSのすべてを望んでいませんよね？ 彼らが期待するとき…私はほとんどFirebugと言いましたが、Chrome DevTools、あなたは完全なリストを手に入れますよね？ このH1を選択したので、ブラウザのスタイルシートに戻るまですべてを説明します。 そして、デザイナーは「ブラウザは何ですか？ ブラウザにはスタイルシートがありますか？」

ドリュー：そのスクロールパネルの暗い底で下に。

アダム：濁った底だよね？

ドリュー：うん。

アダム：それはあなたがすべての層をはがしたようなもので、それからあなたは「ああ、私はもうこれらの層が好きではない」のようです。 そして、ここにある検査ツールには、次のように書かれています。 ただのボーダーカラーです。」 基本的に、それが一意である場合にのみ何かを表示するので、CSSプロパティで私をカバーしないでください。 そして、私は本当に色、タイポグラフィ、そして間隔に本当に興味があります。 それで、余白、行の高さ、フォントファミリの本当に重要なものを見ていきますよね？ ページ上のフォントファミリが何であるかを示すためだけに、拡張機能があります。

Adam： VisBugでは、これは検査ツールの単なるラインアイテムです。 つまり、VisBugを起動し、検査を押して、タイポグラフィにカーソルを合わせるだけで、フォントファミリがわかります。 そうそう、それはデザイナーをそれが表面化するものに集中させようとします、そうです。

ドリュー：そのツールは継承されたスタイルを表示していません。 そうですか？

アダム：その通りです。 それらが継承され、一意でない限り。 したがって、それらが…テキストの色か何か、テキストの色が文字通り単語継承ではない場合、それは計算された値であり、何か面白いものであることがわかります。

ドリュー：ええ、それは本当に便利です…はい。 何かのその1つのインスタンスに文字通り適用されているものに集中するのに役立ちます。これは、明らかに変更したいものです。 つまり、これは本当に役立つと思います。これらのツールはすべて、あなたが言ったように、利害関係者のフィードバックを得るのに本当に役立つでしょう。 そして、クライアントと対話的に作業するようなものです。

ドリュー：最近はますますやらなければならないので、画面共有でも同じようにうまくいくと思います。 誰かとコンピューターの前に座っている必要はありません。通話の相手に座ってブラウザーを共有し、そのようにすることができます。 クライアントが画面を指さして言うことができないときにフィードバックを得るのに非常に効果的な方法だと思います-

アダム：もちろんです。

Adam：ライブWebページをZeplinアートボードのように見せることは常に魔法のようなものです。 誰かが「なに…どこか新しいところに行ったの？」みたいなものです。 そして、あなたは「いいえ、これはあなたの製品です。 非常に視覚的に操作しているだけです。」 ええ、それは本当にいいことができます。

Drew： VisBugが置かれているのを見たことがある、またはあなたに起こった興味深いユースケースは他にありますか？

アダム：うん。 だから、ええ、始めるのが難しいほどたくさんあります。 ああ、重要なのは開発者間のコミュニケーションです。 VisBugは計算値を処理します。 したがって、作成された値は考慮されません。 そして、それは本当に素晴らしいことです。なぜなら、画面上でピクセルが計算される方法で絶対的な最終結果を測定および検査しているからです。 そして、それは本当に素晴らしいことです。オーサリング側ではなく、結果に取り組んでいるときに、そのように会話することができます。

アダム：そして、「さて、これが視覚的に得られたものである場合、オーサリング側でどのように失敗したのですか？」のように戻ることができます。 次のツールは、アクセシビリティ検査ツールです。 したがって、検査ツールを使用すると、要素のスタイルを簡単に確認でき、デザイナーにとって非常に使いやすい方法でスタイルを分類できます。 アクセシビリティツールは、ページ上のすべての要素を検査するのに役立ち、アクセス可能なプロパティを表示します。これにより、何かが行われたことを確認しやすくなります。

アダム：それでPR…そして物事はしばしば作成されます。 つまり、これも開発者から開発者、デザイナー開発者であり、インターフェースを確認していることになります。 それはとても重要です。 インターフェイスを見ていて興味がある場合は、VisBugにユースケースがあります。 ブラウザでプロトタイプを並べ替えることができるユースケースもあります。 それで、クライアントが青を試してみたいというようなものについて話しました。 さて、それは非常に簡単なシナリオです。

アダム：でも他にもあります。 VisBugでコマンドDを押すと、要素が複製されます。 そして、それはあなたが複製しているものを気にしません。 したがって、ヘッダーを複製し、2つのヘッダーの間にいくらかのスペースを追加して、ブラウザーでバリアントをライブにすることができます。 ヘッダーテキストをダブルクリックすると、編集可能なテキストフィールドになります。新しい見出しを試して、見出しがどのように収まるかを確認します。 間隔を調整して、開発者の作業をすべて保存し、ソースファイルなどを見つければ、…

アダム：そうですね、それはあなたが探求し検証するのを助けることができます。 それはちょっと奇妙なことです…つまり、DevToolsが行うことの多くですよね？ それはあなたが終わった後にやって来ます、それは実際にあなたにソースコードをあまり頻繁に与えません、あなたがDevToolsからコードをコピーすることはめったにありません。 キーと値のペアをコピーできます。 「ああ、私はこのスタイルを変えました。」のように。 しかし、とにかく、ええ。

ドリュー：うーん（肯定的）。 うん。 アイテムを複製したいと思うかもしれない、ある種の特に視覚的なケースを考えることができます。 ページのセクション全体を複製して、予想よりも多くのコンテンツがあった場合のシミュレーションを行うことをお勧めします。

アダム：はい。 これがカオステストのユースケースです。

ドリュー：うん。

アダム：もちろんです。

ドリュー：これは私たち全員が対処しなければならないことであり、ある種のCMSベースのシステムとそれらすべての種類の楽しいタスクを使用して設計します。

Adam：はい、それも非常に重要なユースケースです。 私がそれをするので…ええ、私が言ったように、見出し。 テキストをダブルクリックするだけで、キーボードをバタンと閉めることができます。 何とか、何とか、何とか、何とか、そしてたくさんのスペースを打つ、何とか、何とか。 そして、私は「さて、レイアウトはどうでしたか？ ああ、それは良かった。 さて、いいですね、次のことに移ります。 これを4回複製するとどうなりますか？ すべての間にまだスペースがありますか？ 次のアイテムの隣に流れますか？」

アダム：それは、ええ、コンテンツの混乱のシミュレーションにとって本当に素晴らしいことです。 本当に短いタイトル、本当に長いタイトル、友達がいない、100万人の友達がいます。 UIでこれらのユースケースをどのように処理しますか？ うん。

Drew：つまり、ブラウザベースのコンテンツで動作します。 では、PWAと通常のWebページはどうでしょうか。

アダム：はい、そうです。 つまり、Spotifyをインストールしている場合は、常にこれを実行します。Spotifyをインストールしているので、「Spotify、あなたは検査できないアプリのように見えます」のようになります。 しかし、何を推測しますか？ VisBugは気にしません。 VisBugはすべてのものをオーバーレイし、すべてのタイポグラフィを検査します。 ライトテーマを作成しました…ああ、Spotifyのライトテーマを作成したところにツイートがあります。

アダム：ああ、これは色のプロトタイピングの別のユースケースでした。 たくさんのステッカーシートをいじることなく、製品自体に軽いテーマを作成できますよね？ ですから、この重要な考え方もあります。VisBugを使って、人々があなたの製品を遊び場として利用できるように支援したいと思います。 それを次のように使用してください…それはとてもリアルです。 デザインコンプよりもリアルです。 だから、そこでもう少し時間を過ごしてください。 実際の製品に基づいて、より効果的な設計上の決定を下せることがわかると思います。

ドリュー：そして、アクセシビリティの場合も特に興味深いです。なぜなら、特に最近では、コンポーネントライブラリで非常に多くの作業を行っており、ページの小さなコンポーネントを調べているからです。 そして、顧客が実際に対話するようなビューを作成するために、統合されたすべてのものを確認するために費やす時間を短縮します。 また、ページに表示されないアクセシビリティや属性などの詳細を監視することは非常に困難になります。

ドリュー：見えないものを監視するのは非常に難しい。 つまり、これは、ツールが実際に何かを検査して、それが正しい役割を果たしていることを確認するのに本当に役立つ場所です。

アダム：そうです。 それが正確なユースケースです。 PMがこのことを確認できるようにしたいと思います。 デザイナーがアクセシビリティを確認し、ツールを開いてDOMノードを見つける必要がないようにしたいのですが、すべて要素パネルに詰め込まれていて、奇妙に見えます。 「これがエリア属性です。存在する場合はタイトルです。」とだけ書かれています。 他にもいくつかのアクセシビリティツールがあります。 VisBugには検索アイコンが付属しています。 検索アイコンには、複数の方法で操作できます。

アダム：最初にページをクエリします。 したがって、必要な要素タイプまたは要素クラス名がわかっている場合は、それを検索するだけでよいので、マウスで見つける必要はありません。 ただし、スラッシュコマンドも含まれています。 したがって、VisBugにはプラグインがあり、ページ上でスクリプトを実行します。 したがって、3つまたは4つ保存したブックマークがある場合は、「すべての境界線が強調表示され、ボックスが表示されるので、これを使用します」のようになります。 それはデバッグトリックか何かのようなものです。

Adam：おそらくVisBugプラグインです。 したがって、VisBugを起動し、スラッシュを押すと、オートコンプリートが取得され、さまざまなプラグインがすべて表示されます。 そして、エラーをオーバーレイする本当に素晴らしいいくつかのアクセシビリティのもの、およびそのようなさまざまなものがあります。 だから私は同意します。 アクセシビリティはもっとアクセスしやすいはずです。 それは言うのが足りない。 ただし、ツールベルトに近づける必要があります。 そして、私は時々それが遠すぎると思います、そして多分それはそれが逃される理由です。 ですから、もう少し前に出して中央に配置し、チェックしやすくなることを期待しています。 うん。

Drew：興味深いことに、VisBugは、色のように、計算された値のようなもので機能します。 つまり、不透明度のレベルが異なる複数のレイヤー要素がある場合、画面にレンダリングされている正確な色を測定できるのではなく、

アダム：ああ。

ドリュー： …個々の要素を見て、どういうわけかそれを解決しようとしていますか？

アダム：それは本当に良い質問です。 ですから、私が質問を正しく理解している場合、これはフロントエンドの古典的な難しさです、ええ、あなたが半分不透明なテキスト単語を持っているかどうか、灰色の上と白の上でその色は何であるかをどうやって知るのですか？ ？ そして、どのようにそのコントラストを知っていますか？ 今のところわかりません。 したがって、VisBugは色を認識しており、「50％グレー」、またはそこにある色が何であれ、と表示されます。 しかし、それよりも賢いことは何も知りません。 できません…

アダム：その場合、あなたがしなければならないことは、キャンバスを作成し、そこにあるすべてのレイヤーをペイントしてから、スポイトまたは…を使用することだと思います。つまり、キャンバスでレンダリングし、それらをすべて一緒に粉砕して、単一のペイントされたレイヤーを選択し、単一のピクセル値を取り出して、他のものにレイヤー化された後の実際の最終的な計算されたグレーが何であるかを確認します。

Adam：誰かがそれを特定したと思います。あるいは、GitHubの問題としてそれがいいと思います。 VisBugはこれを容易にすることができるので、100％。 VisBugの舞台裏では、テキストメトリックをすでに使用しています。ここでは、物事にカーソルを合わせると、フォントに関するクレイジーな情報が得られます。 エックスハイトやキャップハイトなど、ほとんど情報が多すぎますが、さらに多くの情報が含まれます。 そして、それは、「ああ、私はある時点でオフになっているようなものです」のようなものです。 そこで、信号とノイズを比較する方法を理解する必要があります。

アダム：しかし、ええ、私はこの思考プロセスが好きです。なぜなら、それを行うツールが必要だからです。 そして、それを計算する方法を知っていれば、VisBugにそれを行うように教えることができます。これは、不透明度に関連する計算された色を持つための非常に優れた機能です。 大好きです。

ドリュー：ええ、つまり、背景にテキストを表示するというのは、アクセシビリティの要件を満たすのにコントラストが十分かどうかわからない、一種の標準的なケースです。 おそらくそうではないかもしれませんが、コントラストが低すぎるため、コントラストが良好になるまで値を微調整したいのですが、ブランドの色に関してクライアントが最初に望んでいたものからそれほど離れていませんと物事。

アダム：私はそのバンプを、あなたが通過するまでバンプと呼びます。

ドリュー：うん。

アダム：そういう感じだから。 「ああ、スコアが少し足りない」みたいな感じです。 つまり、HSLの明度に移動し、ぶつかって、ぶつかって、ぶつかって、「Ding」のようになるまで小さな数字が刻々と変化するのを確認します。緑色のチェックマークが表示されます。 私は「オーケー、かっこいい」みたいです。 そして、ええ、時々、その色のいくつかはクールではありません。 それで、あなたは進行中の3.0知覚アクセシビリティ作業の多くを研究しましたか？ AAまたはAAAがなくなるように、数を増やし、フォントの薄さなどを含めます。 したがって、細いフォントの場合はスコアが低くなり、太いフォントの場合はスコアが低くなります…対照的なものがたくさんあるためです。

ドリュー：ええ、いや、私はそれを見たことがありませんでしたが、それは聞こえます-

アダム：とにかく、探索するのは本当にクールなことです。

ドリュー：それは魅力的に聞こえます、はい。 私はそれについて話す誰かを見つけなければならないでしょう。 それは別のエピソードです。 つまり、一部の開発者は、VisBugが実行していることはすべて、DevToolsのCSSパネルを介して実行できると主張するかもしれません。 そして、それは一種の公平だと思いますが、おそらく要点を見逃していると思います。そうです、変更を加えるときにCSSを操作しているのですが、開発者に焦点を当てたインターフェイスではなく、デザイナーに焦点を当てた一種のユーザーインターフェイスを最優先にしています。 それはそれの公正な特徴ですか？

アダム：それは本当に公正なことです。 そして正直なところ、最高のアイデアはVisBugからDevToolsに移行します。 そして、彼らはすでに持っています。 したがって、VisBugは、任意の要素でコマンドオプションCを押すと、すべての計算されたスタイルを取ります。少なくともそれは一意です。 繰り返しになりますが、これらの継承されたプロパティをすべて提供するだけではないようなものを実行します。 しかし、それらをすべてクリップボードに配置すると、そのスタイルを別の場所、スタイルシート、CodePenに貼り付けて、数回クリックするだけで要素を文字通り再作成できます。

アダム：そして、そのような相互作用は、DevTools、その要素パネルに浸透しました。 ただし、そうではないものが他にもあります。つまり、DevToolsは単一ノードの検査専用ツールです。 そして、VisBugは、デザインツールのマントラに従います。つまり、複数選択できるはずです。 一括編集、一括検査ができる必要があります。 そのため、間隔を空けるために常にVisBugを使用しています。 複数の要素を強調表示して、マージンが崩壊するのを見ることができるからです。

Adam： DevToolsでは、複数のマージンを表示する方法はありますが、ほとんどの場合、一度に1つのノードしか表示できないため、表示できません。ただし、同じではありません。 そして、ええ、それはそのように本当に楽しいことができるこれらのニッチなユースケースを持っています。 もう1つは、ハイライト表示する場合です。たとえば、タイポグラフィシステムがあり、ストーリーブックなどのようにH1からH7がある場合、VisBugですべてをハイライト表示し、Shiftキーを押しながら、すべてをクリックするだけです。 ブープ、ブープ、ブープ、ブープ、タイポグラフィツールに移動して上下に押すと、それぞれに相対的な変化が生じます。

アダム：それで、彼らのそれぞれは、1つまたは1つ下に微調整します。 そして、それはDevToolsが非常に簡単にするものではありません。 そして、ええ、それはもう少し不可知論者であるため、そのようないくつかの超能力を持っています。 そして、それは常に配列を反復する準備ができています。 うん。

ドリュー：では、VisBugの起源は何でしたか？ そして今、それは単なる個人的なプロジェクトですか？ それともGoogleプロジェクトですか？ またはそれの状態はどうですか？

アダム：うん。 つまり、最初のステータスは、Googleプロジェクトです。 その主な目標は、DevToolsに入る前に、プロトタイプを作成して探索する場所になることです。 少なくともGoogle側からは。 しかし、私の個人的な側面からは、一般的なタスクを実行する場所、または一般的なタスクを実行するためにいくつかの最適化を実行する場所として、それをまだ見ています。 そして、より多くの聴衆にDOMを調べる方法を提供するためだけに。

Adam： DevToolsは非常に強力だと思いますが、非常に威圧的です。 その中のたった1つのタブで学ぶのにキャリアが必要です。 私はまだDevToolsで物事を学んでおり、常にそれらを使用しています。 そうそう、これはある意味で別の聴衆のようなものです。 コーディングするつもりはないが出力に興味を持っているのは、初心者、入ってきた人々、あるいはPMやマネージャーのような人々ですらあります。 そして、それは彼らに一種の、ええ、そこに入るための軽い道具を与えるだけです。

ドリュー：それはあなたが提起する興味深い点です。なぜなら、私は個人的に、これらすべての種類のDevToolsを管理する上で快適なワークフローを見つけるのに苦労していることに気付くからです。 そして、これらの小さな閉所恐怖症のパネルがすべて揃っているので、それらを別のウィンドウに切り離すことができますが、2つの異なるウィンドウを追跡する必要があります。 そして、いくつかのブラウザウィンドウを開いたら、それはできません…1つに焦点を合わせても、どのDevToolsがそれに属しているのかわかりません。

ドリュー：そして、パネル自体の中で、それは一種のワイルドウェストのユーザーインターフェイスの慣習のようなものです。 あなたはスクロールし、物事はあなたが予期していなかった奇妙なことをし始めるでしょう。 そして、ユーザーエクスペリエンスの観点からは、それはすべて大きな混乱のように感じます。

アダム：そうです。 うん。

ドリュー：それは避けられないと思いますか？ それはもっと良くなることができますか？

アダム：私は間違いなくここで考えを持っています。 そして、ええ、私は良いと思います…それで、あなたが今、次のようなリスナーを持っているとしましょう。「私はDevToolsにかなり精通しています。 彼らはそんなにクレイジーだとは思わない。」 「さて、AndroidStudioまたはXcodeを開いてください。 プロジェクトを開始し、DevToolsを確認し、出力を確認します。 今、どのくらい親しみを感じていますか？」 おそらく非常に外国人です。 あなたはそれを見ています。「これはゴミです。 なぜ彼らはこれをするのですか？ なぜこのパネルがここにあるのですか？」 そして、あなたの心は、なぜこれらすべての質問と混乱で競争し始めます。

Adam：そうですね、DevToolsを初めて開いたときは誰もがそう感じています。 だからあなたは本当にそれに共感する必要があります。

ドリュー：それは避けられないことですか…もっとうまくやれるでしょうか？ それとも、これは一種の自然な秩序ですか？

アダム：これが私の現在の見解です。複雑さは本当に簡単に理解できると思います。 そして、DevToolsはそれらの1つであり、自然に複雑です。 これらの多くを容易にするための優れたUIはありません。 これらのものの多くは開発者によって構築されます。 そして、開発者向けの開発者向けツールを構築することは問題ないと思います。なぜなら、それが唯一の方法である場合、またはそれが良い方法であるとしても、それを学ぶことになるからです。それ、そしてあなたはそれで快適になるでしょう。

Adam：そして、すべてのDevToolsは、奇妙なユースケースのために作られているので、ちょっと奇妙ですよね？ 開発は奇妙です。 正直に言いましょう。 私たちは目に見えない歯車と目に見えない2x4を作り、基本的には目に見えない仮想部品で家を建てます。 そうですね、これらを調べて、何を出力しているのかを教えてくれる奇妙なツールが必要です。

Adam：そうは言っても、VisBugが行うこと、そして私がDevToolsにゆっくりと移行してきたことは、多くのことを行うと主張する大きなツールとは対照的に、より焦点を絞った小さなツールです。 物事が本当にうまくいくのは難しいと思います。 そして、これは古典的な議論ですよね？ これはすべてのスター、スペシャリスト対ジェネラリストです。 どちらも常に完璧になるとは限りません。

アダム：しかし、VisBugがやろうとしているのは、スペシャリストになったことです。 したがって、ガイドツールはガイドを実行するだけです。 そして、そのツールがページの他のツールに漏れることはありません。 だから私はDevToolsでそれをもっとやろうとしています。そこでは、DevToolsはデザイナーをもっと助けたいと思っています。これは、VisBugがDevToolsに見てもらうのに役立ったものです。 そして、私が物事を紹介し続ける方法は、たとえば、グリッドエディタを作成する代わりに、次のことができる場所です…「1つのオーバーレイでグリッドのフルパワー」ですね。 「トラックを追加したり、トラックを削除したりできます。何とか、何とか、何とか。」

アダム：そして私は、「それは本当にクールで、また本当に複雑に聞こえます」のようです。 「グリッドはおかしいです。そのための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. Just, yeah.

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ドキュメント全体を取得して、アートボードに縮小するmodがあります。 アートボードのように見えます。 灰色の空間の影に浮かんでいます。 あなたはそれの周りを無限にパンすることができます。 したがって、ページキャンバスからスクロールして離れることができます。これにより、非常に長いページがあり、上から下に何かを測定したい場合は、今すぐ実行できます。 、しかし、あなたが行くにつれて、あなたは一種の文脈を失うでしょう。

アダム：この新しいVisBugズームシナリオでは、キーボードでオプションまたはAltキーを押したままにするか、マウスホイールを使用するか、コマンドでプラスマイナスを押すと、アートボードのようにWebページをズームできます。 そして、私はそれをそのままシームレスにするようにしています。 つまり、出入りし、下にスクロールし、出入りし、測定します…そしてVisBugは気にしません。 計算されたオーバーレイを描画し続けます。間隔を変更できます。

アダム：デザイナーとして、あなたのページの鳥の目をライブで見ることは本当に重要だと思うので。 アニメーションはまだ再生中です。 スクロール可能な領域はまだスクロール可能ですよね？ 本当にかっこいいです。 あなたは、「私のページ全体を1つのビューに表示する」ようなものです。 とにかく、それでほとんど完了です。 入った-

ドリュー：トリッピーに聞こえる。

アダム：それはとてもトリッピーです。 そして、それは入っています、私はそれがクロスブラウザで動作することを確認する必要があります、なぜならそれはあなたのライブページをそのように感じさせるためにいくつかの、明らかにいくつかのトリッキーなことをしているからです。 しかし、ええ。

ドリュー：すごい。 それは…つまり、VisBugはかなり定期的に更新され、進行していると思います。 将来、私たちが期待することは何ですか？

アダム：うん、それは間違いなく私がそこで取り組んでいる機能の1つです。 私には次のような機能があります…それで、何かをクリックすると、ハンドルのように見えるオーバーレイが表示されますよね？ そしてそれは一種の幻想であり、それはあなたが快適に感じるようになるはずです。 そして、その目的は、最終的にこれらのハンドルをドラッグ可能にすることです。 しかし、ブラウザの要素に幅がないなど、最初に解決しなければならない基本的なことがいくつかあります。 ですから、幅をつかみ始めたばかりの場合は、その幻想を正しく感じさせるために作業を行う必要があります。

アダム：そして、幅を小さくしているのはブロックレベルの要素である可能性があり、その隣のアイテムのリフローが得られないため、希望する結果が得られない可能性もあります。 そして、あなたはなぜ疑問に思うかもしれません。 だから私はあなたが角をドラッグしたり、要素をドラッグしたりできるプロトタイプを持っています。 しかし、私は本当に設計ツールがこれをどのように行っているかに焦点を当てる必要があります。 彼らは常にこのトグルボタンを持っています。 そしてそれは…のようなものです、ほら、トグルは何と呼ばれていますか？

アダム：でも基本的にはシュリンクのようなものです…私はそれをシュリンクラップと呼んでいます。 要素をシュリンクラップします。この要素の幅はコンテンツの幅ですが、これが要素の幅です。何かを貼り付けます。 したがって、ブラウザでそのようなものを要素にオーバーレイして、これらから選択できるようにする必要があります。また、ブロックとインラインのどちらかを選択できるようにして、希望する結果を得ることができるようにする必要もあります。

Adam：しかし、最終的にここでの目標は、VisBugが完全にキーボード駆動になることを望まないことです。 間隔をドラッグできるようにしてほしい。 上部に12の余白の間隔が表示されている場合は、そこに手を伸ばしてつかむことができるはずですが、今はキーボードを押して、ボックスの上部に余白を追加する必要があることを指定する必要があります。

アダム：そうですね、戦略の観点から、解決すべきいくつかの癖があります。 しかし、それを設計ツールにさらに近づけることが非常に目標です。 そして多分私でさえその中で曲がるでしょう。 幅を変更したいときに奇妙なデザインを作成する場合は、位置ツールを使用するとフローから逃れることができるように、VisBugを使用して幅を変更する方法が常にあります。 したがって、流れがあなたのアイデアを台無しにしているので、位置ツールを使用すると脱出できます。

アダム：それで…誰かがVisBugに本当に精通しているとしたら、それは一種の無制限であり、それはあなたがテーブルに何をもたらすことができるかというようなものなので、彼らは人々の心を吹き飛ばします。 それには表現要素があります。 確かに表現力豊かな戦術があります。 とにかく、長い話が短いので、幻想は、私はそれをどんどん小さくしていきたいと思っています。 「うわー、本当にデザインツールのような気分だ」というような錯覚にしたいと思っています。

アダム：そして、ええ、エクスポートのいくつかの機能強化がいいでしょう。 しかしまた、DevToolsのエクスポートを強化することは素晴らしいことであり、それは私たちを本当に止めません。 だからわかりません。 たくさんの問題があります、間違いなくそれらに投票してください。 私がやりたい次の大きな機能の1つは、緑色の線だと思います。 したがって、ホバーにアクセシビリティオーバーレイを表示するだけでなく、実際に緑色の線でいくつかのことを示し、より多くの情報を公開し、より多くの情報を表示しますが、私にはわかりません。 うん。

ドリュー：このようなChrome拡張機能を構築するプロセスについて考えると、すべてJavaScriptで実装されていると仮定すると、通常のWeb開発とどの程度似ていますか？ Chrome拡張機能を構築します。

アダム：いい質問ですね。 それは…ふぅ、これは難しいものです。 風変わりです。 まず、コードを起動するための環境はブラウザーではありません。 彼らは実際にあなたにそこへの完全なアクセスを与えません。 VisBugが卒業しなければならなかった、本当にトリッキーになった場合は、このさらにトリッキーなシナリオを実行できます。 だから今、私はで実行していました…これはとても速くぼやけるでしょう。

Adam：プライバシーの問題のために、拡張機能には複数のサンドボックスがあるためです。 そして、実際のページでスクリプトを実行するのが難しくなりますよね？ 何かを起動するときに誰かがフォームを送信したくないので、自分自身などに送信します。 それは本当に破壊的かもしれません。 だからそれはそのようないくつかの癖があります。 あなたが渡らなければならない橋があります。 そして、VisBugを悩ませてきたものの1つは、VisBugが使用していたものです…

Adam：つまり、それはすべてカスタム要素であり、カスタム要素を使用すると、豊富なデータをプロパティとして渡すことができます。 つまり、customelement.foo = myrichobjectのように、配列などでいっぱいです。 そして、カスタム要素はそれをノード自体のデータとして取得します。 しかし、私はこの奇妙な小さなサンドボックスの世界にいるので、そのようなユニークなものをオブジェクトに設定しようとすると、基本的にそれは除外されます。 彼らは、特定のものができないことを確立しました…したがって、文字列をカスタム要素に渡すことはできますが、リッチオブジェクトを渡すことはできません。

アダム：でも、そうですね、そのようなちょっとした癖を除けば、フローをダウンさせて、ロールアップシナリオを取得するために時間を費やすと、LiveReloadを使用できるようになるまでに1時間ほどかかります。 、それはかなり自然になることができます。 Firefoxは、正直なところ、CLIに精通していれば、1つのコマンドで何かを起動でき、それをインストールして、これらのLiveReload機能を提供し、デバッグツールを提供する最高の拡張機能開発エクスペリエンスを備えていると思います。 それは一種のそれを通してあなたの手を握ります、それは本当に素晴らしいことができます。

アダム：しかし、最終的には、少し風変わりです。 そのため、私はそのデモサイトで、アートボードの束のように見える多くの作業を行っています。ほとんどの場合、実際のWebページを必要とせず、VisBugテストを実行するために、アートボードを持っている限りです。さまざまな問題をシミュレートしたり、アクセス可能なものを見て、私が見る必要のあるコンテンツを提供してくれます。 まるで通常のWebアプリケーションであるかのように、ブラウザで多くの作業を行います。 したがって、VisBugの開発エクスペリエンスは、ブラウザー全体でテストしようとしているのでない限り、非常に簡単です。そうすると、面倒なことになります。

ドリュー：それは本当に興味深い洞察です。 それで、私は今日VisBugについてすべてを学んでいます、あなたは最近何について学んでいますか、アダム？

アダム：私はまだ中華鍋のスキルを向上させています。 だから私は中華なべになりたいと思っています。90年代のカセットプレーヤーについて話しているのではありません。 野菜をひっくり返して、空中で少し火をつけて、おいしいスパイスで覆い、ニンニクを本当に焦がしてサクサクと美味しくしたいです。 そして、それを小さなご飯の上に置き、あなたの方にスライドさせて、あなたがどう思うか見てみましょう。

アダム：それで、私は今夏に興奮しています。それは、中華鍋を取り出して、ペースの速い、熱い調理環境に戻ることができることを意味し、それは本当に楽しいです。

ドリュー：すごい。 美味しそう。 親愛なるリスナーの皆さん、アダムからもっと聞きたい場合は、ツイッターで彼の@argyleincをフォローし、彼の個人Webサイトnerdy.devを見つけることができます。 VisBugを試してみたい場合は、Chromeウェブストアで見つけることができます。サンドボックスバージョンはvisbug.web.appで試すことができます。 本日はアダムにご参加いただきありがとうございます。 別れの言葉はありましたか？

アダム：いいえ、あなたは本当に素晴らしかったです。 これは本当に甘かったです。 よろしくお願いします。