Adam Argyle ile Çarpıcı Podcast Bölüm 37: VisBug Nedir?

Bu bölümde VisBug'dan bahsediyoruz. Nedir ve Chrome DevTools'da halihazırda bulunan seçenekler dizisinden farkı nedir? Drew McLellan öğrenmek için yaratıcısı Adam Argyle ile konuşuyor.

Notları göster

• VisBug sanal alanı ve oyun alanı
• Adam Twitter'da
• Adam'ın kişisel sitesi
• YouTube'da VisBug
• VisBug 101

Haftalık güncelleme

• Çevrimiçi Etkinliklerimizde Kullandığımız Konferans Platformu: Hopin by Amanda Annandale
• Stephanie Eckles'tan CSS Konteyner Sorguları Üzerine Bir Primer
• Düzeltilmesi Gereken Sinir bozucu Tasarım Modelleri: Doğum Günü Seçici, Vitaly Friedman
• Ağaç Sallama: Átila Fassina'dan Bir Başvuru Kılavuzu
• Beau Hartshorne'dan Temel Web Verilerimizi Nasıl Geliştirdik?

Transcript

Drew McLellan: Becerilerini sınıfının en iyisi UI ve UX için kullanmayı ve çevresindekileri güçlendirmeyi tercih eden, web hayranlığı olan parlak, tutkulu, serseri bir mühendis. Küçük ve büyük şirketlerde çalıştı ve şu anda Chrome'da Google'da çalışan bir geliştirici savunucusu. CSS çalışma grubunun bir üyesi ve bir tasarım hata ayıklama aracı olan VisBug'un yaratıcısı. Tasarım ve UX konusunda kendi yolunu bildiğini biliyoruz, ancak yaşayan herhangi bir iki ayaklıdan daha fazla parmak arası terlik çiftine sahip olduğunu biliyor muydunuz? Ezici dostlarım, lütfen Adam Argyle'a hoş geldiniz.

Adam Argyle: Merhaba.

Drew: Merhaba Adam, nasılsın?

Adam: Oh, parçalıyorum, biliyorsun.

Drew: Bunu duymak güzel. Bu yüzden bugün sizinle projeniz, VisBug ve genel olarak tasarım hata ayıklamasının arkasındaki konsept ve bunun proje iş akışlarına nasıl uyabileceği hakkında konuşmak istedim. Demek istediğim, uzun süredir geliştirici odaklı tarayıcı hata ayıklama araçlarımız var, yani muhtemelen on yıldan fazla bir süredir. Ancak bunlar açıkça koda çok odaklanmış durumda. Peki VisBug'un farkı ne? Ve çözmeye çalıştığı problemin türü nedir?

Adem: Harika. Evet, kök saldığı asıl sorun, bir ön uç mühendisi olarak her zaman tasarımcılarla çalışıyorum ve oturduğumuz bu anı her zaman sevmişimdir ve "Tamam. Son dokunuşları yapıyorum. Askere gidene kadar bir iki günümüz var. Peki tasarımcı, otur da bunu eleştirir misin? Tarayıcınızda ve telefonunuzda veya her neyse, yerel ana bilgisayar sürümümü açmanızı ve benimle gördükleriniz hakkında konuşmanızı istiyorum."

Adam: Ve bunu yıllarca yaptıktan ve bu etkileşimi her zaman sevdikten sonra, görevlerin ne kadar yaygın ve basit olduğu için bir süre sonra kendimi suçlu hissetmeye başladım. "Bir piksel aşağıda. Burada beş piksel kenar boşluğu var.” Ve her zaman sirkeler ve dürtüler ve aralıklar ve tipler için sirkeler ve dürtüler vardı. Demek istediğim, nadiren "Ooh, bir dakika bekle, ben 30 dakikayı biraz açısal değiştirerek ya da her neyse, DOM'umu DOM'nin isteğini destekleyebilmesi için ayarlamak için harcarken" ya da her neyse gibiydi.

Adam: Genellikle küçük şeylerdi. Sonra bir anket yaptım ve Google'daki tüm bu tasarımcıları araştırdım. Ben de "DevTools'u açtığınızda ne yaparsınız?" dedim. Ve sadece temel bilgilere ihtiyaçları olduğu yankılandı. Ve bundan doğdu, ben gibiydim, “Bu daha kolay olmalı. Sadece araba koltuklarının rengini değiştirmek için Ferrari'nin kaputunu açmanız, bir parça motor hareket ettirmeniz gerekmez. Adil değil. Tıpkı bir tasarım aracı gibi, arabanın koltuklarına dokunabilmeli ve rengini değiştirebilmelisiniz.” "Bir şey bu iş akışını kolaylaştırabilir" dedim. Ben de "Tamam, sanırım çözümü yaratıp yaratamayacağımı görmek için bir şeyi hackleyeceğim" dedim.

Adam: Ve her şey böyle başladı. Gerçekten boşluk bırakma ve ardından tipografi ile başladı. Ve bir kez, o taklit edilmiş tasarım araçlarıyla ilgili bir seçim mekanizmasına sahip olduğumda, "Peki başka ne yapabilirim?" gibiydi. Ve oradan devam etti. Ama evet, o anda doğdu.

Drew: Buradaki fikir, müşterinin logoyu büyütmenizi istemesi ve VisBug, tarayıcının bu tür ince ayarları yapmak için bir tasarım aracı gibi davranmasına yardımcı oluyor. Illustrator, Photoshop, Figma veya bu tür şeylerden herhangi birine çok daha yakın.

Adem: Evet. Bu kullanım durumu da iyi bir durum. Çünkü bir müşteriyle birlikte olabilirsiniz ve onlar "Oh, buna bayıldık" derler, bu çok klasik, "tasarımı seviyoruz ama bu mavi renk bizim için zor." Ve sen, "Gerçekten mi?" Bu, insanlar bir form gönderebilir ve siz para kazanabilirsiniz ama şu anda benimle mavi hakkında konuşmak ister misiniz? Ve genellikle bütün bir döngü yaratırdı. Başbakan, "Tamam, isteğinizi geri alacağız ve ardından tasarıma göndereceğiz" derdi.

Adam: Ama eğer tasarımcı oradaysa ve bunu gösteren tarayıcılarıysa, "Tamam. Şeye tıklayıp rengini değiştireceğim.” Ve sadece oradaki değişikliği tarayıcıda prototipleyerek tüm bir çalışma döngüsünü kısaltabilirsiniz. İşte bu. Mevcut bir ürüne karşı en etkilidir, değil mi? Çünkü bu bir hata ayıklama aracıdır. Bu mutlaka bir nesil aracı değildir. Sizin için bir site oluşturmaz. Olabilir, ama biraz garip.

Drew: Yani teknik olarak bir Chrome tarayıcısına yüklediğiniz bir uzantı. Bu doğru mu?

