Smashing Podcast Episode 37 с Адамом Аргайлом: что такое VisBug?

В этом эпизоде ​​мы говорим о VisBug. Что это такое и чем оно отличается от набора параметров, уже имеющихся в Chrome DevTools? Дрю Маклеллан разговаривает с его создателем Адамом Аргайлом, чтобы выяснить это.

Показать примечания

• Песочница и игровая площадка VisBug
• Адам в Твиттере
• личный сайт Адама
• ВисБаг на YouTube
• ВисБаг 101

Еженедельное обновление

• Платформа конференции, которую мы используем для наших онлайн-мероприятий: Hopin от Amanda Annandale
• Учебник по запросам контейнеров CSS от Стефани Эклз
• Разочаровывающие шаблоны проектирования, которые нужно исправить: выбор дня рождения Виталия Фридмана
• Tree-Shaking: Справочное руководство Атила Фассина
• Как мы улучшили наши основные веб-жизненные показатели, Бо Хартсхорн

Стенограмма

Дрю Маклеллан: Он яркий, страстный, панк-инженер, обожающий Интернет, который предпочитает использовать свои навыки для лучшего в своем классе UI и UX, а также расширять возможности окружающих. Он работал в малых и крупных компаниях и в настоящее время является защитником интересов разработчиков, работая над Chrome в Google. Он является членом рабочей группы CSS и создателем VisBug, инструмента для отладки дизайна. Итак, мы знаем, что он разбирается в дизайне и UX, но знаете ли вы, что у него больше пар шлепанцев, чем у любого живого двуногого? Мои потрясающие друзья, пожалуйста, поприветствуйте Адама Аргайла.

Адам Аргайл: Здравствуйте.

Дрю: Привет, Адам, как дела?

Адам: О, я разбиваю, ты знаешь это.

Дрю: Приятно слышать. Итак, я хотел поговорить с вами сегодня о вашем проекте VisBug и в целом о концепции отладки проекта и о том, как она может вписаться в рабочие процессы проекта. Я имею в виду, что у нас уже давно есть ориентированные на разработчиков инструменты отладки браузера, я имею в виду, наверное, уже более десяти лет. Но они, очевидно, очень сосредоточены на коде. Так чем отличается VisBug? И какую проблему он пытается решить?

Адам: Потрясающе. Да, главная проблема, из-за которой все это коренится, в том, что я, как фронтенд-инженер, все время работаю с дизайнерами, и мне всегда нравился этот момент, когда мы садились и думали: «Хорошо. Делаю последние штрихи. У нас есть еще день или два до развертывания. Итак, дизайнер, садитесь и не могли бы вы покритиковать это? Я хочу, чтобы вы открыли мою локальную хост-версию в вашем браузере и на вашем телефоне или где-то еще, и поговорите со мной о том, что вы видите».

Адам: И после того, как я занимался этим в течение многих лет и всегда любил это взаимодействие, через некоторое время я начал чувствовать себя виноватым из-за того, насколько обычными и простыми были задачи. Они бы сказали: «Один пиксель здесь. Здесь запас в пять пикселей». И это всегда были гниды и подталкивания, гниды и подталкивания к пробелам и шрифту. Я имею в виду, что редко было что-то вроде: «О, подождите минутку, пока я трачу 30 минут на изменение какого-то угла или чего-то еще, чтобы настроить свой DOM, чтобы DOM мог поддерживать ваш запрос», или что-то в этом роде.

Адам: Обычно это были крошечные вещи. А потом я закончил опрос и опросил всех этих дизайнеров в Google. И я такой: «Когда вы открываете DevTools, что вы делаете?» И как-то звучало, что им просто нужны основы. И так это родилось, я подумал: «Это должно быть проще. Вам не нужно открывать капот на Феррари, перемещать часть двигателя, просто чтобы изменить цвет автомобильных сидений. Это не честно. Вы должны просто иметь возможность прикоснуться к сиденьям автомобиля и изменить цвет, как инструмент дизайна». Я подумал: «Что-то может облегчить этот рабочий процесс». И я подумал: «Хорошо, я думаю, я что-нибудь взломаю, чтобы посмотреть, смогу ли я создать решение».

Адам: Вот так все и началось. На самом деле все началось с пробелов, а затем с типографики. И как только у меня появился механизм выбора, который эмулировал инструменты дизайна, я подумал: «Ну, что еще я могу сделать?» И это просто продолжалось оттуда. Но да, родился в тот момент.

Дрю: Итак, идея в том, что клиент просит вас увеличить логотип, а VisBug помогает браузеру вести себя как инструмент дизайна для внесения таких изменений. Так ближе к чему-то вроде Illustrator, или Photoshop, или Figma, или любому из этих типов вещей.

Адам: Ага. Этот вариант использования тоже хорош. Потому что вы можете быть с клиентом, и он скажет: «О, нам это нравится», это такая классика, «нам нравится дизайн, но синий цвет для нас труден». И ты такой: «Правда?» Это похоже на то, что люди могут отправить форму, и вы можете заработать деньги, но вы хотите поговорить со мной о синем прямо сейчас? И обычно это создавало целый цикл. Менеджер сказал: «Хорошо, мы примем ваш запрос и отправим его в дизайн».

Адам: Но если дизайнер там и его браузер показывает это, они бы сказали: «Хорошо. Что ж, я просто нажму на вещь и изменю цвет». И вы можете пресечь весь цикл работы, просто создав прототип изменения в браузере. Так что, это. Это наиболее эффективно против существующего продукта, верно? Потому что это инструмент отладки. Это не обязательно инструмент генерации. Он не создает сайт для вас. Можно, но как-то неудобно.

