Smashing Podcast Episodul 37 cu Adam Argyle: Ce este VisBug?

În acest episod, vorbim despre VisBug. Ce este și prin ce diferă de gama de opțiuni deja găsite în Chrome DevTools? Drew McLellan vorbește cu creatorul său Adam Argyle pentru a afla.

Afișați note

• Cutie cu nisip VisBug și loc de joacă
• Adam pe Twitter
• Site-ul personal al lui Adam
• VisBug pe YouTube
• VisBug 101

Actualizare săptămânală

• Platforma de conferințe pe care o folosim pentru evenimentele noastre online: Hopin de Amanda Annandale
• O instrucție despre interogările de containere CSS de Stephanie Eckles
• Modele de design frustrante care au nevoie de remediere: Selector de aniversare de Vitaly Friedman
• Tree-Shaking: A Reference Guide de Átila Fassina
• Cum ne-am îmbunătățit elementele vitale web de bază de Beau Hartshorne

Transcriere

Drew McLellan: Este un inginer punk strălucitor, pasionat, cu o adorație pentru web, care preferă să-și folosească abilitățile pentru cele mai bune UI și UX din clasă și să-i împuternicească pe cei din jur. A lucrat la companii mici și mari și, în prezent, este un avocat al dezvoltatorilor care lucrează la Google pe Chrome. Este membru al grupului de lucru CSS și creatorul VisBug, un instrument de depanare a designului. Deci știm că se pricepe la design și UX, dar știai că deține mai multe perechi de șlapi decât orice biped viu? Prietenii mei zdrobitori, vă rog bun venit lui Adam Argyle.

Adam Argyle: Bună.

Drew: Bună Adam, ce mai faci?

Adam: Oh, mă zdrobesc, știi asta.

Drew: E bine de auzit. Așa că am vrut să vă vorbesc astăzi despre proiectul dvs., VisBug și, în general, despre conceptul din spatele depanării de design și despre cum s-ar putea integra în fluxurile de lucru ale proiectului. Adică, avem de mult timp instrumente de depanare a browserului axate pe dezvoltatori, adică, probabil, de peste un deceniu. Dar acestea sunt, evident, foarte concentrate pe cod. Deci, ce este diferit la VisBug? Și care este genul de problemă pe care încearcă să o rezolve?

Adam: Minunat. Da, principala problemă în care își are rădăcina este că, în calitate de inginer front-end, lucrez tot timpul cu designeri și întotdeauna mi-a plăcut acest moment în care ne-am așezat și mi-aș spune: „Bine. Fac ultimele retușuri. Mai avem încă o zi sau două până la desfășurare. Deci, designer, stai jos și ai critica asta? Vreau să-mi deschizi versiunea gazdă locală pe browser și pe telefon, sau orice altceva, și să-mi vorbești despre ceea ce vezi.”

Adam: Și după ce am făcut asta mulți ani și am iubit mereu această interacțiune, am început să mă simt vinovat după un timp din cauza cât de comune și simple erau sarcinile. Ar fi de genul „Un pixel aici jos. Marja de cinci pixeli aici.” Și au fost întotdeauna linii și ghionturi, și linii și ghionturi la spațiere și tip. Adică, rareori era de genul „Oh, stai puțin în timp ce petrec 30 de minute schimbând unele unghiulare, sau orice altceva, pentru a-mi ajusta DOM-ul, astfel încât DOM-ul să poată susține cererea ta” sau orice altceva.

Adam: De obicei erau lucruri mici. Și apoi am ajuns să fac un sondaj și i-am chestionat pe toți acești designeri de la Google. Și am spus: „Când deschizi DevTools, ce faci?” Și a fost oarecum răsunător că au nevoie doar de elemente de bază. Și așa s-a născut din, am spus: „Ar trebui să fie mai ușor. Nu ar trebui să slăbiți capota Ferrari-ului, să mutați o bucată de motor, doar pentru a schimba culoarea scaunelor auto. Nu este cinstit. Ar trebui să poți atinge scaunele mașinii și să schimbi culoarea, la fel ca un instrument de design.” Am spus: „Ceva ar putea facilita acest flux de lucru.” Și am spus: „Bine, cred că voi pirata ceva pentru a vedea dacă pot crea soluția.”

Adam: Și așa a început totul. A început cu adevărat cu spațiere și apoi cu tipografie. Și odată ce am avut un mecanism de selecție care a emulat instrumentele de design, a fost de genul „Ei bine, ce altceva pot face?” Și a continuat să meargă de acolo. Dar da, născut în acel moment.

Drew: Deci, ideea este că clientul vă cere să măriți logo-ul, iar VisBug ajută browserul să se comporte mai mult ca un instrument de design pentru a face astfel de modificări. Deci mai aproape de ceva precum Illustrator, sau Photoshop, sau Figma sau oricare dintre aceste tipuri de lucruri.

Adam: Da. Acest caz de utilizare este și el unul bun. Pentru că ai putea fi cu un client și ei spun: „Oh, ne place asta”, este atât de clasic, „ne place designul, dar acea culoare albastră este grea pentru noi.” Și tu spui: „Serios?” Este ca și cum oamenii pot trimite un formular și tu poți câștiga bani, dar vrei să vorbești cu mine despre albastru chiar acum? Și de obicei ar crea un întreg ciclu. Primul-ministrul spunea: „Bine, vă vom elimina cererea și apoi o vom trimite la proiectare”.

Adam: Dar dacă designerul este acolo și browserul lor este cel care le arată, ar spune: „Bine. Ei bine, voi face doar clic pe chestia și voi schimba culoarea.” Și puteți întrerupe un întreg ciclu de lucru doar prin prototiparea modificării acolo în browser. Deci este. Este cel mai eficient împotriva unui produs existent, nu? Pentru că este un instrument de depanare. Nu este neapărat un instrument de generație. Nu creează un site pentru tine. Se poate, dar e cam ciudat.

