Smashing Podcast Episode 37 Dengan Adam Argyle: Apa Itu VisBug?

Dalam episode ini, kita berbicara tentang VisBug. Apa itu, dan apa bedanya dengan deretan opsi yang sudah ditemukan di Chrome DevTools? Drew McLellan berbicara dengan penciptanya Adam Argyle untuk mencari tahu.

Tampilkan Catatan

• Kotak pasir dan taman bermain VisBug
• Adam di Twitter
• Situs pribadi Adam
• VisBug di YouTube
• VisBug 101

Update mingguan

• Platform Konferensi yang Kami Gunakan Untuk Acara Online Kami: Hopin oleh Amanda Annandale
• Primer Pada Kueri Kontainer CSS oleh Stephanie Eckles
• Pola Desain Frustrasi yang Perlu Diperbaiki: Pemetik Ulang Tahun oleh Vitaly Friedman
• Mengguncang Pohon: Panduan Referensi oleh tila Fassina
• Bagaimana Kami Meningkatkan Vital Web Inti Kami oleh Beau Hartshorne

Salinan

Drew McLellan: Dia adalah insinyur punk yang cerdas, bersemangat, dan menyukai web, yang lebih suka menggunakan keahliannya untuk UI dan UX terbaik di kelasnya, dan memberdayakan orang-orang di sekitarnya. Dia bekerja di perusahaan kecil dan besar, dan saat ini menjadi advokat pengembang yang bekerja di Google di Chrome. Dia adalah anggota kelompok kerja CSS dan pencipta VisBug, alat debugging desain. Jadi kita tahu dia tahu cara di sekitar desain dan UX, tapi tahukah Anda dia memiliki lebih banyak pasang sandal jepit daripada biped yang hidup? Teman-temanku yang hebat, tolong sambut Adam Argyle.

Adam Argyle: Halo.

Drew: Hai Adam, apa kabar?

Adam: Oh, saya menghancurkan, Anda tahu itu.

Drew: Itu bagus untuk didengar. Jadi saya ingin berbicara dengan Anda hari ini tentang proyek Anda, VisBug, dan secara umum, tentang konsep di balik debugging desain dan bagaimana hal itu dapat masuk ke dalam alur kerja proyek. Maksud saya, kami telah memiliki alat debugging browser yang berfokus pada pengembang untuk waktu yang lama, maksud saya, mungkin lebih dari satu dekade sekarang. Tapi itu jelas sangat terfokus pada kode. Lalu apa bedanya dengan VisBug? Dan masalah seperti apa yang coba dipecahkannya?

Adam: Luar biasa. Ya, masalah utama yang menjadi akarnya adalah, sebagai insinyur front-end saya bekerja dengan desainer sepanjang waktu, dan saya selalu menyukai momen di mana kami duduk dan saya akan seperti, “Oke. Saya membuat sentuhan akhir. Kami punya satu atau dua hari lagi sampai kami menyebarkan. Jadi desainer, duduklah, dan maukah Anda mengkritik ini? Saya ingin Anda membuka versi host lokal saya di browser dan ponsel Anda, atau apa pun, dan berbicara dengan saya tentang apa yang Anda lihat.”

Adam: Dan setelah melakukan ini selama bertahun-tahun dan selalu menyukai interaksi ini, saya mulai merasa bersalah setelah beberapa saat karena tugas yang umum dan sederhana. Mereka akan seperti, “Satu piksel di bawah sini. Margin lima piksel di sini.” Dan itu selalu nits dan nudges, dan nits dan nudges untuk spasi dan mengetik. Maksud saya, jarang seperti, "Ooh, tunggu sebentar sementara saya menghabiskan 30 menit mengubah beberapa sudut, atau apa pun, untuk menyesuaikan DOM saya sehingga DOM dapat mendukung permintaan Anda," atau apa pun.

Adam: Itu biasanya barang kecil. Dan akhirnya saya membuat survei, dan saya mensurvei semua desainer ini di Google. Dan saya seperti, "Ketika Anda membuka DevTools, apa yang Anda lakukan?" Dan itu terdengar bahwa mereka hanya membutuhkan dasar-dasar. Dan itu lahir dari, saya seperti, “Ini seharusnya lebih mudah. Anda tidak perlu membuka kap mesin Ferrari, memindahkan sebongkah mesin, hanya untuk mengubah warna jok mobil. Itu tidak adil. Anda seharusnya bisa menyentuh jok mobil dan mengubah warnanya, seperti alat desain.” Saya seperti, "Sesuatu dapat memfasilitasi alur kerja ini." Dan saya seperti, "Oke, saya kira saya akan meretas sesuatu untuk melihat apakah saya bisa membuat solusinya."

Adam: Dan begitulah semuanya dimulai. Ini benar-benar dimulai dengan spasi dan kemudian tipografi. Dan begitu saya memiliki mekanisme pemilihan alat desain yang ditiru itu, rasanya seperti, "Apa lagi yang bisa saya lakukan?" Dan itu terus berjalan dari sana. Tapi ya, lahir pada saat itu.

Drew: Jadi idenya adalah klien meminta Anda untuk membuat logo lebih besar, dan VisBug membantu browser berperilaku lebih seperti alat desain untuk membuat tweak semacam itu. Sangat dekat dengan sesuatu seperti Illustrator, atau Photoshop, atau Figma, atau hal-hal semacam ini.

Adam: Ya. Kasus penggunaan itu juga bagus. Karena Anda bisa menjadi klien dan mereka berkata, "Oh, kami menyukai ini," ini sangat klasik, "kami menyukai desainnya, tetapi warna biru itu sulit bagi kami." Dan Anda seperti, "Benarkah?" Ini seperti, orang dapat mengirimkan formulir dan Anda dapat menghasilkan uang, tetapi Anda ingin berbicara dengan saya tentang biru sekarang? Dan biasanya itu akan membuat seluruh siklus. PM akan berkata, "Oke, kami akan mencatat permintaan Anda dan kemudian kami akan mengirimkannya ke desain."

Adam: Tetapi jika perancangnya ada di sana dan browser mereka yang menunjukkannya, mereka akan seperti, “Oke. Baiklah saya akan mengklik benda itu dan mengubah warnanya. ” Dan Anda dapat memotong seluruh siklus pekerjaan hanya dengan membuat prototipe perubahan yang ada di browser. Begitulah. Ini paling efektif terhadap produk yang sudah ada, bukan? Karena ini adalah alat debugging. Ini belum tentu alat generasi. Itu tidak membuat situs untuk Anda. Bisa sih, tapi agak canggung.

Drew: Jadi secara teknis ini adalah ekstensi yang Anda pasang di browser Chrome. Apakah itu benar?