Adem: Evet. Ve bu bir uzantı. Başlattığınızda, "İşte VisBug adlı özel bir öğe" yazan bir JavaScript dosyası indirir. Ve sonra DOM öğesini sayfaya vis-bug olarak yerleştirirsiniz. Ve puf, o anı alıp bir araç çubuğuna dönüştürüyorum ve sayfadaki olayları dinlemeye başlıyorum. Fareyle üzerine gelme olaylarınızı dinliyorum ve tıklama olaylarınızı dinliyorum. Ve onları engellemek için elimden gelenin en iyisini yapmaya çalışıyorum ve ana sayfanızla rekabet etmiyorum.

Adam: Ama evet, özü bu… Bir uzantı olmasının tek nedeni, sayfanıza koymanın kolay olmasıdır. Bu noktada, tarayıcılarda sizinle birlikte gelen bazı ayarlara sahip olmasına rağmen. Ancak yine de çoğunlukla, %99,9, bağımlılığı olmayan özel bir öğedir. Sanırım kullandığım bir renk kitaplığını seviyorum ve bunun dışında hepsi vanilya. Evet.

Drew: Sanırım Firebug böyle başladı, değil mi? Gün içinde bir Firefox eklentisi olarak.

Adem: Evet. Bu yüzden adı VisBug. Firebug'dan çok ilham aldı, ancak görsel tasarımcılar için.

Duru: Ah. Oraya gidiyoruz. Demek istediğim, görsel bir araçtan bahsetmek için sesli bir podcast olmak belki de ideal format değil. Ancak, eğer isterseniz, VisBug'un size sunduğu bazı araçlar ve seçenekler hakkında bize bilgi verin.

Adem: Kesinlikle. Yani VisBug'un yaptığı ilk şeylerden biri ve siz de evde veya bilgisayardaysanız, visbug.web.app'e gidebilir ve VisBug'u uzantı olmadan deneyebilirsiniz, değil mi?

Duru: Ah.

Adam: Bu bir web bileşeni, bu yüzden burada sizin için visbug.web.app'e bir sürü sanat panosuna sahip gibi görünen bir web sayfası yükledim ve sonra tabii ki VisBug önceden yüklendi. Ve bu sitenin amacı, oynamanıza, keşfetmenize ve silmenize izin vermektir. Silme anahtarının başlamak için en tatmin edici araçlardan biri olduğunu düşünüyorum. "Bir sayfaya ne yapabilirim?" gibisiniz. Ve sen, "Pekala, onu yok edebilirim" gibisin.

Adam: Ve bunu sile basılı tutabilesin diye yaptım, bir sonrakini bulacak... Silerken bu oldukça zor. Bir şeyi silersiniz ve bir sonraki kardeşi seçer. Böylece sonsuza kadar bir sonraki kardeşi seçecek. Tamamını silene kadar sil'i basılı tutarsanız… Neyse, çok tatmin edici. Yenile'ye basın ve hepsi geri gelir. Ancak VisBug ile birlikte gelen ilk araç, yani onu başlattığınızda kılavuzlar aracıdır. Eskiden ekranıma tam anlamıyla kağıt tutardım ya da bir şeyleri işaretlememe ve çizgiler oluşturmama izin verecek bir sistem uzantısı alırdım.

Adam: Çünkü evet, hizalama belli bir noktada pek çok tasarımcı için çok optik hale geliyor, değil mi? Mutlaka matematiksel hizalama istemiyorlar, değil mi? Tipografinin optik karakter aralığına sahip olmasının nedeni budur. Matematik karakter aralığı değil. Bu insan karakter aralığıdır. Ve bu nedenle, kılavuzlar aracının kökleri, bir tasarımcıdan gelen birçok nit'in bir şeyleri yakınlaştırıp hizalamayı kontrol etmesinden kaynaklanmaktadır. Mesafe iyi mi?

Adam: Yani bu, kılavuzlar aracının yaptığı ikinci şey. Fırlattığınızda ve bir şeylerin üzerine geldiğinizde, üzerine geldiğiniz öğenin etrafında küçük bir kutu olduğunu göreceksiniz. Ve sonra, tıpkı cetvellerin normalde yapacağı gibi, kesikli kılavuzlar belirir. Ve tıpkı Sketch ve Zeplin'de olduğu gibi, gezindiğiniz ve bu kılavuzları aldığınız gibi, aynı konsept, sadece sayfanızda yaşıyor. Ve bir şeye tıklarsanız ve ardından yeni bir hedefe giderseniz, ölçüm araçlarını alırsınız. Ve ölçüm araçları piksel cinsindendir ve hesaplanırlar... Yani görsel olarak, aralarında kaç piksel vardır. Biri ne demiş değil. Tüm boşlukları toplamaz, sadece bu şeyi tıklarsınız ve diğer kutudan bu kadar uzaktadır.

Adam: Bunun gerçekten yararlı olduğunu düşünüyorum, çünkü shift tuşunu basılı tutup tıklamaya devam edebilir ve temelde beş simge arasında eşit boşluk olduğunu doğrulayabilirsiniz. Ve bu sadece birkaç tıklama. Kodu bilmenize gerek yok, sadece VisBug'u başlatın, üzerine gelin, tıklayın, tıklayın, tıklayın ve şunu göreceksiniz, “Oh, bakın öyle. Evet. Bunların her biri arasında 15 piksel.” Veya bazen can sıkıcı bir şeyle karşılaşırsınız, bir kutuya tıklarsınız ve ardından üst kutusuna tıklarsınız ve üst mesafesinin dokuz, alttakinin sekiz olduğunu fark edersiniz. Ve siz, “Bunu nasıl ortalayacağım? Bir şekilde arada kalıyor.” Ve yumruk sallıyor.

Adam: Ama en azından kılavuzlar aracıyla güzel ve kolay bir şekilde görebiliyorsun. Yani evet, bu kılavuzlar aracı.

Drew: Kesinlikle oradaydım, ekrana kağıt parçaları tutuyordum. Ayrıca, kullanacağım diğer numara, başka bir tarayıcı penceresi açmak ve öğeleri hizalamak için pencerenin kenarını kullanmaktır. Ve sonra bir şekilde her şeyi doğru yerde tutmaya çalışırsınız, böylece kod değişikliği yaparken ve yenilerken her şey hala sıraya girer. Evet, ideal bir çalışma şekli değil, yani.