Drew: Deci, din punct de vedere tehnic, este o extensie pe care o instalezi într-un browser Chrome. Este corect?

Adam: Da. Și este o extensie. Când îl lansați, descarcă un fișier JavaScript care spune: „Iată un element personalizat numit VisBug”. Și apoi puneți elementul DOM, vis-bug pe pagină. Și uf, iau acel moment și îl transform într-o bară de instrumente și încep să ascult evenimentele de pe pagină. Vă ascult evenimentele de tip hover și vă ascult evenimentele clic. Și încerc să fac tot posibilul să le interceptez și să nu concurez cu pagina ta principală.

Adam: Dar da, asta este esența... Singurul motiv pentru care este o extensie este doar pentru a fi ușor de pus pe pagina ta. Deși în acest moment are unele setări care vin cu dvs. în toate browserele. Dar este în mare parte, 99,9%, un element personalizat fără dependențe. Cred că îmi place o bibliotecă de culori pe care o folosesc și, în rest, este doar vanilie. Da.

Drew: Cred că așa a început Firebug, nu-i așa? Ca o extensie pentru Firefox pe vremuri.

Adam: Da. De aceea se numește VisBug. Este foarte inspirat de Firebug, dar pentru designeri vizuali.

Drew: Ah. Iată-ne. Adică, acesta nu este formatul ideal, fiind un podcast audio, pentru a vorbi despre un instrument vizual. Dar, dacă doriți, treceți-ne prin câteva dintre instrumentele și opțiunile pe care vi le oferă VisBug.

Adam: Absolut. Deci, unul dintre primele lucruri pe care le face VisBug, și poți, de asemenea, dacă ești acasă sau la computer, poți să mergi pe visbug.web.app și să încerci VisBug fără extensie, nu?

Drew: Ah.

Adam: Este o componentă web, așa că am încărcat o pagină web pentru tine aici la visbug.web.app care pare să aibă o grămadă de panouri de artă și apoi, desigur, VisBug preîncărcat. Și scopul acestui site este să vă permită să jucați, să explorați și să ștergeți. Cred că tasta de ștergere este unul dintre cele mai satisfăcătoare instrumente pentru început. Ești de genul „Ce pot să fac unei pagini?” Și tu spui: „Ei bine, pot să-l distrug.”

Adam: Și am făcut-o astfel încât să poți apăsa ștergerea, va găsi următorul... Ceea ce este destul de dificil cu o ștergere. Ștergi ceva și selectează următorul frate. Deci va selecta următorul frate pentru totdeauna. Dacă țineți apăsat șterge până când ștergeți întregul... Oricum, foarte satisfăcător. Apăsați pe reîmprospătare și totul revine. Dar primul instrument cu care VisBug este livrat, așa că atunci când tocmai îl lansați, este instrumentul de ghiduri. Și obișnuiam să țin literalmente hârtie pe ecran, sau mă duceam să iau o extensie de sistem care să-mi permită să marchez lucrurile și să creez linii.

Adam: Pentru că, da, alinierea devine foarte optică la un moment dat pentru mulți designeri, nu? Ei nu vor, neapărat, aliniere matematică, nu? Acesta este motivul pentru care tipografia are kerning optic. Nu este kerning matematică. Aceasta este kerning uman. Și astfel, instrumentul de ghiduri este înrădăcinat în faptul că o mulțime de nits care apar de la un designer se apropie de lucruri, verificând alinierea. Este buna distanta?

Adam: Deci acesta este al doilea lucru pe care îl face instrumentul de ghidare. Când îl lansați și treceți cu mouse-ul pe lucruri, veți vedea că elementul pe care sunteți plasat primește o cutie mică în jurul lui. Și apoi apar ghiduri întrerupte, la fel cum ar face în mod normal conducătorii. Și la fel ca în Sketch și Zeplin, unde treci cu mouse-ul și primești aceste ghiduri, este același concept, doar live pe pagina ta. Și dacă faceți clic pe ceva și apoi treceți cu mouse-ul către o nouă destinație, obțineți instrumente de măsurare. Și instrumentele de măsurare sunt în pixeli și sunt calculate... Deci vizual, câți pixeli sunt între ele. Nu ce a spus cineva. Nu adună toată spațierea, ci doar faci clic pe acest lucru și ești atât de departe de acea altă casetă.

Adam: Și cred că asta devine foarte util, pentru că poți menține shift și continua să dai clic și, în esență, să verifici dacă ai distanță egală între cinci pictograme. Și sunt doar câteva clicuri. Nu trebuie să cunoașteți codul, doar lansați VisBug, treceți cu mouse-ul, faceți clic, faceți clic, faceți clic și veți vedea că, „Oh, uite că este. Da. 15 pixeli între fiecare dintre aceștia.” Sau, uneori, obțineți ceva care este oarecum enervant, veți da clic într-o casetă și apoi veți face clic pe caseta părinte și vă veți da seama că distanța sa de sus este nouă și cea de jos este de opt. Și tu spui: „Cum voi centra asta? Este cumva la mijloc.” Și scutură pumnul.

Adam: Dar măcar poți să-l vezi frumos și ușor cu instrumentul de ghiduri. Deci da, acesta este instrumentul de ghiduri.

Drew: Cu siguranță am fost acolo, ținând bucăți de hârtie pe ecran. Și, de asemenea, celălalt truc pe care l-aș folosi este să deschid o altă fereastră de browser și să folosesc marginea ferestrei pentru a alinia elementele. Și apoi încerci să păstrezi totul la locul potrivit, astfel încât, pe măsură ce faci schimbarea și reîmprospătarea codului, totul este încă în ordine. Da, nu este un mod ideal de lucru, deci.

