Smashing Podcast Episodio 37 Con Adam Argyle: cos'è VisBug?

In questo episodio parliamo di VisBug. Che cos'è e in che cosa differisce dalla gamma di opzioni già presenti in Chrome DevTools? Drew McLellan parla con il suo creatore Adam Argyle per scoprirlo.

Mostra note

• Sandbox e parco giochi VisBug
• Adamo su Twitter
• Sito personale di Adam
• VisBug su YouTube
• Vis Bug 101

Aggiornamento settimanale

• La piattaforma per conferenze che utilizziamo per i nostri eventi online: Hopin di Amanda Annandale
• Una guida alle query sui contenitori CSS di Stephanie Eckles
• Modelli di design frustranti che devono essere corretti: Birthday Picker di Vitaly Friedman
• Tremare gli alberi: una guida di riferimento di Átila Fassina
• Come abbiamo migliorato i nostri vitali web principali di Beau Hartshorne

Trascrizione

Drew McLellan: È un ingegnere punk brillante, appassionato e con un'adorazione per il Web, che preferisce usare le sue abilità per l'interfaccia utente e l'esperienza utente migliori della classe e dare potere a coloro che lo circondano. Ha lavorato in piccole e grandi aziende e attualmente è un sostenitore degli sviluppatori che lavora presso Google su Chrome. È un membro del gruppo di lavoro CSS e il creatore di VisBug, uno strumento di debugging del design. Quindi sappiamo che conosce il design e l'UX, ma lo sapevi che possiede più paia di infradito di qualsiasi bipede vivente? Miei formidabili amici, vi prego di dare il benvenuto ad Adam Argyle.

Adam Argyle: Ciao.

Drew: Ciao Adam, come stai?

Adam: Oh, sto distruggendo, lo sai.

Drew: È bello sentirlo. Quindi volevo parlarti oggi del tuo progetto, di VisBug e, in generale, del concetto alla base del debugging del design e di come potrebbe inserirsi nei flussi di lavoro del progetto. Voglio dire, abbiamo da molto tempo strumenti di debug del browser incentrati sugli sviluppatori, voglio dire, probabilmente più di un decennio ormai. Ma quelli sono ovviamente molto focalizzati sul codice. Allora, cosa c'è di diverso in VisBug? E qual è il tipo di problema che sta cercando di risolvere?

Adamo: Fantastico. Sì, il problema principale su cui è radicato è che, come ingegnere front-end, lavoro con i designer tutto il tempo, e ho sempre amato questo momento in cui ci siamo seduti e dicevo: "Va bene. Sto facendo gli ultimi ritocchi. Abbiamo un altro giorno o due prima dello schieramento. Quindi designer, siediti e lo criticheresti? Voglio che tu apra la mia versione dell'host locale sul tuo browser e sul tuo telefono, o qualsiasi altra cosa, e mi parli di ciò che vedi.

Adam: E dopo aver fatto questo per molti anni e aver sempre amato questa interazione, dopo un po' ho iniziato a sentirmi in colpa a causa di quanto fossero comuni e semplici i compiti. Sarebbero tipo "Un pixel quaggiù. Cinque pixel di margine qui. Ed erano sempre nits e nudge, e nits e nudge alla spaziatura e al tipo. Voglio dire, raramente era come "Ooh, aspetta un minuto mentre passo 30 minuti a cambiare qualche angolo, o altro, per regolare il mio DOM in modo che il DOM possa supportare la tua richiesta", o altro.

Adam: Di solito era roba minuscola. E poi ho finito per fare un sondaggio e ho intervistato tutti questi designer su Google. E io ero tipo "Quando apri DevTools, cosa fai?" Ed è stato clamoroso che abbiano solo bisogno delle basi. E così è nato da, ero tipo "Dovrebbe essere più facile. Non dovresti aprire il cofano della Ferrari, spostare un pezzo di motore, solo per cambiare il colore dei sedili dell'auto. Non è giusto. Dovresti solo essere in grado di toccare i sedili dell'auto e cambiarne il colore, proprio come uno strumento di progettazione". Ero tipo "Qualcosa potrebbe facilitare questo flusso di lavoro". E io ero tipo "Okay, credo che attaccherò qualcosa per vedere se riesco a creare la soluzione".

Adam: Ed è così che è iniziato tutto. È iniziato davvero con la spaziatura e poi la tipografia. E una volta che avevo un meccanismo di selezione che emulava gli strumenti di progettazione, era come "Beh, cos'altro posso fare?" E da lì è andato avanti. Ma sì, nato in quel momento.

Drew: Quindi l'idea è che il client ti chieda di ingrandire il logo e VisBug aiuta il browser a comportarsi più come uno strumento di progettazione per apportare questo tipo di modifiche. Così più vicino a qualcosa come Illustrator, Photoshop, Figma o uno qualsiasi di questi tipi di cose.

Adamo: Sì. Anche quel caso d'uso è buono. Perché potresti essere con un cliente e loro dicono: "Oh, lo adoriamo", questo è così classico, "adoriamo il design, ma quel colore blu è difficile per noi". E tu dici "Davvero?" È come se le persone possano inviare un modulo e tu puoi fare soldi, ma vuoi parlarmi del blu in questo momento? E di solito creerebbe un intero ciclo. Il PM diceva: "Va bene, elimineremo la tua richiesta e poi la invieremo al design".

Adam: Ma se il designer è lì ed è il suo browser a mostrarlo, direbbe: "Va bene. Bene, farò semplicemente clic sulla cosa e cambierò il colore. E puoi interrompere un intero ciclo di lavoro semplicemente prototipando la modifica lì nel browser. Così è. È più efficace contro un prodotto esistente, giusto? Perché è uno strumento di debug. Non è necessariamente uno strumento di generazione. Non crea un sito per te. Può, ma è un po' imbarazzante.