Adam: Ya. Dan itu adalah perpanjangan. Saat Anda meluncurkannya, ia mengunduh file JavaScript yang mengatakan, "Inilah elemen khusus yang disebut VisBug." Dan kemudian Anda meletakkan elemen DOM, vis-bug di halaman. Dan poof, saya mengambil momen itu dan mengubahnya menjadi bilah alat, dan mulai mendengarkan acara di halaman. Saya mendengarkan acara hover Anda, dan saya mendengarkan acara klik Anda. Dan saya mencoba melakukan yang terbaik untuk mencegat mereka, dan tidak bersaing dengan halaman utama Anda.

Adam: Tapi ya, itulah inti dari… Satu-satunya alasan ekstensi adalah agar mudah dipasang di halaman Anda. Meskipun pada titik ini memang memiliki beberapa pengaturan sekarang yang menyertai Anda di seluruh browser. Tapi itu masih sebagian besar, 99,9%, elemen khusus tanpa ketergantungan. Saya pikir saya suka perpustakaan warna yang saya gunakan, dan sebaliknya hanya vanilla. Ya.

Drew: Kurasa begitulah awal mula Firebug, bukan? Sebagai ekstensi Firefox di masa lalu.

Adam: Ya. Itu sebabnya disebut VisBug. Ini sangat terinspirasi oleh Firebug tetapi untuk desainer visual.

Drew: Ah. Di sana kita pergi. Maksud saya, ini mungkin bukan format yang ideal, menjadi podcast audio, untuk berbicara tentang alat visual. Tapi jelajahi kami, jika Anda mau, beberapa jenis alat dan opsi yang diberikan VisBug kepada Anda.

Adam: Tentu saja. Jadi salah satu hal pertama yang dilakukan VisBug, dan Anda juga dapat melakukannya, jika Anda di rumah atau di depan komputer, Anda dapat membuka visbug.web.app, dan mencoba VisBug tanpa ekstensi, bukan?

Drew: Ah.

Adam: Ini adalah komponen web, jadi saya telah memuat halaman web untuk Anda di sini di visbug.web.app yang sepertinya memiliki banyak papan seni, dan tentu saja, VisBug telah dimuat sebelumnya. Dan tujuan situs ini adalah untuk memungkinkan Anda bermain, menjelajahi, dan menghapus. Saya pikir tombol hapus adalah salah satu alat yang paling memuaskan untuk memulai. Anda seperti, "Apa yang bisa saya lakukan untuk sebuah halaman?" Dan Anda seperti, "Yah, saya bisa menghancurkannya."

Adam: Dan saya membuatnya agar Anda dapat menahan penghapusan, itu akan menemukan yang berikutnya ... Yang cukup sulit untuk dihapus. Anda menghapus sesuatu dan itu memilih saudara berikutnya. Jadi itu akan memilih saudara berikutnya selamanya. Kalau tahan delete sampai hapus semua… Pokoknya memuaskan banget. Tekan refresh dan semuanya kembali. Tetapi alat pertama yang dikirimkan oleh VisBug, jadi ketika Anda baru saja meluncurkannya, adalah alat panduan. Dan saya dulu benar-benar memegang kertas ke layar saya, atau saya akan mendapatkan ekstensi sistem yang memungkinkan saya untuk menyortir sesuatu dan membuat garis.

Adam: Karena, ya, keselarasan menjadi sangat optikal pada titik tertentu bagi banyak desainer, bukan? Mereka tidak ingin, tentu saja, keselarasan matematis, bukan? Inilah sebabnya mengapa tipografi memiliki optical kerning. Ini bukan matematika kerning. Ini adalah kerning manusia. Jadi alat panduan berakar pada banyak nits yang terjadi dari seorang desainer memperbesar hal-hal, memeriksa keselarasan. Apakah spasinya bagus?

Adam: Jadi itulah hal kedua yang dilakukan oleh alat pemandu. Saat Anda meluncurkannya dan Anda hanya mengarahkan kursor pada hal-hal, Anda akan melihat elemen yang Anda arahkan memiliki kotak kecil di sekitarnya. Dan kemudian pemandu putus-putus muncul, seperti yang biasanya dilakukan oleh para penguasa. Dan seperti di Sketch dan Zeplin tempat Anda mengarahkan kursor dan mendapatkan panduan ini, konsepnya sama, tinggal langsung di halaman Anda. Dan jika Anda mengklik sesuatu, lalu mengarahkan kursor ke tujuan baru, Anda mendapatkan alat pengukur. Dan alat pengukur dalam piksel, dan mereka dihitung… Jadi secara visual, berapa banyak piksel di antara itu. Bukan apa yang dikatakan seseorang. Ini tidak menambahkan semua spasi, hanya Anda mengklik hal ini dan ini jauh dari kotak lain itu.

Adam: Dan saya pikir itu menjadi sangat membantu, karena Anda dapat menahan shift dan melanjutkan mengklik, dan pada dasarnya memverifikasi bahwa Anda memiliki jarak yang sama antara lima ikon. Dan itu hanya beberapa klik. Tidak perlu tahu kode, cukup luncurkan VisBug, arahkan kursor, klik, klik, klik, dan Anda akan melihat bahwa, “Oh, lihat itu. Ya. 15 piksel di antara masing-masing ini.” Atau kadang-kadang Anda mendapatkan sesuatu yang agak mengganggu, Anda akan mengklik sebuah kotak dan kemudian mengklik kotak induknya dan Anda akan menyadari bahwa jarak atasnya adalah sembilan dan jarak bawahnya adalah delapan. Dan Anda pergi, “Bagaimana saya akan memusatkan ini? Itu entah bagaimana di antaranya. ” Dan mengepalkan tinju.

Adam: Tapi setidaknya Anda bisa melihatnya dengan baik dan mudah dengan alat panduan. Jadi ya, itulah alat panduan.

Drew: Saya pasti pernah ke sana, dengan mengangkat potongan kertas ke layar. Dan juga, trik lain yang akan saya gunakan adalah membuka jendela browser lain dan menggunakan tepi jendela untuk menyelaraskan item. Dan kemudian Anda mencoba dan menyimpan semuanya di tempat yang tepat sehingga saat Anda membuat perubahan kode dan menyegarkan semuanya masih berbaris. Ya, bukan cara kerja yang ideal, jadi.

Adam: Bukan cara kerja yang ideal. Ya. Dan ada yang berikutnya... Jadi, oh, dan versi pertama itu sangat longgar. Itu tidak patah, itu hanya mengangkat crosshair, yang merupakan fitur yang akan saya tambahkan kembali nanti. Jadi beberapa pengguna seperti, “Hei, saya suka gertakan, itu seperti alat desain saya. Tetapi bagaimana jika saya menginginkan pengukuran yang longgar? Atau saya ingin membuat surat, saya ingin mengukur surat, bukan kotak suratnya?” Jadi, alat panduan ini dapat dengan mudah diubah menjadi memiliki kunci pengubah.