Adam: İdeal bir çalışma şekli değil. Evet. Ve bir sonraki… Yani, oh, ve bunun ilk versiyonu çok gevşekti. Çırpınmadı, sadece artı işaretini kaldırdı, bu daha sonra ekleyeceğim bir özellik. Bu yüzden bazı kullanıcılar, "Hey, yakalamayı seviyorum, tıpkı tasarım araçlarım gibi. Ama ya gevşek bir ölçüm istersem? Yoksa bir harf yapmak istiyorum, bir harfi ölçmek istiyorum, onun mektup kutusunu değil mi?” Ve böylece, bu kılavuzlar aracı çok kolay bir şekilde bir değiştirici tuşa sahip olacak şekilde değiştirilebilir.

Adam: İşte burada VisBug biraz farklılaşıyor, ama aynı zamanda umarız tanıdık geliyor, kısayol tuşu değiştiricileri çok ağır. Yani tıpkı profesyonel bir tasarımcıyı izlerseniz, kısayol konusunda çok bilgilidirler. Ve burada kısayol tuşlarına basıyorlar, yakınlaştırıyorlar, şuradaki kısayol tuşlarına basıyorlar ve tüm dürtülerini klavyelerinden yapıyorlar. Ve böylece VisBug, bir şeyleri değiştirme şeklinizde çok klavye merkezlidir.

Adam: Aynı zamanda VisBug'un birden fazla seçime izin vermesi ve aynı anda 100 öğenin aralığını değiştirebilmesi nedeniyle. Ve bunu göreceli olarak yapıyor. Her neyse, birkaç ilginç tuhaflığı var, ancak değiştirici konseptindeki klavye gerçekten önemli. Ve birçok araçta seçeneği, kaydırmayı veya komutları tutabilir ve farklı bir şey elde edebilir veya orada yeni bir tür özellik elde edebilirsiniz.

Drew: Yani klavye kısayollarını öğrenmenin gerçekten para kazandırdığı araçlardan biri.

Adem: Öyle. Ve böylece VisBug'u başlattığınızda ve araç simgelerinden birinin üzerine geldiğinizde, bir döküm alacaksınız. Küçük bir açılır menü çıkarır, bu aracı seçmek için kısayol tuşunu söyler ve size ne yapabileceğini ve bunları elde etmek için hangi etkileşimleri yapacağını söyler. Kılavuzlar aracı, "Öğe kılavuzları, fareyle üzerine gelmeniz yeterli. Bir şeyi ölçün, tıklayın ve ardından yeni bir şeyin üzerine gelin. Yapışkan ölçümler kaydırma artı tıklamadır, böylece kalıcı olurlar.”

Adam: Ve bu kılavuzlar ekran görüntüsü almak için de gerçekten güzel. Dolayısıyla, yalnızca bir ön uç mühendisi veya belki de bir PR'ı inceleyen bir tasarımcı olarak bile bir Halkla İlişkileri gözden geçiriyorsanız, bu, oraya girmenin ve evet, yüksek doğrulukta bir denetime sahip olmanın gerçekten güçlü bir yolu olabilir. Hangi tür bizi bir sonraki araca götürür. Bir sonraki araç hakkında bilgi almak ister misiniz?

Duru: Evet, tabii. Bunun için gidelim.

Adem: Harika. Bir sonraki inceleme aracıdır. Bu da şöyle… Tasarımcılar genellikle CSS'nin tamamını istemezler, değil mi? Beklediklerinde… Neredeyse Firebug diyordum, ancak Chrome DevTools, tam listeyi alıyorsunuz, değil mi? Bu H1'i seçtim ve işte tarayıcı stil sayfasına kadar her şey. Ve tasarımcı, "Tarayıcı ne? Tarayıcının bir stil sayfası var mı?"

Drew: Aşağı kaydırma panelinin bulanık alt kısmında.

Adam: Karanlık alt, değil mi?

Duru: Evet.

Adam: Sanki tüm katmanları soymuşsun ve sonra "Ooh, artık bu katmanları sevmiyorum" diyorsunuz. Ve buradaki denetleme aracı, "Ah, tasarımcılar, ne istediğinizi biliyorum. Bu sadece sınır rengi.” Temel olarak, bana bir şeyi yalnızca benzersizse gösterin, bu yüzden beni yalnızca CSS özellikleriyle kaplamayın. Ve gerçekten en çok renk, tipografi ve boşlukla ilgileniyorum. Bu yüzden kenar boşluklarına, satır yüksekliklerine bakacağım, yazı tipi ailesi gerçekten önemli, değil mi? Size bir sayfada yazı tipi ailesinin ne olduğunu söyleyen bir uzantı var.

Adam: VisBug'da bu, inceleme aracındaki yalnızca bir satır öğesidir. Böylece VisBug'u başlatır, incele'ye basın ve herhangi bir tipografinin üzerine gelin ve size yazı tipi ailesini söyleyecektir. Yani evet, bir tasarımcıyı ortaya çıkardığı şeye odaklamaya çalışıyor, evet.

Drew: Yani bu araç, miras alınan stilleri göstermiyor. Bu doğru mu?

Adem: Bu doğru. Kalıtsal ve benzersiz olmadıkça. Yani eğer onlar… Bir metin rengi ya da başka bir şey, eğer metin rengi kelimenin tam anlamıyla miras kelimesi değilse, size bunun hesaplanmış bir değer olduğunu, bunun ilginç bir şey olduğunu söyleyecektir.

Drew: Evet, bu gerçekten faydalı bir şey... Evet. Bir şeyin o tek örneğine tam anlamıyla uygulanan şeylere odaklanmanıza yardımcı olur, ki bu açıkça değiştirmek istediğiniz şeydi. Demek istediğim, sanırım bu gerçekten faydalı olabilir, tüm bu araçlar, bir nevi bahsettiğiniz gibi, paydaş geri bildirimi almak için gerçekten faydalı olabilir. Ve bir çeşit müşteriyle etkileşimli çalışma.

Drew: Sanırım bugünlerde giderek daha fazla yapmamız gerektiği gibi, ekran paylaşımı üzerinde de eşit derecede işe yarayacak. Biriyle bilgisayar başında oturmak zorunda değilsiniz, bir aramanın diğer ucunda oturabilir ve tarayıcınızı paylaşabilir ve bu şekilde yapabilirsiniz. Sanırım bir müşteri ekranı gösterip şöyle diyemediğinde geri bildirim almanın oldukça etkili bir yolu olurdu.

Adem: Kesinlikle.

Adam: Canlı web sayfasını Zeplin çalışma yüzeyi gibi görünen bir şeye dönüştürmek her zaman büyülüdür. Birisi, "Ne... Az önce yeni bir yere mi gittik?" Ve siz, “Hayır, bu sizin ürününüz. Onunla sadece görsel olarak etkileşim halindeyiz.” Evet, gerçekten güzel olabilir.

Drew: VisBug'un uygulandığını gördüğünüz veya aklınıza gelen, ilginç olabilecek başka ilginç kullanım örnekleri var mı?