Дрю: Технически это расширение, которое вы устанавливаете в браузере Chrome. Это правильно?

Адам: Ага. И это расширение. Когда вы запускаете его, он загружает файл JavaScript, в котором говорится: «Вот пользовательский элемент с именем VisBug». А затем вы помещаете элемент DOM, vis-bug на страницу. И пуф, я просто использую этот момент и превращаю его в панель инструментов, и начинаю слушать события на странице. Я слушаю ваши события наведения, и я слушаю ваши события кликов. И я стараюсь изо всех сил их перехватывать, а не конкурировать с вашей главной страницей.

Адам: Но да, в этом суть… Единственная причина, по которой это расширение, в том, что его легко разместить на вашей странице. Хотя на данный момент у него есть некоторые настройки, которые вы можете использовать в разных браузерах. Но это по-прежнему в основном, 99,9%, пользовательский элемент без зависимостей. Я думаю, мне нравится библиотека цветов, которую я использую, а в остальном это просто ваниль. Да.

Дрю: Думаю, именно так начинался Firebug, не так ли? Как расширение Firefox в тот же день.

Адам: Ага. Вот почему он называется VisBug. Он очень вдохновлен Firebug, но для визуальных дизайнеров.

Дрю: Ах. Ну вот. Я имею в виду, что это, пожалуй, не идеальный формат, будь то аудиоподкаст, чтобы говорить о визуальном инструменте. Но расскажите нам, если хотите, о некоторых инструментах и ​​возможностях, которые предлагает вам VisBug.

Адам: Абсолютно. Итак, одна из первых вещей, которые делает VisBug, и вы также можете, если вы находитесь дома или за компьютером, вы можете зайти на visbug.web.app и попробовать VisBug без расширения, верно?

Дрю: Ах.

Адам: Это веб-компонент, поэтому я загрузил для вас веб-страницу здесь, на visbug.web.app, которая выглядит так, как будто у нее есть целая куча арт-досок, и, конечно же, VisBug предварительно загружен. И цель этого сайта — позволить вам играть, исследовать и удалять. Я думаю, что клавиша удаления — один из самых удобных инструментов для начала. Вы такой: «Что я могу сделать со страницей?» И ты такой: «Ну, я могу его уничтожить».

Адам: И я сделал так, что вы можете удерживать удаление, оно найдет следующее… Что довольно сложно при удалении. Вы удаляете что-то, и он выбирает следующего брата. Таким образом, он навсегда выберет следующего брата. Если вы будете удерживать «Удалить», пока не удалите все целиком… В любом случае, очень приятно. Нажмите «Обновить», и все вернется. Но первый инструмент, с которым поставляется VisBug, когда вы только запускаете его, — это инструмент направляющих. Раньше я буквально подносил бумагу к экрану или брал системное расширение, которое позволяло мне сортировать пометки и создавать линии.

Адам: Потому что, да, в какой-то момент для многих дизайнеров выравнивание становится очень оптическим, верно? Они не обязательно хотят математического выравнивания, верно? Вот почему типографика имеет оптический кернинг. Это не математический кернинг. Это человеческий кернинг. И поэтому инструмент направляющих основан на том, что многие гниды, которые случаются с дизайнером, увеличивают масштаб, проверяя выравнивание. Расстояние хорошее?

Адам: Итак, это вторая вещь, которую делает инструмент направляющих. Когда вы запускаете его и просто наводите курсор на что-то, вы увидите, что элемент, на который вы навели курсор, получает небольшую рамку вокруг него. А затем появляются пунктирные направляющие, как это обычно делают линейки. И точно так же, как в Sketch и Zeplin, где вы как бы наводите курсор и получаете эти направляющие, это та же концепция, просто живите на своей странице. И если вы щелкнете что-нибудь, а затем наведете курсор на новое место назначения, вы получите измерительные инструменты. И средства измерения в пикселях, и они рассчитываются… Так что наглядно, сколько между ними пикселей. Не то, что кто-то сказал. Это не суммирование всех интервалов, вы просто щелкаете по этой штуке, и она находится так далеко от той другой коробки.

Адам: И я думаю, что это становится действительно полезным, потому что вы можете удерживать Shift и продолжать щелкать, и, по сути, убедиться, что у вас есть равные интервалы между пятью значками. И это всего в пару кликов. Не нужно знать код, просто запустите VisBug, наведите указатель мыши, щелкните, щелкните, щелкните, и вы увидите это: «О, смотрите, это так. Да. 15 пикселей между каждым из них». Или иногда вы получаете что-то, что немного раздражает, вы щелкаете в поле, а затем щелкаете его родительское поле, и вы понимаете, что его верхнее расстояние равно девяти, а нижнее — восьми. А вы говорите: «Как мне это центрировать? Это что-то среднее». И трясет кулаком.

Адам: Но, по крайней мере, вы можете легко и красиво увидеть это с помощью инструмента направляющих. Так что да, это инструмент направляющих.

Дрю: Я определенно был там, держа листы бумаги на экране. А также, другой трюк, который я бы использовал, заключается в том, чтобы открыть другое окно браузера и использовать край окна для выравнивания элементов. А затем вы как бы пытаетесь держать все в правильном месте, чтобы, когда вы меняете и обновляете код, все по-прежнему выстраивалось. Да, не идеальный способ работы, так что.