Adam: Jadi di sinilah VisBug sedikit berbeda, tetapi juga mudah-mudahan akrab, apakah itu sangat berat pada pengubah hotkey. Jadi sama seperti jika Anda menonton seorang desainer profesional, mereka sangat paham hotkey. Dan mereka menekan tombol cepat di sini, memperbesar, menekan tombol cepat di sana, dan hanya melakukan semua dorongan dari keyboard mereka. Jadi VisBug sangat berorientasi pada keyboard dalam cara Anda mengubah banyak hal.

Adam: Itu juga karena VisBug memungkinkan beberapa pilihan, dan dapat mengubah jarak 100 item pada waktu yang sama. Dan itu relatif. Jadi, bagaimanapun, ini memiliki beberapa kebiasaan yang menarik, tetapi keyboard dalam konsep pengubah sangat penting. Dan Anda dapat menahan opsi, atau shift, atau perintah di banyak alat dan mendapatkan sesuatu yang berbeda, atau mendapatkan jenis fitur baru di sana.

Drew: Jadi ini adalah salah satu alat yang benar-benar bermanfaat untuk mempelajari pintasan keyboard.

Adam: Memang. Jadi ketika Anda meluncurkan VisBug dan Anda mengarahkan kursor ke salah satu ikon alat, Anda akan mendapatkan gangguan. Itu mengeluarkan menu flyout kecil, dikatakan hotkey untuk memilih alat ini, dan itu memberi tahu Anda apa yang bisa dilakukan, dan interaksi apa yang harus dilakukan untuk mendapatkannya. Jadi alat pemandu mengatakan, “Panduan elemen, cukup arahkan. Ukur sesuatu, klik, lalu arahkan sesuatu yang baru. Pengukuran lengket adalah shift plus klik sehingga tetap ada.”

Adam: Dan panduan ini juga sangat bagus untuk screenshot. Jadi, jika Anda meninjau PR, bahkan hanya sebagai insinyur front-end, atau mungkin seorang desainer meninjau PR, ini bisa menjadi cara yang sangat ampuh bagi Anda untuk masuk ke sana dan, ya, melakukan inspeksi kesetiaan yang tinggi. Jenis mana yang membawa kita ke alat berikutnya. Apakah Anda ingin mendengar tentang alat berikutnya?

Drew: Ya, tentu. Mari kita lakukan.

Adam: Luar biasa. Yang berikutnya adalah alat inspeksi. Dan yang ini seperti… Desainer biasanya, mereka tidak menginginkan semua CSS, kan? Ketika mereka berharap dengan… Saya hampir mengatakan Firebug, tetapi Chrome DevTools, Anda mendapatkan daftar lengkapnya, bukan? Saya memilih H1 ini dan jadi inilah semuanya kembali ke lembar gaya browser. Dan desainernya seperti, “Browser apa? Peramban memiliki lembar gaya?”

Drew: Turun di bagian bawah panel gulir itu.

Adam: Dasarnya keruh, kan?

Drew: Ya.

Adam: Ini seperti Anda mengupas semua lapisan dan kemudian Anda seperti, "Ooh, saya tidak suka lapisan ini lagi." Dan alat inspeksi di sini, dikatakan, “Ah, desainer, saya tahu apa yang Anda inginkan. Itu hanya warna perbatasan.” Pada dasarnya, tunjukkan saya sesuatu hanya jika itu unik, jadi jangan hanya menutupi saya dengan properti CSS. Dan saya sangat tertarik pada warna, tipografi, dan spasi. Jadi saya akan melihat margin, tinggi garis, keluarga font sangat penting, bukan? Ada seluruh ekstensi hanya untuk memberi tahu Anda apa keluarga font di halaman.

Adam: Di VisBug itu hanya item baris di alat periksa. Jadi, Anda cukup meluncurkan VisBug, tekan periksa, dan arahkan kursor ke tipografi apa pun dan itu akan memberi tahu Anda jenis font. Jadi ya, itu mencoba membuat seorang desainer fokus pada apa yang muncul, ya.

Drew: Jadi alat itu tidak menunjukkan gaya apa pun yang diwariskan. Apakah itu benar?

Adam: Itu benar. Kecuali mereka diwariskan dan unik. Jadi jika mereka... Warna teks atau sesuatu, jika warna teks bukan secara harfiah kata mewarisi, itu akan memberi tahu Anda bahwa itu adalah nilai yang dihitung, bahwa itu adalah sesuatu yang menarik.

Drew: Ya, itu benar-benar berguna… Ya. Membantu Anda fokus pada hal-hal yang benar-benar berlaku untuk satu kejadian itu, yang jelas-jelas ingin Anda ubah. Maksud saya, saya kira ini bisa sangat berguna, semua alat ini akan sangat berguna, seperti yang Anda sebutkan, mendapatkan umpan balik pemangku kepentingan. Dan semacam bekerja secara interaktif dengan klien.

Drew: Saya kira itu akan bekerja sama baiknya dengan berbagi layar, seperti yang harus kita lakukan hari ini, lebih dan lebih. Anda tidak harus duduk di depan komputer dengan seseorang, Anda bisa duduk di ujung telepon dan berbagi browser Anda dan melakukannya dengan cara itu. Saya kira itu akan menjadi cara yang cukup efektif untuk mendapatkan umpan balik ketika klien tidak dapat menunjuk ke layar dan berkata-

Adam: Pasti.

Adam: Selalu ajaib ketika Anda mengubah halaman web langsung menjadi apa yang tampak seperti papan seni Zeplin. Seseorang seperti, "Apa... Apakah kita baru saja pergi ke suatu tempat baru?" Dan Anda seperti, “Tidak, ini produk Anda. Kami hanya berinteraksi dengannya secara visual.” Ya, itu bisa sangat bagus.

Drew: Apakah ada kasus penggunaan menarik lainnya yang pernah Anda lihat dilakukan VisBug atau yang mungkin menarik bagi Anda?

Adam: Ya. Jadi, ya, ada begitu banyak sehingga agak sulit untuk memulai. Oh, salah satu yang penting adalah komunikasi developer ke developer. VisBug bekerja pada nilai yang dihitung. Jadi itu tidak melihat nilai-nilai yang Anda tulis. Dan itu bisa sangat bagus, karena Anda mengukur dan memeriksa hasil akhir absolut ke dalam cara piksel dihitung di layar. Dan itu bisa sangat menyenangkan, untuk melakukan percakapan seperti itu, saat Anda sedang mengerjakan hasil, sebagai lawan dari sisi penulisan.