Drew: Quindi tecnicamente è un'estensione che installi in un browser Chrome. È giusto?

Adamo: Sì. Ed è un'estensione. Quando lo avvii, scarica un file JavaScript che dice "Ecco un elemento personalizzato chiamato VisBug". E poi metti l'elemento DOM, vis-bug sulla pagina. E poof, prendo quel momento e lo trasformo in una barra degli strumenti e inizio ad ascoltare gli eventi sulla pagina. Ascolto i tuoi eventi al passaggio del mouse e ascolto i tuoi eventi clic. E cerco di fare del mio meglio per intercettarli e non competere con la tua pagina principale.

Adam: Ma sì, questa è l'essenza di... L'unico motivo per cui è un'estensione è che è facile da mettere sulla tua pagina. Anche se a questo punto ha alcune impostazioni ora disponibili su tutti i browser. Ma è ancora principalmente, 99,9%, un elemento personalizzato senza dipendenze. Penso che mi piaccia una libreria di colori che uso, e per il resto è solo tutta vaniglia. Sì.

Drew: Immagino che sia così che è iniziato Firebug, vero? Come estensione per Firefox ai tempi.

Adamo: Sì. Ecco perché si chiama VisBug. È molto ispirato a Firebug ma per i visual designer.

Drew: Ah. Eccoci. Voglio dire, questo forse non è il formato ideale, essendo un podcast audio, per parlare di uno strumento visivo. Ma esaminaci, se vuoi, alcuni degli strumenti e delle opzioni che VisBug ti offre.

Adamo: Assolutamente. Quindi una delle prime cose che fa VisBug, e puoi anche, se sei a casa o al computer, puoi andare su visbug.web.app e provare VisBug senza l'estensione, giusto?

Drew: Ah.

Adam: È un componente web, quindi ho caricato una pagina web per te qui su visbug.web.app che sembra avere un sacco di tavole da disegno e poi, ovviamente, VisBug precaricato. E l'obiettivo di questo sito è quello di farti giocare, esplorare ed eliminare. Penso che la chiave di eliminazione sia uno degli strumenti più soddisfacenti per cominciare. Sei tipo "Cosa posso fare a una pagina?" E tu dici "Beh, posso distruggerlo".

Adam: E l'ho fatto in modo che tu possa tenere premuto Elimina, troverà il prossimo... Il che è piuttosto difficile su un'eliminazione. Elimini qualcosa e seleziona il fratello successivo. Quindi selezionerà il prossimo fratello per sempre. Se tieni premuto elimina finché non elimini il tutto... Comunque, molto soddisfacente. Premi Aggiorna e tutto torna. Ma il primo strumento fornito da VisBug, quindi quando lo avvii, è lo strumento delle guide. E tenevo letteralmente la carta sullo schermo, oppure prendevo un'estensione di sistema che mi permettesse di segnare le cose e creare linee.

Adam: Perché, sì, l'allineamento diventa molto ottico a un certo punto per molti designer, giusto? Non vogliono, necessariamente, l'allineamento matematico, giusto? Questo è il motivo per cui la tipografia ha la crenatura ottica. Non è crenatura matematica. Questa è la crenatura umana. E quindi lo strumento delle guide è radicato nel fatto che molte lendini che accadono da un designer stanno ingrandendo le cose, controllando l'allineamento. Il distanziamento è buono?

Adam: Quindi questa è la seconda cosa che fa lo strumento Guide. Quando lo avvii e passi con il mouse su cose, vedrai che l'elemento su cui sei passato con il mouse ottiene una piccola scatola attorno ad esso. E poi vengono visualizzate le guide tratteggiate, proprio come farebbero normalmente i governanti. E proprio come in Sketch e Zeplin in cui ti muovi con il mouse e ottieni queste guide, è lo stesso concetto, vivi semplicemente sulla tua pagina. E se fai clic su qualcosa e poi passi con il mouse su una nuova destinazione, ottieni strumenti di misurazione. E gli strumenti di misurazione sono in pixel e vengono calcolati... Quindi visivamente, quanti pixel ci sono tra di essi. Non quello che ha detto qualcuno. Non sta sommando tutta la spaziatura, è solo che fai clic su questa cosa ed è così lontano da quell'altra casella.

Adam: E penso che diventi davvero utile, perché puoi tenere premuto Maiusc e continuare a fare clic, e essenzialmente verificare di avere la stessa spaziatura tra cinque icone. E sono solo un paio di clic. Non è necessario conoscere il codice, basta avviare VisBug, passare il mouse, fare clic, fare clic, fare clic e vedrai che "Oh guarda che è. Sì. 15 pixel tra ciascuno di questi. Oppure a volte ottieni qualcosa di piuttosto fastidioso, fai clic in una casella e quindi fai clic sulla sua casella principale e ti renderai conto che la sua distanza superiore è nove e quella inferiore è otto. E tu dici: "Come posso centrare questo? In qualche modo sta nel mezzo". E stringe il pugno.

Adam: Ma almeno puoi vederlo bene e facilmente con lo strumento delle guide. Quindi sì, questo è lo strumento delle guide.

Drew: Ci sono stato sicuramente, con pezzetti di carta sullo schermo. Inoltre, l'altro trucco che userei è aprire un'altra finestra del browser e utilizzare il bordo della finestra per allineare gli elementi. E quindi provi a mantenere tutto nel posto giusto in modo che mentre apporti modifiche al codice e aggiorni, tutto sia ancora in fila. Sì, non è un modo ideale di lavorare, quindi.

