Adam Argyle와 함께하는 스매싱 팟캐스트 에피소드 37: VisBug란?
게시 됨: 2022-03-10이 에피소드에서 우리는 VisBug에 대해 이야기하고 있습니다. 이것은 무엇이며 Chrome DevTools에 이미 있는 옵션 배열과 어떻게 다릅니까? Drew McLellan은 제작자 Adam Argyle과 이야기를 나눴습니다.
메모 표시
- VisBug 샌드박스 및 놀이터
- 트위터의 아담
- 아담의 개인 사이트
- YouTube의 VisBug
- 비스버그 101
주간 업데이트
- 온라인 이벤트에 사용하는 회의 플랫폼: Hopin by Amanda Annandale
- Stephanie Eckles의 CSS 컨테이너 쿼리 입문서
- 수정이 필요한 짜증나는 디자인 패턴: Vitaly Friedman의 생일 선택 도구
- 나무 흔들기: Átila Fassina의 참조 가이드
- Beau Hartshorne의 핵심 Web Vitals를 개선한 방법
성적 증명서
Drew McLellan: 그는 웹에 대한 동경이 있는 밝고 열정적이며 펑크한 엔지니어로, 동급 최고의 UI 및 UX를 위해 자신의 기술을 사용하고 주변 사람들에게 권한을 부여하는 것을 선호합니다. 그는 크고 작은 회사에서 일했으며 현재 Chrome에서 Google에서 일하는 개발자 옹호자입니다. 그는 CSS 작업 그룹의 구성원이자 디자인 디버깅 도구인 VisBug의 창시자입니다. 그래서 우리는 그가 디자인과 UX에 대한 자신의 길을 알고 있다는 것을 알고 있지만 그가 살아있는 어떤 Biped보다 더 많은 슬리퍼를 소유하고 있다는 것을 알고 있습니까? 내 스매싱 친구, Adam Argyle을 환영하십시오.
아담 아가일: 안녕하세요.
드류: 아담, 안녕하십니까?
Adam: 오, 정말 대단합니다. 아시죠?
드류: 반갑 습니다. 그래서 저는 오늘 VisBug라는 프로젝트에 대해 이야기하고 일반적으로 디자인 디버깅 이면의 개념과 이것이 프로젝트 워크플로에 어떻게 적용될 수 있는지에 대해 이야기하고 싶었습니다. 제 말은, 우리는 오랫동안 개발자 중심의 브라우저 디버깅 도구를 사용해 왔습니다. 제 말은, 아마도 지금은 10년 이상일 것입니다. 그러나 그것들은 분명히 코드에 매우 집중되어 있습니다. VisBug와 다른 점은 무엇입니까? 그리고 해결하려는 문제의 종류는 무엇입니까?
아담: 굉장하다. 네, 그것이 뿌리를 두고 있는 주된 문제는 프론트 엔드 엔지니어로서 저는 항상 디자이너와 함께 일하고 우리가 앉는 이 순간을 항상 사랑했고 저는 "알았어. 마지막 손질을 하고 있습니다. 배포까지 하루나 이틀이 더 있습니다. 그러니 디자이너여, 앉아서 이것을 비판하시겠습니까? 내 로컬 호스트 버전을 브라우저나 휴대전화 등에서 열어 보고 보이는 내용에 대해 이야기해 주세요."
Adam: 그리고 수년 동안 이 일을 하고 항상 이 상호작용을 사랑한 후에는 작업이 얼마나 흔하고 단순한지 잠시 후에 죄책감을 느끼기 시작했습니다. 그들은 "여기서 1픽셀 아래에 있습니다. 여기에 5픽셀의 여백이 있습니다." 그리고 그것은 항상 넛지(nits and nudges)였고, 간격과 유형에 대한 넛지(nits and 넛지)였습니다. 내 말은, "오, 잠시만 기다려 주세요. DOM이 귀하의 요청을 지원할 수 있도록 DOM을 조정하기 위해 각도 등을 변경하는 데 30분을 소비하는 동안" 또는 기타 등등.
Adam: 일반적으로 작은 물건이었습니다. 그리고 결국 설문조사를 했고 Google의 모든 디자이너를 대상으로 설문조사를 했습니다. 그리고 저는 "DevTools를 열면 무엇을 하나요?"라고 물었습니다. 그리고 그들은 단지 기본이 필요하다는 소리가 들렸습니다. 그래서 저는 "이것이 더 쉬워야 합니다. 자동차 시트의 색상을 변경하기 위해 페라리의 후드를 열거나 엔진 덩어리를 움직일 필요가 없습니다. 그건 불공평하네요. 디자인 도구처럼 자동차 시트를 만지고 색상을 변경할 수 있어야 합니다.” 저는 "이 워크플로를 용이하게 할 수 있는 방법이 있습니다."라고 생각했습니다. "알겠습니다. 솔루션을 만들 수 있는지 알아보기 위해 해킹을 해봐야겠네요."
Adam: 그리고 그렇게 시작되었습니다. 그것은 실제로 간격과 타이포그래피에서 시작되었습니다. 그리고 설계 도구를 에뮬레이트하는 선택 메커니즘을 갖게 되자 "내가 할 수 있는 다른 일은 무엇입니까?"와 같았습니다. 그리고 그것은 거기에서 계속 진행되었습니다. 하지만 그래, 그 순간에 태어났어.
Drew: 그래서 아이디어는 클라이언트가 로고를 더 크게 만들도록 요청하고 VisBug가 브라우저가 이러한 종류의 조정을 만들기 위한 디자인 도구처럼 작동하도록 도와준다는 것입니다. Illustrator, Photoshop, Figma 또는 이러한 유형의 것들에 더 가깝습니다.
아담: 네. 그 사용 사례도 좋은 사례입니다. 고객과 함께 있을 때 "오, 우리는 이것을 좋아합니다"라고 말할 수 있기 때문에 이것은 매우 고전적입니다. "우리는 디자인을 좋아하지만 파란색은 우리에게 어렵습니다." "정말요?" 이것은 사람들이 양식을 제출하고 돈을 벌 수 있지만 지금 파란색에 대해 이야기하고 싶습니까? 그리고 일반적으로 전체 주기를 생성합니다. PM은 "알겠습니다. 귀하의 요청을 접수한 다음 설계를 위해 보내드리겠습니다."라고 말했습니다.
Adam: 하지만 디자이너가 그곳에 있고 그것을 보여주는 것이 그들의 브라우저라면 그들은 "알았어. 글쎄, 난 그냥 항목을 클릭하고 색상을 변경합니다.” 그리고 브라우저에서 변경 사항을 프로토타이핑하기만 하면 전체 작업 주기를 줄일 수 있습니다. 그래서 그렇습니다. 기존 제품 대비 가장 효과적이죠? 디버깅 도구이기 때문입니다. 반드시 생성 도구는 아닙니다. 그것은 당신을 위해 사이트를 만들지 않습니다. 그럴 수 있지만 좀 어색합니다.
Drew: 기술적으로 Chrome 브라우저에 설치하는 확장 프로그램입니다. 맞나요?
아담: 네. 그리고 확장입니다. 실행하면 "여기에 VisBug라는 사용자 지정 요소가 있습니다."라는 JavaScript 파일이 다운로드됩니다. 그런 다음 페이지에 vis-bug라는 DOM 요소를 넣습니다. 그리고 젠장, 그 순간을 도구 모음으로 바꾸고 페이지의 이벤트를 듣기 시작합니다. 나는 당신의 호버 이벤트를 듣고, 당신의 클릭 이벤트를 듣습니다. 그리고 나는 그들을 가로채기 위해 최선을 다하고, 당신의 메인 페이지와 경쟁하지 않습니다.
Adam: 하지만 그게 핵심입니다. 확장 기능인 유일한 이유는 페이지에 쉽게 넣을 수 있기 때문입니다. 현재로서는 여러 브라우저에서 사용할 수 있는 몇 가지 설정이 있습니다. 그러나 여전히 대부분 99.9%, 종속성이 없는 사용자 지정 요소입니다. 내가 사용하는 색상 라이브러리가 마음에 든다고 생각합니다. 그렇지 않으면 모든 것이 바닐라입니다. 응.
Drew: Firebug가 그렇게 시작된 것 같아요. 그렇지 않나요? 당시에는 Firefox 확장 기능으로 사용되었습니다.
아담: 네. 그래서 VisBug라고 합니다. Firebug에서 많은 영감을 얻었지만 비주얼 디자이너를 위한 것입니다.
드류: 아. 우리는 거기에 갈. 내 말은, 이것은 시각적 도구에 대해 이야기하기 위한 오디오 팟캐스트와 같은 이상적인 형식이 아닐 수도 있습니다. 그러나 원한다면 VisBug가 제공하는 도구와 옵션을 살펴보십시오.
아담: 물론입니다. VisBug가 가장 먼저 하는 일 중 하나는 집이나 컴퓨터에 있을 때 visbug.web.app으로 이동하여 확장 프로그램 없이 VisBug를 사용해 볼 수도 있습니다. 맞죠?
드류: 아.
Adam: 이것은 웹 구성 요소입니다. 그래서 여기 visbug.web.app에 웹 페이지를 로드했습니다. 이 웹 페이지에는 아트 보드가 잔뜩 들어 있고 물론 VisBug가 미리 로드되어 있는 것처럼 보입니다. 그리고 이 사이트의 목표는 플레이하고 탐색하고 삭제할 수 있도록 하는 것입니다. 삭제 키는 처음부터 가장 만족스러운 도구 중 하나라고 생각합니다. "페이지에 무엇을 할 수 있습니까?" 그리고 당신은 "글쎄, 나는 그것을 파괴 할 수 있습니다."
Adam: 그리고 삭제를 누르고 있으면 다음 항목을 찾을 수 있도록 만들었습니다. 삭제 시 꽤 어렵습니다. 무언가를 삭제하면 다음 형제가 선택됩니다. 따라서 영원히 다음 형제를 선택합니다. 전체를 지울 때까지 삭제를 누르고 있으면... 어쨌든 매우 만족스럽습니다. 새로 고침을 누르면 모두 돌아옵니다. 그러나 VisBug와 함께 제공되는 첫 번째 도구는 바로 실행할 때 가이드 도구입니다. 그리고 저는 문자 그대로 화면에 종이를 대고 있었습니다. 그렇지 않으면 일종의 표시를 하고 선을 만들 수 있는 시스템 확장을 구입하러 갔습니다.
Adam: 많은 디자이너에게 정렬은 특정 지점에서 매우 광학적이기 때문입니다. 맞죠? 그들은 반드시 수학적 정렬을 원하지 않습니다. 그렇죠? 이것이 타이포그래피에 광학 커닝이 있는 이유입니다. 수학 커닝이 아닙니다. 이것은 인간의 커닝입니다. 그래서 가이드 도구는 디자이너로부터 발생하는 많은 니트가 물건을 확대하고 정렬을 확인한다는 데 뿌리를 두고 있습니다. 간격이 좋은가요?
Adam: 이것이 가이드 도구가 수행하는 두 번째 작업입니다. 당신이 그것을 시작하고 당신이 물건 위에 마우스를 올려 놓으면 당신이 가리킨 요소 주위에 작은 상자가 생기는 것을 볼 수 있습니다. 그런 다음 통치자가 일반적으로 하는 것처럼 점선 안내선이 나타납니다. 그리고 스케치와 제플린에서 마우스로 가리키면 이러한 가이드가 표시되는 것과 마찬가지로 동일한 개념이며 페이지에 표시됩니다. 그리고 무언가를 클릭한 다음 새 대상으로 마우스를 가져가면 측정 도구가 표시됩니다. 그리고 측정 도구는 픽셀 단위이며 계산됩니다... 시각적으로 보면 그 사이에 픽셀이 몇 개인지 알 수 있습니다. 누군가가 한 말이 아닙니다. 모든 간격을 합산하는 것이 아니라 이 항목을 클릭하면 다른 상자에서 이만큼 멀리 떨어져 있습니다.
Adam: 그리고 Shift 키를 누른 상태에서 계속 클릭할 수 있고 기본적으로 5개의 아이콘 사이에 동일한 간격이 있는지 확인할 수 있기 때문에 이것이 정말 도움이 된다고 생각합니다. 클릭 몇 번이면 됩니다. 코드를 알 필요가 없습니다. VisBug를 실행하고, 마우스를 가리키고, 클릭하고, 클릭하고, 클릭하면 "오, 그렇군요. 응. 이들 각각 사이에 15픽셀이 있습니다." 또는 가끔 성가신 것을 얻을 수 있습니다. 상자를 클릭한 다음 상위 상자를 클릭하면 맨 위 거리는 9이고 맨 아래는 8이라는 것을 알게 될 것입니다. 그리고 당신은 "어떻게 이것을 중앙에 배치할 것인가? 그것은 어떻게 든 사이에 있습니다.” 그리고 주먹을 휘두릅니다.
Adam: 하지만 적어도 가이드 도구를 사용하면 멋지고 쉽게 볼 수 있습니다. 네, 바로 가이드 도구입니다.
Drew: 나는 분명히 거기에 갔고, 화면에 종이 조각을 들고 있었습니다. 또한 내가 사용할 다른 방법은 다른 브라우저 창을 열고 창 가장자리를 사용하여 항목을 정렬하는 것입니다. 그런 다음 모든 것을 올바른 위치에 유지하려고 시도하고 코드를 변경하고 새로 고칠 때 모든 것이 여전히 정렬되도록 합니다. 예, 이상적인 작업 방식이 아닙니다.
Adam: 이상적인 작업 방식은 아닙니다. 네. 그리고 다음이 있습니다. 아, 그리고 첫 번째 버전은 매우 느슨했습니다. 그것은 스냅되지 않고 십자선을 유지했습니다. 이것은 나중에 다시 추가할 기능입니다. 따라서 일부 사용자는 "이봐, 나는 스냅을 좋아한다. 내 디자인 도구와 같다. 그러나 느슨한 측정을 원하면 어떻게 합니까? 아니면 편지를 쓰고 싶은데 편지함이 아니라 편지를 측정하고 싶습니까?” 따라서 이 가이드 도구는 수정자 키를 갖도록 매우 쉽게 변경할 수 있습니다.
Adam: 여기에서 VisBug가 약간 다른 부분이 있지만 또한 친숙해지기를 바랍니다. 핫키 수정자가 매우 무겁다는 것입니다. 그래서 마치 프로 디자이너를 보는 것처럼 그들은 단축키에 매우 능숙합니다. 그리고 그들은 여기에서 바로 가기 키를 누르고, 확대하고, 저기에서 바로 가기를 치고, 키보드에서 모든 넛지를 하고 있습니다. 따라서 VisBug는 변경하는 방식에서 매우 키보드 중심적입니다.
Adam: VisBug가 다중 선택을 허용하고 동시에 100개 항목의 간격을 변경할 수 있기 때문이기도 합니다. 그리고 상대적으로 그렇게 합니다. 어쨌든 몇 가지 흥미로운 단점이 있지만 수정자 개념에서 키보드는 정말 중요합니다. 그리고 많은 도구에서 옵션, 시프트 또는 명령을 누르고 다른 것을 얻거나 거기에 새로운 종류의 기능을 얻을 수 있습니다.
Drew: 따라서 키보드 단축키를 배우는 데 비용이 많이 드는 도구 중 하나입니다.
아담: 그렇습니다 . 따라서 VisBug를 시작하고 도구 아이콘 중 하나에 마우스를 가져가면 분석 결과가 표시됩니다. 작은 플라이아웃 메뉴가 표시되고 이 도구를 선택하기 위한 단축키가 표시되며 도구가 무엇을 할 수 있는지, 도구를 얻기 위해 수행해야 할 상호 작용이 무엇인지 알려줍니다. 따라서 가이드 도구는 "요소 가이드, 그냥 호버링합니다. 무언가를 측정하고 클릭한 다음 새로운 것을 가리킵니다. 고정 측정은 Shift + 클릭이므로 지속됩니다."
Adam: 그리고 이 가이드는 스크린샷을 찍기에도 정말 좋습니다. 따라서 PR을 검토하는 경우에는 프론트 엔드 엔지니어이거나 PR을 검토하는 디자이너일 수도 있습니다. 이것은 매우 강력한 방법이 될 수 있습니다. 어떤 종류가 우리를 다음 도구로 인도합니다. 다음 도구에 대해 듣고 싶습니까?
드류: 네, 물론입니다. 가자.
아담: 굉장하다. 다음은 검사 도구입니다. 그리고 이것은 마치... 디자이너들은 일반적으로 모든 CSS를 원하지 않죠? 그들이 기대했을 때… 나는 거의 Firebug라고 말했지만 Chrome DevTools는 전체 목록을 얻습니다. 맞죠? 나는 이 H1을 선택했고 여기 모든 것이 브라우저 스타일 시트로 돌아갑니다. 그리고 디자이너는 "브라우저가 뭐죠? 브라우저에 스타일 시트가 있습니까?”
Drew: 스크롤 패널의 어두운 바닥 아래로.
Adam: 어두운 바닥, 맞죠?
드류: 네.
Adam: 마치 모든 레이어를 벗겨낸 다음 "오, 이 레이어가 더 이상 마음에 들지 않습니다."라고 말하는 것과 같습니다. 그리고 여기 있는 검사 도구에는 "아, 디자이너들이여, 당신이 무엇을 원하는지 압니다. 테두리 색상일 뿐입니다.” 기본적으로 고유한 경우에만 표시하므로 CSS 속성으로만 다루지 마십시오. 그리고 저는 주로 색상, 타이포그래피, 간격에 관심이 있습니다. 그래서 여백, 줄 높이, 글꼴 모음이 정말 중요한지 살펴보겠습니다. 맞죠? 페이지에 있는 글꼴 모음이 무엇인지 알려주는 전체 확장 기능이 있습니다.
Adam: VisBug에서는 검사 도구의 항목일 뿐입니다. 따라서 VisBug를 실행하고 검사를 누르고 아무 타이포그래피에 마우스를 가져가면 글꼴 모음이 표시됩니다. 네, 디자이너가 그것이 표면화하는 것에 초점을 맞추도록 노력합니다. 네.
Drew: 그 도구는 상속된 스타일을 표시하지 않습니다. 맞나요?
아담: 맞습니다. 그들이 상속되고 고유하지 않는 한. 그래서 만약 그들이… 텍스트 색상이나 다른 것, 텍스트 색상이 말 그대로 상속이라는 단어가 아닌 경우, 그것은 계산된 값이고 흥미로운 것임을 알려줄 것입니다.
Drew: 예, 정말 유용합니다. 예. 분명히 변경하고 싶었던 것의 한 인스턴스에 말 그대로 적용되는 것들에 집중할 수 있도록 도와줍니다. 내 말은, 이것이 정말 유용할 수 있다고 생각합니다. 이 모든 도구는 당신이 언급했듯이 이해 관계자 피드백을 받는 데 정말 유용할 것입니다. 그리고 일종의 클라이언트와 대화식으로 작업합니다.
Drew: 요즘 우리가 해야 하는 것처럼 화면 공유에서도 똑같이 잘 작동할 것이라고 생각합니다. 다른 사람과 컴퓨터에 앉아 있을 필요가 없습니다. 통화의 다른 쪽 끝에 앉아서 브라우저를 공유하고 그렇게 할 수 있습니다. 클라이언트가 화면을 가리키며 말할 수 없을 때 피드백을 받는 것이 꽤 효과적인 방법이라고 생각합니다.
아담: 확실히.
Adam: 라이브 웹페이지를 Zeplin 아트보드처럼 보이게 만드는 것은 항상 마법과 같습니다. 누군가는 "뭐... 우리가 방금 새로운 곳으로 갔나요?"라고 말합니다. 그리고 당신은 "아니요, 이것은 당신의 제품입니다. 우리는 매우 시각적으로 상호 작용하고 있습니다.” 예, 정말 좋을 수 있습니다.
Drew: VisBug가 적용되는 것을 보았거나 흥미를 느꼈던 다른 흥미로운 사용 사례가 있습니까?
아담: 네. 예, 너무 많아서 시작하기가 어렵습니다. 아, 중요한 것은 개발자와 개발자 간의 커뮤니케이션입니다. VisBug는 계산된 값에 대해 작동합니다. 그래서 그것은 당신의 저작된 가치를 보지 않습니다. 픽셀이 화면에서 계산되는 방식으로 절대적인 최종 결과를 측정하고 검사하기 때문에 정말 좋을 수 있습니다. 저작하는 쪽이 아니라 결과에 대해 작업하면서 그런 식으로 대화를 나누는 것은 정말 좋은 일입니다.
Adam: "좋아요, 이것이 시각적으로 얻은 것이라면 저작 측면에서 우리가 어떻게 잘못 되었습니까?"와 같이 돌아갈 수 있습니다. 또한 다음 도구는 접근성 검사 도구입니다. 따라서 검사 도구를 사용하면 요소의 스타일을 쉽게 볼 수 있으며 매우 디자이너 친화적인 방식으로 분류합니다. 접근성 도구는 페이지의 모든 요소를 검사하는 데 도움이 되며 액세스 가능한 모든 속성을 표시하므로 무엇인가 완료되었는지 확인하기가 더 쉽습니다.
Adam: 그래서 PR은… 그리고 일이 종종 만들어집니다. 그래서 이것은 다시 개발자 대 개발자, 디자이너 개발자입니다. 여러분은 인터페이스를 검토하고 있습니다. 너무 중요합니다. 인터페이스를 보고 있고 궁금한 점이 있으면 VisBug에 사용 사례가 있습니다. 브라우저에서 일종의 프로토타입을 만들 수 있는 사용 사례도 있습니다. 그래서 우리는 클라이언트가 파란색을 시도하고 싶어하는 것과 같은 것에 대해 이야기했습니다. 네, 아주 쉬운 시나리오입니다.
Adam: 하지만 다른 것들도 있습니다. VisBug에서 명령 D를 누르면 요소가 복제됩니다. 그리고 무엇을 복제하든 상관없습니다. 따라서 헤더를 복제하고 두 헤더 사이에 약간의 간격을 추가하고 브라우저에서 변형을 라이브로 만들 수 있습니다. 헤더 텍스트를 두 번 클릭하면 편집 가능한 텍스트 필드가 됩니다. 그러면 새 헤드라인을 시도하고 헤드라인이 어떻게 맞는지 확인합니다. 간격을 조정하고 소스 파일과 그런 종류의 모든 것을 찾는 이 모든 개발자 작업을 저장하면 됩니다.
Adam: 네, 탐색하고 확인하는 데 도움이 될 수 있습니다. 좀 이상하네요... 제 말은, DevTools가 하는 많은 일들이죠, 그렇죠? 작업을 마친 후에 들어옵니다. 실제로 소스 코드를 자주 제공하지 않으며 DevTools에서 코드를 복사하는 경우도 많지 않습니다. 키 값 쌍을 복사할 수 있습니다. "아, 스타일 바꿨어." 하지만 그래, 어쨌든.
드류: 음-흠 (긍정적). 응. 나는 당신이 언급한 항목 복제를 원할 수 있는 특히 시각적인 경우를 생각할 수 있습니다. 페이지의 전체 섹션을 복사하여 예상했던 것보다 훨씬 더 많은 콘텐츠가 있는 경우 어떤 모습일지 시뮬레이션할 수 있습니다.
아담: 네. 이것이 카오스 테스트 사용 사례입니다.
드류: 네.
아담: 물론입니다.
Drew: 이것은 CMS 기반 시스템과 모든 종류의 재미있는 작업으로 디자인하는 우리 모두가 처리해야 하는 것입니다.
Adam: 네, 그것도 정말 중요한 사용 사례입니다. 내가 그 일을 하기 위해... 그래, 내가 말했듯이 헤드라인. 텍스트를 두 번 클릭하기만 하면 키보드가 쾅 닫힙니다. 블라, 블라, 블라, 블라, 그리고 공백을 많이 쳤다, 블라, 블라 그리고 저는 "좋아, 레이아웃은 어땠어? 오, 잘했어. 좋아요, 다음으로 넘어갈 수 있습니다. 이것을 네 번 복제하면 어떻게 됩니까? 여전히 모든 것 사이에 공간이 있습니까? 다음 항목 옆에 흐르나요?”
Adam: 콘텐츠 혼돈의 시뮬레이션에 정말 좋을 수 있습니다. 정말 짧은 제목, 정말 긴 제목, 친구는 없고 백만 명의 친구가 있습니다. UI에서 이러한 사용 사례를 어떻게 처리합니까? 네.
Drew: 따라서 모든 브라우저 기반 콘텐츠에서 작동합니다. 그래서 일반 웹 페이지뿐만 아니라 PWA?
아담: 네, 그렇습니다. 따라서 Spotify가 설치되어 있으면 항상 이 작업을 수행하고 Spotify를 설치하고 "Spotify, 당신은 검사할 수 없는 앱처럼 보입니다."라고 말할 것입니다. 하지만 그거 알아? VisBug는 상관하지 않습니다. VisBug는 모든 항목을 오버레이하고 모든 타이포그래피를 검사합니다. 라이트 테마를 만들었습니다... 아, 스포티파이 라이트 테마를 만든 트윗이 어딘가요.
Adam: 오, 이것은 색상 프로토타이핑에 대한 또 다른 사용 사례였습니다. 죄송합니다. 많은 스티커 시트를 어지럽히지 않고도 제품 자체에 밝은 테마를 만들 수 있습니다. 따라서 중요한 멘탈리티가 있습니다. VisBug가 사람들이 제품을 놀이터로 사용하는 데 도움이 되었으면 합니다. 그것을 사용하십시오 ... 너무 현실적입니다. 디자인 구성 요소보다 더 사실적입니다. 그러니 거기에서 더 많은 시간을 보내십시오. 실제 제품을 작업하면서 보다 효과적인 디자인 결정을 내릴 수 있다는 것을 알게 되리라 생각합니다.
Drew: 접근성의 경우도 특히 흥미롭습니다. 특히 요즘에는 구성 요소 라이브러리에서 많은 작업을 하고 페이지의 작은 구성 요소를 살펴보고 있기 때문입니다. 그리고 고객이 실제로 상호 작용하는 일종의 보기를 생성하기 위해 함께 통합된 모든 항목을 살펴보는 데 시간을 덜 소비합니다. 그리고 페이지에 표시되지 않는 접근성 항목, 속성과 같은 미세한 세부 사항을 주시하기가 정말 어려워집니다.
Drew: 보이지 않는 것을 관찰하는 것은 매우 어렵습니다. 이것이 바로 도구가 무언가를 검사하고 올바른 역할을 하고 있다는 것을 확인하는 데 정말 정말 도움이 되는 부분입니다.
아담: 그렇습니다 . 그것이 정확한 사용 사례입니다. PM이 이 내용을 확인할 수 있기를 바랍니다. 디자이너가 접근성을 살펴보고 도구를 열지 않고 DOM 노드를 찾을 수 있기를 바랍니다. 모든 것이 요소 패널에 정리되어 이상하게 보입니다. "여기에 영역 속성이 있습니다. 존재하는 경우 제목이 있습니다." 다른 접근성 도구도 있습니다. VisBug는 검색 아이콘과 함께 제공됩니다. 검색 아이콘에는 여러 가지 방법으로 상호 작용할 수 있습니다.
Adam: 먼저 페이지를 쿼리합니다. 따라서 원하는 요소 유형이나 요소 클래스 이름을 알고 있으면 검색만 하면 되므로 마우스로 찾을 필요가 없습니다. 그러나 여기에는 슬래시 명령도 있습니다. VisBug에는 플러그인이 있으며 페이지에서 스크립트를 실행합니다. 따라서 3~4개의 책갈피를 저장한 적이 있다면... "모든 테두리를 강조 표시하고 내 상자를 표시하기 때문에 이 책을 사용하겠습니다." 디버그 트릭이나 그런 것과 같습니다.
Adam: 아마도 VisBug 플러그인일 것입니다. 그래서 VisBug를 시작하고 슬래시를 누르면 자동 완성이 되고 다른 모든 플러그인이 표시됩니다. 그리고 오류를 오버레이하는 정말 좋은 접근성 기능과 이와 같은 다양한 것들이 있습니다. 그래서 동의합니다. 접근성이 더 높아야 합니다. 하기가 애매합니다. 그러나 공구 벨트에 더 가까워야 합니다. 그리고 때로는 너무 멀리 떨어져 있어서 놓치는 경우도 있다고 생각합니다. 그래서 좀 더 전면에 있고 중앙에 있고 더 쉽게 확인되기를 바랍니다. 응.
Drew: 그리고 VisBug가 색상과 같은 일종의 계산된 값으로 작동한다고 말씀하신 것도 흥미롭습니다. 즉, 불투명도 수준이 다른 여러 계층 요소가 있는 경우 화면에 렌더링되는 정확한 색상을 측정할 수 있습니다.
아담: 오오.
Drew: ... 개별 요소를 살펴보고 어떻게든 해결하려고 합니까?
Adam: 정말 좋은 질문입니다. 그래서 제 생각에 제가 질문을 제대로 이해하고 있다면 이것은 프론트 엔드의 고전적인 어려움입니다. 예, 반불투명한 텍스트 단어가 있는지 어떻게 알 수 있습니까? 회색과 흰색의 색상은 무엇입니까 ? 그리고 그 대조를 어떻게 알 수 있습니까? 지금 당장은 모릅니다. 따라서 VisBug는 색상을 알고 있으며 "50% 회색" 또는 거기에 있는 색상이 무엇이든 말합니다. 하지만 그보다 더 똑똑한 것은 없습니다. 할 수 없다…
Adam: 이 경우에 해야 할 일은 캔버스를 만들고 거기에 모든 레이어를 칠한 다음 스포이드를 사용하거나… 단일 페인팅된 레이어를 선택한 다음 단일 픽셀 값을 뽑아 다른 항목에 레이어링된 후 실제 끝 계산 회색이 무엇인지 확인합니다.
Adam: 누군가 지정했다고 생각합니다. 아니면 GitHub 문제로 있으면 좋을 것 같습니다. VisBug가 이것을 용이하게 할 수 있기 때문에 100%. VisBug, 무대 뒤에서 이미 텍스트 메트릭으로 작업을 완료했습니다. 여기서 마우스를 가져가면 글꼴에 대한 미친 정보를 얻을 수 있습니다. x 높이 및 캡 높이와 같이 거의 너무 많은 정보이지만 더 많이 사용됩니다. 그리고 그것은 "오, 나는 특정 지점에서 일종의 꺼짐입니다."와 같습니다. 그래서 신호 대 잡음을 찾는 방법을 알아내야 합니다.
Adam: 하지만 네, 저는 이 사고 과정을 좋아합니다. 왜냐하면 우리는 그렇게 하는 도구가 있어야 하기 때문입니다. 그리고 그것을 계산하는 방법을 안다면 VisBug에게 그렇게 하도록 가르칠 수 있으며, 불투명도와 관련된 계산된 색상을 갖는 것은 정말 멋진 기능이 될 것입니다. 사랑해.
Drew: 네, 제 말은, 대비가 접근성 요구 사항을 통과하기에 충분한지 확신할 수 없는 배경에 대해 텍스트가 있는 일종의 표준 사례입니다. 그리고 아마도 그렇지 않을 수도 있습니다. 아마도 너무 낮은 대비이고 대비가 좋은 지점에 도달할 때까지 값을 조정하고 싶지만 브랜드 색상 측면에서 클라이언트가 처음에 원했던 것에서 너무 멀리 표류하지 않았습니다. 그리고 것들.
Adam: 통과할 때까지 충돌이라고 합니다.
드류: 네.
Adam: 그것이 바로 그런 느낌이기 때문입니다. 나는 "오, 나는 점수가 조금 부족합니다." 따라서 HSL 밝기로 이동하여 "Ding"과 같이 녹색 확인 표시가 나타날 때까지 작은 숫자가 똑딱거리는 것을 지켜봅니다. 나는 "좋아, 좋아." 그리고 예, 때로는 그 색상 중 일부가 시원하지 않습니다. 자, 진행 중인 3.0 지각 접근성 작업에 대해 많이 공부하셨나요? 더 이상 AA 또는 AAA를 사용하지 않기 위해 숫자를 사용하고 글꼴 두께와 같은 항목을 포함합니다. 그래서 얇은 글꼴이면 점수가 낮고, 두꺼운 글꼴이면 ... 대조되는 부분이 많기 때문입니다.
드류: 네, 아니요, 그런 건 본 적이 없지만 그런 소리는-
Adam: 어쨌든, 탐험하는 것은 정말 멋진 일입니다.
Drew: 흥미롭게 들립니다. 그렇습니다. 그것에 대해 이야기할 사람을 찾아야 합니다. 또 다른 에피소드입니다. 따라서 일부 개발자는 VisBug가 수행하는 모든 작업을 DevTools의 CSS 패널을 통해 수행할 수 있다고 주장할 수도 있습니다. 그리고 제 생각에는 그것이 공평하지만 아마도 요점을 놓쳤을 것입니다. 예, 변경할 때 CSS를 조작하고 있지만 개발자 중심 인터페이스가 아닌 일종의 디자이너 중심 사용자 인터페이스를 맨 위에 놓는 것입니다. 그것이 정당한 특성인가?
아담: 정말 공정한 말씀입니다. 그리고 솔직히 최고의 아이디어는 VisBug에서 DevTools로 옮겨집니다. 그리고 그들은 이미 가지고 있습니다. 따라서 VisBug는 요소에서 명령 옵션 C를 누르면 최소한 고유한 모든 계산된 스타일을 사용합니다. 다시 말하지만, 우리는 이러한 모든 상속된 속성을 제공하지 않을 것입니다. 그러나 모두 클립보드에 저장하고 스타일 시트나 CodePen에 해당 스타일을 붙여넣고 말 그대로 몇 번의 클릭으로 요소를 다시 만들 수 있습니다.
Adam: 그런 종류의 상호 작용은 DevTools, 해당 요소 패널로 이어졌습니다. 하지만 그렇지 않은 것이 있습니다. 즉, DevTools는 단일 노드 검사 전용 도구입니다. 그리고 VisBug는 디자인 도구의 만트라를 따릅니다. 아니요, 다중 선택이 가능해야 합니다. 일괄 편집, 일괄 검사를 할 수 있어야 합니다. 그래서 저는 항상 간격을 두고 VisBug를 사용합니다. 여러 요소를 강조 표시하고 여백이 축소되는 것을 볼 수 있기 때문입니다.
Adam: DevTools에서는 이를 볼 수 없습니다. 대부분의 시간에 한 번에 하나의 노드만 볼 수 있기 때문입니다. 여러 여백을 표시하는 방법이 있지만 동일하지는 않습니다. 네, 정말 재미있을 수 있는 틈새 사용 사례가 있습니다. 또 다른 하나는 강조 표시하는 경우... 타이포그래피 시스템이 있고 H1에서 H7까지 있다고 가정해 보겠습니다. 동화책이나 이와 유사한 것입니다. VisBug에서 모든 항목을 강조 표시하고 Shift 키를 누른 상태에서 모두 클릭하기만 하면 됩니다. 뽈뽈뽈뽈뽈뽈뽈뽈뽈뽈뽈뽈뽈뺑뺑뺑뺑뺑뺑뺑뺑뺑뺑뺑뺑뺑뱱뱱뇱뇱뇱뇱뇱뇱.........
Adam: 그래서 그들 각각은 하나씩 위로 또는 아래로 조금씩 움직입니다. 그리고 그것은 DevTools가 매우 쉽게 만드는 것이 아닙니다. 그래서, 예, 그것은 약간 더 불가지론적이기 때문에 그런 초능력을 가지고 있습니다. 그리고 항상 배열을 반복할 준비가 되어 있습니다. 응.
Drew: VisBug의 기원은 무엇입니까? 그리고 지금은 단지 개인 프로젝트입니까? 아니면 구글 프로젝트인가요? 아니면 상태가 어떤가요?
아담: 네. 먼저 상태는 Google 프로젝트입니다. 주요 목표는 DevTools에 들어가기 전에 프로토타입을 만들고 탐색할 수 있는 장소가 되는 것입니다. 적어도 구글 측에서는 말이다. 그러나 개인적인 측면에서는 여전히 일반적인 작업을 수행하거나 일반적인 작업을 수행하기 위해 일부 최적화를 수행하는 곳으로 봅니다. 그리고 더 많은 청중이 DOM을 살펴볼 수 있는 방법을 제공합니다.
Adam: 저는 DevTools가 매우 강력하다고 생각하지만 매우 위협적입니다. 탭 하나만으로도 경력을 쌓을 수 있습니다. 저는 여전히 DevTools에서 무언가를 배우고 있으며 항상 사용하고 있습니다. 네, 이것은 어떤 면에서 다른 청중입니다. 코딩할 생각은 없지만 출력에 관심이 있는 초보자, 들어오는 사람들 또는 PM, 관리자와 같은 사람들이 더 많습니다. 그래서 그것은 그들에게 단지 거기에 들어갈 수 있는 가벼운 도구를 제공합니다.
Drew: 흥미로운 점입니다. 개인적으로 이러한 모든 종류의 DevTools를 관리할 때 편안한 워크플로를 찾는 데 어려움을 겪는 경우가 많기 때문입니다. 그리고 여러분은 이 작은 밀실 공포증 패널을 가지고 있고, 그것들을 다른 창으로 분리할 수 있지만 두 개의 다른 창을 추적해야 합니다. 브라우저 창을 몇 개 열면 다음 작업을 할 수 없습니다. 한 창에 집중하면 어느 DevTools가 그 창에 속하는지 알 수 없습니다.
Drew: 그리고 패널 자체 내에서는 일종의 와일드 웨스트 사용자 인터페이스 규약입니다. 스크롤을 내리면 예상하지 못한 이상한 일이 일어나기 시작합니다. 그리고 사용자 경험의 관점에서 보면 이 모든 것이 큰 혼란에 불과하다고 생각합니다.
아담: 그렇습니다 . 응.
드류: 그게 불가피하다고 생각하세요? 더 좋을 수 있습니까?
Adam: 확실히 여기에 생각이 있습니다. 그리고 예, 제 생각에는 좋은 것 같아요... 지금 여러분에게 다음과 같은 청취자가 있다고 가정해 보겠습니다. “저는 DevTools에 대해 잘 알고 있습니다. 나는 그들이 그렇게 미쳤다고 생각하지 않습니다.” "알겠습니다. Android Studio 또는 Xcode를 엽니다. 프로젝트를 시작하고 DevTools를 살펴보고 출력을 살펴보세요. 당신은 지금 얼마나 친숙하다고 느끼십니까?” 아마도 매우 외국. 당신은 그 진행을보고 있습니다, "이것은 쓰레기입니다. 그들은 왜 이것을합니까? 이 패널이 왜 여기에 있습니까?” 그리고 당신의 마음은 이 모든 질문과 이유와 혼란으로 경주하기 시작합니다.
Adam: 그리고 모든 사람들이 DevTools를 처음 열 때 느끼는 느낌이 같습니다. 그래서 당신은 그것에 대해 정말로 공감해야 합니다.
Drew: 불가피한 일인가요... 더 잘할 수 있을까요? 아니면 이것은 일종의 자연스런 질서입니까?
Adam: 이에 대한 저의 현재 견해는 다음과 같습니다. 저는 복잡성에 빠져들기 정말 쉽다고 생각합니다. 그리고 DevTools는 그러한 것들 중 하나이며, 자연스럽게 복잡합니다. 이러한 많은 것들을 용이하게 하는 좋은 UI는 없습니다. 이러한 많은 것들이 개발자에 의해 구축됩니다. 그리고 저는 개발자가 개발자를 위한 도구를 구축하는 것이 괜찮다고 생각합니다. 왜냐하면 당신은 다음을 갖게 될 것이기 때문입니다. 그것이 유일한 방법이거나 그것이 좋은 방법일지라도 당신은 그것을 배우고 능숙하게 될 것입니다. 그러면 편안해집니다.
Adam: 그리고 모든 DevTools는 이상한 사용 사례를 위해 만들어졌기 때문에 좀 이상합니다. 그렇죠? 개발이 이상합니다. 그냥 정직하자. 우리는 보이지 않는 톱니와 보이지 않는 것을 2개씩 만들고 기본적으로 보이지 않는 가상 부품으로 집을 짓습니다. 네, 우리는 이러한 것들을 검사하고 그들이 무엇을 출력하고 있는지 알려주기 위해 이상한 도구가 필요합니다.
Adam: 즉, VisBug가 하는 일과 제가 천천히 DevTools로 옮기고 있는 것은 많은 작업을 수행한다고 주장하는 큰 도구와 대조적으로 더 집중된 작은 도구입니다. 많은 일을 정말 잘한다는 것은 어려운 일이라고 생각합니다. 그리고 이것은 고전적인 주장입니다. 그렇죠? 이것은 모든 별, 전문가 대 제너럴리스트입니다. 어느 쪽도 항상 완벽하지는 않습니다.
Adam: 그러나 VisBug가 하려고 하는 것은 전문가를 만들었다는 것입니다. 따라서 가이드 도구는 가이드를 수행합니다. 그리고 그 도구는 페이지의 다른 도구로 누출되지 않습니다. 그래서 저는 DevTools가 디자이너를 더 많이 돕고자 하는 DevTools로 더 많은 일을 하려고 노력하고 있습니다. VisBug는 DevTools가 볼 수 있도록 영감을 주는 데 도움이 된 것입니다. 그리고 제가 계속해서 소개하는 방식은 예를 들어 그리드 편집기를 만드는 대신... "하나의 오버레이에서 그리드의 모든 기능"을 수행할 수 있는 곳입니다. "트랙을 추가하고 트랙을 제거할 수 있습니다. ㅋ, ㅋ, ㅋ."
Adam: 그리고 저는 "정말 멋지고도 복잡하게 들립니다."라고 생각합니다. 저는 "그리드가 미쳤습니다. 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. 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. 그래서…
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는 상관하지 않습니다. 계산된 오버레이를 계속 그리므로 간격을 변경할 수 있습니다.
Adam: 디자이너로서 페이지의 조감도를 실시간으로 보는 것이 정말 중요하다고 생각하기 때문입니다. 애니메이션은 여전히 재생 중입니다. 스크롤 가능한 영역은 여전히 스크롤할 수 있습니다. 맞죠? 정말 쿨하다. "내 전체 페이지를 한 번에 볼 수 있습니다." 어쨌든 거의 다 되었습니다. 안에-
드류: 이상하게 들리네요.
Adam: 매우 엉뚱합니다. 그리고 그것이 들어 있습니다. 브라우저 간에 작동하는지 확인해야 합니다. 라이브 페이지가 그런 식으로 느껴지도록 하기 위해 분명히 몇 가지 까다로운 일을 하고 있기 때문입니다. 하지만 그래.
드류: 놀랍군. 그렇습니까… 제 말은, VisBug가 상당히 정기적으로 업데이트되고 진행되고 있다고 가정합니다. 미래에 우리가 볼 수 있는 것은 무엇입니까?
Adam: 네, 확실히 제가 작업하고 있는 기능 중 하나입니다. 제게는... 그래서, 당신이 무언가를 클릭하면 당신이 핸들처럼 보이는 오버레이를 얻게 됩니다, 그렇죠? 그리고 그것은 일종의 환상입니다. 그것은 당신을 편안하게 해줄 것입니다. 그리고 의도는 결국 해당 핸들을 드래그할 수 있게 하는 것입니다. 하지만 브라우저의 요소에 너비가 없는 것과 같이 먼저 해결해야 하는 몇 가지 기본적인 사항이 있습니다. 따라서 너비를 잡기 시작하면 그 환상이 제대로 느껴지도록 작업을 수행해야 합니다.
Adam: 그리고 원하는 결과를 얻지 못할 수도 있습니다. 왜냐하면 너비를 더 작게 당기는 블록 수준 요소일 수 있고 옆에 있는 항목의 리플로우를 얻지 못할 수 있기 때문입니다. 그리고 그 이유가 궁금할 것입니다. 그래서 모서리를 끌거나 요소를 끌 수 있는 프로토타입이 있습니다. 하지만 디자인 도구가 이 작업을 수행하는 방법에 집중해야 합니다. 항상 이 토글 버튼이 있습니다. 그리고 그것은 마치... 보세요, 토글의 이름은 무엇입니까?
Adam: 하지만 기본적으로 수축과 비슷합니다. 저는 수축 포장이라고 부릅니다. 내 요소를 축소합니다. 이 요소의 너비는 해당 콘텐츠의 너비입니다. 여기 내 요소의 너비는 무엇인가를 붙이십시오. 따라서 브라우저에서 이와 같은 것이 필요합니다. 요소에 오버레이되어 이들 중에서 선택할 수 있고 어쩌면 블록과 인라인 중에서 선택할 수 있도록 하여 원하는 결과를 얻을 수 있습니다.
Adam: 하지만 궁극적으로 여기서 목표는 VisBug가 완전히 키보드로 구동되는 것을 원하지 않는다는 것입니다. 나는 당신이 간격을 끌 수 있기를 바랍니다. 상단에 12개의 여백 간격이 표시되면 손을 뻗어 잡을 수 있어야 하지만 지금은 상자의 상단을 지정하기 위해 키보드를 눌러야 하며 여백을 추가해야 합니다.
Adam: 네, 전략 측면에서 해결해야 할 몇 가지 단점이 있습니다. 그러나 설계 도구에 더 가깝게 만드는 것이 매우 큰 목표입니다. 그리고 어쩌면 나도 그것에 구부릴 것입니다. 너비를 변경하고 이상한 디자인을 얻으려는 경우 위치 도구를 사용하여 흐름을 벗어날 수 있는 것처럼 VisBug를 사용하면 항상 벗어날 수 있는 방법이 있습니다. 흐름이 아이디어를 망치고 있으므로 위치 도구를 사용하면 탈출할 수 있습니다.
Adam: 그리고 거기에... 누군가 VisBug에 대해 정말 잘 알고 있다면 사람들의 마음을 사로잡을 것입니다. 일종의 무제한이기 때문에 테이블에 무엇을 가져올 수 있습니까? 표현 요소가 있습니다. 확실히 표현 전술이 있습니다. 하지만 어쨌든, 간단히 말해서 환상은, 나는 단지 그것을 점점 더 작게 만들고 싶다는 것입니다. 저는 환상이 "와, 정말 디자인 도구가 된 기분입니다."라고 하고 싶습니다.
Adam: 그러면 수출에 대한 몇 가지 개선 사항이 좋을 것입니다. 그러나 또한 DevTools용 내보내기 기능이 향상되면 좋을 것입니다. 그래서 나는 모른다. 많은 문제가 있습니다. 확실히 그것에 대해 투표하십시오. 다음으로 하고 싶은 큰 기능 중 하나는 녹색 선입니다. 따라서 마우스를 가져갈 때 접근성 오버레이를 표시하는 대신 실제로 일부 항목을 녹색 선으로 표시하고 더 많이 노출하고 더 많은 정보를 표시합니다. 응.
Drew: 이와 같은 Chrome 확장 프로그램을 구축하는 과정에 대해 생각해보면, 모든 것이 JavaScript로 구현되었다고 가정할 때 일반 웹 개발과 얼마나 비슷할까요? Chrome 확장 프로그램 빌드.
아담: 좋은 질문입니다. 그것은… 휴, 이것은 어려운 것입니다. 그것은 기발하다. 우선, 코드를 실행하는 환경은 브라우저가 아닙니다. 그들은 거기에서 당신에게 완전한 접근을 제공하지 않습니다. VisBug가 졸업해야 하는 이 작업이 정말 까다로워지면 이 더 까다로운 시나리오도 가능합니다. 그래서 바로 지금, 나는 ...에서 실행하곤 했습니다. 이것은 너무 빨리 퍼지게 될 것입니다.
Adam: 개인 정보 보호 문제를 위해 확장에 대한 샌드박스가 여러 개 있기 때문입니다. 그리고 그들은 실제 페이지에서 스크립트를 실행하기 어렵게 만듭니다. 그렇죠? 당신이 무언가를 시작할 때 누군가가 당신의 양식을 제출하는 것을 원하지 않기 때문입니다. 정말 파괴적일 수 있습니다. 그래서 그런 단점이 있습니다. 건너야 할 다리가 있습니다. VisBug를 괴롭히는 것 중 하나는 VisBug가 사용하던…
Adam: 모든 것이 사용자 지정 요소이고 사용자 지정 요소를 사용하면 풍부한 데이터를 속성으로 전달할 수 있습니다. 그래서 당신은 customelement.foo=myrichobject, 배열로 가득 찬 것과 같은 것을 말하고 있는 것입니다. 그리고 커스텀 요소는 그것을 노드 자체의 일부 데이터로 가져옵니다. 그러나 나는 이 이상한 작은 샌드박스 세계에 있기 때문에 내 개체에 이와 같은 고유한 것을 설정하려고 하면 기본적으로 필터링됩니다. 그들은 특정 항목이 할 수 없다는 것을 확인했습니다. 따라서 문자열을 사용자 지정 요소에 전달할 수 있지만 풍부한 개체는 전달할 수 없습니다.
Adam: 하지만 예, 그런 사소한 문제를 제외하고는 일단 흐름이 저하되고 롤업 시나리오를 얻는 데 시간을 할애하면 한 시간 정도 작업을 하여 LiveReload를 작업에 제공할 것입니다. , 꽤 자연스럽게 될 수 있습니다. 솔직히 말해서 Firefox는 CLI에 정통하다면 하나의 명령으로 무언가를 실행할 수 있고 설치하고 이러한 LiveReload 기능을 제공하며 디버깅 도구를 제공하는 경우 최고의 확장 개발 경험을 가지고 있다고 생각합니다. 그것은 그것을 통해 당신의 손을 잡고, 그것은 정말 멋질 수 있습니다.
Adam: 그러나 궁극적으로, 그것은 조금 기발합니다. 이것이 내가 많은 시간 동안 실제 웹 페이지가 필요하지 않기 때문에 VisBug 테스트를 수행하기 위해 대지가 있는 한 많은 대지처럼 보이는 데모 사이트에서 많은 작업을 수행하는 이유입니다. 다양한 문제를 시뮬레이션하거나 볼 수 있는 접근 가능한 항목을 갖고 내가 보고 싶은 콘텐츠를 제공합니다. 나는 그것이 단지 일반적인 웹 응용 프로그램인 것처럼 브라우저에서 바로 많은 작업을 수행합니다. 따라서 VisBug의 개발 경험은 브라우저 전체에서 테스트하려고 하지 않는 한 정말 쉽습니다.
Drew: 정말 흥미로운 통찰력입니다. 그래서 저는 오늘 VisBug에 대해 모두 배웠습니다. Adam, 최근에 무엇을 배웠습니까?
Adam: 나는 여전히 wok 기술을 향상시키고 있습니다. 그래서 저는 웍맨이 되고 싶습니다. 90년대 카세트 플레이어를 말하는 것이 아닙니다. 나는 야채를 뒤집고 공중에서 약간의 불을 붙이고 맛있는 향신료로 덮고 마늘을 정말 구워서 바삭하게 맛있게 만들고 싶습니다. 그리고 그것을 작은 밥 위에 놓고 당신쪽으로 밀어서 당신이 생각하는 것을보십시오.
Adam: 그래서 저는 지금 여름에 신이 났어요. 왜냐하면 냄비를 꺼내고 빠르게 변화하는 뜨거운 요리 환경으로 돌아가야 한다는 것을 의미하기 때문입니다. 정말 재미있습니다.
드류: 놀랍군. 맛있겠다. 청취자 여러분, Adam의 소식을 더 듣고 싶다면 Twitter에서 @argyleinc로 그를 팔로우하고 nerdy.dev에서 그의 개인 웹사이트를 찾을 수 있습니다. VisBug를 사용해보고 싶다면 Chrome 웹 스토어에서 찾을 수 있으며 visbug.web.app에서 샌드박스 버전을 사용해 볼 수 있습니다. 오늘 함께해주셔서 감사합니다. Adam. 이별의 말은 없었나요?
Adam: 아니요, 당신은 정말 좋았습니다. 이것은 정말 달콤했습니다. 참여해주셔서 감사합니다. 정말 감사합니다.