Adam: Dan Anda dapat kembali ke seperti, "Oke, bagaimana kita bisa salah di sisi penulisan jika ini yang kita dapatkan secara visual?" Yang juga berperan, alat berikutnya adalah alat pemeriksaan aksesibilitas. Jadi alat inspeksi memudahkan hanya untuk melihat gaya pada suatu elemen, dan itu memecahnya dengan cara yang sangat ramah desainer. Alat aksesibilitas membantu Anda memeriksa semua elemen pada halaman, dan menampilkan semua properti yang dapat diakses yang dimilikinya, yang saya harap, lebih mudah untuk memverifikasi bahwa sesuatu telah dilakukan.

Adam: Jadi PR… Dan hal-hal sering dibuat. Jadi ini, sekali lagi, pengembang ke pengembang, pengembang desainer, Anda meninjau antarmuka. Ini sangat kritis. Jika Anda melihat antarmuka dan penasaran, VisBug memiliki kasus penggunaan untuk Anda di sana. Ada juga kasus penggunaan di mana Anda dapat mengurutkan prototipe di browser. Jadi kami berbicara tentang satu di mana itu seperti, klien ingin mencoba warna biru. Oke, itu skenario yang cukup mudah.

Adam: Tapi ada yang lain juga. Jika Anda menekan perintah D pada VisBug, Anda akan menduplikasi sebuah elemen. Dan tidak peduli apa yang Anda duplikat. Jadi Anda bisa menduplikasi sebuah header, menambahkan beberapa spasi di antara kedua header, dan membuat varian langsung di browser. Anda mengklik dua kali teks header dan itu menjadi bidang teks yang dapat diedit, dan Anda mencoba judul baru dan melihat bagaimana judulnya cocok. Sesuaikan beberapa spasi dan Anda baru saja menyimpan sendiri semua pekerjaan pengembang ini, menemukan file sumber dan semua hal semacam itu, dan Anda hanya…

Adam: Jadi ya, itu dapat membantu Anda menjelajahi dan memverifikasi. Agak aneh… Maksudku, banyak hal yang dilakukan DevTools, kan? Itu masuk setelah Anda selesai, itu tidak benar-benar memberi Anda kode sumber sangat sering, tidak terlalu sering Anda menyalin kode dari DevTools. Anda dapat menyalin pasangan nilai kunci. Seperti, "Oh, saya mengubah gaya ini." Tapi ya, bagaimanapun.

Menarik: Mm-hmm (mengiyakan). Ya. Saya dapat memikirkan semacam kasus visual khusus di mana Anda mungkin ingin, yang Anda sebutkan, menduplikasi item. Anda mungkin ingin mengambil seluruh bagian halaman dan menduplikasinya untuk mensimulasikan seperti apa jadinya jika ada lebih banyak konten daripada yang Anda harapkan.

Adam: Ya. Itulah kasus penggunaan pengujian kekacauan.

Drew: Ya.

Adam: Tentu saja.

Drew: Itu adalah sesuatu yang harus kita tangani, mendesain dengan semacam sistem berbasis CMS dan segala macam tugas yang menyenangkan.

Adam: Ya, itu juga kasus penggunaan yang sangat penting. Karena saya melakukan itu untuk… Ya, headline, seperti yang saya katakan. Anda cukup mengklik dua kali beberapa teks dan saya langsung membanting keyboard. Bla, bla, bla, bla, dan tekan banyak spasi, bla, bla. Dan saya seperti, “Oke, bagaimana tata letaknya? Oh, itu bagus. Oke, bagus, saya bisa melanjutkan ke hal berikutnya. Apa yang terjadi jika saya menggandakan ini empat kali? Apakah masih ada ruang di antara semuanya? Apakah itu mengalir di sebelah item berikutnya? ”

Adam: Ini bisa sangat bagus untuk simulasi, ya, kekacauan konten. Judul yang sangat pendek, judul yang sangat panjang, tidak memiliki teman, memiliki sejuta teman. Bagaimana Anda menangani kasus penggunaan ini di UI? Ya.

Drew: Jadi ini berfungsi dengan konten berbasis browser apa pun. Jadi PWA serta halaman web biasa?

Adam: Ya, memang. Jadi jika Anda telah menginstal Spotify, saya melakukan ini sepanjang waktu, saya telah menginstal Spotify dan saya hanya akan berkata, "Spotify, Anda terlihat seperti aplikasi yang mustahil untuk diperiksa." Tapi coba tebak? VisBug tidak peduli. VisBug melapisi semua barang Anda, memeriksa semua tipografi. Saya membuat tema ringan untuk… Oh, saya punya tweet di suatu tempat di mana saya membuat tema ringan Spotify.

Adam: Oh, ini adalah kasus penggunaan lain, maaf, untuk membuat prototipe warna. Saya dapat membuat tema ringan pada produk itu sendiri tanpa harus mengacaukan banyak lembar stiker, bukan? Jadi ada mentalitas penting ini, saya ingin VisBug membantu orang masuk ke dalamnya, menggunakan produk Anda sebagai taman bermain. Gunakan itu sebagai... Ini sangat nyata. Ini lebih nyata daripada perusahaan desain Anda. Jadi habiskan lebih banyak waktu di sana. Saya pikir Anda akan menemukan bahwa Anda dapat membuat keputusan desain yang lebih efektif dengan mengerjakan produk Anda yang sebenarnya.

Drew: Dan kasus aksesibilitas juga sangat menarik, karena sering kali, khususnya akhir-akhir ini, kami banyak bekerja di pustaka komponen, dan melihat komponen kecil dari sebuah halaman. Dan menghabiskan lebih sedikit waktu untuk melihat semua yang terintegrasi bersama untuk menciptakan jenis tampilan yang benar-benar berinteraksi dengan pelanggan. Dan menjadi sangat sulit untuk mengawasi detail yang lebih halus seperti hal-hal aksesibilitas, atribut, yang tidak terlihat di halaman.

Drew: Sangat sulit untuk mengawasi hal-hal yang tidak terlihat. Jadi di sinilah perkakas dapat benar-benar membantu untuk dapat memeriksa sesuatu dan melihat bahwa, ya, ia memiliki peran yang benar di dalamnya dan itu-

Adam: Memang. Itulah kasus penggunaan yang tepat. Saya ingin seorang PM dapat pergi memverifikasi hal-hal ini. Saya ingin seorang desainer dapat melihat aksesibilitas dan tidak perlu membuka alat, menemukan simpul DOM, semuanya berderak di panel elemen dan terlihat aneh. Itu hanya mengatakan, "Ini atribut area, ini judulnya jika ada." Ada juga beberapa alat aksesibilitas lainnya untuk. VisBug dikirimkan dengan ikon pencarian. Ikon pencarian memiliki banyak cara untuk berinteraksi dengannya.