Adam: Nu este un mod ideal de lucru. Da. Și urmează următorul... Deci, oh, și prima versiune a fost foarte liberă. Nu s-a rupt, ci doar a susținut o cruce, care este o caracteristică pe care o voi adăuga mai târziu. Așa că unii utilizatori spun: „Hei, îmi place snapping, este exact ca instrumentele mele de design. Dar dacă vreau o măsurătoare liberă? Sau vreau să fac o scrisoare, vreau să măsor o scrisoare, nu cutia ei de scrisori?” Și așa, ei bine, acest instrument de ghiduri ar putea fi schimbat foarte ușor cu o cheie modificatoare.

Adam: Așadar, aici este locul în care VisBug devine puțin diferit, dar și, sperăm, familiar, este foarte greu de modificatori de taste rapide. Așa că, la fel ca dacă te uiți la un designer profesionist, ei sunt foarte pricepuți la tastele rapide. Și apăsează taste rapide aici, măresc, apăsează taste rapide acolo și doar fac toate ghionturile de la tastatură. Și astfel, VisBug este foarte centrat pe tastatură în modul în care schimbați lucrurile.

Adam: De asemenea, se datorează faptului că VisBug permite selecții multiple și poate modifica distanța a 100 de articole în același timp. Și o face relativ. Deci, oricum, are câteva ciudatenii interesante, dar tastatura într-un concept de modificator este cu adevărat importantă. Și puteți menține opțiunea, sau schimbați sau comanda într-o mulțime de instrumente și obțineți ceva diferit sau obțineți un nou tip de caracteristică acolo.

Drew: Deci este unul dintre acele instrumente în care merită să înveți comenzile rapide de la tastatură.

Adam: Da. Și atunci când lansați VisBug și treceți cu mouse-ul peste una dintre pictogramele instrumentului, veți obține o defalcare. Aruncă un mic meniu derulant, spune tasta rapidă pentru alegerea acestui instrument și vă spune ce poate face și ce interacțiuni trebuie să faceți pentru a le obține. Deci, instrumentul de ghiduri spune: „Ghiduri de elemente, treceți cu mouse-ul. Măsurați ceva, faceți clic și apoi plasați cursorul pe ceva nou. Măsurătorile lipicioase sunt shift plus clic, astfel încât acestea vor persista.”

Adam: Și aceste ghiduri sunt foarte bune și pentru capturi de ecran. Deci, dacă revizuiți un PR, chiar și ca doar un inginer front-end, sau poate un designer care revizuiește un PR, aceasta poate fi o modalitate foarte puternică de a intra acolo și, da, să aveți o inspecție de înaltă fidelitate. Ceea ce ne conduce la următorul instrument. Vrei să auzi despre următorul instrument?

Drew: Da, sigur. Hai sa incercăm asta.

Adam: Minunat. Următorul este instrumentul de inspectare. Și acesta este ca... Designerii, de obicei, nu vor tot CSS-ul, nu? Când se așteaptă cu... Aproape am spus Firebug, dar Chrome DevTools, obțineți lista completă, nu? Am selectat acest H1 și deci aici este totul până la foaia de stil a browserului. Iar designerul spune: „Ce browser-ul? Browserul are o foaie de stil?”

Drew: Jos, în partea de jos tulbure a acelui panou de defilare.

Adam: Fundul tulbure, nu?

Drew: Da.

Adam: E ca și cum ai dezlipit toate straturile și apoi îți spui: „Ooh, nu-mi mai plac aceste straturi.” Și instrumentul de inspectare de aici spune: „Ah, designeri, știu ce vreți. Este doar culoarea chenarului.” Practic, arată-mi ceva doar dacă este unic, așa că nu mă acoperi doar cu proprietăți CSS. Și sunt foarte interesat de culoare, tipografie și spațiere. Așa că mă voi uita la marginile, înălțimile liniilor, familia de fonturi este foarte importantă, nu? Există o extensie întreagă doar pentru a vă spune care este familia de fonturi pe o pagină.

Adam: În VisBug, acesta este doar un element rând din instrumentul de inspectare. Deci, lansați VisBug, apăsați inspectați și plasați cursorul pe orice tipografie și vă va spune familia de fonturi. Deci, da, încearcă să facă un designer concentrat pe ceea ce iese la suprafață, da.

Drew: Deci instrumentul nu afișează niciun stil moștenit. Este corect?

Adam: Este corect. Cu excepția cazului în care sunt moștenite și unice. Deci, dacă ei... O culoare de text sau ceva, dacă culoarea textului nu este literalmente cuvântul moștenire, vă va spune că este o valoare calculată, că este ceva interesant.

Drew: Da, este un lucru foarte util doar... Da. Vă ajută să vă concentrați asupra lucrurilor care se aplică literal acelui exemplu de ceva, care este, evident, ceea ce ați vrut să schimbați. Adică, cred că acest lucru ar putea fi cu adevărat util, toate aceste instrumente ar fi foarte utile pentru, așa cum ați menționat, obținerea de feedback a părților interesate. Și un fel de lucru interactiv cu un client.

Drew: Cred că ar funcționa la fel de bine peste partajarea ecranului, așa cum trebuie să facem în aceste zile, din ce în ce mai mult. Nu trebuie să fii așezat la un computer cu cineva, ai putea fi așezat la celălalt capăt al unui apel și să-ți partajezi browserul și să o faci așa. Cred că ar fi o modalitate destul de eficientă de a obține feedback atunci când un client nu poate arăta spre ecran și spune:

Adam: Cu siguranță.

Adam: Este întotdeauna magic când transformi pagina web live în ceea ce arată ca o planșă de artă Zeplin. Cineva spune: „Ce... tocmai am plecat într-un loc nou?” Și îți spui: „Nu, acesta este produsul tău. Interacționăm cu el doar vizual.” Da, poate fi foarte frumos.

Drew: Există și alte cazuri de utilizare interesante pe care le-ați văzut pe VisBug sau care vi s-au întâmplat să fie interesante?