Adam: Non è un modo ideale di lavorare. Sì. E c'è il prossimo... Quindi, oh, e la prima versione era molto libera. Non si è spezzato, ha solo sollevato un mirino, che è una caratteristica che aggiungerò in seguito. Quindi alcuni utenti dicono: "Ehi, adoro lo snap, è proprio come i miei strumenti di progettazione. Ma cosa succede se voglio una misura ampia? Oppure voglio fare una lettera, voglio misurare una lettera, non la sua cassetta delle lettere?" E quindi, beh, questo strumento di guida potrebbe essere facilmente modificato in un tasto modificatore.

Adam: Quindi qui è dove VisBug diventa un po' diverso, ma si spera anche familiare, è molto pesante sui modificatori dei tasti di scelta rapida. Quindi, proprio come se guardi un designer professionista, sono molto esperti di tasti di scelta rapida. E stanno premendo i tasti di scelta rapida qui, ingrandendo, premendo i tasti di scelta rapida laggiù e semplicemente facendo tutto il loro spostamento dalla tastiera. E quindi VisBug è molto incentrato sulla tastiera nel modo in cui cambi le cose.

Adam: È anche perché VisBug consente selezioni multiple e può modificare la spaziatura di 100 elementi contemporaneamente. E lo fa relativamente. Quindi, comunque, ha un paio di stranezze interessanti, ma la tastiera in un concetto di modificatore è davvero importante. E puoi tenere premuto l'opzione, o spostare o comandare in molti strumenti e ottenere qualcosa di diverso, o ottenere un nuovo tipo di funzionalità lì dentro.

Drew: Quindi è uno di quegli strumenti in cui vale davvero la pena imparare le scorciatoie da tastiera.

Adamo: Lo fa. Quindi, quando avvii VisBug e passi con il mouse su una delle icone degli strumenti, otterrai un'analisi dettagliata. Viene visualizzato un piccolo menu a comparsa, dice il tasto di scelta rapida per scegliere questo strumento e ti dice cosa può fare e quali interazioni fare per ottenerli. Quindi lo strumento Guide dice: "Guide agli elementi, passa con il mouse. Misura qualcosa, fai clic e poi passa il mouse su qualcosa di nuovo. Le misurazioni permanenti sono shift plus click in modo che persistano.

Adam: E queste guide sono davvero carine anche per gli screenshot. Quindi, se stai esaminando un PR, anche solo come ingegnere front-end, o forse un designer che sta rivedendo un PR, questo può essere un modo davvero potente per entrare lì e, sì, avere un'ispezione ad alta fedeltà. Che tipo di ci conduce nel prossimo strumento. Vuoi conoscere il prossimo strumento?

Drew: Sì, certo. Facciamolo.

Adamo: Fantastico. Il prossimo è lo strumento di ispezione. E questo è come... I designer di solito non vogliono tutti i CSS, giusto? Quando si aspettano con... Ho quasi detto Firebug, ma Chrome DevTools, ottieni l'elenco completo, giusto? Ho selezionato questo H1 e quindi ecco tutto fino al foglio di stile del browser. E il designer dice: “Il browser cosa? Il browser ha un foglio di stile?"

Drew: Giù nella parte inferiore oscura di quel pannello a scorrimento.

Adam: Il fondo oscuro, giusto?

Drew: Sì.

Adam: È come se avessi rimosso tutti gli strati e poi pensassi: "Ooh, non mi piacciono più questi strati". E lo strumento di ispezione qui dice: "Ah, designer, so cosa volete. È solo il colore del bordo". Fondamentalmente, mostrami qualcosa solo se è unico, quindi non coprirmi solo con le proprietà CSS. E sono davvero interessato principalmente al colore, alla tipografia e alla spaziatura. Quindi esaminerò i margini, l'altezza delle linee, la famiglia di caratteri è davvero importante, giusto? C'è un'intera estensione solo per dirti qual è la famiglia di caratteri su una pagina.

Adam: In VisBug è solo un elemento pubblicitario nello strumento di ispezione. Quindi avvii VisBug, premi ispeziona e passa il mouse su qualsiasi tipografia e ti dirà la famiglia di caratteri. Quindi sì, cerca di rendere un designer concentrato su ciò che emerge, sì.

Drew: Quindi quello strumento non mostra stili ereditati. È giusto?

Adam: È corretto. A meno che non siano ereditati e unici. Quindi se loro... Un colore del testo o qualcosa del genere, se il colore del testo non è letteralmente la parola ereditare, ti dirà che è un valore calcolato, che è qualcosa di interessante.

Drew: Sì, è davvero utile... Sì. Ti aiuta a concentrarti sulle cose che si stanno letteralmente applicando a quell'unica istanza di qualcosa, che è ovviamente ciò che volevi cambiare. Voglio dire, immagino che questo potrebbe essere davvero utile, tutti questi strumenti sarebbero davvero utili, un po' come hai detto tu, per ottenere il feedback degli stakeholder. E una sorta di lavoro interattivo con un cliente.

Drew: Immagino che funzionerebbe ugualmente bene sulla condivisione dello schermo, come dobbiamo fare in questi giorni, sempre di più. Non devi essere seduto al computer con qualcuno, potresti essere seduto all'altro capo di una chiamata e condividere il tuo browser e farlo in questo modo. Immagino che sarebbe un modo abbastanza efficace per ottenere un feedback quando un cliente non può indicare lo schermo e dire-

Adamo: Sicuramente.

Adam: È sempre magico quando trasformi la pagina web live in quella che sembra una tavola da disegno Zeplin. Qualcuno dice: "Cosa... siamo appena andati in un posto nuovo?" E tu dici: "No, questo è il tuo prodotto. Stiamo solo interagendo con esso in modo molto visivo”. Sì, può essere davvero bello.

Drew: Ci sono altri casi d'uso interessanti che hai visto mettere VisBug o che ti sono venuti in mente che potrebbero essere interessanti?