Адам: Не идеальный способ работы. Ага. А вот и следующая… Итак, о, и первая версия была очень свободной. Он не щелкнул, он просто держал перекрестие, и это функция, которую я добавлю позже. Поэтому некоторые пользователи говорят: «Эй, мне нравится привязка, это похоже на мои инструменты дизайна. Но что, если мне нужно свободное измерение? Или я хочу сделать письмо, я хочу измерить письмо, а не его почтовый ящик?» Итак, ну, этот инструмент направляющих можно очень легко изменить на наличие клавиши-модификатора.

Адам: Итак, вот где VisBug становится немного другим, но также, надеюсь, знакомым, это очень много модификаторов горячих клавиш. Так же, как если вы посмотрите на профессионального дизайнера, они очень хорошо разбираются в горячих клавишах. И они нажимают горячие клавиши здесь, увеличивают масштаб, нажимают горячие клавиши там и просто делают все, что им нужно, со своей клавиатуры. И поэтому VisBug очень ориентирован на клавиатуру в том, как вы меняете вещи.

Адам: Это также связано с тем, что VisBug допускает множественный выбор и может изменять интервал между 100 элементами одновременно. И делает это относительно. Так или иначе, у него есть пара интересных особенностей, но клавиатура в концепции модификатора действительно важна. И вы можете удерживать опцию, или сдвигать, или управлять многими инструментами и получать что-то другое, или получить новую функцию.

Дрю: Так что это один из тех инструментов, где действительно стоит выучить сочетания клавиш.

Адам: Это так. И поэтому, когда вы запускаете VisBug и наводите курсор на один из значков инструментов, вы получаете разбивку. Он выбрасывает небольшое всплывающее меню, в нем указана горячая клавиша для выбора этого инструмента, и он сообщает вам, что он может сделать, и какие действия нужно выполнить, чтобы получить их. Итак, инструмент направляющих говорит: «Направляющие элементы, просто наведите курсор. Измерьте что-то, нажмите, а затем наведите курсор на что-то новое. Закрепленные измерения — это сдвиг и щелчок, чтобы они сохранялись».

Адам: И эти руководства очень хороши для создания скриншотов. Так что, если вы просматриваете PR, даже будучи просто фронтенд-инженером, или, может быть, дизайнером, просматривающим PR, это может быть действительно мощным способом для вас попасть туда и, да, провести тщательную проверку. Который ведет нас к следующему инструменту. Хотите узнать о следующем инструменте?

Дрю: Да, конечно. Давай сделаем это.

Адам: Потрясающе. Следующим является инструмент проверки. А этот такой… Дизайнеры обычно не хотят весь CSS, верно? Когда они ожидают с… Я почти сказал Firebug, но Chrome DevTools, вы же знаете полный список, верно? Я выбрал этот H1, и вот все, вплоть до таблицы стилей браузера. А дизайнер такой: «Браузер что ли? В браузере есть таблица стилей?»

Дрю: Внизу, в темной нижней части панели прокрутки.

Адам: Темное дно, да?

Дрю: Ага.

Адам: Как будто ты снял все слои, а потом такой: «О, мне больше не нравятся эти слои». И инструмент проверки здесь говорит: «А, дизайнеры, я знаю, чего вы хотите. Это просто цвет границы». По сути, покажите мне что-то, только если оно уникально, так что не прикрывайте меня просто свойствами CSS. И меня больше всего интересуют цвет, типографика и интервалы. Итак, я собираюсь посмотреть на поля, высоту строки, семейство шрифтов, которые действительно важны, верно? Существует целое расширение, просто чтобы сообщить вам, какое семейство шрифтов используется на странице.

Адам: В VisBug это просто строка в инструменте проверки. Итак, вы просто запускаете VisBug, нажимаете «Проверить» и наводите курсор на любую типографику, и он сообщит вам семейство шрифтов. Так что да, он пытается заставить дизайнера сосредоточиться на том, что он выводит на поверхность, да.

Дрю: Значит, этот инструмент не показывает никаких унаследованных стилей. Это правильно?

Адам: Это правильно. Если только они не унаследованы и не уникальны. Итак, если они… Цвет текста или что-то в этом роде, если цвет текста не является буквальным словом «наследовать», он скажет вам, что это вычисленное значение, что это что-то интересное.

Дрю: Да, это очень полезно, просто… Да. Помогает вам сосредоточиться на вещах, которые буквально применимы к этому единственному экземпляру чего-то, что, очевидно, вы хотели изменить. Я имею в виду, я думаю, это могло бы быть действительно полезно, все эти инструменты были бы действительно полезны, как вы упомянули, для получения отзывов заинтересованных сторон. И своего рода интерактивная работа с клиентом.

Дрю: Я думаю, это сработает так же хорошо, как совместное использование экрана, что нам приходится делать в наши дни все чаще и чаще. Вам не нужно сидеть с кем-то за компьютером, вы можете сидеть на другом конце провода и делиться своим браузером, и делать это таким образом. Думаю, это был бы весьма эффективный способ получить обратную связь, когда клиент не может указать на экран и сказать:

Адам: Определенно.

Адам: Это всегда волшебно, когда вы превращаете живую веб-страницу в то, что выглядит как артборд Zeplin. Кто-то такой: «Что… Мы только что пошли в новое место?» А ты такой: «Нет, это твой продукт. Мы просто взаимодействуем с ним визуально». Да, это может быть очень красиво.

Дрю: Есть ли какие-нибудь другие интересные варианты использования VisBug, которые, по вашему мнению, могут быть вам интересны?