Adam: Da. Deci, da, sunt atât de multe încât este cam greu să începi. Oh, unul care este important este comunicarea dintre dezvoltatori. VisBug lucrează pe valorile calculate. Deci nu se uită la valorile tale de autor. Și asta poate fi foarte frumos, pentru că măsori și inspectezi rezultatul final absolut în modul în care pixelii au fost calculati pe ecran. Și asta poate fi foarte frumos, să ai o conversație în acest fel, în timp ce lucrezi la rezultate, spre deosebire de partea de autor.

Adam: Și poți să te întorci spre genul „Bine, cum am greșit în partea de autor, dacă asta am obținut vizual?” Care este, de asemenea, un fel de joacă, următorul instrument este instrumentul de inspectare a accesibilității. Deci, instrumentul de inspectare ușurează doar vizualizarea stilurilor de pe un element și le defalcă într-un mod foarte prietenos cu designerul. Instrumentul de accesibilitate vă ajută să inspectați toate elementele dintr-o pagină și evidențiază orice proprietăți accesibile pe care le are, ceea ce face, sper, mai ușor să verificați dacă ceva este făcut.

Adam: Deci un PR... Și lucrurile sunt adesea create. Deci, acesta este, din nou, de la dezvoltator la dezvoltat, de la dezvoltator de designer, tu revizuiești interfețele. Este atât de critic. Dacă te uiți la o interfață și ești curios, VisBug are un caz de utilizare pentru tine acolo. Există, de asemenea, cazuri de utilizare în care puteți sorta prototipuri în browser. Așa că am vorbit despre unul în care se pare că clientul a vrut să încerce albastrul. Bine, acesta este un scenariu destul de ușor.

Adam: Dar mai sunt și altele. Dacă apăsați comanda D pe VisBug, veți duplica un element. Și nu-i pasă ce duplicați. Deci, puteți duplica un antet, adăugați niște spații între cele două anteturi și faceți o variantă live în browser. Faceți dublu clic pe textul antetului și acesta devine un câmp de text editabil și încercați un nou titlu și vedeți cum se potrivește titlul. Ajustați puțin spațierea și tocmai v-ați salvat toată munca asta de dezvoltator, găsind un fișier sursă și tot felul de chestii și ești doar...

Adam: Deci da, te poate ajuta să explorezi și să verifici. Este un fel de ciudat... Adică, sunt multe dintre lucrurile pe care le face DevTools, nu? Vine după ce ați terminat, de fapt nu vă oferă cod sursă foarte des, nu se întâmplă foarte des să copiați codul din DevTools. Puteți copia o pereche cheie valoare. De exemplu, „Oh, am schimbat acest stil”. Dar da, oricum.

Drew: Mm-hmm (afirmativ). Da. Mă pot gândi la un fel de cazuri deosebit de vizuale în care ați putea dori, ați menționat, să duplicați articole. Poate doriți să luați o secțiune întreagă a paginii și să o duplicați pentru a simula cum ar fi dacă ar exista mult mai mult conținut decât v-ați aștepta.

Adam: Da. Acesta este cazul de utilizare a testării haosului.

Drew: Da.

Adam: Absolut.

Drew: Ceea ce este ceva cu care trebuie să ne confruntăm cu toții, proiectând cu un fel de sisteme bazate pe CMS și tot felul de sarcini distractive.

Adam: Da, și acesta este un caz de utilizare cu adevărat crucial. Pentru că o fac pentru... Da, titluri, așa cum am spus. Doar faceți dublu clic pe un text și eu doar trântesc tastatura. Bla, bla, bla, bla, și lovește o grămadă de spații, bla, bla. Și eu zic: „Bine, cum a mers aspectul? Oh, a făcut bine. Bine, bine, pot trece la următorul lucru. Ce se întâmplă dacă o dublez de patru ori? Mai există spațiu între toate? Curge lângă următorul articol?”

Adam: Poate fi foarte frumos pentru acea simulare a haosului de conținut. Titlu foarte scurt, titluri foarte lungi, nu are prieteni, are un milion de prieteni. Cum gestionați aceste cazuri de utilizare în UI? Da.

Drew: Deci funcționează cu orice conținut bazat pe browser. Deci, PWA, precum și pagini web obișnuite?

Adam: Da, da. Deci, dacă aveți Spotify instalat, fac asta tot timpul, am instalat Spotify și voi spune doar „Spotify, pari o aplicație imposibil de inspectat”. Dar ghicește ce? VisBug nu-i pasă. VisBug suprapune toate lucrurile dvs., inspectează toată tipografia. Am creat o temă ușoară pentru... Oh, am un tweet undeva unde am făcut o temă ușoară pentru Spotify.

Adam: Oh, acesta a fost un alt caz de utilizare, scuze, pentru prototiparea culorii. Pot crea o temă ușoară pe produsul în sine, fără a fi nevoit să mă încurc cu o grămadă de foi de autocolante, nu? Așa că există această mentalitate importantă și uniformă, mi-ar plăcea ca VisBug să-i ajute pe oameni să intre, adică să folosească produsul dvs. ca loc de joacă. Folosește asta ca... Este atât de real. Este mai real decât sunt compușii dvs. de design. Așa că petreceți mai mult timp acolo. Cred că veți descoperi că puteți lua decizii de design mai eficiente lucrând la produsul dvs. real.

Drew: Și cazul accesibilității este deosebit de interesant, pentru că adesea, în special în zilele noastre, lucrăm foarte mult în biblioteci de componente și ne uităm la componente mici ale unei pagini. Și petrecând mai puțin timp uitându-se la toate cele integrate împreună pentru a crea genul de vederi cu care interacționează de fapt un client. Și devine foarte dificil să urmăriți acele detalii mai fine, cum ar fi lucruri de accesibilitate, atribute, care nu sunt vizibile pe pagină.

Drew: Este foarte dificil să fii cu ochii pe lucruri care nu sunt vizibile. Așadar, aici uneltele pot ajuta cu adevărat, într-adevăr, pentru a putea inspecta ceva și a vedea că, da, are rolurile corecte și este...