Adamo: Sì. Quindi, sì, ce ne sono così tanti che è un po' difficile iniziare. Oh, uno che è importante è la comunicazione tra sviluppatori e sviluppatori. VisBug lavora sui valori calcolati. Quindi non guarda i tuoi valori di autore. E può essere davvero bello, perché stai misurando e ispezionando il risultato finale assoluto nel modo in cui i pixel sono stati calcolati sullo schermo. E può essere davvero bello avere una conversazione in questo modo, mentre stai lavorando sui risultati, invece che sul lato dell'autore.

Adam: E puoi tornare indietro dicendo: "Okay, beh, come abbiamo sbagliato nella parte di authoring se questo è quello che abbiamo ottenuto visivamente?" Che anche in qualche modo gioca, lo strumento successivo è lo strumento di controllo dell'accessibilità. Quindi lo strumento di ispezione semplifica la visualizzazione degli stili su un elemento e li scompone in un modo molto adatto ai designer. Lo strumento di accessibilità ti aiuta a ispezionare tutti gli elementi di una pagina e fa emergere tutte le proprietà accessibili che ha, il che rende, spero, più facile verificare che qualcosa sia fatto.

Adam: Quindi un PR... E spesso le cose vengono create. Quindi questo è, ancora una volta, da sviluppatore a sviluppatore, designer sviluppatore, stai rivedendo le interfacce. È così critico. Se stai guardando un'interfaccia e sei curioso, VisBug ha un caso d'uso per te lì. Ci sono anche casi d'uso in cui puoi ordinare un prototipo nel browser. Quindi ne abbiamo parlato di uno in cui è come se il cliente volesse provare il blu. Ok, è uno scenario abbastanza facile.

Adam: Ma ce ne sono anche altri. Se premi il comando D su VisBug, duplicherai un elemento. E non importa cosa stai duplicando. Quindi puoi duplicare un'intestazione, aggiungere un po' di spazio tra le due intestazioni e creare una variante attiva nel browser. Fai doppio clic sul testo dell'intestazione e diventa un campo di testo modificabile, quindi provi un nuovo titolo e vai a vedere come si adatta il titolo. Vai a regolare un po' di spaziatura e ti sei appena salvato tutto questo lavoro di sviluppo, trovando un file sorgente e tutto quel genere di cose, e sei solo...

Adam: Quindi sì, può aiutarti a esplorare e verificare. È un po' strano... Voglio dire, sono molte delle cose che fa DevTools, giusto? Arriva dopo che hai finito, in realtà non ti fornisce il codice sorgente molto spesso, non capita molto spesso di copiare il codice da DevTools. Potresti copiare una coppia chiave-valore. Tipo: "Oh, ho cambiato questo stile". Ma sì, comunque.

Drew: Mm-hmm (affermativo). Sì. Riesco a pensare a una specie di casi particolarmente visivi in ​​cui potresti voler, hai menzionato, duplicare oggetti. Potresti voler prendere un'intera sezione della pagina e duplicarla per simulare come sarebbe se ci fosse molto più contenuto di quello che ti aspettavi.

Adamo: Sì. Questo è il caso d'uso del test del caos.

Drew: Sì.

Adamo: Assolutamente.

Drew: Che è qualcosa con cui tutti abbiamo a che fare, progettando con una sorta di sistemi basati su CMS e tutti quei tipi di attività divertenti.

Adam: Sì, anche questo è un caso d'uso davvero cruciale. Perché lo faccio per... Sì, i titoli dei giornali, come ho detto. Fai solo doppio clic su un testo e io vado a sbattere la tastiera. Blah, blah, blah, blah, e colpisci un sacco di spazi, blah, blah. E io dico: "Okay, com'è andato il layout? Oh, è andata bene. Ok, bene, posso passare alla prossima cosa. Cosa succede se lo duplico quattro volte? C'è ancora spazio tra tutto? Scorre accanto all'elemento successivo?"

Adam: Può essere davvero bello per quella simulazione del caos dei contenuti, sì. Titolo davvero breve, titoli davvero lunghi, non ha amici, ha un milione di amici. Come gestisci questi casi d'uso nell'interfaccia utente? Sì.

Drew: Quindi funziona con qualsiasi contenuto basato su browser. Quindi le PWA e le normali pagine Web?

Adam: Sì, lo fa. Quindi, se hai installato Spotify, lo faccio sempre, ho installato Spotify e dirò semplicemente "Spotify, sembri un'app impossibile da ispezionare". Ma indovinate un po? VisBug non importa. VisBug sovrappone tutte le tue cose, ispeziona tutta la tipografia. Ho creato un tema leggero per... Oh, ho un tweet da qualche parte in cui ho creato un tema leggero di Spotify.

Adam: Oh, questo era un altro caso d'uso, scusa, per la prototipazione del colore. Posso creare un tema leggero sul prodotto stesso senza dover pasticciare con un mucchio di fogli di adesivi, giusto? Quindi c'è questa mentalità importante e uniforme, mi piacerebbe che VisBug aiutasse le persone a entrare, ovvero usare il tuo prodotto come un parco giochi. Usalo come... È così reale. È più reale delle tue composizioni di design. Quindi passa un po' più di tempo lì dentro. Penso che scoprirai che puoi prendere decisioni di progettazione più efficaci lavorando sul tuo prodotto reale.

Drew: E anche il caso dell'accessibilità è particolarmente interessante, perché spesso, in particolare di questi tempi, lavoriamo molto nelle librerie di componenti e osserviamo piccoli componenti di una pagina. E dedicando meno tempo a guardare tutti quelli integrati insieme per creare il tipo di visualizzazioni con cui un cliente interagisce effettivamente. E diventa davvero difficile tenere d'occhio quel tipo di dettagli più fini come cose di accessibilità, attributi, che non sono visibili sulla pagina.