Адам: Ага. Так что, да, их так много, что трудно начать. О, один из важных моментов — это общение между разработчиками. VisBug работает с рассчитанными значениями. Таким образом, он не смотрит на ваши авторские значения. И это может быть очень приятно, потому что вы как бы измеряете и проверяете абсолютный конечный результат по тому, как вычисляются пиксели на экране. И это может быть очень приятно вести такой разговор, когда вы работаете над результатами, а не на стороне автора.

Адам: И вы можете вернуться к чему-то вроде: «Хорошо, а как мы ошиблись в авторской работе, если это то, что мы получили визуально?» Что также играет роль, следующий инструмент — инструмент проверки доступности. Таким образом, инструмент проверки позволяет легко увидеть стили элемента и разбить их очень удобным для дизайнера способом. Инструмент специальных возможностей помогает вам проверять все элементы на странице и выявляет любые доступные свойства, которые у него есть, что, я надеюсь, упрощает проверку того, что что-то сделано.

Адам: Итак, пиар… А вещи часто создаются. Итак, опять же, разработчик для разработчика, дизайнер-разработчик, вы просматриваете интерфейсы. Просто это так критично. Если вы смотрите на интерфейс и вам любопытно, у VisBug есть вариант использования для вас. Также есть случаи, когда вы можете отсортировать прототип в браузере. Итак, мы говорили об одном случае, когда клиент хотел попробовать синий цвет. Хорошо, это довольно простой сценарий.

Адам: Но есть и другие. Если вы нажмете команду D в VisBug, вы продублируете элемент. И неважно, что вы дублируете. Таким образом, вы можете продублировать заголовок, добавить интервал между двумя заголовками и запустить вариант в браузере. Вы дважды щелкаете текст заголовка, и он становится редактируемым текстовым полем, и вы пробуете новый заголовок и смотрите, как он подходит. Настройте интервалы, и вы только что избавили себя от всей этой работы разработчика, поиска исходного файла и всего такого, и вы просто…

Адам: Так что да, это может помочь вам изучить и проверить. Это немного странно… Я имею в виду, что DevTools делает много вещей, верно? Он приходит после того, как вы закончите, на самом деле он не очень часто дает вам исходный код, не очень часто вы копируете код из DevTools. Вы можете скопировать пару ключ-значение. Например: «О, я изменил этот стиль». Но да, в любом случае.

Дрю: Мм-хмм (утвердительно). Да. Я могу придумать особенно визуальные случаи, когда вы, как вы упомянули, можете захотеть дублировать элементы. Возможно, вы захотите взять целый раздел страницы и продублировать его, чтобы смоделировать, как это было бы, если бы контента было намного больше, чем вы ожидали.

Адам: Да. Это случай использования тестирования хаоса.

Дрю: Ага.

Адам: Абсолютно.

Дрю: Это то, с чем нам всем приходится сталкиваться, проектируя с помощью систем на основе CMS и выполняя всевозможные забавные задачи.

Адам: Да, это тоже очень важный вариант использования. Потому что я делаю это для… Да, для заголовков, как я уже сказал. Вы просто дважды щелкаете по тексту, а я просто хлопаю по клавиатуре. Бла, бла, бла, бла, и нажал кучу пробелов, бла, бла. И я такой: «Хорошо, как тебе макет? О, получилось хорошо. Хорошо, хорошо, я могу перейти к следующему. Что произойдет, если я продублирую это четыре раза? Есть ли еще пространство между всем? Он течет рядом со следующим элементом?»

Адам: Это может быть очень хорошо для этой симуляции, да, хаоса контента. Очень короткое название, очень длинное название, нет друзей, есть миллион друзей. Как вы справляетесь с этими вариантами использования в пользовательском интерфейсе? Ага.

Дрю: Так что это работает с любым контентом в браузере. Итак, PWA и обычные веб-страницы?

Адам: Да, это так. Так что, если у вас установлен Spotify, я делаю это все время, у меня установлен Spotify, и я просто говорю: «Spotify, ты выглядишь так, будто ты невозможное приложение для проверки». Но знаете что? VisBug не волнует. VisBug накладывает все ваши материалы, проверяет все типографику. Я сделал легкую тему для… О, у меня где-то есть твит, где я сделал легкую тему для Spotify.

Адам: О, это был еще один вариант использования, извините, для прототипирования цвета. Я могу создать светлую тему для самого продукта, не возясь с кучей наклеек, верно? Так что есть еще один важный менталитет, я бы хотел, чтобы VisBug помог людям понять, что значит использовать ваш продукт как игровую площадку. Используйте это как… Это так реально. Это более реально, чем ваши дизайнерские композиции. Так что проведи там еще немного времени. Я думаю, вы обнаружите, что можете принимать более эффективные дизайнерские решения, работая над своим реальным продуктом.

Дрю: И случай доступности также особенно интересен, потому что часто, особенно в наши дни, мы очень много работаем с библиотеками компонентов и смотрим на небольшие компоненты страницы. И тратить меньше времени на изучение всех этих элементов, интегрированных вместе, чтобы создать вид, с которым клиент действительно взаимодействует. И становится очень сложно следить за такими мелкими деталями, как доступность, атрибуты, которые не видны на странице.

Дрю: Очень сложно следить за тем, чего не видно. Так что именно здесь инструментарий действительно может помочь проверить что-то и увидеть, что да, на нем есть правильные роли, и это-