Adam: Da. Acesta este exact cazul de utilizare. Vreau ca un PM să poată verifica aceste lucruri. Vreau ca un designer să poată să se uite la accesibilitate și să nu fie nevoit să deschidă instrumentele, să găsească nodul DOM, totul este strâns în panoul de elemente și arată ciudat. Că doar spune: „Iată atributele zonei, iată titlul dacă există.” Există și alte instrumente de accesibilitate. VisBug este livrat cu pictograma de căutare. Pictograma de căutare are mai multe moduri de a interacționa cu ea.

Adam: Deci mai întâi interogează pagina. Deci, dacă știți tipul de element sau numele clasei de element pe care îl doriți, îl puteți căuta, astfel încât să nu fie nevoie să îl găsiți cu mouse-ul. Dar are și comenzi slash în el. Deci există pluginuri în VisBug și vor executa scripturi pe pagină. Deci, dacă ați avut vreodată un marcaj pe care l-ați salvat trei sau patru... Vă spuneți: „O să-l folosesc pe acesta pentru că evidențiază toate chenarele și îmi arată cutiile”. Este ca un truc de depanare sau așa ceva.

Adam: Probabil este un plugin VisBug. Deci lansați VisBug, apăsați slash și veți obține completarea automată și vă va afișa toate pluginurile diferite. Și există unele de accesibilitate care sunt foarte drăguțe care suprapun erori și diverse lucruri de genul acesta. Deci sunt de acord. Accesibilitatea ar trebui să fie mai accesibilă. E doar prost să spun. Dar trebuie să fie mai aproape de centura de scule. Și cred că uneori este prea departe și poate de aceea este ratat. Așa că sper că dacă este puțin mai în față și în centru și mai ușor să fie verificat mai mult. Da.

Drew: Și este interesant să spui că VisBug funcționează cu genul de valori calculate ale lucrurilor, așa cum sunt culorile. Înseamnă asta că, dacă aveți mai multe elemente stratificate care au niveluri diferite de opacitate, veți putea măsura exact culoarea care este redată pe ecran, mai degrabă decât...

Adam: Ooh.

Drew: … uitându-te la elementele individuale și încercând să rezolvi cumva?

Adam: E o întrebare foarte bună. Deci, cred că, dacă înțeleg bine întrebarea, care este o dificultate clasică în front-end este, da, de unde știi dacă ai un cuvânt text pe jumătate opac, care este culoarea lui peste gri versus peste alb ? Și de unde îi știi contrastul? Momentan, nu știm. Deci, VisBug știe culoarea și va spune „50% gri” sau orice culoare este pe care o aveți acolo. Dar nu știe nimic mai inteligent decât atât. Nu este capabil să…

Adam: Cred că ceea ce ar trebui să faci în acest caz este să creezi o pânză, să pictezi toate straturile de acolo și apoi să folosești o picătură sau o... Așa că ai reda-o în pânză, le-ai face pe toate zdrobite într-un un singur strat pictat, apoi scoateți valoarea unui singur pixel pentru a vedea care este capătul său real de gri calculat după ce a fost stratificat pe celelalte lucruri.

Adam: Cred că cineva a specificat-o, sau poate că o am ca problemă GitHub că ar fi bine. Pentru că VisBug ar putea facilita acest lucru, 100%. VisBug, în culise, am terminat deja cu metrica text, unde treci cu mouse-ul pe lucruri și îți oferă informații nebunești despre fonturi. Sunt aproape prea multe informații, cum ar fi înălțimea x și înălțimea capacului, dar merge și mai mult. Și este de genul: „Ooh, sunt cam oprit la un moment dat.” Așa că trebuie să-mi dau seama cum să găsesc semnalul față de zgomot acolo.

Adam: Dar da, îmi place acest proces de gândire, pentru că ar trebui să avem un instrument care să facă asta. Și dacă știm cum să-l calculăm, îl putem învăța pe VisBug să o facă și ar fi o caracteristică foarte grozavă de a avea o culoare calculată relevantă pentru opacitate. Place.

Drew: Da, vreau să spun, este genul de caz standard de a avea text pe un fundal în care nu ești sigur dacă contrastul este suficient pentru a trece cerințele de accesibilitate. Și poate că nu este, poate că este un contrast prea scăzut și vrei să modifici apoi valorile până când ajungi până la punctul în care contrastul este bun, dar nu se îndepărtează prea mult de ceea ce și-a dorit inițial clientul în ceea ce privește culorile mărcii. si lucruri.

Adam: Eu o numesc bump, bump până treci.

Drew: Da.

Adam: Pentru că așa se simte. Eu zic: „Oh, sunt puțin scurt la scor”. Așa că e ca și cum, voi merge la luminozitatea mea HSL și voi doar să ciocnesc, să mă lovesc și să mă uit la numerele mici care se ridică până când îmi spune „Ding”, am o bifă verde. Eu zic: „Bine, bine.” Și da, uneori, o parte din acea culoare nu este grozavă. Deci, ați studiat o mare parte din activitatea de accesibilitate perceptivă 3.0 care se desfășoară? Ca să nu mai avem AA sau AAA, vom avea un număr și include lucruri precum subțirea fontului. Deci, dacă este un font subțire, va obține un scor mai mic, dacă este un font gros, merge... Pentru că sunt multe care intră în contrast.

Drew: Da, nu, nu văzusem nimic din toate astea, dar asta sună...

Adam: Oricum, este un lucru foarte tare de explorat.

Drew: Sună fascinant, da. Va trebui să găsesc pe cineva cu care să vorbesc despre asta. Este un alt episod. Deci, vreau să spun, sunt sigur că unii dezvoltatori ar putea argumenta că tot ceea ce face VisBug îl poți face doar prin panoul CSS din DevTools. Și cred că este oarecum corect, dar probabil că pierde sensul, deoarece, da, manipulezi CSS atunci când faci modificări, dar pune deasupra un fel de interfață de utilizator axată pe designer, mai degrabă decât o interfață axată pe dezvoltator. Este aceasta o caracterizare corectă a ei?