Drew: È molto difficile tenere d'occhio le cose che non sono visibili. Quindi è qui che gli strumenti possono davvero, davvero aiutare a essere in grado di ispezionare qualcosa e vedere che, sì, ha i ruoli corretti su di esso ed è-

Adamo: Lo fa. Questo è il caso d'uso esatto. Voglio un PM per poter andare a verificare questa roba. Voglio che un designer sia in grado di dare un'occhiata all'accessibilità e non dover aprire gli strumenti, trovare il nodo DOM, è tutto accartocciato nel pannello degli elementi e sembra strano. Che dice solo: "Ecco gli attributi dell'area, ecco il titolo se esiste". Ci sono anche altri strumenti di accessibilità per. VisBug viene fornito con l'icona di ricerca. L'icona di ricerca ha diversi modi per interagire con essa.

Adam: Quindi prima interroga la pagina. Quindi, se conosci il tipo di elemento o il nome della classe dell'elemento che desideri, puoi semplicemente cercarlo, quindi non devi trovarlo con il mouse. Ma questo contiene anche i comandi slash. Quindi ci sono plug-in in VisBug e eseguiranno gli script sulla pagina. Quindi, se hai mai avuto un segnalibro di cui ne hai salvati tre o quattro... Sei tipo "Userò questo perché evidenzia tutti i bordi e mi mostra le mie caselle". È come un trucco per il debug o qualcosa del genere.

Adam: Probabilmente è un plugin VisBug. Quindi avvii VisBug, premi slash e otterrai il completamento automatico e ti mostrerà tutti i diversi plugin. E ce ne sono alcuni di accessibilità che sono davvero belli che si sovrappongono agli errori e varie cose del genere. Quindi sono d'accordo. L'accessibilità dovrebbe essere più accessibile. È solo stupido da dire. Ma deve essere più vicino alla cintura degli attrezzi. E penso che a volte sia troppo lontano, e forse è per questo che viene perso. Quindi spero che sia un po' più in avanti, al centro e più facile che venga controllato di più. Sì.

Drew: Ed è interessante che tu dica che VisBug funziona con il tipo di valori calcolati delle cose, quindi come i colori. Quindi significa che se hai diversi elementi a strati che hanno diversi livelli di opacità, saresti in grado di misurare il colore esatto che viene visualizzato sullo schermo piuttosto che-

Adamo: Oh.

Drew: … guardando i singoli elementi e cercando di risolverlo in qualche modo?

Adam: Questa è davvero una bella domanda. Quindi penso, se ho capito bene la domanda, che questa è una classica difficoltà nel front-end è, sì, come fai a sapere se hai una parola di testo semiopaca, qual è il suo colore sul grigio rispetto al bianco ? E come fai a sapere il suo contrasto? In questo momento, non lo sappiamo. Quindi VisBug conosce il colore e dirà "50% grigio" o qualunque sia il colore che hai lì. Ma non sa niente di più intelligente di quello. Non è in grado di...

Adam: Penso che quello che dovresti fare in quel caso è creare una tela, dipingere tutti i livelli lì sopra, e poi usare un contagocce o un... Quindi lo faresti su tela, li frantumerai tutti insieme in un singolo livello dipinto, quindi prendi il valore del singolo pixel per vedere qual è il suo effettivo grigio calcolato alla fine dopo che è stato sovrapposto alle altre cose.

Adam: Penso che qualcuno l'abbia specificato, o forse ho un problema con GitHub che sarebbe carino. Perché VisBug potrebbe facilitare questo, al 100%. VisBug, dietro le quinte, l'ho già fatto con le metriche del testo, in cui passi il mouse sulle cose e ti dà informazioni pazze sui caratteri. Sono quasi troppe informazioni, come x height e cap height, ma vanno anche di più. Ed è come, "Ooh, a un certo punto mi sono spento". Quindi devo capire come trovare il segnale rispetto al rumore lì.

Adam: Ma sì, mi piace questo processo di pensiero, perché dovremmo avere uno strumento che lo faccia. E se sappiamo come calcolarlo, possiamo insegnare a VisBug a farlo, e sarebbe una caratteristica davvero interessante avere un colore calcolato rilevante per l'opacità. Lo adoro.

Drew: Sì, voglio dire, è il tipo di caso standard di avere il testo su uno sfondo in cui non sei sicuro che il contrasto sia sufficiente per soddisfare i requisiti di accessibilità. E forse non lo è, forse è un contrasto troppo basso e vuoi quindi modificare i valori fino ad arrivare al punto in cui il contrasto è buono, ma non è troppo lontano da ciò che il cliente voleva inizialmente in termini di colori del marchio e cose.

Adam: Io chiamo quell'urto, urto finché non passi.

Drew: Sì.

Adam: Perché è così che ci si sente. Sono tipo "Ooh, sono un po' a corto di punteggio". Quindi è come se andrò alla mia leggerezza HSL e mi limiterò a urtare, urtare, urtare e guardare i piccoli numeri che spuntano finché non è come "Ding", ho un segno di spunta verde. Sono tipo "Va bene, bene". E sì, a volte, alcuni di quei colori non sono belli. Quindi, hai studiato gran parte del lavoro in corso sull'accessibilità percettiva 3.0? In modo che non avremo più AA o AAA, avremo il numero e includerà cose come la sottigliezza del carattere. Quindi se è un font sottile otterrà un punteggio più basso, se è un font spesso va... Perché c'è molto che va in contrasto.

Drew: Sì, no, non l'avevo visto, ma sembra-

Adam: Comunque, è una cosa davvero interessante da esplorare.