Адам: Это так. Это точный вариант использования. Я хочу, чтобы премьер-министр смог проверить это. Я хочу, чтобы дизайнер мог посмотреть на доступность и ему не нужно было открывать инструменты, находить узел DOM, все это скомкано на панели элементов и выглядит странно. Что он просто говорит: «Вот атрибуты области, вот название, если оно существует». Есть также некоторые другие инструменты доступности. VisBug поставляется со значком поиска. Значок поиска имеет несколько способов взаимодействия с ним.

Адам: Итак, сначала он запрашивает страницу. Поэтому, если вы знаете тип элемента или имя класса элемента, который вам нужен, вы можете просто найти его, так что вам не нужно искать его с помощью мыши. Но в нем также есть слэш-команды. Итак, в VisBug есть плагины, и они будут выполнять скрипты на странице. Итак, если у вас когда-либо была закладка, которую вы сохранили три или четыре… ​​Вы говорите: «Я собираюсь использовать эту, потому что она выделяет все границы и показывает мне мои поля». Это похоже на трюк отладки или что-то в этом роде.

Адам: Вероятно, это плагин VisBug. Итак, вы запускаете VisBug, нажимаете косую черту, и вы получаете автозаполнение, и оно покажет вам все различные плагины. И есть некоторые специальные возможности, которые действительно хороши, которые накладывают ошибки и тому подобное. Так что я согласен. Доступность должна быть более доступной. Это просто глупо говорить. Но он должен быть ближе к поясу с инструментами. И я думаю, что иногда это слишком далеко, и, может быть, поэтому его упускают. Так что я надеюсь, что если он будет немного больше спереди, по центру и легче, его будут больше проверять. Да.

Дрю: Интересно, что вы говорите, что VisBug работает с вычисляемыми значениями вещей, например, с цветами. Значит ли это, что если у вас есть несколько многослойных элементов с разными уровнями непрозрачности, вы сможете измерить точный цвет, отображаемый на экране, а не...

Адам: Ох.

Дрю: … смотришь на отдельные элементы и пытаешься как-то это проработать?

Адам: Это действительно хороший вопрос. Итак, я думаю, если я правильно понимаю вопрос, который является классической трудностью во внешнем интерфейсе, да, как узнать, есть ли у вас полупрозрачное текстовое слово, какой его цвет над серым или над белым? ? А как узнать его контраст? Прямо сейчас мы не знаем. Итак, VisBug знает цвет и скажет «50% серого» или любой другой цвет, который у вас есть. Но ничего умнее этого не знает. Это не в состоянии…

Адам: Я думаю, что в этом случае вам нужно будет создать холст, нарисовать на нем все слои, а затем использовать пипетку или… Таким образом, вы отрендерите это на холсте, смешаете все вместе в единое целое. один нарисованный слой, а затем выберите значение одного пикселя, чтобы увидеть, каков его фактический конец, вычисленный серый цвет, после того, как он был наложен на другой материал.

Адам: Я думаю, что кто-то определил это, или, может быть, у меня есть проблема на GitHub, что было бы неплохо. Потому что VisBug может облегчить это на 100%. VisBug, за кулисами, я уже сделал с текстовыми метриками, когда вы наводите курсор на что-то, и это дает вам сумасшедшую информацию о шрифтах. Это почти слишком много информации, например, x высота и высота шапки, но это еще больше. И это похоже на: «О, я как бы отключился в какой-то момент». Поэтому я должен выяснить, как найти там сигнал и шум.

Адам: Но да, мне нравится этот мыслительный процесс, потому что у нас должен быть инструмент, который это делает. И если мы знаем, как его вычислить, мы можем научить VisBug делать это, и это было бы действительно здорово, если бы вычисляемый цвет соответствовал непрозрачности. Любить это.

Дрю: Да, я имею в виду, что это стандартный случай, когда текст расположен на фоне, и вы не уверены, что контраста достаточно, чтобы соответствовать требованиям доступности. И, возможно, это не так, возможно, это слишком низкий контраст, и вы хотите затем настроить значения, пока не добьетесь того, чтобы контраст был хорошим, но не слишком далеко от того, что клиент изначально хотел с точки зрения цветов бренда. и вещи.

Адам: Я называю этот удар, удар, пока не пройдете.

Дрю: Ага.

Адам: Потому что это то, на что это похоже. Я такой: «О, мне немного не хватает очков». Так что это похоже на то, что я перейду к своей легкости HSL и буду просто стучать, стучать, стучать и смотреть, как маленькие цифры тикают, пока не будет похоже на «Динь», я получаю зеленую галочку. Я такой: «Хорошо, круто». И да, иногда некоторые из этих цветов не крутые. Итак, вы изучили большую часть работы по перцептивной доступности 3.0, которая сейчас ведется? Так что у нас больше не будет AA или AAA, у нас будет on number, включая такие вещи, как тонкость шрифта. Так что, если это тонкий шрифт, он получит более низкую оценку, если это толстый шрифт, он пойдет… Потому что многое идет на контраст.

Дрю: Да, нет, я ничего подобного не видел, но звучит…

Адам: В любом случае, это действительно крутая вещь для исследования.

Дрю: Звучит увлекательно, да. Я должен найти кого-нибудь, чтобы поговорить об этом. Это другой эпизод. Итак, я имею в виду, я уверен, что некоторые разработчики могут возразить, что все, что делает VisBug, вы можете просто сделать через панель CSS в DevTools. И я думаю, что это справедливо, но, вероятно, упускает из виду то, что да, вы манипулируете CSS, когда вносите изменения, но это ставит на первое место некий пользовательский интерфейс, ориентированный на дизайнера, а не интерфейс, ориентированный на разработчика. Это справедливая его характеристика?