Adam: Este unul cu adevărat corect. Și sincer, cele mai bune idei trec din VisBug în DevTools. Și au deja. Deci, VisBug, dacă apăsați opțiunea de comandă C pe orice element, este nevoie de fiecare stil calculat, cel puțin acesta este unic. Din nou, se pare că vom face unele pe care nu le vom oferi doar toate aceste proprietăți moștenite. Dar le puneți pe toate în clipboard și puteți merge să lipiți acel stil în altă parte, într-o foaie de stil, într-un CodePen și să recreați literalmente elementul în câteva clicuri.

Adam: Și astfel de interacțiuni și-au făcut loc în DevTools, în acel panou de elemente. Există, totuși, alte lucruri care nu au, și anume, DevTools este un instrument de inspecție cu un singur nod. Și VisBug urmează mantra instrumentului de design care este, nu, ar trebui să pot să selectez multiplă. Trebuie să pot edita în bloc, să inspectez în bloc. Și așa folosesc VisBug tot timpul pentru spațiere. Pentru că pot evidenția mai multe elemente și pot vedea marginea care se prăbușește.

Adam: În DevTools nu îl poți vedea niciodată, pentru că poți vedea doar un nod la un moment dat de cele mai multe ori, deși există modalități de a afișa mai multe margini, dar nu este același lucru. Și așa, da, are aceste cazuri de utilizare de nișă care pot fi foarte distractive așa. Un altul este, dacă evidențiați un... Să presupunem că aveți un sistem de tipografie și aveți de la H1 la H7, ca într-o carte de povești sau ceva de genul, le puteți evidenția pe toate în VisBug, țineți apăsat shift, doar faceți clic pe toate. Boop, boop, boop, boop, accesați instrumentul de tipografie și apăsați în sus sau în jos și face o schimbare relativă pentru fiecare dintre ele.

Adam: Așa că fiecare dintre ei va împinge unul în sus sau în jos unul. Și nu este ceva pe care DevTools îl face foarte ușor. Și așa, da, are niște superputeri de genul acesta, pentru că este puțin mai agnostic. Și este pregătit să repete întotdeauna pe o matrice. Da.

Drew: Deci care a fost originea VisBug? Și acum este doar un proiect personal? Sau este un proiect Google? Sau care este starea?

Adam: Da. Deci, în primul rând, starea este că este un proiect Google. Scopul său principal este să fie un loc de prototip și de explorat înainte ca lucrurile să intre în DevTools. Cel puțin din partea Google a lucrurilor. Dar din partea mea personală a lucrurilor, încă îl văd ca un loc în care să merg în sarcinile obișnuite sau să coacem în unele optimizări pentru a îndeplini sarcinile comune. Și doar pentru a oferi unui public mai larg o modalitate de a privi în DOM.

Adam: Chiar cred că DevTools este super puternic, dar este foarte intimidant. Doar o singură filă poate fi nevoie de o carieră pentru a învăța. Încă învăț lucruri în DevTools și le folosesc tot timpul. Și da, acesta este un public diferit în anumite privințe. Sunt mai degrabă începători, oameni care vin, sau poate chiar oameni precum PM, manageri, care nu intenționează niciodată să codifice, dar sunt interesați de rezultat. Și așa le oferă, da, doar unelte ușoare pentru a intra acolo.

Drew: Este un punct interesant pe care îl aduceți în discuție, pentru că eu personal deseori constat că mă străduiesc să găsesc un flux de lucru confortabil în gestionarea tuturor acestor tipuri de DevTools. Și aveți toate aceste mici panouri claustrofobe și le puteți detașa într-o altă fereastră, dar apoi trebuie să urmăriți două ferestre diferite. Și odată ce ai câteva ferestre de browser deschise, nu poți... Te concentrezi pe una și nu știi care DevTools îi aparține.

Drew: Și apoi, în interiorul panourilor în sine, este un fel de un fel de Vestul Sălbatic al convențiilor interfeței cu utilizatorul. Vei derula și lucrurile vor începe să facă lucruri ciudate la care nu te așteptai. Și în ceea ce privește experiența utilizatorului, simt că totul este doar o mare mizerie.

Adam: Este. Da.

Drew: Crezi că asta e inevitabil? Poate fi mai bine?

Adam: Cu siguranță am gânduri aici. Și da, cred că este un lucru bun... Deci, să presupunem că aveți un ascultător chiar acum, care este de genul „Sunt destul de priceput cu DevTools. Nu cred că sunt atât de nebuni.” Aș spune: „Bine, deschide Android Studio sau Xcode. Începeți un proiect și uitați-vă la DevTools, uitați-vă la rezultat. Cât de familiar te simți acum?” Probabil foarte străin. Te uiți la asta: „Acesta este gunoi. De ce fac asta? De ce este acest panou aici?” Și mintea ta începe să se întreabă cu toate aceste întrebări de ce și confuzie.

Adam: Și e ca și cum, așa se simte toată lumea prima dată când deschid DevTools. Deci trebuie să fii într-adevăr empatic cu asta.

Drew: Este inevitabil ca... Putem face mai bine? Sau este acesta doar genul de ordine naturală a lucrurilor?

Adam: Așadar, iată părerea mea actuală despre asta: cred că este foarte ușor să intri în complexitate. Și DevTools este unul dintre acele lucruri, sunt doar complexe în mod natural. Nu există o interfață de utilizare bună care să faciliteze multe dintre aceste lucruri. Multe dintre aceste lucruri sunt construite de dezvoltatori. Și cred că dezvoltatorii construiesc instrumente pentru dezvoltatori, pentru că vei avea... Dacă este singura modalitate, sau chiar dacă este o modalitate bună, o vei învăța și te vei pricepe la și te vei simți confortabil cu el.