Adam: Jadi pertama-tama ia menanyakan halaman itu. Jadi jika Anda mengetahui tipe elemen atau nama kelas elemen yang Anda inginkan, Anda bisa mencarinya saja, jadi tidak perlu mencarinya dengan mouse. Tapi itu juga memiliki perintah slash di dalamnya. Jadi ada plugin di VisBug, dan mereka akan mengeksekusi skrip di halaman. Jadi, jika Anda pernah memiliki bookmark yang telah Anda simpan tiga atau empat... Anda seperti, "Saya akan menggunakan yang ini karena ini menyoroti semua batas dan menunjukkan kotak saya." Ini seperti trik debug atau semacamnya.

Adam: Ini mungkin plugin VisBug. Jadi Anda meluncurkan VisBug, tekan slash, dan Anda akan mendapatkan pelengkapan otomatis, dan itu akan menunjukkan kepada Anda semua plugin yang berbeda. Dan ada beberapa aksesibilitas yang sangat bagus yang menutupi kesalahan, dan berbagai hal seperti itu. Jadi saya setuju. Aksesibilitas harus lebih mudah diakses. Itu hanya lumpuh untuk mengatakan. Tapi itu harus lebih dekat ke sabuk alat. Dan saya pikir kadang-kadang terlalu jauh, dan mungkin itu sebabnya itu terlewatkan. Jadi saya berharap jika itu sedikit lebih di depan, dan di tengah, dan lebih mudah untuk diperiksa lebih lanjut. Ya.

Drew: Dan menarik Anda mengatakan bahwa VisBug bekerja dengan jenis nilai yang dihitung dari berbagai hal, seperti warna. Jadi, apakah itu berarti jika Anda memiliki beberapa elemen berlapis yang memiliki tingkat opasitas berbeda, Anda dapat mengukur warna persis yang ditampilkan di layar daripada-

Adam: Ooh.

Drew: … melihat elemen individu dan mencoba entah bagaimana menyelesaikannya?

Adam: Itu pertanyaan yang sangat bagus. Jadi saya pikir, jika saya memahami pertanyaan dengan benar, yang merupakan kesulitan klasik di bagian depan adalah, ya, bagaimana Anda tahu jika Anda memiliki kata teks setengah buram, apa warnanya di atas abu-abu versus di atas putih ? Dan bagaimana Anda tahu kontrasnya? Saat ini, kami tidak tahu. Jadi VisBug tahu warnanya, dan dia akan berkata, "50% abu-abu," atau warna apa pun yang Anda miliki di sana. Tapi itu tidak tahu apa-apa lebih pintar dari itu. Itu tidak bisa…

Adam: Saya pikir apa yang harus Anda lakukan dalam hal ini adalah membuat kanvas, melukis semua lapisan di sana, dan kemudian menggunakan pipet atau ... Jadi Anda akan membuatnya di kanvas, membuat semuanya menjadi satu lapisan dicat tunggal, dan kemudian ambil nilai piksel tunggal untuk melihat apa yang sebenarnya dihitung abu-abu setelah itu berlapis pada hal-hal lain.

Adam: Saya pikir seseorang menentukannya, atau mungkin saya memilikinya sebagai masalah GitHub yang akan menyenangkan. Karena VisBug bisa memfasilitasi ini, 100%. VisBug, di balik layar, saya sudah selesai dengan metrik teks, di mana Anda mengarahkan kursor pada sesuatu dan itu memberi Anda informasi gila tentang font. Ini hampir terlalu banyak info, seperti x tinggi, dan tinggi topi, tetapi bahkan lebih. Dan itu seperti, "Ooh, saya agak dimatikan pada titik tertentu." Jadi saya harus mencari cara untuk menemukan sinyal versus kebisingan di sana.

Adam: Tapi ya, saya suka proses berpikir ini, karena kita harus punya alat yang melakukan itu. Dan jika kita tahu cara menghitungnya, kita bisa mengajari VisBug untuk melakukannya, dan itu akan menjadi fitur yang sangat keren untuk dimiliki, warna terhitung yang relevan dengan opacity. Suka sekali.

Drew: Ya, maksud saya, ini semacam kasus standar memiliki teks dengan latar belakang di mana Anda tidak yakin apakah kontrasnya cukup untuk memenuhi persyaratan aksesibilitas. Dan mungkin tidak, mungkin kontrasnya terlalu rendah dan Anda ingin mengubah nilainya sampai Anda mendapatkannya tepat pada titik di mana kontrasnya bagus, tetapi tidak terlalu jauh dari apa yang awalnya diinginkan klien dalam hal warna merek dan hal-hal.

Adam: Saya menyebutnya benjolan, benjolan sampai Anda lulus.

Drew: Ya.

Adam: Karena seperti itulah rasanya. Saya seperti, "Ooh, saya sedikit kekurangan skor." Jadi seperti, saya akan pergi ke lightness HSL saya dan saya hanya akan menabrak, menabrak, menabrak, dan melihat angka-angka kecil berdetak sampai seperti, "Ding," saya mendapat tanda centang hijau. Saya seperti, "Oke, keren." Dan ya, terkadang, beberapa warna itu tidak keren. Jadi, sudahkah Anda mempelajari banyak pekerjaan aksesibilitas perseptual 3.0 yang sedang berlangsung? Sehingga kita tidak lagi memiliki AA atau AAA, kita akan memiliki nomor dan itu mencakup hal-hal seperti ketipisan font. Jadi jika itu adalah font yang tipis maka akan mendapatkan skor yang lebih rendah, jika itu adalah font yang tebal akan… Karena ada banyak hal yang kontras.

Drew: Ya, tidak, saya belum pernah melihat semua itu, tapi kedengarannya-

Adam: Pokoknya, itu hal yang sangat keren untuk dijelajahi.

Drew: Kedengarannya menarik, ya. Aku harus mencari seseorang untuk diajak bicara tentang itu. Itu episode lain. Jadi, maksud saya, saya yakin beberapa pengembang mungkin berpendapat bahwa semua yang dilakukan VisBug dapat Anda lakukan melalui panel CSS di DevTools. Dan saya pikir itu agak adil tetapi mungkin tidak tepat, dalam hal itu, ya, Anda memanipulasi CSS ketika Anda membuat perubahan, tetapi menempatkan semacam antarmuka pengguna yang berfokus pada desainer di atas daripada antarmuka yang berfokus pada pengembang. Apakah itu karakterisasi yang adil?