Адам: Это действительно справедливо. И, честно говоря, лучшие идеи переходят из VisBug в DevTools. И они уже есть. Итак, VisBug, если вы нажмете опцию команды C для любого элемента, он примет каждый вычисленный стиль, по крайней мере, уникальный. Опять же, мы будем делать такие, которые не просто дадут вам все эти унаследованные свойства. Но помещает их все в буфер обмена, и вы можете вставить этот стиль куда-нибудь еще, в таблицу стилей, в CodePen, и буквально воссоздать элемент за пару кликов.

Адам: И такого рода взаимодействия попали в DevTools, в эту панель элементов. Однако есть и другие вещи, которых нет, а именно DevTools — это инструмент только для проверки одного узла. И VisBug следует мантре инструментов дизайна, а именно: нет, я должен иметь возможность множественного выбора. Мне нужна возможность массового редактирования, массовой проверки. И поэтому я все время использую VisBug для интервалов. Потому что я могу выделить несколько элементов и увидеть схлопывание полей.

Адам: В DevTools вы никогда не сможете увидеть это, потому что большую часть времени вы можете видеть только один узел за раз, хотя есть способ показать несколько полей, но это не одно и то же. И так, да, у него есть эти нишевые варианты использования, которые могут быть действительно забавными. Другой вариант: если вы выделите… Допустим, у вас есть система типографики, и у вас есть H1–H7, как в сборнике рассказов или что-то в этом роде, вы можете выделить их все в VisBug, удерживая Shift, просто щелкнуть их все. Буп, буп, буп, буп, перейдите к инструменту типографики и нажмите вверх или вниз, и он вносит относительное изменение в каждый из них.

Адам: Итак, каждый из них подтолкнет вверх или вниз. И это не то, что DevTools упрощает. Так что, да, у него есть такие сверхспособности, потому что он немного более агностичен. И он готов всегда перебирать массив. Да.

Дрю: Так откуда появился VisBug? А сейчас это просто личный проект? Или это проект Google? Или каков его статус?

Адам: Ага. Итак, во-первых, статус такой: это проект Google. Его основная цель — быть местом для прототипирования и изучения, прежде чем что-то войдет в DevTools. По крайней мере, со стороны Google. Но с моей личной точки зрения я по-прежнему рассматриваю его как место, где можно заняться общими задачами или внести некоторые оптимизации для выполнения общих задач. И просто дать более широкой аудитории возможность заглянуть в DOM.

Адам: Я действительно думаю, что DevTools очень мощный, но он очень пугающий. Всего одна вкладка в нем может занять всю карьеру, чтобы учиться. Я все еще изучаю DevTools и постоянно ими пользуюсь. Так что да, в каком-то смысле это другая аудитория. Это больше новички, приходящие люди или, может быть, даже такие люди, как продакт-менеджеры, менеджеры, которые никогда не собираются кодировать, но заинтересованы в результате. Так что это как бы дает им, да, легкий инструмент, чтобы проникнуть туда.

Дрю: Это интересный момент, который вы поднимаете, потому что лично я часто сталкиваюсь с трудностями в поиске удобного рабочего процесса при управлении всеми этими инструментами разработчика. И у вас есть все эти маленькие клаустрофобные панели, и вы можете отсоединить их от другого окна, но тогда вам придется следить за двумя разными окнами. И как только у вас открыто несколько окон браузера, вы не можете… Вы фокусируетесь на одном и не знаете, какой DevTools принадлежит ему.

Дрю: А внутри самих панелей это что-то вроде Дикого Запада условностей пользовательского интерфейса. Вы будете прокручивать, и все начнет делать странные вещи, которых вы не ожидали. И с точки зрения пользовательского опыта я чувствую, что все это просто большой беспорядок.

Адам: Это так. Да.

Дрю: Думаешь, это неизбежно? Может быть лучше?

Адам: У меня определенно есть мысли. И да, я думаю, что это хорошо… Допустим, прямо сейчас у вас есть слушатель, который говорит: «Я довольно хорошо разбираюсь в DevTools. Я не думаю, что они настолько сумасшедшие». Я бы сказал: «Хорошо, откройте Android Studio или Xcode. Начните проект и посмотрите на DevTools, посмотрите на результат. Насколько знакомым ты сейчас себя чувствуешь? Наверное, очень иностранный. Вы смотрите на это и говорите: «Это мусор. Почему они это делают? Почему эта панель здесь? И ваш разум начинает мчаться со всеми этими вопросами, почему и путаницей.

Адам: И это похоже на то, что все чувствуют, когда впервые открывают DevTools. Так что вы должны быть действительно чуткими к этому.

Дрю: Это неизбежно, что… Можем ли мы сделать лучше? Или это просто естественный порядок вещей?

Адам: Итак, вот мой текущий взгляд на это: я думаю, что в сложность действительно легко попасть. И DevTools — одна из таких вещей, они просто сложны по своей природе. Нет хорошего пользовательского интерфейса для облегчения многих из этих вещей. Многие из этих вещей создаются разработчиками. И я думаю, что разработчики создают инструменты для разработчиков, это нормально, потому что у вас будет… Если это единственный способ, или даже если это хороший способ, вы изучите его и станете хороши в это, и вы получите удобный с ним.