Drew: Sembra affascinante, sì. Dovrò trovare qualcuno con cui parlarne. Questo è un altro episodio. Quindi, voglio dire, sono sicuro che alcuni sviluppatori potrebbero obiettare che tutto ciò che VisBug sta facendo lo puoi fare semplicemente attraverso il pannello CSS in DevTools. E penso che sia un po 'giusto, ma probabilmente non coglie il punto, in quanto sì, stai manipolando i CSS quando apporti modifiche, ma sta mettendo in primo piano una sorta di interfaccia utente incentrata sul designer piuttosto che un'interfaccia incentrata sullo sviluppatore. È una sua giusta caratterizzazione?

Adam: Questo è davvero giusto. E onestamente, le idee migliori passano da VisBug a DevTools. E l'hanno già fatto. Quindi VisBug, se premi l'opzione di comando C su qualsiasi elemento, prende ogni stile calcolato, almeno questo è unico. Di nuovo, quindi è come se ne faremo di quelli che non ti daremo solo tutte queste proprietà ereditate. Ma li metti tutti negli appunti e puoi incollare quello stile da qualche altra parte, in un foglio di stile, in una CodePen e ricreare letteralmente l'elemento in un paio di clic.

Adam: E questo tipo di interazioni si è fatto strada in DevTools, in quel pannello degli elementi. Ci sono altre cose, tuttavia, che non hanno, ovvero DevTools è uno strumento di ispezione di un solo nodo. E VisBug segue il mantra dello strumento di progettazione che è, no, dovrei essere in grado di selezionare più volte. Devo essere in grado di modificare in blocco, ispezionare in blocco. E quindi uso sempre VisBug per la spaziatura. Perché posso evidenziare più elementi e vedere il collasso del margine.

Adam: In DevTools non puoi mai vederlo, perché puoi vedere solo un nodo alla volta per la maggior parte del tempo, anche se c'è un modo per mostrare più margini, ma non è lo stesso. E quindi, sì, ha questi casi d'uso di nicchia che possono essere davvero divertenti in questo modo. Un altro è, se evidenzi un... Diciamo che hai un sistema tipografico e hai da H1 a H7, come in un libro di fiabe o qualcosa del genere, puoi evidenziarli tutti in VisBug, tenere premuto MAIUSC, semplicemente fare clic su tutti loro. Boop, boop, boop, boop, vai allo strumento tipografia e premi su o giù, e apporta una modifica relativa a ciascuno di essi.

Adam: Quindi ognuno di loro spingerà su uno o giù di uno. E questo non è qualcosa che DevTools rende molto facile. E quindi, sì, ha dei superpoteri del genere, perché è un po' più agnostico. Ed è pronto per eseguire sempre l'iterazione su un array. Sì.

Drew: Allora, qual è stata l'origine di VisBug? E ora è solo un progetto personale? O è un progetto Google? O qual è lo stato di esso?

Adamo: Sì. Quindi, prima di tutto, lo stato è che è un progetto Google. Il suo obiettivo principale è quello di essere un luogo in cui creare prototipi ed esplorare prima che le cose entrino in DevTools. Almeno dal lato Google delle cose. Ma dal mio lato personale delle cose lo vedo ancora come un posto dove andare a cuocere le attività comuni o in cui apportare alcune ottimizzazioni per completare le attività comuni. E solo per dare a un pubblico più ampio un modo per guardare nel DOM.

Adam: Penso davvero che DevTools sia super potente, ma è molto intimidatorio. Solo una scheda in esso può richiedere una carriera per imparare. Sto ancora imparando cose in DevTools e le uso sempre. E quindi sì, questo è un tipo di pubblico diverso in qualche modo. Sono più i principianti, le persone che entrano, o forse anche persone come PM, manager, che non hanno mai intenzione di programmare ma sono interessate all'output. E quindi in qualche modo dà loro, sì, solo strumenti leggeri per entrare lì.

Drew: È un punto interessante che sollevi, perché personalmente spesso trovo che faccio fatica a trovare un flusso di lavoro confortevole nella gestione di tutti questi tipi di DevTools. E hai tutti questi piccoli pannelli claustrofobici, e puoi staccarli in un'altra finestra, ma poi devi tenere traccia di due finestre diverse. E una volta aperte alcune finestre del browser, non puoi... Ne focalizzi una e non sai a quale DevTools appartiene.

Drew: E poi all'interno dei pannelli stessi, è una specie di un po' un Far West delle convenzioni dell'interfaccia utente. Scorri e le cose inizieranno a fare cose strane che non ti aspettavi. E in termini di esperienza utente, mi sembra che sia tutto solo un gran casino.

Adamo: Lo è. Sì.

Drew: Pensi che sia inevitabile? Può essere migliore?

Adam: Ho sicuramente dei pensieri qui. E sì, penso che un buon... Quindi diciamo che in questo momento hai un ascoltatore che dice: "Sono piuttosto esperto con DevTools. Non penso che siano così pazzi". Direi: "Va bene, apri Android Studio o Xcode. Inizia un progetto e vai a guardare DevTools, vai a guardare l'output. Quanto ti senti familiare in questo momento?" Probabilmente molto straniero. Lo stai guardando dicendo: “Questa è spazzatura. Perché lo fanno? Perché questo pannello è qui?" E la tua mente inizia a correre con tutte queste domande perché e confusione.

Adam: Ed è come, beh, è ​​così che tutti si sentono la prima volta che aprono DevTools. Quindi devi essere davvero empatico a questo.

Drew: È inevitabile che... Possiamo fare di meglio? O questo è solo il tipo di ordine naturale delle cose?

Adam: Quindi ecco la mia attuale opinione su questo, penso che la complessità sia davvero facile da trovare. E DevTools è una di quelle cose, sono solo naturalmente complesse. Non esiste una buona interfaccia utente per facilitare molte di queste cose. Molte di queste cose vengono costruite dagli sviluppatori. E penso che gli sviluppatori che costruiscono strumenti per gli sviluppatori vadano bene, perché avrai... Se è l'unico modo, o se lo è anche se è un buon modo, lo imparerai e diventerai bravo e ti sentirai a tuo agio.