Adam: Itu benar-benar adil. Dan sejujurnya, ide-ide terbaik keluar dari VisBug ke DevTools. Dan mereka sudah. Jadi VisBug, jika Anda menekan opsi perintah C pada elemen apa pun, dibutuhkan setiap gaya yang dihitung, setidaknya itu unik. Sekali lagi, jadi seperti, kami akan melakukan yang tidak hanya akan kami berikan kepada Anda semua properti yang diwarisi ini. Tapi letakkan semuanya di clipboard Anda, dan Anda bisa menempelkan gaya itu di tempat lain, di lembar gaya, di CodePen, dan benar-benar membuat ulang elemen itu dalam beberapa klik.

Adam: Dan interaksi semacam itu telah masuk ke DevTools, ke panel elemen itu. Namun, ada hal lain yang belum, yaitu, DevTools adalah alat pemeriksaan node tunggal saja. Dan VisBug mengikuti mantra alat desain yaitu, tidak, saya harus bisa memilih banyak. Saya harus dapat mengedit secara massal, memeriksa secara massal. Jadi saya menggunakan VisBug sepanjang waktu untuk mengatur jarak. Karena saya dapat menyorot beberapa elemen dan melihat margin menciut.

Adam: Di DevTools Anda tidak pernah bisa melihatnya, karena Anda hanya dapat melihat satu node pada satu waktu sebagian besar waktu, meskipun ada cara untuk menunjukkan beberapa margin, tapi itu tidak sama. Jadi, ya, ia memiliki kasus penggunaan khusus yang bisa sangat menyenangkan seperti itu. Satu lagi adalah, jika Anda menyorot sebuah… Katakanlah Anda memiliki sistem tipografi dan Anda memiliki H1 hingga H7, seperti di buku cerita atau semacamnya, Anda dapat menyorot semuanya di VisBug, tahan shift, klik saja semuanya. Boop, boop, boop, boop, pergi ke alat tipografi dan tekan ke atas atau ke bawah, dan itu membuat perubahan relatif untuk masing-masing.

Adam: Jadi masing-masing dari mereka akan mendorong satu atau ke bawah satu. Dan itu bukan sesuatu yang dibuat sangat mudah oleh DevTools. Jadi, ya, ia memiliki beberapa kekuatan super seperti itu, karena sedikit lebih agnostik. Dan itu siap untuk selalu beralih pada array. Ya.

Drew: Jadi apa asal usul VisBug? Dan sekarang apakah itu hanya proyek pribadi? Atau itu proyek Google? Atau bagaimana statusnya?

Adam: Ya. Jadi pertama, statusnya adalah, ini adalah proyek Google. Tujuan utamanya adalah menjadi tempat untuk membuat prototipe dan mengeksplorasi sebelum hal-hal masuk ke DevTools. Setidaknya dari sisi Google. Tetapi dari sisi pribadi saya, saya masih melihatnya sebagai tempat untuk mengerjakan tugas-tugas umum, atau memanggang beberapa pengoptimalan untuk menyelesaikan tugas-tugas umum. Dan hanya untuk memberikan audiens yang lebih luas cara untuk melihat ke dalam DOM.

Adam: Saya benar-benar berpikir bahwa DevTools sangat kuat, tetapi sangat menakutkan. Hanya satu tab di dalamnya dapat mengambil karir untuk belajar. Saya masih mempelajari banyak hal di DevTools, dan saya menggunakannya sepanjang waktu. Dan ya, ini adalah jenis penonton yang berbeda dalam beberapa hal. Ini lebih dari pemula, orang-orang yang datang, atau bahkan mungkin orang-orang seperti PM, manajer, yang tidak pernah berniat untuk membuat kode tetapi tertarik pada hasilnya. Jadi itu memberi mereka, ya, hanya perkakas ringan untuk masuk ke sana.

Drew: Ini adalah poin menarik yang Anda kemukakan, karena saya pribadi sering menemukan bahwa saya berjuang untuk menemukan alur kerja yang nyaman dalam mengelola semua jenis DevTools ini. Dan Anda memiliki semua panel klaustrofobia kecil ini, dan Anda dapat melepaskannya ke jendela lain, tetapi kemudian Anda harus melacak dua jendela yang berbeda. Dan begitu Anda membuka beberapa jendela browser, Anda tidak bisa… Anda memfokuskan satu dan Anda tidak tahu DevTools mana yang menjadi miliknya.

Drew: Dan kemudian di dalam panel itu sendiri, itu semacam semacam konvensi antarmuka pengguna Wild West. Anda akan menggulir dan hal-hal akan mulai melakukan hal-hal aneh yang tidak Anda harapkan. Dan dalam hal pengalaman pengguna, saya merasa itu semua hanya kekacauan besar.

Adam: Itu. Ya.

Drew: Apakah menurut Anda itu tidak bisa dihindari? Bisakah itu lebih baik?

Adam: Saya pasti punya pemikiran di sini. Dan ya, menurut saya bagus… Jadi, katakanlah Anda memiliki pendengar saat ini seperti, “Saya cukup paham dengan DevTools. Saya tidak berpikir mereka gila. ” Saya akan berkata, “Oke, buka Android Studio atau Xcode. Mulailah sebuah proyek, dan lihat DevTools, lihat hasilnya. Seberapa akrab yang Anda rasakan sekarang? ” Mungkin sangat asing. Anda sedang melihat hal itu, “Ini sampah. Mengapa mereka melakukan ini? Mengapa panel ini ada di sini?” Dan pikiran Anda mulai berpacu dengan semua pertanyaan mengapa dan kebingungan ini.

Adam: Dan seperti itulah perasaan semua orang saat pertama kali membuka DevTools. Jadi, Anda harus benar-benar berempati terhadap hal itu.

Drew: Apakah tidak bisa dihindari bahwa… Bisakah kita melakukan yang lebih baik? Atau ini hanya semacam tatanan alam?

Adam: Jadi, inilah pandangan saya saat ini, apakah saya pikir kompleksitas sangat mudah untuk Anda hadapi. Dan DevTools adalah salah satunya, mereka secara alami kompleks. Tidak ada UI yang bagus untuk memfasilitasi banyak hal ini. Banyak dari hal-hal ini dibangun oleh para pengembang. Dan saya pikir devs membangun alat untuk devs baik-baik saja, karena Anda akan memiliki... Jika itu satu-satunya cara, atau jika itu adalah cara yang baik, Anda akan mempelajarinya, dan Anda akan mahir dalam itu, dan Anda akan merasa nyaman dengannya.