Adem: Evet. Yani, evet, o kadar çok var ki, başlaması biraz zor. Oh, önemli olan geliştiriciden geliştiriciye iletişimdir. VisBug hesaplanan değerler üzerinde çalışır. Bu yüzden yazdığınız değerlere bakmaz. Ve bu gerçekten güzel olabilir, çünkü piksellerin ekranda hesaplandığı şekilde mutlak sonucu ölçüyor ve inceliyorsunuz. Ve yazarlık tarafının aksine sonuçlar üzerinde çalışırken bu şekilde bir konuşma yapmak gerçekten güzel olabilir.

Adam: Ve "Tamam, görsel olarak elde ettiğimiz buysa, yazar tarafında nasıl yanlış yaptık?" gibi bir şeye geri dönebilirsiniz. Bir sonraki araç da erişilebilirlik denetleme aracıdır. Bu nedenle, inceleme aracı bir öğe üzerindeki stilleri görmeyi kolaylaştırır ve tasarımcı dostu bir şekilde onları parçalara ayırır. Erişilebilirlik aracı, bir sayfadaki tüm öğeleri incelemenize yardımcı olur ve sahip olduğu tüm erişilebilir özellikleri ortaya çıkarır, bu da, umarım, gidip bir şeylerin yapıldığını doğrulamayı kolaylaştırır.

Adam: Yani bir PR… Ve çoğu zaman bir şeyler yaratılır. Yani bu, yine, geliştiriciden geliştiriciye, tasarımcı geliştirici, arayüzleri gözden geçiriyorsunuz. Bu çok kritik. Bir arayüze bakıyorsanız ve merak ediyorsanız, VisBug'un orada sizin için bir kullanım durumu var. Tarayıcıda prototip oluşturabileceğiniz kullanım durumları da vardır. Müşterinin maviyi denemek istediği bir yerden bahsettik. Tamam, bu oldukça kolay bir senaryo.

Adam: Ama başkaları da var. VisBug'da D komutuna basarsanız, bir öğeyi çoğaltacaksınız. Ve neyi kopyaladığın umrunda değil. Böylece bir başlığı çoğaltabilir, iki başlık arasına biraz boşluk ekleyebilir ve tarayıcıda canlı bir değişken oluşturabilirsiniz. Başlık metnine çift tıklarsınız ve düzenlenebilir bir metin alanı haline gelir ve yeni bir başlık deneyin ve başlığın nasıl uyduğunu görün. Git biraz boşluk ayarla ve tüm bu geliştirici işini kendine sakladın, bir kaynak dosya bul ve tüm bu tür şeyler ve sen sadece…

Adam: Yani evet, keşfetmenize ve doğrulamanıza yardımcı olabilir. Bu biraz garip… Yani, DevTools'un yaptığı pek çok şey var, değil mi? İşiniz bittikten sonra gelir, aslında size çok sık kaynak kodu vermez, DevTools'dan kod kopyalamanız çok sık olmaz. Bir anahtar değer çiftini kopyalayabilirsiniz. "Oh, bu tarzı değiştirdim" gibi. Ama evet, neyse.

Drew: Mm-hmm (olumlu). Evet. Öğeleri çoğaltmaktan bahsettiğiniz, özellikle görsel durumlar düşünebilirim. Beklediğinizden çok daha fazla içerik olsaydı nasıl olacağını simüle etmek için sayfanın bütün bir bölümünü alıp çoğaltmak isteyebilirsiniz.

Adem: Evet. Bu, kaos testi kullanım durumudur.

Duru: Evet.

Adem: Kesinlikle.

Drew: CMS tabanlı sistemler ve tüm bu tür eğlenceli görevlerle tasarım yapmak hepimizin uğraşması gereken bir şey.

Adam: Evet, bu da gerçekten çok önemli bir kullanım örneği. Çünkü ben bunu... Dediğim gibi manşetler için yapıyorum. Sen sadece bir metne çift tıkla ve ben gidip klavyeyi çarpayım. Falan, vıla, vıla, vılla ve bir sürü boşluğa vur, falan, falan. Ben de "Tamam, düzen nasıldı? İyi oldu. Tamam, güzel, bir sonraki şeye geçebilirim. Bunu dört kez çoğaltırsam ne olur? Her şey arasında hala boşluk var mı? Bir sonraki öğenin yanında mı akıyor?”

Adam: Evet, içerik kaosu simülasyonu için gerçekten güzel olabilir. Gerçekten kısa başlıklar, gerçekten uzun başlıklar, hiç arkadaşı yok, bir milyon arkadaşı var. Kullanıcı arayüzünde bu kullanım durumlarını nasıl ele alıyorsunuz? Evet.

Drew: Yani herhangi bir tarayıcı tabanlı içerikle çalışır. Yani PWA'lar ve normal web sayfaları?

Adem: Evet, öyle. Yani sende Spotify yüklüyse, bunu her zaman yapıyorum, bende Spotify yüklü ve "Spotify, denetlenmesi imkansız bir uygulama gibi görünüyorsun" diyeceğim. Ama tahmin et ne oldu? VisBug'ın umurunda değil. VisBug tüm eşyalarınızı kaplar, tüm tipografiyi denetler. Şunun için hafif bir tema yaptım… Oh, Spotify'ın hafif bir temasını yaptığım bir yerde bir tweetim var.

Adam: Oh, bu başka bir kullanım örneğiydi, üzgünüm, renk prototipleme için. Bir sürü çıkartma kağıdıyla uğraşmak zorunda kalmadan ürünün kendisinde hafif bir tema oluşturabilirim, değil mi? Yani şu önemli hatta zihniyet var, insanların ürününüzü bir oyun alanı olarak kullanmasına yardımcı olmak için VisBug'u çok isterim. Bunu şu şekilde kullan... Çok gerçek. Tasarım kompozisyonlarınızdan daha gerçek. O yüzden orada biraz daha zaman geçir. Sanırım asıl ürününüz üzerinde çalışarak daha etkili tasarım kararları alabileceğinizi göreceksiniz.

Drew: Erişilebilirlik durumu da özellikle ilginç, çünkü çoğu zaman, özellikle bu günlerde, bileşen kitaplıklarında çok çalışıyoruz ve bir sayfanın küçük bileşenlerine bakıyoruz. Ve bir müşterinin gerçekten etkileşime girdiği türden görünümler oluşturmak için bir araya getirilen tüm bunlara bakmak için daha az zaman harcamak. Erişilebilirlik öğeleri, nitelikler gibi sayfada görünmeyen bu tür ince ayrıntılara göz kulak olmak gerçekten zorlaşıyor.

Drew: Görünmeyen şeylere göz kulak olmak çok zor. İşte tam bu noktada takımlar, bir şeyi kontrol edebilmek ve bunu görebilmek için gerçekten ama gerçekten yardımcı olabilir, evet, üzerinde doğru roller var ve bu-