Adam: E tutti i DevTools sono un po' strani, perché sono fatti per i loro casi d'uso strani, giusto? Lo sviluppo è strano. Siamo solo onesti. Produciamo ingranaggi invisibili e invisibili a due a quattro, e costruiamo case, fondamentalmente, con parti invisibili e virtuali. Quindi sì, abbiamo bisogno di strani strumenti per ispezionare queste cose e per dirci cosa stanno producendo.

Adam: Detto questo, quello che fa VisBug, e quello che ho spostato lentamente le cose in DevTools, sono strumenti più piccoli che sono più focalizzati rispetto a un grande strumento che afferma di fare molto. Penso che sia difficile che le cose vadano molto bene. E questo è un argomento classico, giusto? Questo è tutto stelle, specialisti contro generalisti. Nessuno dei due sarà sempre perfetto.

Adam: Ma quello che VisBug sta cercando di fare è che ha creato degli specialisti. Quindi lo strumento Guide fa solo guide. E quello strumento non perde mai negli altri strumenti della pagina. E quindi sto cercando di farlo di più con DevTools, dove DevTools vuole aiutare di più i designer, che è qualcosa che VisBug ha aiutato a ispirare DevTools a vedere. E il modo in cui continuo a introdurre le cose è, invece di creare un editor di griglia, ad esempio, dove puoi... "Piena potenza della griglia in una sovrapposizione", giusto? "Puoi aggiungere tracce, rimuovere tracce, bla, bla, bla".

Adam: E io sono tipo, "Sembra davvero fantastico e anche molto complesso". 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: Ho una mod in cui, quando avvii VisBug, prende l'intero documento HTML e lo riduce in una tavola da disegno. Sembra una tavola da disegno. Sta fluttuando su un'ombra in uno spazio grigio. Puoi girarci intorno all'infinito. Quindi puoi scorrere lontano dalla tela della tua pagina e ciò che ti consente di fare è, vedi, diciamo che hai una pagina molto lunga e vuoi misurare qualcosa dall'alto verso il basso, beh puoi farlo subito , ma perderesti il ​​contesto mentre procedi.

Adam: Bene, in questo nuovo scenario di zoom VisBug, tieni premuto l'opzione o alt sulla tastiera, usi la rotellina del mouse o premi più meno con il tuo comando e puoi ingrandire la tua pagina web come se fosse una tavola da disegno. E cerco di renderlo perfetto così com'è. Quindi entri ed esci, e scorri verso il basso, entri ed esci, misuri dal... E a VisBug semplicemente non importa. Continua a disegnare sovrapposizioni calcolate, puoi cambiare la spaziatura.

Adam: Perché penso che sia davvero importante, come designer, vedere la tua pagina a volo d'uccello dal vivo. Le animazioni sono ancora in riproduzione, tutti voi. Le aree scorrevoli sono ancora scorrevoli, giusto? È davvero fico. Sei tipo "La mia intera pagina in una vista". Comunque, quindi è quasi fatto. È dentro-

Drew: Suona da brivido.

Adam: È molto divertente. Ed è dentro, devo solo assicurarmi che funzioni su più browser, perché sta facendo alcune, ovviamente, alcune cose complicate per far sentire la tua pagina live in quel modo. Ma si.

Drew: Incredibile. È... Voglio dire, presumo che VisBug sia aggiornato abbastanza regolarmente e sia in fase di evoluzione. Cosa possiamo aspettarci di vedere in futuro?

Adam: Sì, questa è sicuramente una delle funzionalità su cui sto lavorando lì. Ho una funzione in cui... Quindi, quando fai clic su qualcosa, ottieni una sovrapposizione con quelle che sembrano maniglie, giusto? Ed è una specie di illusione, dovrebbe farti sentire a tuo agio. E l'intento è quello di fare in modo che quelle maniglie siano trascinabili. Ma ho alcune cose fondamentali che devo risolvere prima, come gli elementi nel browser non hanno una larghezza. Quindi, se inizi ad afferrare la larghezza, devo lavorare per far sentire bene quell'illusione.

Adam: E potresti anche non ottenere i risultati desiderati, perché potrebbe essere un elemento a livello di blocco che stai riducendo la larghezza e non stai ottenendo il reflow di un elemento accanto ad esso. E ti starai chiedendo perché. Quindi ho prototipi in cui puoi trascinare angoli, trascinare elementi in giro. Ma ho davvero bisogno di concentrarmi su come gli strumenti di progettazione stanno facendo questo. Hanno sempre questo pulsante di commutazione. Ed è come... Vedi, come si chiama l'interruttore?

Adam: Ma fondamentalmente è come un termoretraibile... io lo chiamo termoretraibile. Riduci avvolgere il mio elemento, è la larghezza di questo elemento è la larghezza del suo contenuto, rispetto a questa è la larghezza del mio elemento, attacca qualcosa al suo interno. Quindi ho bisogno di qualcosa del genere nel browser, sovrapposto all'elemento in modo da poter scegliere tra questi e forse anche qualcosa che ti consente di scegliere tra block e inline, in modo da poter ottenere i risultati desiderati.

Adam: Ma alla fine l'obiettivo qui è che VisBug non voglia essere interamente guidato dalla tastiera. Voglio che tu sia in grado di trascinare la spaziatura. Se vedi 12 margini di spaziatura in alto, dovresti essere in grado di allungare una mano e afferrarlo, mentre in questo momento devi premere sulla tastiera per specificare che il lato superiore della casella necessita di un'aggiunta di margine.