Адам: И все DevTools какие-то странные, потому что они созданы для своих странных вариантов использования, верно? Развитие странное. Давайте просто будем честными. Делаем невидимые винтики и невидимые два на четыре, а дома строим, в основном, из невидимых, виртуальных частей. Так что да, нам нужны странные инструменты, чтобы проверять эти штуки и сообщать нам, что они выдают.

Адам: Теперь, как говорится, то, что делает VisBug, и то, что я как бы медленно перемещал в DevTools, — это более мелкие инструменты, которые более сфокусированы, в отличие от большого инструмента, который заявляет, что делает много. Я думаю, что трудно делать много вещей действительно хорошо. И это классический аргумент, верно? Это все звезды, специалисты против универсалов. Ни один из них не всегда будет идеальным.

Адам: VisBug пытается создать специалистов. Таким образом, инструмент направляющих просто делает направляющие. И этот инструмент никогда не просочится в другие инструменты страницы. И поэтому я пытаюсь сделать это больше с помощью DevTools, где DevTools хочет больше помочь дизайнерам, что VisBug помог вдохновить DevTools увидеть. И способ, которым я продолжаю вводить вещи, заключается в том, что вместо создания редактора сетки, например, вы можете… «Вся мощь сетки в одном наложении», верно? «Вы можете добавлять треки, удалять треки, бла-бла-бла».

Адам: И я такой: «Звучит очень круто, а также очень сложно». I'm like, “Grid is crazy, there's no way we're going to build a GUI for that.” 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. We understand that. 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. So…

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.

Адам: У меня есть мод, в котором при запуске VisBug он берет весь HTML-документ и сжимает его в артборд. Похоже на артборд. Он плывет в тени по серому пространству. Вы можете бесконечно панорамировать его. Таким образом, вы можете прокручивать страницу с холста, и это позволяет вам, видите, скажем, у вас есть очень длинная страница, и вы хотите измерить что-то сверху вниз, вы можете сделать это прямо сейчас , но вы как бы теряете контекст по ходу дела.

Адам: Что ж, в этом новом сценарии масштабирования VisBug вы удерживаете option или alt на клавиатуре, используете колесико мыши или нажимаете плюс-минус в своей команде, и вы можете масштабировать свою веб-страницу, как будто это артборд. И я стараюсь сделать его максимально цельным. Итак, вы входите и выходите, и вы прокручиваете вниз, вы входите и выходите, измеряете от… И VisBug просто не заботится. Он продолжает рисовать вычисленные наложения, вы можете изменить интервал.

Адам: Потому что я думаю, что для дизайнера очень важно увидеть вашу страницу с высоты птичьего полета вживую. Анимации все еще играют, вы все. Прокручиваемые области по-прежнему прокручиваются, верно? Это действительно здорово. Ты такой: «Вся моя страница за один просмотр». Так или иначе, это почти сделано. Это в-

Дрю: Звучит странно.

Адам: Это очень странно. И он готов, мне просто нужно убедиться, что он работает в разных браузерах, потому что он делает некоторые, очевидно, некоторые хитрые вещи, чтобы ваша живая страница выглядела именно так. Но да.

Дрю: Удивительно. Это… Я имею в виду, я предполагаю, что VisBug довольно регулярно обновляется и развивается. Что мы можем ожидать увидеть в будущем?

Адам: Да, это определенно одна из функций, над которой я работаю. У меня есть функция, где… Итак, когда вы нажимаете что-то, вы получаете наложение с чем-то вроде ручек, верно? И это своего рода иллюзия, это должно заставить вас чувствовать себя комфортно. И цель состоит в том, чтобы в конечном итоге эти ручки можно было перетаскивать. Но у меня есть некоторые фундаментальные вещи, которые я должен решить в первую очередь, например, элементы в браузере не имеют ширины. Так что, если вы просто начнете хвататься за ширину, мне придется поработать, чтобы эта иллюзия казалась правильной.

Адам: И вы можете даже не получить желаемых результатов, потому что это может быть элемент уровня блока, ширина которого уменьшается, и вы не получаете перекомпоновку элемента рядом с ним. И вам может быть интересно, почему. Итак, у меня есть прототипы, в которых можно перетаскивать углы, перетаскивать элементы. Но мне действительно нужно сосредоточиться на том, как инструменты дизайна делают это. У них всегда есть эта кнопка переключения. И это как… Видите, как называется переключатель?

Адам: Но в основном это похоже на термоусадку… Я называю это термоусадочной пленкой. Оберните мой элемент в термоусадочную пленку, ширина этого элемента равна ширине его содержимого, а вот ширина моего элемента, вставьте что-нибудь в него. Поэтому мне нужно что-то подобное в браузере, наложенное на элемент, чтобы вы могли выбирать между ними и, возможно, даже что-то, что позволяло бы вам выбирать между блочным и встроенным, чтобы вы могли получить желаемые результаты.

Адам: Но, в конечном счете, цель здесь в том, чтобы VisBug не хотел полностью управляться с клавиатуры. Я хочу, чтобы вы могли перетаскивать интервалы. Если вы видите 12 отступов сверху, вы сможете дотянуться и взять его, тогда как прямо сейчас вам нужно нажать на клавиатуре, чтобы указать, что верхняя сторона поля нуждается в добавлении поля.

Адам: Итак, да, мне нужно проработать пару причуд в плане стратегии. Но очень важно сделать его еще ближе к инструментам дизайна. И, может быть, даже я прогнусь в этом. Это похоже на то, что если вы хотите изменить ширину и собираетесь получить странный дизайн, всегда есть способы выйти из этого с помощью VisBug, например, инструмент позиционирования действительно позволяет вам избежать потока. Таким образом, поток разрушает вашу идею, инструмент позиционирования позволяет вам убежать.