Adem: Öyle. Tam kullanım durumu budur. Bir PM'nin bu şeyleri doğrulayabilmesini istiyorum. Bir tasarımcının erişilebilirliğe bakabilmesini ve araçları açıp DOM düğümünü bulması gerekmemesini istiyorum, hepsi öğeler panelinde çatırdadı ve garip görünüyor. Sadece "İşte alan özellikleri, varsa başlık burada" yazıyor. Ayrıca başka erişilebilirlik araçları da var. VisBug, arama simgesiyle birlikte gelir. Arama simgesinin onunla etkileşim kurmanın birden çok yolu vardır.

Adam: Yani önce sayfayı sorguluyor. Bu nedenle, istediğiniz öğe türünü veya öğe sınıfı adını biliyorsanız, onu aramanız yeterlidir, böylece onu fareyle bulmak zorunda kalmazsınız. Ancak bunun içinde eğik çizgi komutları da var. Yani VisBug'da eklentiler var ve sayfada komut dosyalarını çalıştıracaklar. Yani, üç veya dört tane kaydettiğiniz bir yer imi olduysa… “Bunu kullanacağım çünkü tüm sınırları vurguluyor ve bana kutularımı gösteriyor” diyorsunuz. Hata ayıklama numarası gibi bir şey.

Adam: Muhtemelen bir VisBug eklentisidir. Böylece VisBug'u başlatırsınız, eğik çizgiye basarsınız ve otomatik tamamlama alırsınız ve size tüm farklı eklentileri gösterir. Ve hataların üst üste bindirildiği gerçekten güzel bazı erişilebilirlik olanlar ve bunun gibi çeşitli şeyler var. Bu yüzden katılıyorum. Erişilebilirlik daha erişilebilir olmalıdır. Bunu söylemek çok saçma. Ancak alet kemerine daha yakın olması gerekiyor. Ve bazen çok uzakta olduğunu düşünüyorum ve belki de bu yüzden gözden kaçıyor. Bu yüzden, biraz daha önde ve ortadaysa ve daha fazla kontrol edilmesi daha kolaysa umuyorum. Evet.

Drew: Ve ilginçtir ki VisBug, renkler gibi şeylerin hesaplanmış değerleriyle çalışıyor. Yani bu, farklı opaklık seviyelerine sahip birkaç katmanlı öğeniz varsa, ekranda görüntülenen rengi tam olarak ölçebileceğiniz anlamına mı geliyor?

Adem: Ooo.

Drew: … bireysel unsurlara bakıp bir şekilde çözmeye mi çalışıyorsunuz?

Adam: Bu gerçekten iyi bir soru. Bu yüzden, sanırım, soruyu doğru anlıyorsam, ki bu ön uçta klasik bir zorluktur, evet, yarı opak bir metin kelimeniz olup olmadığını nasıl anlarsınız, gri üzeri beyaza karşı rengi nedir? ? Ve onun kontrastını nasıl biliyorsun? Şu anda, bilmiyoruz. Yani VisBug rengi biliyor ve “%50 gri” ya da orada sahip olduğunuz renk ne ise diyecek. Ama bundan daha akıllı bir şey bilmiyor. Mümkün değil…

Adam: Bence bu durumda yapman gereken bir tuval oluşturmak, oradaki tüm katmanları boyamak ve sonra bir damlalık ya da bir... Yani onu tuvale çevirip hepsini bir araya getirerek bir resim haline getirmek. tek boyanmış katman ve ardından diğer şeyler üzerinde katmanlandıktan sonra gerçek sonunun hesaplanan grinin ne olduğunu görmek için tek piksel değerini çıkarın.

Adam: Sanırım birisi bunu belirledi, ya da belki GitHub sorunu olarak güzel olurdu. Çünkü VisBug bunu %100 kolaylaştırabilir. VisBug, perde arkasında, bir şeylerin üzerinde gezindiğiniz metin ölçümleriyle zaten yaptım ve bu size yazı tipleri hakkında çılgınca rad bilgi verir. X yüksekliği ve kapak yüksekliği gibi neredeyse çok fazla bilgi var, ancak daha da fazlasını yapıyor. Ve sanki, "Ooh, belli bir noktada kapalıyım." Bu yüzden oradaki gürültüye karşı sinyali nasıl bulacağımı bulmam gerekiyor.

Adam: Ama evet, bu düşünce sürecini seviyorum çünkü bunu yapan bir aracımız olmalı. Ve eğer nasıl hesaplayacağımızı biliyorsak, bunu yapmasını VisBug'a öğretebiliriz ve bu gerçekten harika bir özellik olurdu, opaklıkla ilgili hesaplanmış renge sahip olmak. Sevdim.

Drew: Evet, yani, kontrastın erişilebilirlik gereksinimlerini geçmek için yeterli olup olmadığından emin olmadığınız bir arka plana karşı metin olması bir tür standart durum. Ve belki de değil, belki çok düşük kontrast ve kontrastın iyi olduğu noktaya gelene kadar değerleri değiştirmek istiyorsunuz, ancak müşterinin başlangıçta marka renkleri açısından istediği şeyden çok uzağa sürüklenmedi. ve şeyler.

Adam: Ben buna yumru diyorum, geçene kadar çarp.

Duru: Evet.

Adam: Çünkü öyle hissettiriyor. Ben, "Ooh, skorum biraz eksik." Yani, HSL hafifliğime gideceğim ve sadece çarpacağım, çarpacağım, çarpacağım ve "Ding" gibi yeşil bir onay işareti alana kadar küçük sayıların artmasını izleyeceğim. Ben "Tamam, güzel" gibiyim. Ve evet, bazen bu rengin bir kısmı havalı değil. Peki, sürmekte olan 3.0 algısal erişilebilirlik çalışmasının çoğunu incelediniz mi? Artık AA veya AAA'ya sahip olmayacağız, sayıya sahip olacağız ve yazı tipi inceliği gibi şeyleri içeriyor. Yani ince bir yazı tipiyse daha düşük puan alır, kalın bir yazı tipiyse gider… Çünkü kontrast oluşturan çok şey var.

Drew: Evet, hayır, bunların hiçbirini görmemiştim, ama kulağa...

Adam: Her neyse, keşfetmek gerçekten harika bir şey.

Drew: Kulağa büyüleyici geliyor, evet. Bunu konuşacak birini bulmam gerekecek. Bu başka bir bölüm. Yani, bazı geliştiricilerin VisBug'un yaptığı her şeyi DevTools'daki CSS paneli aracılığıyla yapabileceğinizi iddia edebileceğinden eminim. Ve bence bu biraz adil ama muhtemelen asıl noktayı kaçırıyor, evet, değişiklik yaparken CSS'yi manipüle ediyorsunuz, ancak geliştirici odaklı bir arayüz yerine bir tür tasarımcı odaklı kullanıcı arayüzünü üste koyuyor. Bu onun adil bir karakterizasyonu mu?