Adam: E quindi sì, ho un paio di stranezze da risolvere, in termini di strategia. Ma è davvero un obiettivo renderlo ancora più vicino agli strumenti di progettazione. E forse anche io mi piegherò in quello. È come, beh, se vuoi cambiare la larghezza e otterrai un design strano, ci sono sempre modi per uscirne con VisBug, come se lo strumento di posizione ti permette davvero di sfuggire al flusso. Quindi il flusso sta rovinando la tua idea, lo strumento di posizione ti lascia scappare.

Adam: E quindi c'è... Se qualcuno diventasse davvero esperto con VisBug, lascerebbe a bocca aperta le persone, perché è una sorta di illimitato, ed è tipo, cosa puoi portare in tavola? Ha un elemento di espressione. C'è sicuramente una tattica espressiva. Ma comunque, per farla breve, l'illusione è che voglio solo renderlo sempre più piccolo. Voglio che l'illusione sia del tipo: "Wow, mi sento davvero come uno strumento di progettazione".

Adam: E poi, sì, alcuni miglioramenti all'esportazione sarebbero utili. Ma anche, il miglioramento dell'esportazione per DevTools sarebbe bello, e questo non ci ferma davvero. Quindi non lo so. Ci sono un sacco di problemi, sicuramente vai a votarli. Penso che una delle prossime grandi funzionalità che mi piacerebbe fare siano le linee verdi. Quindi, invece di mostrare semplicemente sovrapposizioni di accessibilità al passaggio del mouse per indicare davvero alcune cose con linee verdi, ed esporre di più e far emergere più informazioni, e non lo so. Sì.

Drew: Una specie di pensare al processo di creazione di un'estensione di Chrome come questa, voglio dire, supponendo che sia tutto implementato in JavaScript, quanto è simile al normale sviluppo web? Creazione di un'estensione di Chrome.

Adam: Questa è una buona domanda. È... Uff, questo è difficile. È bizzarro. Prima di tutto, l'ambiente in cui puoi avviare il tuo codice non è il browser. In realtà non ti danno pieno accesso lì. Puoi, se davvero diventi complicato, in cui VisBug ha dovuto laurearsi, questo scenario ancora più complicato. Quindi in questo momento, eseguivo nel... Questo diventerà così sfocato così velocemente.

Adam: Perché ci sono più sandbox per la tua estensione, per problemi di privacy. E rendono difficile eseguire gli script sulla pagina reale, giusto? Perché non vuoi che qualcuno invii il tuo modulo quando avvii la cosa o qualcosa, lo invii a se stesso o altro. Potrebbe essere davvero distruttivo. Quindi ha alcune stranezze del genere. C'è un ponte su cui devi passare. E uno di questi che ha afflitto VisBug è che VisBug usava...

Adam: Quindi sono tutti elementi personalizzati e gli elementi personalizzati ti consentono di passare loro dati avanzati come proprietà. Quindi stai dicendo tipo, customelement.foo=myrichobject, pieno di array o altro. E l'elemento personalizzato lo ottiene solo come alcuni dati sul nodo stesso. Ma dal momento che sono in questo strano piccolo mondo sandbox, se provo a impostare qualcosa di unico come quello sul mio oggetto, essenzialmente viene filtrato. Hanno stabilito che certe cose non possono... Quindi posso passare una stringa al mio elemento personalizzato, ma non posso passargli un oggetto ricco.

Adam: Ma sì, a parte piccole stranezze del genere, una volta che hai abbassato il flusso e se passi il tempo a ottenere uno scenario di rollup, ci vorrà circa un'ora di lavoro in modo da dare LiveReload nella tua cosa , può diventare abbastanza naturale. Penso che Firefox abbia, onestamente, la migliore esperienza di sviluppo di estensioni se sei esperto con la CLI puoi creare qualcosa con un comando e lo installa, ti offre queste funzionalità di LiveReload e ti offre strumenti di debug. In un certo senso ti tiene la mano attraverso, può essere davvero bello.

Adam: Ma alla fine, è un po' strano. Ecco perché faccio molto del lavoro su quel sito demo che sembra un mucchio di tavole da disegno, perché non ho davvero bisogno di una vera pagina web la maggior parte del tempo, per eseguire i test di VisBug, purché disponga di tavole da disegno che simulare vari problemi o avere cose accessibili da guardare e in qualche modo darmi il contenuto che devo vedere. Eseguo gran parte del lavoro proprio lì nel browser come se fosse solo una normale applicazione web. Quindi l'esperienza di sviluppo di VisBug è davvero semplice, a meno che tu non stia provando a testarla sul browser, e quindi diventa un po' disordinata e altro.

Drew: Sono spunti davvero interessanti. Quindi ho imparato tutto su VisBug oggi, cosa hai imparato ultimamente, Adam?

Adam: Sto ancora migliorando le mie abilità nel wok. Quindi voglio essere un uomo wok, e non sto parlando del lettore di cassette degli anni '90. Voglio capovolgere le verdure e farle prendere fuoco un po' nell'aria, coprirle con alcune deliziose spezie e scottare davvero quell'aglio e renderlo delizioso e croccante. E poi mettilo su un lettino di riso e fallo scorrere verso di te e guarda cosa ne pensi.

Adam: Quindi sono eccitato per l'estate in questo momento, perché questo significa che posso tirare fuori il wok e tornare in quell'ambiente di cucina caldo e frenetico, ed è davvero divertente.

Drew: Incredibile. Sembra delizioso. Se tu, caro ascoltatore, vorresti sentire di più da Adam puoi seguirlo su Twitter dove è @argyleinc e trovare il suo sito web personale su nerdy.dev. Se vuoi provare VisBug, puoi trovarlo nel Chrome Web Store e puoi provare la versione sandbox su visbug.web.app. Grazie per esserti unito a noi oggi Adam. Hai avuto qualche parola d'addio.

Adam: No, sei stato davvero gentile. Questo è stato davvero dolce. Grazie per avermi accolto, lo apprezzo davvero.