Адам: И так вот… Если бы кто-то действительно разобрался с VisBug, он бы взорвал людям мозги, потому что он вроде безграничен, и это похоже на то, что вы можете принести к столу? В нем есть элемент экспрессии. Безусловно, есть экспрессивная тактика. Но в любом случае, короче говоря, иллюзия состоит в том, что я просто хочу сделать ее все меньше, меньше и меньше. Я хочу, чтобы иллюзия была такой: «Вау, я действительно чувствую себя инструментом дизайна».

Адам: И потом, да, было бы неплохо немного улучшить экспорт. Но также было бы неплохо улучшить экспорт для DevTools, и это нас не останавливает. Так что я не знаю. Есть куча вопросов, обязательно проголосуйте по ним. Я думаю, что одной из следующих больших функций, которые я хотел бы сделать, являются зеленые линии. Таким образом, вместо того, чтобы просто показывать наложения специальных возможностей при наведении курсора, чтобы действительно указать некоторые вещи зелеными линиями, и показать больше, и показать больше информации, и я не знаю. Да.

Дрю: Размышляя над процессом создания такого расширения для Chrome, я имею в виду, предполагая, что все это реализовано на JavaScript, насколько это похоже на обычную веб-разработку? Создание расширения для Chrome.

Адам: Хороший вопрос. Это… Фу, это сложно. Это причудливо. Во-первых, среда, в которой вы запускаете свой код, — это не браузер. Они действительно не дают вам полный доступ там. Вы можете, если вы действительно с этим столкнетесь, что VisBug должен был перейти в этот еще более сложный сценарий. Так что прямо сейчас я выполнял в… Это так быстро станет нечетким.

Адам: Потому что для вашего расширения есть несколько песочниц из-за проблем с конфиденциальностью. И они затрудняют выполнение скриптов на реальной странице, верно? Потому что вы не хотите, чтобы кто-то отправлял вашу форму, когда вы запускаете эту вещь или что-то в этом роде, отправлял ее себе или что-то еще. Это может быть действительно разрушительно. Так что у него есть такие особенности. Там есть мост, по которому нужно пройти. И один из них, который преследует VisBug, это то, что VisBug использовал…

Адам: Итак, это все пользовательские элементы, а пользовательские элементы позволяют передавать им расширенные данные как свойство. Итак, вы говорите, например, customelement.foo=myrichobject, полный массивов или что-то в этом роде. И пользовательский элемент просто получает это как некоторые данные о самом узле. Но так как я нахожусь в этом странном маленьком мире-песочнице, если я пытаюсь установить что-то уникальное, подобное этому, на свой объект, по сути, это отфильтровывается. Они установили, что некоторые вещи не могут... Итак, я могу передать строку своему пользовательскому элементу, но я не могу передать ее расширенному объекту.

Адам: Но да, если не считать таких маленьких причуд, как только вы разберетесь с потоком, и если вы потратите время на получение сценария объединения, что займет час или около того работы, чтобы вы включили LiveReload в свою вещь , это может стать довольно естественным. Я думаю, что Firefox, честно говоря, имеет лучший опыт разработки расширений, если вы хорошо разбираетесь в CLI, вы можете что-то запустить с помощью одной команды, и он установит его, предоставит вам эти функции LiveReload и даст вам инструменты отладки. Это как бы держит вас за руку, это может быть очень приятно.

Адам: Но, в конце концов, это немного странно. Вот почему я много работаю над демонстрационным сайтом, который выглядит как набор артбордов, потому что большую часть времени мне не нужна настоящая веб-страница для тестирования VisBug, пока у меня есть артборды, которые имитировать различные проблемы или иметь доступные вещи для просмотра, и как бы дать мне контент, который мне нужно увидеть. Я делаю большую часть работы прямо в браузере, как если бы это было обычное веб-приложение. Таким образом, опыт разработки VisBug действительно прост, если только вы не пытаетесь протестировать его в браузере, а затем он просто становится беспорядочным и все такое.

Дрю: Это действительно интересные выводы. Итак, сегодня я узнал все о VisBug, о чем ты узнал в последнее время, Адам?

Адам: Я все еще совершенствую свои навыки вока. Так что я хочу быть мастером вока, и я не говорю о кассетном плеере 90-х. Я хочу перевернуть овощи, чтобы они немного загорелись в воздухе, посыпать их вкусными специями и просто поджарить этот чеснок, чтобы он стал хрустящим и вкусным. А затем положите его на небольшую подушку из риса и сдвиньте к себе и посмотрите, что вы думаете.

Адам: Итак, я с нетерпением жду лета прямо сейчас, потому что это означает, что я могу достать вок и вернуться в эту быстро развивающуюся, горячую среду для приготовления пищи, и это действительно весело.

Дрю: Удивительно. Звучит вкусно. Если вы, дорогой слушатель, хотели бы услышать больше от Адама, вы можете следить за ним в Твиттере, где он @argyleinc, и найти его личный сайт по адресу nerdy.dev. Если вы хотите попробовать VisBug, вы можете найти его в Интернет-магазине Chrome, а также попробовать тестовую версию на сайте visbug.web.app. Спасибо, что присоединились к нам сегодня, Адам. Были ли у вас напутствия.

Адам: Нет, ты был очень мил. Это было очень мило. Спасибо, что пригласили меня, я очень ценю это.