Adam: Bu gerçekten adil bir şey. Ve dürüst olmak gerekirse, en iyi fikirler VisBug'dan DevTools'a dönüşür. Ve zaten sahipler. Yani VisBug, herhangi bir öğede C komutuna basarsanız, hesaplanan her stili alır, en azından bu benzersizdir. Yine, sanki size tüm bu kalıtsal özellikleri vermeyeceğimiz şeyleri yapacağız. Ancak hepsini panonuza koyar ve bu stili başka bir yere, bir stil sayfasına, bir CodePen'e yapıştırabilir ve birkaç tıklamayla öğeyi kelimenin tam anlamıyla yeniden oluşturabilirsiniz.

Adam: Ve bu tür etkileşimler DevTools'a, bu öğeler paneline girdi. Bununla birlikte, olmayan başka şeyler de var, yani DevTools yalnızca tek bir düğüm inceleme aracıdır. Ve VisBug, hayır, çoklu seçim yapabilmem gereken tasarım aracı mantrasını takip ediyor. Toplu düzenleme, toplu inceleme yapabilmem gerekiyor. Ve bu yüzden boşluk için her zaman VisBug kullanıyorum. Çünkü birden fazla öğeyi vurgulayabilir ve kenar boşluğunun çöktüğünü görebilirim.

Adam: DevTools'da bunu asla göremezsiniz, çünkü çoğu zaman bir seferde yalnızca bir düğüm görebilirsiniz, ancak birden çok kenar boşluğu göstermenin bir yolu vardır, ancak bu aynı değildir. Ve böylece, evet, böyle gerçekten eğlenceli olabilen bu niş kullanım durumları var. Bir diğeri ise, bir tanesini vurgularsanız… Diyelim ki bir tipografi sisteminiz var ve H1'den H7'ye kadar, hikaye kitabındaki gibi veya bunun gibi bir şeyiniz var, hepsini VisBug'da vurgulayabilirsiniz, shift'e basılı tutun, hepsine tıklayın. Boop, boop, boop, boop, tipografi aracına gidin ve yukarı veya aşağı vurun ve her birinde göreceli bir değişiklik yapar.

Adam: Yani her biri bir yukarı veya bir aşağı itecek. Ve bu DevTools'un çok kolay yaptığı bir şey değil. Ve evet, bunun gibi bazı süper güçleri var çünkü biraz daha agnostik. Ve her zaman bir dizide yinelenmeye hazır. Evet.

Drew: Peki VisBug'un kökeni neydi? Ve şimdi sadece kişisel bir proje mi? Yoksa bir Google projesi mi? Veya durumu nedir?

Adem: Evet. İlk olarak, durum şu ki, bu bir Google projesi. Birincil hedefi, DevTools'a geçmeden önce prototip oluşturacak ve keşfedecek bir yer olmaktır. En azından şeylerin Google tarafından. Ancak kişisel açımdan, onu hala ortak görevlerde pişirmek veya ortak görevlerin üstesinden gelmek için bazı optimizasyonlarda pişirmek için bir yer olarak görüyorum. Ve sadece daha geniş bir kitleye DOM'a bakmanın bir yolunu vermek için.

Adam: Gerçekten DevTools'un süper güçlü olduğunu düşünüyorum, ama çok korkutucu. Sadece bir sekme öğrenmek için bir kariyer alabilir. Hala DevTools'ta bir şeyler öğreniyorum ve bunları her zaman kullanıyorum. Ve evet, bu bazı yönlerden farklı bir izleyici kitlesi. Daha çok yeni başlayanlar, gelen insanlar, hatta belki de PM'ler, yöneticiler gibi, hiç kodlama niyetinde olmayan ancak çıktıyla ilgilenen insanlar. Ve bu onlara bir nevi, evet, oraya girmeleri için sadece hafif aletler veriyor.

Drew: Bu bahsettiğin ilginç bir nokta, çünkü kişisel olarak sık sık bu tür DevTools'u yönetirken rahat bir iş akışı bulmakta zorlandığımı görüyorum. Ve tüm bu küçük klostrofobik panelleriniz var ve onları başka bir pencereye ayırabilirsiniz, ama sonra iki farklı pencereyi takip etmeniz gerekiyor. Ve birkaç tarayıcı penceresi açtıktan sonra yapamazsınız… Bir tanesine odaklanıyorsunuz ve hangi DevTools'un ona ait olduğunu bilmiyorsunuz.

Drew: Ve sonra panellerin kendi içinde, bir tür Vahşi Batı kullanıcı arayüzü kuralları gibi. Kaydıracaksınız ve işler beklemediğiniz garip şeyler yapmaya başlayacak. Ve kullanıcı deneyimi açısından, her şeyin büyük bir karmaşa olduğunu hissediyorum.

Adem: Öyle. Evet.

Drew: Sence bu kaçınılmaz mı? Daha iyi olabilir mi?

Adam: Burada kesinlikle düşüncelerim var. Ve evet, bence iyi… Diyelim ki şu anda şöyle bir dinleyiciniz var: “DevTools konusunda oldukça bilgiliyim. O kadar çılgın olduklarını düşünmüyorum.” “Tamam, git Android Studio veya Xcode'u aç. Bir projeye başlayın ve DevTools'a bakın, çıktıya bakın. Şu anda ne kadar tanıdık hissediyorsun?" Muhtemelen çok yabancı. Buna bakıyorsunuz, “Bu çöp. Bunu neden yapıyorlar? Bu panel neden burada?” Ve zihniniz tüm bu neden soruları ve kafa karışıklığıyla yarışmaya başlar.

Adam: Ve sanki, DevTools'u ilk açtıklarında herkes böyle hissediyor. Bu yüzden gerçekten biraz empatik olmalısın.

Drew: Bu kaçınılmaz mı… Daha iyisini yapabilir miyiz? Yoksa bu sadece şeylerin doğal düzeni mi?

Adam: İşte bu konudaki şu anki görüşüm, karmaşıklığın içine girmenin gerçekten kolay olduğunu düşünüyorum. Ve DevTools bunlardan biri, sadece doğal olarak karmaşıklar. Bunların çoğunu kolaylaştırmak için iyi bir kullanıcı arayüzü yok. Bunların çoğu geliştiriciler tarafından yapılır. Ve bence geliştiriciler geliştiriciler için araçlar geliştiriyor, çünkü sahip olacaksınız… Tek yol buysa veya bu iyi bir yol olsa bile, öğreneceksiniz ve bunda iyi olacaksınız. ve onunla rahat edeceksin.