Adam: Și toate DevTools sunt oarecum ciudate, pentru că sunt făcute pentru cazurile lor de utilizare ciudate, nu? Dezvoltarea este ciudată. Să fim sinceri. Facem roți invizibile și invizibile doi câte patru și construim case, practic, cu părți invizibile, virtuale. Deci da, avem nevoie de instrumente ciudate pentru a inspecta aceste lucruri și pentru a ne spune ce produc.

Adam: Acum, acestea fiind spuse, ceea ce face VisBug și cum am mutat încet lucrurile în DevTools, sunt instrumente mai mici, care sunt mai concentrate, spre deosebire de un instrument mare care pretinde că face multe. Cred că este greu ca lucrurile să se descurce foarte bine. Și acesta este un argument clasic, nu? Toate astea sunt vedete, specialiști versus generaliști. Nici unul nu va fi întotdeauna perfect.

Adam: Dar ceea ce încearcă să facă VisBug este că a făcut specialiști. Deci, instrumentul de ghiduri face doar ghiduri. Și acel instrument nu se scurge niciodată în celelalte instrumente ale paginii. Și așa că încerc să fac asta mai mult cu DevTools, unde DevTools dorește să ajute mai mult designerii, ceea ce VisBug a ajutat să inspire DevTools să vadă. Și modul în care continui să introduc lucruri este, în loc să fac un editor de grilă, de exemplu, unde poți... „Puterea completă a rețelei într-o singură suprapunere”, nu? „Puteți adăuga piese, elimina piese, bla, bla, bla.”

Adam: Și eu zic: „Sună foarte tare și, de asemenea, foarte complex.” 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.

Adam: Am un mod în care, când lansați VisBug, ia întregul document HTML și îl micșorează într-o planșă de desen. Arată ca o panou de artă. Plutește pe o umbră pe un spațiu gri. Îl poți deplasa la infinit. Deci, puteți derula departe de pânza paginii dvs. și ceea ce vă permite să faceți este să vedeți, să presupunem că aveți o pagină care este foarte lungă și doriți să măsurați ceva de sus în jos, ei bine, puteți face asta chiar acum , dar ai cam pierde contextul pe măsură ce mergi.

Adam: Ei bine, în acest nou scenariu de zoom VisBug, țineți apăsată opțiunea sau alt pe tastatură, folosiți rotița mouse-ului sau apăsați pe plus minus cu comanda dvs. și vă puteți mări pagina web ca și cum ar fi o panou de desen. Și încerc să o fac la fel de perfectă. Deci intri și ieși, și derulezi în jos, intri și ieși, măsori de la... Și lui VisBug pur și simplu nu-i pasă. Continuă să deseneze suprapuneri calculate, puteți schimba spațierea.

Adam: Pentru că cred că este foarte important, ca designer, să vezi în direct pagina ta. Animațiile încă rulează, toți. Zonele care pot fi derulate sunt încă derulabile, nu? E foarte tare. Ești de genul „Toată pagina mea într-o singură vizualizare”. Oricum, deci aproape gata. Este înăuntru-

Drew: Sună deranjant.

Adam: Este foarte trippy. Și este în, trebuie doar să mă asigur că funcționează în mai multe browsere, pentru că face unele, evident, niște lucruri dificile pentru a face pagina ta live să se simtă așa. Dar da.

Drew: Uimitor. Este... Adică, presupun că VisBug este actualizat destul de regulat și este în curs de progres. Ce ne-am putea aștepta să vedem în viitor?

Adam: Da, asta este cu siguranță una dintre caracteristicile la care lucrez acolo. Am o caracteristică în care... Deci, când dai clic pe ceva, primești o suprapunere cu ceea ce arată ca mânere, nu? Și este un fel de iluzie, ar trebui să te facă să te simți confortabil. Și intenția este ca, în cele din urmă, ca acele mânere să fie trasabile. Dar am câteva lucruri fundamentale pe care trebuie să le rezolv mai întâi, cum ar fi elementele din browser nu au o lățime. Așa că, dacă începi să apuci lățimea, trebuie să lucrez pentru ca acea iluzie să se simtă corectă.

Adam: Și s-ar putea să nu obții nici măcar rezultatele pe care le dorești, pentru că ar putea fi un element la nivel de bloc care micșorezi lățimea și nu obții un element de lângă el. Și s-ar putea să vă întrebați de ce. Deci am prototipuri în care puteți trage colțuri, trage elemente în jur. Dar chiar trebuie să mă concentrez asupra modului în care instrumentele de design fac acest lucru. Au întotdeauna acest buton de comutare. Și este ca... Vezi, cum se numește comutatorul?

Adam: Dar practic este ca și cum ar fi shrink... Eu o numesc shrink wrap. Shrink wrap elementul meu, este lățimea acestui element este lățimea conținutului său, față de aici este lățimea elementului meu, lipiți ceva în el. Așa că am nevoie de așa ceva în browser, suprapus pe element, astfel încât să puteți alege între acestea și poate chiar ceva care să vă permită să alegeți între bloc și inline, astfel încât să puteți obține rezultatele pe care le doriți.

Adam: Dar, în cele din urmă, scopul aici este ca VisBug să nu dorească să fie în întregime condus de tastatură. Vreau să poți trage spațierea. Dacă vedeți o distanță de 12 marje deasupra, ar trebui să puteți ajunge și să o luați, în timp ce acum trebuie să apăsați pe tastatură pentru a specifica partea superioară a casetei necesită o adăugare de marjă.

Adam: Și așa da, am câteva ciudații de rezolvat, în ceea ce privește strategia. Dar este foarte mult un obiectiv să-l apropii și mai mult de instrumentele de proiectare. Și poate chiar și eu mă voi apleca în asta. E ca și cum, ei bine, dacă vrei să schimbi lățimea și vei obține un design ciudat, există întotdeauna modalități de a ieși din el cu VisBug, ca și cum instrumentul de poziție chiar te lasă să scapi de flux. Deci fluxul îți distruge ideea, instrumentul de poziție te lasă să scapi.