Adam: Dan semua DevTools agak aneh, karena dibuat untuk kasus penggunaan yang aneh, bukan? Perkembangannya aneh. Mari kita jujur ​​saja. Kami membuat roda gigi yang tidak terlihat dan tidak terlihat dua per empat, dan kami membangun rumah, pada dasarnya, dengan bagian virtual yang tidak terlihat. Jadi ya, kami membutuhkan alat aneh untuk memeriksa hal-hal ini, dan untuk memberi tahu kami apa yang mereka hasilkan.

Adam: Sekarang, apa yang dilakukan VisBug, dan apa yang telah saya pindahkan secara perlahan ke DevTools, adalah alat yang lebih kecil yang lebih fokus dibandingkan dengan alat besar yang mengklaim dapat melakukan banyak hal. Saya pikir sulit untuk melakukan banyak hal dengan sangat baik. Dan ini adalah argumen klasik, bukan? Ini semua adalah bintang, spesialis versus generalis. Keduanya tidak akan selalu sempurna.

Adam: Tapi apa yang VisBug coba lakukan adalah, ia telah membuat spesialis. Jadi alat panduan hanya melakukan panduan. Dan alat itu tidak pernah bocor ke alat halaman lainnya. Jadi saya mencoba melakukannya lebih banyak dengan DevTools, di mana DevTools ingin membantu desainer lebih banyak, yang merupakan sesuatu yang VisBug telah membantu menginspirasi DevTools untuk melihatnya. Dan cara saya terus memperkenalkan sesuatu adalah, alih-alih membuat editor grid, misalnya, di mana Anda bisa… “Kekuatan grid penuh dalam satu overlay,” kan? “Anda dapat menambahkan trek, menghapus trek, bla, bla, bla.”

Adam: Dan saya seperti, "Kedengarannya sangat keren dan juga sangat rumit." 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. Jadi…

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: Saya memiliki mod di mana, ketika Anda meluncurkan VisBug, ia mengambil seluruh dokumen HTML dan mengecilkannya menjadi artboard. Itu terlihat seperti papan seni. Itu mengambang di atas bayangan di ruang abu-abu. Anda dapat menggeser tanpa batas di sekitarnya. Jadi Anda dapat menggulir dari kanvas halaman Anda, dan apa yang memungkinkan Anda lakukan adalah, lihat, katakanlah Anda memiliki halaman yang sangat panjang, dan Anda ingin mengukur sesuatu dari atas ke bawah, Anda dapat melakukannya sekarang , tetapi Anda akan kehilangan konteks saat melakukannya.

Adam: Nah dalam skenario zoom VisBug baru ini, Anda menahan opsi atau alt pada keyboard Anda, Anda menggunakan roda mouse, atau Anda menekan plus minus dengan perintah Anda dan Anda dapat memperbesar halaman web Anda seolah-olah itu adalah artboard. Dan saya mencoba membuatnya semulus itu. Jadi Anda masuk dan keluar, dan Anda gulir ke bawah, Anda masuk dan keluar, mengukur dari ... Dan VisBug tidak peduli. Itu terus menggambar hamparan yang dihitung, Anda dapat mengubah jarak.

Adam: Karena saya pikir itu sangat penting, sebagai seorang desainer untuk melihat mata burung dari halaman Anda secara langsung. Animasi masih diputar, kalian semua. Area yang dapat digulir masih dapat digulir, bukan? Ini benar-benar keren. Anda seperti, "Seluruh halaman saya dalam satu tampilan." Pokoknya, jadi hampir selesai. Ini di-

Drew: Kedengarannya kacau.

Adam: Ini sangat trippy. Dan itu masuk, saya hanya perlu memastikan itu berfungsi lintas browser, karena itu melakukan beberapa, jelas, beberapa hal rumit untuk membuat halaman langsung Anda terasa seperti itu. Tapi ya.

Drew: Luar biasa. Apakah itu… Maksud saya, saya menganggap bahwa VisBug cukup sering diperbarui dan sedang dikembangkan. Apa yang mungkin kita harapkan untuk dilihat di masa depan?

Adam: Ya, itu pasti salah satu fitur yang saya kerjakan di sana. Saya memiliki fitur di mana… Jadi, ketika Anda mengklik sesuatu, Anda mendapatkan overlay dengan apa yang tampak seperti pegangan, bukan? Dan itu semacam ilusi, yang seharusnya membuatmu merasa nyaman. Dan tujuannya adalah agar pegangan itu bisa diseret. Tetapi saya memiliki beberapa hal mendasar yang harus saya selesaikan terlebih dahulu, seperti elemen di browser yang tidak memiliki lebar. Jadi, jika Anda baru mulai mengambil lebarnya, saya harus melakukan pekerjaan untuk membuat ilusi itu terasa benar.

Adam: Dan Anda bahkan mungkin tidak mendapatkan hasil yang Anda inginkan, karena itu bisa menjadi elemen level blok yang Anda tarik lebarnya lebih kecil, dan Anda tidak mendapatkan reflow item di sebelahnya. Dan Anda mungkin bertanya-tanya mengapa. Jadi saya memiliki prototipe di mana Anda dapat menarik sudut, menyeret elemen ke sekeliling. Tapi saya benar-benar perlu fokus pada bagaimana alat desain melakukan ini. Mereka selalu memiliki tombol sakelar ini. Dan itu seperti... Lihat, apa nama tombolnya?

Adam: Tapi pada dasarnya seperti shrink... Saya menyebutnya shrink wrap. Kecilkan bungkus elemen saya, lebar elemen ini adalah lebar kontennya, versus di sini lebar elemen saya, tempelkan sesuatu di dalamnya. Jadi saya membutuhkan sesuatu seperti itu di browser, overlay pada elemen sehingga Anda dapat memilih di antara ini dan bahkan mungkin sesuatu yang memungkinkan Anda memilih antara blok dan inline, sehingga Anda bisa mendapatkan hasil yang Anda inginkan.

Adam: Tetapi pada akhirnya tujuan di sini adalah agar VisBug tidak ingin sepenuhnya dikendalikan oleh keyboard. Saya ingin Anda dapat menarik spasi. Jika Anda melihat 12 spasi margin di atas, Anda seharusnya bisa meraih dan meraihnya, sedangkan saat ini Anda harus menekan keyboard untuk menentukan sisi atas kotak membutuhkan tambahan margin.

Adam: Jadi ya, saya punya beberapa kebiasaan untuk dikerjakan, dalam hal strategi. Tapi itu sangat banyak tujuan untuk membuatnya lebih dekat dengan alat desain. Dan mungkin bahkan aku akan membungkuk dalam hal itu. Ini seperti, baik, jika Anda ingin mengubah lebar dan Anda akan mendapatkan desain yang aneh, selalu ada cara untuk keluar dari itu dengan VisBug, seperti alat posisi benar-benar memungkinkan Anda keluar dari arus. Jadi aliran merusak ide Anda, alat posisi memungkinkan Anda melarikan diri.