Adam: Ve tüm DevTool'lar biraz tuhaf, çünkü garip kullanım durumları için yapılmışlar, değil mi? Gelişim tuhaf. Dürüst olalım. Dörtte iki görünmez çarklar ve görünmezler yapıyoruz ve temelde görünmez, sanal parçalarla evler inşa ediyoruz. Yani evet, bu şeyleri incelemek ve bize ne çıktıklarını söylemek için garip araçlara ihtiyacımız var.

Adam: Şimdi, söylendiği gibi, VisBug'un yaptığı ve benim yavaş yavaş DevTools'a taşıdığım şey, çok şey yaptığını iddia eden büyük bir aracın aksine daha odaklı daha küçük araçlar. Bence birçok şeyi gerçekten iyi yapmak zor. Ve bu klasik argüman, değil mi? Bunların hepsi yıldızlar, uzmanlara karşı genelciler. İkisi de her zaman mükemmel olmayacak.

Adam: Ama VisBug'un yapmaya çalıştığı şey, uzmanlar yapmış. Yani kılavuzlar aracı sadece kılavuzluk yapar. Ve bu araç asla sayfanın diğer araçlarına sızmaz. Ve bu yüzden DevTools'un tasarımcılara daha fazla yardım etmek istediği DevTools ile bunu daha çok yapmaya çalışıyorum, bu da VisBug'un DevTools'a görmesi için ilham vermesine yardımcı oldu. Ve bir şeyleri tanıtmaya devam etme şeklim, örneğin, bir ızgara düzenleyicisi yapmak yerine, "Şebekeden gelen tüm güç tek bir katmanda", değil mi? "Parça ekleyebilir, parçaları kaldırabilirsin, falan, falan, falan."

Adam: Ben de "Bu kulağa gerçekten harika ve aynı zamanda gerçekten karmaşık geliyor." 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: VisBug'u başlattığınızda tüm HTML belgesini alıp çalışma yüzeyine küçülttüğü bir modum var. Bir çalışma tahtası gibi görünüyor. Gri bir alanda bir gölge üzerinde yüzüyor. Etrafında sonsuz kaydırabilirsiniz. Böylece sayfa tuvalinizden uzaklaşabilirsiniz ve bunun yapmanıza izin verdiği şey, bakın, diyelim ki gerçekten uzun bir sayfanız var ve yukarıdan aşağıya bir şeyi ölçmek istiyorsunuz, peki bunu hemen şimdi yapabilirsiniz. , ancak ilerledikçe bağlamı kaybedersiniz.

Adam: Peki bu yeni VisBug yakınlaştırma senaryosunda, klavyenizde options veya alt tuşunu basılı tutuyorsunuz, fare tekerleğini kullanıyorsunuz veya komutunuzla artı eksi'ye basıyorsunuz ve web sayfanızı bir çalışma yüzeyi gibi yakınlaştırabiliyorsunuz. Ve onu olduğu kadar sorunsuz hale getirmeye çalışıyorum. Yani içeri girip çıkıyorsunuz ve aşağı kaydırıyorsunuz, içeri girip çıkıyorsunuz, yerden ölçüyorsunuz… Ve VisBug umursamıyor. Hesaplanmış bindirmeleri çizmeye devam eder, aralığı değiştirebilirsiniz.

Adam: Çünkü bir tasarımcı olarak sayfanızın kuşbakışı canlı olarak görülmesinin gerçekten önemli olduğunu düşünüyorum. Animasyonlar hala oynuyor, millet. Kaydırılabilir alanlar hala kaydırılabilir, değil mi? Bu gerçekten havalı. "Tüm sayfam tek bir görünümde" gibisiniz. Her neyse, neredeyse bitti. İçinde-

Drew: Kulağa tuhaf geliyor.

Adam: Çok trippy. Ve geldi, sadece tarayıcılar arası çalıştığından emin olmam gerekiyor, çünkü canlı sayfanızı bu şekilde hissettirmek için açıkçası bazı zor şeyler yapıyor. Ama evet.

Drew: İnanılmaz. Öyle mi… Yani, sanırım VisBug oldukça düzenli bir şekilde güncelleniyor ve geliştiriliyor. Gelecekte görmeyi bekleyebileceğimiz şey nedir?

Adam: Evet, kesinlikle üzerinde çalıştığım özelliklerden biri bu. Bir özelliğim var... Yani, bir şeye tıkladığınızda, tutamaçlara benzeyen bir kaplama elde edersiniz, değil mi? Ve bu bir tür illüzyon, sizi rahat hissettirmesi gerekiyor. Ve amaç, sonunda bu tutamaçların sürüklenebilir olmasını sağlamaktır. Ama önce çözmem gereken bazı temel şeyler var, tarayıcıdaki öğelerin genişliği yok gibi. Bu yüzden, genişliği yakalamaya başlarsanız, bu yanılsamayı doğru hissettirmek için çalışmam gerekir.

Adam: Ve istediğiniz sonuçları bile alamayabilirsiniz, çünkü blok düzeyinde bir öğe olabilir, genişliği küçültür ve yanındaki öğenin yeniden akışını alamayabilirsiniz. Ve nedenini merak ediyor olabilirsiniz. Bu yüzden köşeleri sürükleyebileceğiniz, öğeleri etrafa sürükleyebileceğiniz prototiplerim var. Ama gerçekten tasarım araçlarının bunu nasıl yaptığına odaklanmam gerekiyor. Her zaman bu geçiş düğmesine sahiptirler. Ve sanki... Bakın, geçiş ne denir?

Adam: Ama temelde büzülme gibi… Ben buna büzülme sargısı diyorum. Öğemi küçültün, bu öğenin genişliği, içeriğinin genişliğidir, işte öğemin genişliği, içine bir şey yapıştırın. Bu yüzden, tarayıcıda böyle bir şeye ihtiyacım var, bunlar arasında seçim yapabilmeniz için öğenin üzerine bindirilmiş ve hatta belki de blok ve satır içi arasında seçim yapmanıza izin veren bir şey, böylece istediğiniz sonuçları elde edebilirsiniz.

Adam: Ama sonuçta buradaki amaç, VisBug'un tamamen klavyeyle çalışmak istememesi. Aralığı sürükleyebilmeni istiyorum. Üstte 12 kenar boşluğu görüyorsanız, uzanıp yakalayabilmelisiniz, oysa şu anda kutunun üst tarafının bir kenar boşluğuna ihtiyacı olduğunu belirtmek için klavyeye basmanız gerekiyor.

Adam: Ve evet, strateji açısından çözmem gereken birkaç tuhaflık var. Ancak, onu tasarım araçlarına daha da yakın hale getirmek büyük bir hedef. Ve belki ben bile buna katlanacağım. Şey, genişliği değiştirmek istiyorsanız ve garip bir tasarım elde edecekseniz, VisBug ile bundan kurtulmanın her zaman yolları vardır, tıpkı pozisyon aracının akıştan kaçmanıza gerçekten izin vermesi gibi. Yani akış fikrinizi mahvediyor, konum aracı kaçmanıza izin veriyor.