Adam: Și așa mai sunt... Dacă cineva ar deveni cu adevărat priceput cu VisBug, le-ar uimi mințile oamenilor, pentru că este un fel de nelimitat, și este ca, ce poți aduce la masă? Are un element de expresie. Cu siguranță există tactici expresive. Dar oricum, atât de lungă povestea este, iluzia este că vreau doar să o fac din ce în ce mai mică și mai mică. Vreau ca iluzia să fie de genul „Wow, chiar mă simt ca un instrument de design”.

Adam: Și apoi, da, unele îmbunătățiri ale exportului ar fi bine. Dar, de asemenea, îmbunătățirea exportului pentru DevTools ar fi plăcută, iar asta nu ne oprește cu adevărat. Deci nu stiu. Sunt o mulțime de probleme, cu siguranță mergi la vot. Cred că una dintre următoarele mari caracteristici pe care mi-ar plăcea să le fac sunt liniile verzi. Așa că, în loc să afișăm doar suprapuneri de accesibilitate la trecerea cursorului, pentru a indica cu adevărat unele lucruri cu linii verzi și a expune mai multe și a scoate la suprafață mai multe informații, și nu știu. Da.

Drew: Cum mă gândesc la procesul de construire a unei extensii Chrome ca acesta, adică, presupunând că totul este implementat în JavaScript, cât de mult seamănă cu dezvoltarea web obișnuită? Crearea unei extensii Chrome.

Adam: E bună întrebare. Este... Puff, asta e greu. Este ciudat. În primul rând, mediul în care puteți lansa codul nu este browserul. Nu vă oferă cu adevărat acces deplin acolo. Puteți, dacă într-adevăr deveniți complicat cu el, în care VisBug a trebuit să treacă, acest scenariu și mai complicat. Deci chiar acum, obișnuiam să execute în... Acest lucru va deveni atât de neclar, atât de repede.

Adam: Pentru că există mai multe sandbox-uri pentru extensia ta, pentru probleme de confidențialitate. Și fac dificilă executarea scripturilor pe pagina reală, nu? Pentru că nu doriți ca cineva să vă trimită formularul atunci când lansați lucrul sau ceva, să-l trimită singuri sau orice altceva. Ar putea fi cu adevărat distructiv. Deci are niște ciudatenii de genul acesta. Există un pod peste care trebuie să treci. Și unul dintre ele care a afectat VisBug este că VisBug obișnuia să folosească...

Adam: Deci toate sunt elemente personalizate, iar elementele personalizate vă permit să le transmiteți date bogate ca proprietate. Deci spui ca, customelement.foo=myrichobject, plin de matrice sau orice altceva. Și elementul personalizat primește asta ca niște date pe nodul în sine. Dar, din moment ce mă aflu în această lume mică și ciudată, dacă încerc să setez ceva unic ca acesta pe obiectul meu, în esență este filtrat. Ei au stabilit că anumite lucruri nu pot... Așa că pot trece un șir elementului meu personalizat, dar nu pot să îi transmit un obiect bogat.

Adam: Dar da, în afară de mici ciudatenii de genul ăsta, odată ce scazi fluxul și dacă îți petreci timpul pentru a obține un scenariu de acumulare, care va fi o oră și ceva de lucru, astfel încât să dai LiveReload în treaba ta. , poate deveni destul de natural. Cred că Firefox are, sincer, cea mai bună experiență de dezvoltare a extensiilor, dacă sunteți priceput cu CLI, puteți învârti ceva cu o singură comandă și îl instalează, vă oferă aceste funcții LiveReload și vă oferă instrumente de depanare. Îți cam ține mâna prin el, poate fi foarte drăguț.

Adam: Dar în cele din urmă, este puțin ciudat. De aceea lucrez mult pe acel site demo care arată ca o grămadă de tablouri de artă, pentru că nu prea am nevoie de o pagină web reală de cele mai multe ori, pentru a face testarea VisBug, atâta timp cât am tablouri de artă care simulează diverse probleme sau am lucruri accesibile pe care să le privesc și îmi oferă într-un fel conținutul pe care trebuie să-l văd. Fac o mare parte din lucru chiar acolo, în browser, ca și cum ar fi doar o aplicație web normală. Deci, experiența dezvoltatorului VisBug este foarte ușoară, cu excepția cazului în care încercați să o testați în browser și apoi devine cam dezordonată și orice altceva.

Drew: Sunt o perspectivă cu adevărat interesante. Așa că am învățat totul despre VisBug astăzi, despre ce ai învățat în ultima vreme, Adam?

Adam: Încă îmi îmbunătățesc abilitățile de wok. Așa că vreau să fiu un om wok și nu mă refer la casetofonul anilor '90. Vreau să răsturn legumele și să le fac să ia foc puțin în aer, să le acopăr cu mirodenii delicioase și să prăjesc usturoiul și să-l fac crocant delicios. Și apoi pune-l pe un pat de orez și alunecă-l spre tine și vezi ce crezi.

Adam: Așa că sunt încântat de vară chiar acum, pentru că asta înseamnă că pot să scot wok-ul și să mă întorc în acel mediu de gătit fierbinte, în ritm rapid, și este foarte distractiv.

Drew: Uimitor. Suna delicios. Dacă, dragă ascultător, ați dori să aflați mai multe de la Adam, îl puteți urmări pe Twitter, unde este @argyleinc, și găsiți site-ul său personal la nerdy.dev. Dacă doriți să încercați VisBug, îl puteți găsi în Magazinul web Chrome și puteți încerca versiunea sandbox la visbug.web.app. Îți mulțumim că ești alături de noi astăzi Adam. Ai avut cuvinte de despărțire?

Adam: Nu, ai fost foarte drăguț. Asta a fost foarte dulce. Mulțumesc că m-ai luat, apreciez foarte mult.