Adam: Jadi ada... Jika seseorang benar-benar paham dengan VisBug, mereka akan membuat orang tercengang, karena itu semacam tidak terbatas, dan seperti, apa yang bisa Anda bawa ke meja? Ini memiliki elemen ekspresi untuk itu. Pasti ada taktik ekspresif. Tapi bagaimanapun, singkat cerita, ilusinya adalah, saya hanya ingin membuatnya lebih kecil dan lebih kecil dan lebih kecil. Saya ingin ilusi menjadi seperti, "Wow, saya benar-benar merasa seperti alat desain."

Adam: Dan kemudian, ya, beberapa peningkatan ekspor akan menyenangkan. Tetapi juga, peningkatan ekspor untuk DevTools akan menyenangkan, dan itu tidak benar-benar menghentikan kami. Jadi saya tidak tahu. Ada banyak masalah, pasti pilih mereka. Saya pikir salah satu fitur besar berikutnya yang ingin saya lakukan adalah garis hijau. Jadi, alih-alih hanya menampilkan hamparan aksesibilitas saat mengarahkan kursor untuk benar-benar menunjukkan beberapa hal dengan garis hijau, dan mengekspos lebih banyak, dan memunculkan lebih banyak informasi, dan saya tidak tahu. Ya.

Drew: Semacam berpikir tentang proses membangun ekstensi Chrome seperti ini, maksud saya, menganggap semuanya diimplementasikan dalam JavaScript, seberapa mirip dengan pengembangan web biasa? Membangun ekstensi Chrome.

Adam: Itu pertanyaan yang bagus. Ini... Fiuh, ini yang sulit. Ini aneh. Pertama, lingkungan tempat Anda meluncurkan kode bukanlah browser. Mereka tidak benar-benar memberi Anda akses penuh ke sana. Anda bisa, jika Anda benar-benar rumit dengannya, yang harus dilalui VisBug, skenario yang lebih rumit ini. Jadi sekarang, saya biasa mengeksekusi di... Ini akan menjadi sangat kabur begitu cepat.

Adam: Karena ada beberapa kotak pasir untuk ekstensi Anda, untuk masalah privasi. Dan mereka mempersulit eksekusi skrip di halaman sebenarnya, bukan? Karena Anda tidak ingin seseorang mengirimkan formulir Anda ketika Anda meluncurkan sesuatu atau sesuatu, mengirimkannya kepada diri mereka sendiri atau apa pun. Itu bisa sangat merusak. Jadi itu memiliki beberapa keanehan seperti itu. Ada jembatan yang harus kamu lewati. Dan salah satunya yang mengganggu VisBug adalah, VisBug dulu menggunakan…

Adam: Jadi itu semua elemen khusus, dan elemen khusus memungkinkan Anda meneruskan data yang kaya kepada mereka sebagai properti. Jadi Anda mengatakan seperti, customelement.foo=myrichobject, penuh dengan array atau apa pun. Dan elemen kustom hanya mendapatkannya karena beberapa data pada node itu sendiri. Tetapi karena saya berada di dunia kotak pasir kecil yang aneh ini, jika saya mencoba untuk mengatur sesuatu yang unik seperti itu pada objek saya, pada dasarnya itu disaring. Mereka telah menetapkan bahwa hal-hal tertentu tidak bisa... Jadi saya bisa meneruskan string ke elemen kustom saya, tapi saya tidak bisa meneruskannya ke objek kaya.

Adam: Tapi ya, selain kebiasaan kecil seperti itu, setelah Anda mendapatkan alurnya, dan jika Anda menghabiskan waktu untuk mendapatkan skenario rollup, yang akan menjadi satu jam atau lebih kerja sehingga Anda memberikan LiveReload dalam hal Anda , itu bisa menjadi sangat alami. Saya pikir Firefox memiliki, sejujurnya, pengalaman pengembangan ekstensi terbaik jika Anda paham dengan CLI, Anda dapat memutar sesuatu dengan satu perintah, dan menginstalnya, memberi Anda fitur LiveReload ini, dan memberi Anda alat debugging. Ini semacam memegang tangan Anda melalui itu, itu bisa sangat bagus.

Adam: Tapi pada akhirnya, ini agak aneh. Itulah mengapa saya melakukan banyak pekerjaan di situs demo yang terlihat seperti sekumpulan artboard, karena saya tidak terlalu membutuhkan halaman web yang sebenarnya, untuk melakukan pengujian VisBug, selama saya memiliki artboard yang mensimulasikan berbagai masalah, atau memiliki hal-hal yang dapat diakses untuk dilihat, dan memberi saya konten yang perlu saya lihat. Saya melakukan banyak pekerjaan di sana di browser seolah-olah itu hanya aplikasi web biasa. Jadi pengalaman dev VisBug sangat mudah, kecuali jika Anda mencoba mengujinya di browser, dan kemudian menjadi berantakan dan apa pun.

Drew: Itu wawasan yang sangat menarik. Jadi saya telah mempelajari semua tentang VisBug hari ini, apa yang telah Anda pelajari akhir-akhir ini, Adam?

Adam: Saya masih meningkatkan keterampilan wajan saya. Jadi saya ingin menjadi seorang wok man, dan saya tidak berbicara tentang pemutar kaset tahun 90-an. Saya ingin membalik sayuran dan membuat mereka sedikit terbakar di udara, menutupinya dengan beberapa bumbu lezat, dan benar-benar membakar bawang putih itu dan membuatnya renyah lezat. Dan kemudian taruh di tempat tidur kecil beras dan geser ke arah Anda dan lihat apa yang Anda pikirkan.

Adam: Jadi saya bersemangat untuk musim panas sekarang, karena itu berarti saya bisa mengeluarkan wajan dan kembali ke lingkungan memasak yang cepat dan panas, dan itu sangat menyenangkan.

Drew: Luar biasa. Itu kedengarannya lezat. Jika Anda, pendengar yang baik, ingin mendengar lebih banyak dari Adam, Anda dapat mengikutinya di Twitter di mana dia berada @argyleinc, dan menemukan situs pribadinya di nerdy.dev. Jika Anda ingin mencoba VisBug, Anda dapat menemukannya di Toko Web Chrome, dan Anda dapat mencoba versi kotak pasir di visbug.web.app. Terima kasih telah bergabung dengan kami hari ini Adam. Apakah Anda memiliki kata-kata perpisahan.

Adam: Tidak, kamu sangat baik. Ini benar-benar manis. Terima kasih telah menerima saya, saya sangat menghargainya.