Adam: Ve işte… Biri VisBug konusunda gerçekten bilgili olsaydı, insanların aklını başından alırdı, çünkü bu bir çeşit sınırsız ve sanki, masaya ne getirebilirsin? Bunun için bir ifade öğesi vardır. Kesinlikle etkileyici taktikler var. Ama her neyse, uzun lafın kısası, yanılsama şu ki, onu daha da küçültmek ve küçültmek istiyorum. İllüzyonun "Vay canına, gerçekten bir tasarım aracı gibi hissediyorum" gibi olmasını istiyorum.

Adam: Ve sonra, evet, ihracata yönelik bazı geliştirmeler iyi olurdu. Ama aynı zamanda DevTools için dışa aktarmanın geliştirilmesi de iyi olurdu ve bu bizi gerçekten durdurmuyor. Yani bilmiyorum. Bir ton sorun var, kesinlikle onlara oy verin. Sanırım yapmak isteyeceğim sonraki büyük özelliklerden biri yeşil çizgiler. Bu nedenle, bazı şeyleri yeşil çizgilerle gerçekten belirtmek ve daha fazlasını ortaya çıkarmak ve daha fazla bilgiyi ortaya çıkarmak için üzerine gelindiğinde erişilebilirlik bindirmeleri göstermek yerine ve bilmiyorum. Evet.

Drew: Bunun gibi bir Chrome uzantısı oluşturma sürecini düşünmek, yani, hepsinin JavaScript'te uygulandığını varsayarsak, normal web geliştirmeye ne kadar benziyor? Bir Chrome uzantısı oluşturma.

Adem: Bu güzel bir soru. Bu… Vay canına, bu zor. Bu ilginç. Öncelikle, kodunuzu başlatacağınız ortam tarayıcı değil. Size orada tam erişim hakkı vermiyorlar. VisBug'un mezun olmak zorunda olduğu bu konuda gerçekten yanıltıcı olursanız, bu daha da zor senaryoyu yapabilirsiniz. Yani şu anda, ben yürütüyordum… Bu çok hızlı bir şekilde bulanıklaşacak.

Adam: Çünkü uzantınız için, gizlilik sorunları için birden fazla sanal alan var. Ve gerçek sayfada komut dosyalarını çalıştırmayı zorlaştırıyorlar, değil mi? Çünkü bir şeyi ya da bir şeyi başlattığınızda formunuzu gönderen, kendilerine ya da her neyse gönderen birini istemiyorsunuz. Gerçekten yıkıcı olabilir. Yani bunun gibi bazı tuhaflıkları var. Geçmen gereken bir köprü var. Ve VisBug'un başına bela olan bunlardan biri, VisBug'un eskiden kullandığı...

Adam: Yani hepsi özel öğeler ve özel öğeler, zengin verileri onlara mülk olarak aktarmanıza izin veriyor. Yani, customelement.foo=myrichobject, dizilerle dolu ya da her neyse diyorsunuz. Ve özel öğe, bunu düğümün kendisindeki bazı veriler olarak alır. Ama bu tuhaf, küçük sandbox dünyasında olduğum için, nesneme böyle benzersiz bir şey koymaya çalışırsam, esasen filtrelenmiş olur. Bazı şeylerin yapamayacağını belirlediler… Yani özel öğeme bir dize iletebilirim, ancak onu zengin bir nesne ile geçiremiyorum.

Adam: Ama evet, bunun gibi küçük tuhaflıklar dışında, akışı bir kez azalttığınızda ve bir toplama senaryosu almak için zaman harcarsanız, bu bir saat kadar iş olacak, böylece LiveReload'u kendi işinize alıyorsunuz. , oldukça doğal hale gelebilir. Dürüst olmak gerekirse, Firefox'un en iyi uzantı geliştirme deneyimine sahip olduğunu düşünüyorum, eğer CLI konusunda bilgiliyseniz, tek bir komutla bir şeyi döndürebilirsiniz ve onu yükler, size bu LiveReload özelliklerini verir ve size hata ayıklama araçları sunar. Bir nevi elini tutuyor, gerçekten güzel olabilir.

Adam: Ama nihayetinde, biraz tuhaf. Bu nedenle, bir grup çalışma yüzeyine benzeyen bu demo sitesinde çok fazla iş yapıyorum, çünkü çalışma yüzeylerim olduğu sürece, çoğu zaman VisBug testi yapmak için gerçek bir web sayfasına gerçekten ihtiyacım yok. çeşitli sorunları simüle edin ya da bakmak için erişilebilir şeylere sahip olun ve bana görmem gereken içeriği verin. İşlerin çoğunu, sanki normal bir web uygulamasıymış gibi tarayıcıda yapıyorum. VisBug'un geliştirici deneyimi, tarayıcıda test etmeye çalışmadığınız sürece gerçekten kolaydır ve sonra biraz dağınık olur ve her neyse.

Drew: Bu gerçekten ilginç bilgiler. Yani bugün VisBug hakkında her şeyi öğreniyorum, son zamanlarda ne hakkında öğreniyorsun, Adam?

Adam: Hala wok becerilerimi geliştiriyorum. Yani ben bir wok adamı olmak istiyorum ve 90'ların kasetçalarından bahsetmiyorum. Sebzeleri ters çevirip havada biraz tutuşturmak, üzerlerini lezzetli baharatlarla kaplamak ve sarımsağı gerçekten kavurup çıtır çıtır yapmak istiyorum. Sonra küçük bir pirinç yatağına koyun ve kendinize doğru kaydırın ve ne düşündüğünüzü görün.

Adam: Bu yüzden şu anda yaz için heyecanlıyım çünkü bu, wok'u kırıp hızlı tempolu, sıcak pişirme ortamına geri döneceğim anlamına geliyor ve bu gerçekten eğlenceli.

Drew: İnanılmaz. Kulağa lezzetli geliyor. Sevgili dinleyici, Adam'dan daha fazlasını duymak istiyorsanız, onu @argyleinc olduğu Twitter'da takip edebilir ve kişisel web sitesini nerdy.dev'de bulabilirsiniz. VisBug'u denemek isterseniz, Chrome Web Mağazasında bulabilir ve korumalı alan sürümünü visbug.web.app adresinde deneyebilirsiniz. Bugün bize katıldığınız için teşekkürler Adem. Ayrılık sözleriniz oldu mu?

Adam: Hayır, gerçekten güzeldin. Bu gerçekten çok tatlıydı. Beni kabul ettiğin için teşekkürler, gerçekten minnettarım.