Smashing Podcast ตอนที่ 37 กับ Adam Argyle: VisBug คืออะไร?
เผยแพร่แล้ว: 2022-03-10ในตอนนี้ เรากำลังพูดถึง VisBug มันคืออะไร และแตกต่างจากอาร์เรย์ของตัวเลือกที่มีอยู่แล้วใน Chrome DevTools อย่างไร Drew McLellan พูดคุยกับผู้สร้าง Adam Argyle เพื่อหาคำตอบ
แสดงหมายเหตุ
- กล่องทราย VisBug และสนามเด็กเล่น
- อดัมบน Twitter
- เว็บไซต์ส่วนตัวของอดัม
- VisBug บน YouTube
- VisBug 101
อัพเดทประจำสัปดาห์
- แพลตฟอร์มการประชุมที่เราใช้สำหรับกิจกรรมออนไลน์ของเรา: Hopin โดย Amanda Annandale
- A Primer On CSS Container Queries โดย Stephanie Eckles
- รูปแบบการออกแบบที่น่าผิดหวังที่ต้องแก้ไข: Birthday Picker โดย Vitaly Friedman
- การเขย่าต้นไม้: คู่มืออ้างอิงโดย Átila Fassina
- เราปรับปรุง Core Web Vitals ของเราอย่างไรโดย Beau Harthorne
การถอดเสียง
Drew McLellan: เขาเป็นวิศวกรพังค์ที่สดใส หลงใหล และชื่นชอบเว็บ เขาชอบใช้ทักษะของเขาเพื่อ UI และ UX ที่ดีที่สุดในชั้นเรียน และส่งเสริมให้คนรอบข้างเขา เขาเคยทำงานในบริษัทขนาดเล็กและขนาดใหญ่ และปัจจุบันเป็นนักพัฒนาซอฟต์แวร์ที่ทำงานอยู่ที่ Google บน Chrome เขาเป็นสมาชิกของคณะทำงาน CSS และผู้สร้าง VisBug ซึ่งเป็นเครื่องมือแก้ไขข้อบกพร่องด้านการออกแบบ ดังนั้นเราจึงรู้ว่าเขารู้จักการออกแบบและ UX ของเขาเป็นอย่างดี แต่คุณรู้หรือไม่ว่าเขาเป็นเจ้าของรองเท้าแตะมากกว่าเท้าเปล่าทั่วไป เพื่อนที่ยอดเยี่ยมของฉัน ได้โปรดต้อนรับอดัม อาร์ไกล์ด้วย
อดัม อาร์ไกล์: สวัสดี
ดรูว์: สวัสดีอดัม สบายดีไหม
อดัม: โอ้ฉันยอดเยี่ยมมากคุณรู้ไหม
ดริว : ดีจังที่ได้ยิน วันนี้ฉันอยากจะคุยกับคุณเกี่ยวกับโปรเจ็กต์ของคุณ, VisBug, และโดยทั่วไป เกี่ยวกับแนวคิดเบื้องหลังการดีบักการออกแบบและวิธีที่มันอาจเข้ากับเวิร์กโฟลว์ของโปรเจ็กต์ ฉันหมายถึง เรามีเครื่องมือดีบักเบราว์เซอร์ที่เน้นนักพัฒนามาเป็นเวลานาน ฉันหมายความว่าตอนนี้น่าจะมากกว่าหนึ่งทศวรรษแล้ว แต่เห็นได้ชัดว่าสิ่งเหล่านี้เน้นที่โค้ดเป็นอย่างมาก VisBug แตกต่างกันอย่างไร? และปัญหาที่พยายามแก้ไขคืออะไร?
อดัม: ยอดเยี่ยม ใช่ ปัญหาหลักที่มันหยั่งรากลึกคือ ในฐานะวิศวกรส่วนหน้า ฉันทำงานกับนักออกแบบตลอดเวลา และฉันชอบช่วงเวลานี้เสมอที่เรานั่งลงและฉันก็แบบว่า "โอเค ฉันกำลังทำสัมผัสสุดท้าย เรามีเวลาอีกวันหรือสองวันจนกว่าเราจะปรับใช้ ดีไซเนอร์ นั่งลง แล้วคุณช่วยวิจารณ์เรื่องนี้ได้ไหม ฉันต้องการให้คุณเปิดเวอร์ชันโฮสต์ในพื้นที่ของฉันบนเบราว์เซอร์และบนโทรศัพท์ของคุณ หรืออะไรก็ตาม และพูดคุยกับฉันเกี่ยวกับสิ่งที่คุณเห็น”
อดัม: และหลังจากทำเช่นนี้มาหลายปีและชอบปฏิสัมพันธ์นี้เสมอ ฉันก็รู้สึกผิดหลังจากนั้นไม่นานเพราะงานธรรมดาและเรียบง่าย พวกเขาจะเป็นเหมือน “หนึ่งพิกเซลด้านล่างที่นี่ ระยะขอบห้าพิกเซลที่นี่” และมันก็มักจะเป็นตัวเหาและเขยิบเสมอ และตัวก็และตัวสะกิดเพื่อเว้นวรรคและพิมพ์ ฉันหมายถึง ไม่ค่อยจะเป็นแบบ "โอ้ ขอรอสักครู่ในขณะที่ฉันใช้เวลา 30 นาทีในการเปลี่ยนมุม หรืออะไรก็ตาม เพื่อปรับ DOM ของฉันเพื่อให้ DOM สามารถรองรับคำขอของคุณได้" หรืออะไรก็ตาม
อดัม: ปกติมันเป็นของเล็กๆ แล้วฉันก็ลงเอยด้วยการทำแบบสำรวจ และสำรวจนักออกแบบเหล่านี้ทั้งหมดที่ Google และฉันก็แบบ "เมื่อคุณเปิด DevTools คุณจะทำอย่างไร" และมันก็ดังมากที่พวกเขาแค่ต้องการพื้นฐาน และมันก็เกิดมาจากผมแบบว่า “น่าจะง่ายกว่านี้ คุณไม่จำเป็นต้องเปิดฝากระโปรงหน้ารถ Ferrari ขยับชิ้นส่วนของเครื่องยนต์เพียงเพื่อเปลี่ยนสีเบาะรถ นั่นไม่ยุติธรรม. คุณควรจะสามารถสัมผัสเบาะนั่งของรถและเปลี่ยนสีได้ เช่นเดียวกับเครื่องมือออกแบบ” ฉันชอบ "บางสิ่งบางอย่างสามารถอำนวยความสะดวกเวิร์กโฟลว์นี้" และฉันก็แบบ “ตกลง ฉันจะแฮ็คอะไรบางอย่างเพื่อดูว่าฉันจะสร้างวิธีแก้ปัญหาได้ไหม”
อดัม: และนั่นคือจุดเริ่มต้นทั้งหมด จริงๆมันเริ่มต้นด้วยการเว้นวรรคแล้วพิมพ์ และเมื่อฉันมีกลไกการเลือกที่เลียนแบบเครื่องมือออกแบบแล้ว มันก็เหมือนกับว่า "ฉันจะทำอะไรได้อีก" และมันก็ดำเนินต่อไปจากที่นั่น แต่ใช่ เกิดในช่วงเวลานั้น
Drew: ดังนั้น แนวคิดก็คือลูกค้าขอให้คุณทำโลโก้ให้ใหญ่ขึ้น และ VisBug ช่วยให้เบราว์เซอร์ทำงานเหมือนเครื่องมือออกแบบมากขึ้นสำหรับการปรับแต่งเหล่านั้น ใกล้เคียงกับบางอย่างเช่น Illustrator หรือ Photoshop หรือ Figma หรือสิ่งเหล่านี้
อดัม: ครับ กรณีการใช้งานนั้นเป็นสิ่งที่ดีเช่นกัน เนื่องจากคุณอาจเป็นลูกค้ารายหนึ่ง และพวกเขาพูดว่า "โอ้ เราชอบนี่" มันดูคลาสสิกมาก "เรารักการออกแบบ แต่สีฟ้านั้นยากสำหรับเรา" และคุณก็แบบ “จริงเหรอ” แบบว่าคนส่งแบบฟอร์มได้ แล้วทำเงินได้ แต่อยากคุยกับผมเรื่องสีฟ้าตอนนี้เลยไหม? และโดยปกติแล้วจะสร้างวงจรทั้งหมด นายกรัฐมนตรีจะพูดว่า “ตกลง เราจะลบคำขอของคุณ จากนั้นเราจะส่งไปที่การออกแบบ”
อดัม: แต่ถ้าดีไซเนอร์อยู่ที่นั่นและเบราว์เซอร์แสดงออกมา พวกเขาจะแบบว่า “โอเค ฉันจะคลิกที่สิ่งนั้นและเปลี่ยนสี” และคุณสามารถตัดวงจรการทำงานทั้งหมดได้เพียงแค่สร้างต้นแบบการเปลี่ยนแปลงในเบราว์เซอร์ ดังนั้นจึงเป็น มีประสิทธิภาพสูงสุดเมื่อเทียบกับผลิตภัณฑ์ที่มีอยู่แล้วใช่ไหม เพราะมันเป็นเครื่องมือแก้จุดบกพร่อง ไม่จำเป็นต้องเป็นเครื่องมือสร้าง มันไม่ได้สร้างเว็บไซต์ให้คุณ ได้ครับ แต่ค่อนข้างจะงงๆ
Drew: ในทางเทคนิคแล้ว มันเป็นส่วนขยายที่คุณติดตั้งในเบราว์เซอร์ Chrome นั่นถูกต้องใช่ไหม?
อดัม : ครับ และเป็นส่วนขยาย เมื่อคุณเปิดใช้งาน มันจะดาวน์โหลดไฟล์ JavaScript ที่ระบุว่า "นี่คือองค์ประกอบที่กำหนดเองที่เรียกว่า VisBug" จากนั้นคุณใส่องค์ประกอบ DOM, vis-bug บนหน้า แย่จัง ฉันแค่ใช้เวลานั้นแล้วเปลี่ยนมันเป็นแถบเครื่องมือ แล้วเริ่มฟังเหตุการณ์บนหน้า ฉันฟังเหตุการณ์ที่โฮเวอร์ของคุณ และฉันฟังเหตุการณ์การคลิกของคุณ และฉันพยายามอย่างเต็มที่เพื่อสกัดกั้นพวกเขา และไม่แข่งขันกับหน้าหลักของคุณ
อดัม: แต่ใช่ นั่นแหละคือแก่นแท้ของ... เหตุผลเดียวที่มันเป็นส่วนขยายก็คือเพื่อให้ง่ายต่อการวางบนเพจของคุณ แม้ว่า ณ จุดนี้จะมีการตั้งค่าบางอย่างที่มาพร้อมกับคุณในเบราว์เซอร์ต่างๆ แต่ยังคงเป็นส่วนใหญ่ 99.9% ซึ่งเป็นองค์ประกอบแบบกำหนดเองที่ไม่มีการขึ้นต่อกัน ฉันคิดว่าฉันชอบห้องสมุดสีที่ฉันใช้ และอย่างอื่นก็เป็นแค่วานิลลาทั้งหมด ใช่.
Drew: ฉันเดาว่านั่นเป็นวิธีที่ Firebug เริ่มต้นใช่ไหม เป็นส่วนขยายของ Firefox ในสมัยก่อน
อดัม : ครับ นั่นเป็นเหตุผลที่เรียกว่า VisBug มันได้รับแรงบันดาลใจจาก Firebug อย่างมาก แต่สำหรับนักออกแบบภาพ
ดริว : เอ่อ.. เราจะไปที่นั่น. ฉันหมายความว่า นี่อาจไม่ใช่รูปแบบในอุดมคติ การเป็นพอดคาสต์เสียง เพื่อพูดคุยเกี่ยวกับเครื่องมือภาพ แต่โปรดแจ้งให้เราทราบหากต้องการใช้เครื่องมือบางประเภทและตัวเลือกที่ VisBug มอบให้คุณ
อดัม: แน่นอน ดังนั้น สิ่งแรกที่ VisBug ทำ และคุณยังสามารถ ถ้าคุณอยู่ที่บ้านหรือที่คอมพิวเตอร์ คุณสามารถไปที่ visbug.web.app และลองใช้ VisBug โดยไม่มีส่วนขยาย ใช่ไหม
ดริว : เอ่อ..
อดัม: มันเป็นส่วนประกอบของเว็บ ดังนั้นฉันจึงโหลดหน้าเว็บให้คุณที่นี่ที่ visbug.web.app ซึ่งดูเหมือนว่าจะมีอาร์ตบอร์ดจำนวนมาก และแน่นอนว่า VisBug โหลดไว้ล่วงหน้าแล้ว และเป้าหมายของไซต์นี้คือให้คุณเล่น สำรวจ และลบ ฉันคิดว่าปุ่มลบเป็นหนึ่งในเครื่องมือที่น่าพึงพอใจที่สุดในการเริ่มต้น คุณชอบ "ฉันจะทำอะไรกับเพจได้บ้าง" และคุณก็แบบว่า “ฉันสามารถทำลายมันได้”
อดัม: และฉันสร้างมันขึ้นมาเพื่อให้คุณสามารถกด Delete ไว้ได้ มันจะเจอสิ่งต่อไป… ซึ่งค่อนข้างยากในการลบ คุณลบบางสิ่งและมันจะเลือกพี่น้องคนต่อไป มันจะเลือกพี่คนต่อไปตลอดไป หากคุณกดลบค้างไว้จนกว่าคุณจะลบทั้งหมด… ยังไงก็ตาม มันน่าพอใจมาก กดรีเฟรชและทุกอย่างกลับมา แต่เครื่องมือแรกที่ VisBug ส่งมาด้วย ดังนั้นเมื่อคุณเพิ่งเปิดตัว เป็นเครื่องมือแนะนำ และฉันเคยถือกระดาษไว้บนหน้าจออย่างแท้จริง ไม่เช่นนั้นฉันจะไปหาส่วนขยายระบบที่อนุญาตให้ฉันจัดเรียงสิ่งของต่างๆ และสร้างเส้นได้
อดัม: เพราะใช่ การจัดตำแหน่งจะชัดเจนมาก ณ จุดหนึ่งสำหรับนักออกแบบหลายคนใช่ไหม พวกเขาไม่ต้องการการจัดตำแหน่งทางคณิตศาสตร์ใช่ไหม? นี่คือเหตุผลที่วิชาการพิมพ์มีการจัดช่องไฟแบบออปติคัล มันไม่ใช่การจัดช่องไฟทางคณิตศาสตร์ นี่คือการจัดช่องไฟของมนุษย์ ดังนั้นเครื่องมือไกด์จึงมีรากฐานมาจากจุดเล็กๆ จำนวนมากที่เกิดขึ้นจากนักออกแบบกำลังซูมเข้าในสิ่งต่างๆ และตรวจสอบการจัดตำแหน่ง ระยะประชิดดีไหม?
อดัม: นั่นคือสิ่งที่สองที่เครื่องมือนำทางทำ เมื่อคุณเปิดมันและเพียงแค่วางเมาส์เหนือสิ่งของต่างๆ คุณจะเห็นองค์ประกอบที่คุณวางอยู่นั้นจะมีกล่องเล็กๆ ล้อมรอบ จากนั้นเส้นประจะปรากฏขึ้นเหมือนกับที่ผู้ปกครองมักทำ และเช่นเดียวกับใน Sketch และ Zeplin ที่คุณวางเมาส์ไว้และได้รับคำแนะนำเหล่านี้ มันเป็นแนวคิดเดียวกัน เพียงแค่แสดงอยู่บนเพจของคุณ และหากคุณคลิกอะไรบางอย่าง แล้วเลื่อนเมาส์ไปที่ปลายทางใหม่ คุณจะได้เครื่องมือวัด และเครื่องมือวัดอยู่ในหน่วยพิกเซล และคำนวณออกมาแล้ว... ดังนั้น ให้เห็นภาพว่ามีกี่พิกเซลระหว่างกัน ไม่ใช่สิ่งที่ใครพูด มันไม่ได้รวมการเว้นวรรคทั้งหมด แค่คุณคลิกสิ่งนี้ และมันอยู่ไกลจากกล่องอื่นนั้นมาก
อดัม: และฉันคิดว่านั่นจะมีประโยชน์จริงๆ เพราะคุณสามารถกด shift ค้างไว้แล้วคลิกต่อ และตรวจสอบว่าคุณมีระยะห่างเท่ากันระหว่างไอคอนห้าไอคอน และเพียงไม่กี่คลิก ไม่จำเป็นต้องรู้รหัส เพียงแค่เปิด VisBug โฮเวอร์ คลิก คลิก คลิก แล้วคุณจะเห็นว่า “โอ้ ดูสิ ใช่. 15 พิกเซลระหว่างแต่ละสิ่งเหล่านี้” หรือบางครั้งคุณได้รับสิ่งที่น่ารำคาญ คุณจะคลิกในกล่องแล้วคลิกกล่องหลัก และคุณจะรู้ว่า ระยะห่างบนสุดคือเก้า และด้านล่างเป็นแปด และคุณไป "ฉันจะจัดสิ่งนี้ได้อย่างไร มันเป็นอย่างใดในระหว่าง” และเขย่ากำปั้น
อดัม: แต่อย่างน้อย คุณก็สามารถเห็นมันได้ดีและง่ายดายด้วยเครื่องมือไกด์ ใช่แล้ว นั่นคือเครื่องมือนำทาง
ดรูว์: ฉันเคยไปที่นั่นมาแล้วโดยที่ถือกระดาษมาที่หน้าจอ และเคล็ดลับอื่นๆ ที่ฉันจะใช้คือเปิดหน้าต่างเบราว์เซอร์อื่นและใช้ขอบหน้าต่างเพื่อจัดแนวรายการ จากนั้นคุณพยายามเก็บทุกอย่างไว้ในที่ที่ถูกต้อง เพื่อที่เมื่อคุณเปลี่ยนโค้ดและรีเฟรช โค้ดทั้งหมดยังคงเข้าแถวอยู่ ใช่ ไม่ใช่วิธีการทำงานในอุดมคติ ดังนั้น
อดัม: ไม่ใช่วิธีการทำงานในอุดมคติ ใช่. และมีต่อไป… ดังนั้น โอ้ และรุ่นแรกของสิ่งนั้นก็หลวมมาก มันไม่ได้หัก แค่ยกเป้าขึ้นมา ซึ่งเป็นคุณลักษณะที่ฉันจะเพิ่มกลับเข้าไปในภายหลัง ผู้ใช้บางคนก็แบบว่า "ฉันชอบการหักมุม มันเหมือนกับเครื่องมือออกแบบของฉัน แต่ถ้าฉันต้องการการวัดแบบหลวมล่ะ? หรือฉันต้องการทำจดหมาย ฉันต้องการวัดตัวอักษร ไม่ใช่กล่องจดหมาย?” ดังนั้น เครื่องมือแนะนำนี้สามารถเปลี่ยนเป็นมีคีย์ตัวปรับแต่งได้ง่ายมาก
อดัม: ดังนั้นนี่คือจุดที่ VisBug มีความแตกต่างเล็กน้อย แต่ก็หวังว่าจะคุ้นเคยด้วย เพราะการปรับเปลี่ยนปุ่มลัดนั้นหนักมาก เช่นเดียวกับถ้าคุณดูนักออกแบบมืออาชีพ พวกเขาเข้าใจคีย์ลัดอย่างมาก และพวกเขากำลังกดปุ่มลัดที่นี่ ซูมเข้า กดปุ่มลัดที่นั่น และเพียงแค่สะกิดจากแป้นพิมพ์เท่านั้น ดังนั้น VisBug จึงมีคีย์บอร์ดเป็นศูนย์กลางในการเปลี่ยนแปลงสิ่งต่างๆ
อดัม: เป็นเพราะ VisBug อนุญาตให้เลือกได้หลายรายการ และสามารถเปลี่ยนระยะห่างของรายการได้ 100 รายการพร้อมกัน และมันก็ค่อนข้างจะเป็นเช่นนั้น อย่างไรก็ตาม มันมีนิสัยใจคอที่น่าสนใจสองสามอย่าง แต่คีย์บอร์ดในแนวคิดตัวปรับแต่งนั้นสำคัญมาก และคุณสามารถกด option หรือ shift หรือ command ในเครื่องมือต่างๆ มากมาย และรับสิ่งที่แตกต่างออกไป หรือรับฟีเจอร์ใหม่ๆ ในนั้น
Drew: ดังนั้นมันจึงเป็นหนึ่งในเครื่องมือที่คุ้มค่าจริงๆ ในการเรียนรู้แป้นพิมพ์ลัด
อดัม: มันเป็นเช่นนั้น ดังนั้นเมื่อคุณเปิด VisBug แล้ววางเมาส์เหนือไอคอนเครื่องมือใดไอคอนหนึ่ง คุณจะเห็นรายละเอียด มันแสดงเมนูลอยออกมาเล็กน้อย มันบอกว่าปุ่มลัดสำหรับเลือกเครื่องมือนี้ และบอกคุณว่ามันทำอะไรได้บ้าง และต้องโต้ตอบอะไรบ้างเพื่อให้ได้มา ดังนั้นเครื่องมือเส้นบอกแนวบอกว่า "เส้นบอกแนวองค์ประกอบ เพียงแค่วางเมาส์ไว้ วัดผลบางอย่าง คลิก แล้ววางเมาส์เหนือสิ่งใหม่ การวัดที่เหนียวเหนอะหนะเป็น shift บวกคลิก ดังนั้นมันจะคงอยู่”
อดัม: และคำแนะนำเหล่านี้ก็ดีมากเช่นกันสำหรับการจับภาพหน้าจอ ดังนั้น หากคุณกำลังตรวจสอบการประชาสัมพันธ์ แม้จะเป็นเพียงวิศวกรส่วนหน้า หรืออาจเป็นนักออกแบบที่กำลังตรวจสอบการประชาสัมพันธ์ นี่อาจเป็นวิธีที่มีประสิทธิภาพมากสำหรับคุณที่จะเข้าไปที่นั่น และใช่ มีการตรวจสอบที่มีความแม่นยำสูง ซึ่งจะนำเราไปสู่เครื่องมือต่อไป คุณต้องการทราบเกี่ยวกับเครื่องมือถัดไปหรือไม่?
ดริว : ใช่ แน่นอน ไปกันเถอะ
อดัม: ยอดเยี่ยม ต่อไปเป็นเครื่องมือตรวจสอบ และอันนี้ก็ประมาณว่า… โดยปกติแล้ว นักออกแบบจะไม่ต้องการ CSS ทั้งหมดใช่ไหม เมื่อพวกเขาคาดหวังกับ... ฉันเกือบจะพูดว่า Firebug แต่ Chrome DevTools คุณได้รับรายการทั้งหมดใช่ไหม ฉันเลือก H1 นี้ และนี่คือทุกอย่างจนถึงสไตล์ชีตของเบราว์เซอร์ และนักออกแบบก็ชอบ “เบราว์เซอร์อะไร? เบราว์เซอร์มีสไตล์ชีตหรือไม่”
Drew: ลงไปที่ด้านล่างของแผงเลื่อนที่มืดมน
อดัม: ก้นมืดใช่มั้ย?
ดริว : ครับ
อดัม: มันเหมือนกับว่าคุณลอกเลเยอร์ทั้งหมดกลับคืนมา แล้วคุณก็แบบ “โอ้ ฉันไม่ชอบเลเยอร์เหล่านี้แล้ว” และเครื่องมือตรวจสอบที่นี่ก็บอกว่า "โอ้ นักออกแบบ ฉันรู้ว่าคุณต้องการอะไร มันเป็นแค่สีเส้นขอบ” โดยพื้นฐานแล้ว แสดงบางสิ่งให้ฉันเห็นถ้ามันไม่ซ้ำกัน ดังนั้นอย่าคลุมฉันด้วยคุณสมบัติ CSS และฉันสนใจเรื่องสี การออกแบบตัวอักษร และระยะห่างเป็นส่วนใหญ่ ผมจะดูระยะขอบ ความสูงของบรรทัด ตระกูลฟอนต์สำคัญมาก จริงไหม? มีส่วนขยายทั้งหมดเพียงเพื่อบอกคุณว่าตระกูลฟอนต์คืออะไรบนหน้า
อดัม: ใน VisBug นั่นเป็นเพียงรายการโฆษณาในเครื่องมือตรวจสอบ ดังนั้นคุณเพียงแค่เปิด VisBug กดตรวจสอบ และเลื่อนเมาส์ไปที่รูปแบบตัวอักษรใด ๆ และมันจะบอกคุณถึงตระกูลแบบอักษร ใช่ มันพยายามทำให้ดีไซเนอร์จดจ่ออยู่กับสิ่งที่ปรากฏออกมา ใช่
Drew: เพื่อให้เครื่องมือนั้นไม่แสดงสไตล์ที่สืบทอดมา นั่นถูกต้องใช่ไหม?
อดัม: ถูกต้อง เว้นแต่จะสืบทอดมาและมีเอกลักษณ์เฉพาะตัว ดังนั้นหากพวกเขา... สีข้อความหรืออย่างอื่น ถ้าสีข้อความไม่ใช่คำที่สืบทอดตามตัวอักษร มันจะบอกคุณว่าเป็นค่าที่คำนวณได้ ว่าเป็นสิ่งที่น่าสนใจ
Drew: ใช่ มันมีประโยชน์มาก แค่… ใช่ ช่วยให้คุณจดจ่อกับสิ่งต่าง ๆ ที่นำไปใช้กับบางตัวอย่างได้อย่างแท้จริง ซึ่งชัดเจนว่าคุณต้องการเปลี่ยนแปลงอะไร ฉันหมายความว่า ฉันเดาว่ามันน่าจะมีประโยชน์จริงๆ เครื่องมือทั้งหมดเหล่านี้จะมีประโยชน์อย่างมากในประเภทที่คุณพูดถึง การได้รับคำติชมจากผู้มีส่วนได้ส่วนเสีย และการทำงานแบบโต้ตอบกับลูกค้า
Drew: ฉันเดาว่ามันน่าจะทำงานได้ดีพอๆ กับการแชร์หน้าจอ อย่างที่เราต้องทำในทุกวันนี้ มากขึ้นเรื่อยๆ คุณไม่จำเป็นต้องนั่งหน้าคอมพิวเตอร์กับใคร คุณสามารถนั่งอีกด้านหนึ่งของการสนทนาและแบ่งปันเบราว์เซอร์ของคุณแล้วทำแบบนั้นได้ ฉันเดาว่ามันน่าจะเป็นวิธีที่ได้ผลในการรับคำติชมเมื่อลูกค้าไม่สามารถชี้ไปที่หน้าจอและพูดว่า-
อดัม: แน่นอน
อดัม: มันวิเศษเสมอเมื่อคุณเปลี่ยนหน้าเว็บสดให้ดูเหมือนบอร์ดศิลปะ Zeplin มีคนแบบว่า “อะไรนะ… เราเพิ่งไปที่ใหม่ๆ มาหรือเปล่า” และคุณก็แบบ "ไม่ นี่คือผลิตภัณฑ์ของคุณ เราแค่โต้ตอบกับมันด้วยภาพเท่านั้น” ใช่มันสามารถดีจริงๆ
Drew: มีกรณีการใช้งานที่น่าสนใจอื่น ๆ ที่คุณเคยเห็น VisBug นำเสนอหรือเกิดขึ้นกับคุณหรือไม่?
อดัม: ครับ ใช่ มีหลายอย่างที่ยากต่อการเริ่ม โอ้ สิ่งที่สำคัญอย่างหนึ่งคือ Developer กับ Developer Communication VisBug ทำงานบนค่าที่คำนวณได้ จึงไม่ดูที่ค่าที่คุณเขียน และนั่นก็เป็นเรื่องที่ดีมาก เพราะคุณกำลังวัดและตรวจสอบผลลัพธ์สุดท้ายแบบสัมบูรณ์ ด้วยวิธีการคำนวณพิกเซลบนหน้าจอ และนั่นก็เป็นเรื่องที่ดีจริงๆ ที่ได้พูดคุยกันในแบบนั้น ในขณะที่คุณกำลังทำงานกับผลลัพธ์ แทนที่จะเป็นด้านการเขียน
อดัม: และคุณสามารถกลับไปเป็นแบบ "เอาล่ะ เราผิดพลาดในด้านการเขียนได้อย่างไร ถ้านี่คือสิ่งที่เราเห็น" เครื่องมือประเภทต่อไปคือเครื่องมือตรวจสอบการช่วยสำหรับการเข้าถึง ดังนั้นเครื่องมือตรวจสอบจึงทำให้การดูสไตล์ในองค์ประกอบเป็นเรื่องง่าย และแยกย่อยในลักษณะที่เป็นมิตรกับนักออกแบบ เครื่องมือการช่วยสำหรับการเข้าถึงช่วยให้คุณตรวจสอบองค์ประกอบทั้งหมดบนหน้า และแสดงคุณสมบัติที่สามารถเข้าถึงได้ ซึ่งทำให้ฉันหวังว่าจะสามารถตรวจสอบว่าบางสิ่งเสร็จสิ้นแล้วได้ง่ายขึ้น
อดัม: ดังนั้นการประชาสัมพันธ์… และสิ่งต่าง ๆ มักจะถูกสร้างขึ้น นี่คืออีกครั้ง ระหว่างนักพัฒนากับนักพัฒนา นักพัฒนานักออกแบบ คุณกำลังตรวจสอบอินเทอร์เฟซ มันสำคัญมาก หากคุณกำลังดูอินเทอร์เฟซและคุณอยากรู้ VisBug มีกรณีการใช้งานสำหรับคุณที่นั่น นอกจากนี้ยังมีกรณีการใช้งานที่คุณสามารถจัดเรียงต้นแบบในเบราว์เซอร์ได้ เราก็เลยคุยกันว่า ลูกค้าอยากลองสีฟ้า โอเค นั่นเป็นสถานการณ์ที่ค่อนข้างง่าย
อดัม: แต่ก็มีคนอื่นด้วย หากคุณกดคำสั่ง D บน VisBug คุณจะทำซ้ำองค์ประกอบ และไม่สนใจสิ่งที่คุณกำลังทำซ้ำ ดังนั้น คุณสามารถทำซ้ำส่วนหัว เพิ่มระยะห่างระหว่างส่วนหัวทั้งสอง และทำให้ตัวแปรใช้งานได้จริงในเบราว์เซอร์ คุณคลิกสองครั้งที่ข้อความส่วนหัวและข้อความนั้นจะกลายเป็นช่องข้อความที่แก้ไขได้ จากนั้นคุณลองใช้หัวข้อใหม่และไปดูว่าหัวเรื่องนั้นพอดีอย่างไร ไปปรับการเว้นวรรค และคุณเพิ่งช่วยตัวเองทำงานของนักพัฒนาซอฟต์แวร์ ค้นหาไฟล์ต้นฉบับและสิ่งต่างๆ เหล่านั้น และคุณก็แค่...
อดัม: ใช่ มันสามารถช่วยให้คุณสำรวจและตรวจสอบได้ มันค่อนข้างแปลก… ฉันหมายถึง มีหลายอย่างที่ DevTools ทำใช่ไหม มันเข้ามาหลังจากที่คุณทำเสร็จแล้ว จริง ๆ แล้วมันไม่ได้ให้ซอร์สโค้ดแก่คุณบ่อยนัก ไม่บ่อยนักที่คุณจะคัดลอกโค้ดจาก DevTools คุณอาจคัดลอกคู่ค่าคีย์ เช่น “โอ้ ฉันเปลี่ยนรูปแบบนี้แล้ว” แต่ใช่แล้วล่ะ
ดรูว์: อืม อืม (ยืนยัน) ใช่. ฉันสามารถนึกถึงกรณีพิเศษที่มองเห็นได้ซึ่งคุณอาจต้องการ คุณพูดถึง ทำซ้ำรายการ คุณอาจต้องการใช้ทั้งส่วนของหน้าและทำซ้ำเพื่อจำลองว่าจะเป็นอย่างไรหากมีเนื้อหามากกว่าที่คุณคาดไว้
อดัม: ครับ นั่นคือกรณีการใช้งานการทดสอบความโกลาหล
ดริว : ครับ
อดัม: แน่นอน
Drew: สิ่งที่เราทุกคนต้องเผชิญ คือการออกแบบระบบที่ใช้ CMS และงานสนุก ๆ เหล่านั้น
อดัม: ใช่ นั่นเป็นกรณีการใช้งานที่สำคัญจริงๆ เช่นกัน เพราะฉันทำอย่างนั้นเพื่อ… ใช่ พาดหัวข่าวอย่างที่ฉันพูด คุณเพียงแค่ดับเบิลคลิกที่ข้อความและฉันก็ไปกระแทกคีย์บอร์ด บลา บลา บลา บลา และชนช่องว่าง บลา บลา และฉันก็แบบ “โอเค เลย์เอาต์เป็นยังไงบ้าง? โอ้ มันทำได้ดี โอเค ดี ฉันสามารถไปยังสิ่งต่อไปได้ จะเกิดอะไรขึ้นหากฉันทำซ้ำสี่ครั้ง ยังมีช่องว่างระหว่างทุกสิ่งหรือไม่? มันไหลถัดจากรายการถัดไปหรือไม่”
อดัม: มันอาจจะดีมากสำหรับการจำลองความโกลาหลของเนื้อหาใช่ ชื่อเรื่องสั้นจริงๆ ชื่อเรื่องยาวจริงๆ ไม่มีเพื่อน มีเพื่อนเป็นล้าน คุณจัดการกับกรณีการใช้งานเหล่านี้ใน UI อย่างไร ใช่.
Drew: ดังนั้นจึงใช้งานได้กับเนื้อหาบนเบราว์เซอร์ ดังนั้น กปปส. เช่นเดียวกับหน้าเว็บทั่วไป?
อดัม: ใช่ มันเป็นเช่นนั้น ดังนั้น หากคุณได้ติดตั้ง Spotify ฉันทำเช่นนี้ตลอดเวลา ฉันติดตั้ง Spotify แล้ว และฉันจะแบบว่า "Spotify คุณดูเหมือนเป็นแอปที่ตรวจสอบไม่ได้" แต่เดาอะไร? VisBug ไม่สนใจ VisBug ซ้อนทับข้อมูลทั้งหมดของคุณ ตรวจสอบตัวพิมพ์ทั้งหมด ฉันสร้างธีมสว่างสำหรับ… โอ้ ฉันมีทวีตอยู่ที่ไหนสักแห่งที่ฉันสร้างธีมสว่างของ Spotify
อดัม: โอ้ นี่เป็นกรณีการใช้งานอื่น ขออภัยสำหรับการสร้างต้นแบบสี ฉันสามารถสร้างธีมสีสว่างบนผลิตภัณฑ์ได้เองโดยไม่ต้องไปยุ่งกับแผ่นสติกเกอร์จำนวนมากใช่ไหม มีความคิดที่สำคัญเช่นนี้ ฉันชอบ VisBug เพื่อช่วยให้ผู้คนเข้าถึง นั่นคือ ใช้ผลิตภัณฑ์ของคุณเป็นสนามเด็กเล่น ใช้สิ่งนั้นเป็น... มันเป็นของจริงมาก มีความสมจริงมากกว่าการออกแบบของคุณเสียอีก ดังนั้นจงใช้เวลาอยู่ที่นั่นมากขึ้น ฉันคิดว่าคุณจะพบว่าคุณสามารถตัดสินใจในการออกแบบที่มีประสิทธิภาพมากขึ้นในการทำงานกับผลิตภัณฑ์จริงของคุณ
Drew: และกรณีของการช่วยสำหรับการเข้าถึงก็น่าสนใจเป็นพิเศษ เพราะบ่อยครั้ง โดยเฉพาะอย่างยิ่งในทุกวันนี้ เรากำลังดำเนินการอย่างมากในไลบรารีส่วนประกอบ และดูส่วนประกอบเล็กๆ ของเพจ และใช้เวลาน้อยลงในการดูสิ่งเหล่านั้นที่รวมเข้าด้วยกันเพื่อสร้างมุมมองที่ลูกค้าโต้ตอบด้วยจริงๆ และเป็นเรื่องยากมากที่จะจับตาดูรายละเอียดปลีกย่อยเหล่านั้น เช่น สิ่งอำนวยความสะดวกในการเข้าถึง คุณลักษณะ ที่ไม่ปรากฏบนหน้า
Drew: การจับตาดูสิ่งที่มองไม่เห็นเป็นเรื่องยากมาก ดังนั้นนี่คือจุดที่เครื่องมือสามารถช่วยในการตรวจสอบบางสิ่งบางอย่างได้จริงๆ และเห็นว่าใช่ มันมีบทบาทที่ถูกต้องกับมัน และมัน-
อดัม: มันเป็นเช่นนั้น นั่นคือกรณีการใช้งานที่แน่นอน ฉันต้องการให้ PM ไปตรวจสอบสิ่งนี้ได้ ฉันต้องการให้นักออกแบบสามารถดูการช่วยสำหรับการเข้าถึงและไม่ต้องเปิดเครื่องมือขึ้นมา ค้นหาโหนด DOM มันถูกบีบอัดไว้ในแผงองค์ประกอบและดูแปลก ๆ ที่มันบอกว่า "นี่คือแอตทริบิวต์ของพื้นที่ นี่คือชื่อถ้ามี" นอกจากนี้ยังมีเครื่องมือช่วยการเข้าถึงอื่นๆ VisBug มาพร้อมกับไอคอนค้นหา ไอคอนค้นหามีหลายวิธีในการโต้ตอบกับมัน
อดัม: อันดับแรกเลย ให้ค้นหาหน้าเว็บ ดังนั้นหากคุณทราบประเภทองค์ประกอบหรือชื่อคลาสขององค์ประกอบที่คุณต้องการ คุณก็ค้นหาได้ ดังนั้นคุณจึงไม่ต้องค้นหาด้วยเมาส์ แต่นั่นก็มีคำสั่งทับอยู่ด้วย ดังนั้นจึงมีปลั๊กอินใน VisBug และพวกมันจะรันสคริปต์บนหน้า ดังนั้นหากคุณเคยมีบุ๊กมาร์กที่คุณบันทึกไว้สามหรือสี่... คุณชอบ "ฉันจะใช้อันนี้เพราะมันเน้นเส้นขอบทั้งหมดและแสดงกล่องของฉัน" มันเหมือนกับเคล็ดลับการดีบักหรืออะไรทำนองนั้น
อดัม: น่าจะเป็นปลั๊กอิน VisBug ดังนั้นคุณจึงเปิด VisBug กดสแลช และคุณจะได้รับการเติมข้อความอัตโนมัติ และจะแสดงปลั๊กอินต่างๆ ทั้งหมดให้คุณเห็น และมีบางอย่างที่ช่วยในการเข้าถึงซึ่งดีมากที่มีข้อผิดพลาดในการซ้อนทับ และสิ่งต่างๆ เช่นนั้น ดังนั้นฉันจึงเห็นด้วย การเข้าถึงควรสามารถเข้าถึงได้มากขึ้น นั่นเป็นเพียงง่อยที่จะพูด แต่ต้องอยู่ใกล้สายพานเครื่องมือมากขึ้น และฉันคิดว่าบางครั้งมันก็อยู่ไกลเกินไป และนั่นอาจเป็นสาเหตุว่าทำไมมันถึงพลาด ดังนั้นฉันหวังว่าถ้ามันอยู่ข้างหน้าและตรงกลางและง่ายกว่าที่จะได้รับการตรวจสอบมากขึ้น ใช่.
Drew: และมันน่าสนใจที่คุณพูดว่า VisBug ทำงานกับการเรียงลำดับของค่าที่คำนวณได้ของสิ่งต่าง ๆ เช่นเดียวกับสี นั่นหมายความว่าถ้าคุณมีองค์ประกอบหลายชั้นที่มีระดับความทึบต่างกัน คุณจะสามารถวัดสีที่แน่นอนที่แสดงบนหน้าจอมากกว่า
อดัม : โอ้
Drew: … มองไปที่องค์ประกอบแต่ละอย่างและพยายามทำให้มันออกมาดี?
อดัม: นั่นเป็นคำถามที่ดีจริงๆ ดังนั้น ฉันคิดว่าถ้าฉันเข้าใจคำถามถูกต้อง ซึ่งนี่เป็นความยากแบบคลาสสิกที่ส่วนหน้าคือ ใช่ คุณจะรู้ได้อย่างไรว่าคุณมีข้อความกึ่งโปร่งแสง สีเทากับสีขาวเป็นสีอะไร ? และคุณรู้ได้อย่างไรว่าความคมชัดของมัน? ตอนนี้เราไม่รู้ ดังนั้น VisBug จึงรู้จักสี และจะพูดว่า “สีเทา 50%” หรือสีใดก็ตามที่คุณมี แต่มันไม่รู้ว่ามีอะไรฉลาดไปกว่านั้น มันไม่สามารถ…
อดัม: ฉันคิดว่าสิ่งที่คุณต้องทำในกรณีนี้คือสร้างผืนผ้าใบ ทาสีเลเยอร์ทั้งหมดที่นั่น แล้วใช้หลอดดูดหยดหรือ... ดังนั้น คุณจะเรนเดอร์มันในแคนวาส ทำให้พวกเขาทุบรวมกันเป็น เลเยอร์ที่ทาสีเพียงชั้นเดียว แล้วดึงค่าพิกเซลเดียวออกเพื่อดูว่าสีเทาที่คำนวณเสร็จแล้วจริง ๆ แล้วเป็นสีเทาหลังจากวางเลเยอร์บนสิ่งอื่นแล้ว
อดัม: ฉันคิดว่ามีคนระบุหรือบางทีฉันอาจมีปัญหา GitHub ว่ามันคงจะดี เนื่องจาก VisBug สามารถอำนวยความสะดวกนี้ได้ 100% เบื้องหลังของ VisBug ฉันได้ทำการวัดข้อความเสร็จแล้ว ซึ่งคุณสามารถวางเมาส์เหนือสิ่งต่าง ๆ และให้ข้อมูลบ้าๆ เกี่ยวกับแบบอักษรแก่คุณ ข้อมูลเกือบจะมากเกินไป เช่น ความสูง x และความสูงของฝา แต่มันมีอะไรมากกว่านั้น และมันก็เหมือนกับว่า “โอ้ ฉันถูกปิดตัวไปเมื่อถึงจุดหนึ่ง” ดังนั้นฉันต้องหาวิธีหาสัญญาณกับสัญญาณรบกวนที่นั่น
อดัม: แต่ใช่ ฉันชอบกระบวนการคิดนี้ เพราะเราควรมีเครื่องมือที่ทำแบบนั้น และถ้าเรารู้วิธีคำนวณ เราสามารถสอนให้ VisBug ทำสิ่งนั้นได้ และนั่นจะเป็นคุณสมบัติที่ยอดเยี่ยมมากที่จะมี สีที่คำนวณได้ที่เกี่ยวข้องกับความทึบ รักมัน
Drew: ใช่ ฉันหมายถึง มันเป็นกรณีมาตรฐานที่มีข้อความตัดกับพื้นหลัง ซึ่งคุณไม่แน่ใจว่าคอนทราสต์เพียงพอที่จะผ่านข้อกำหนดการช่วยสำหรับการเข้าถึงหรือไม่ และบางทีอาจไม่ใช่ บางทีอาจเป็นคอนทราสต์ต่ำเกินไป และคุณต้องการปรับแต่งค่าจนกว่าคุณจะได้มันถึงจุดที่คอนทราสต์ดี แต่ก็ไม่ได้ห่างไกลจากสิ่งที่ลูกค้าต้องการในตอนแรกในแง่ของสีสันของแบรนด์มากเกินไป และสิ่งของต่างๆ
อดัม: ฉันเรียกสิ่งนั้นว่ากระแทกจนกว่าคุณจะผ่าน
ดริว : ครับ
อดัม: เพราะนั่นคือสิ่งที่รู้สึก ฉันชอบ "โอ้ ฉันคะแนนน้อยไปนิด" ดังนั้นมันเหมือนกับว่า ฉันจะไปที่ความสว่าง HSL ของฉัน และฉันจะชน กระแทก กระแทก และดูตัวเลขเล็กๆ น้อยๆ จนกว่าจะขึ้นว่า “ติง” ฉันได้เครื่องหมายถูกสีเขียว ฉันชอบ "โอเค เจ๋ง" และใช่ บางครั้ง สีนั้นบางสีก็ไม่เท่ คุณได้ศึกษางานการช่วยสำหรับการเข้าถึงการรับรู้ 3.0 ที่กำลังดำเนินการอยู่หรือไม่? เพื่อที่เราจะไม่มี AA หรือ AAA อีกต่อไป เราจะมีตัวเลขและรวมถึงสิ่งต่างๆ เช่น ความบางของแบบอักษร ดังนั้นหากเป็นฟอนต์แบบบาง ก็จะได้คะแนนต่ำกว่า หากเป็นฟอนต์แบบหนาก็จะมีผล... เพราะมีหลายอย่างที่ตัดกัน
ดรูว์: ใช่ ไม่ ฉันไม่เคยเห็นสิ่งนั้นเลย แต่นั่นฟังดู-
อดัม: อย่างไรก็ตาม การสำรวจเป็นสิ่งที่เจ๋งจริงๆ
Drew: นั่นฟังดูน่าสนใจใช่ ฉันจะต้องหาคนคุยเรื่องนั้น นั่นเป็นอีกตอนหนึ่ง ฉันหมายความว่า ฉันแน่ใจว่านักพัฒนาบางคนอาจโต้แย้งว่าทุกสิ่งที่ VisBug กำลังทำ คุณสามารถทำได้ผ่านแผง CSS ใน DevTools และฉันคิดว่าเป็นเรื่องที่ยุติธรรม แต่อาจพลาดประเด็นนั้นไป ใช่ คุณกำลังจัดการ CSS เมื่อคุณทำการเปลี่ยนแปลง แต่มันวางอินเทอร์เฟซผู้ใช้ที่เน้นการออกแบบไว้ด้านบน แทนที่จะเป็นอินเทอร์เฟซที่เน้นนักพัฒนา นั่นเป็นลักษณะที่ยุติธรรมของมันหรือไม่?
อดัม: นั่นเป็นสิ่งที่ยุติธรรมจริงๆ และตามจริงแล้ว แนวคิดที่ดีที่สุดจะย้ายออกจาก VisBug ไปสู่ DevTools และพวกเขามีอยู่แล้ว ดังนั้น VisBug หากคุณกดตัวเลือกคำสั่ง C บนองค์ประกอบใด ๆ มันต้องใช้สไตล์การคำนวณทุกรูปแบบ อย่างน้อยก็มีเอกลักษณ์เฉพาะตัว เหมือนเดิม เหมือนกับว่า เราจะทำสิ่งที่เราไม่ได้ให้คุณสมบัติที่สืบทอดมาทั้งหมดเหล่านี้แก่คุณ แต่ใส่ทั้งหมดไว้ในคลิปบอร์ดของคุณ และคุณสามารถไปวางรูปแบบนั้นที่อื่น ในสไตล์ชีต ใน CodePen และสร้างองค์ประกอบขึ้นใหม่ได้อย่างแท้จริงด้วยการคลิกเพียงไม่กี่ครั้ง
อดัม: และการโต้ตอบเหล่านั้นได้เข้าสู่ DevTools ลงในแผงองค์ประกอบนั้น อย่างไรก็ตาม ยังมีอย่างอื่นที่ยังไม่มี กล่าวคือ DevTools เป็นเครื่องมือตรวจสอบโหนดเดียวเท่านั้น และ VisBug ปฏิบัติตามมนต์เครื่องมือออกแบบ ซึ่งก็คือ ไม่ ฉันควรจะสามารถเลือกได้หลายแบบ ฉันต้องสามารถแก้ไขเป็นกลุ่ม ตรวจสอบเป็นกลุ่มได้ ดังนั้นฉันจึงใช้ VisBug ตลอดเวลาสำหรับการเว้นวรรค เพราะฉันสามารถเน้นองค์ประกอบหลายอย่างและเห็นการยุบตัวของระยะขอบ
อดัม: ใน DevTools คุณไม่สามารถมองเห็นมันได้ เพราะคุณสามารถเห็นได้ครั้งละหนึ่งโหนดเกือบตลอดเวลา แม้ว่าจะมีวิธีแสดงระยะขอบหลายจุด แต่ก็ไม่เหมือนกัน ใช่แล้ว มันมีกรณีการใช้งานเฉพาะกลุ่มที่สามารถสนุกได้อย่างนั้นจริงๆ อีกอย่างหนึ่งคือ ถ้าคุณเน้น a... สมมติว่าคุณมีระบบการพิมพ์และคุณมี H1 ถึง H7 เช่นเดียวกับในหนังสือนิทานหรืออะไรทำนองนั้น คุณสามารถไฮไลต์ทั้งหมดได้ใน VisBug กด shift ค้างไว้ เพียงคลิกทั้งหมด โบ๊ท โบ๊ท โบ๊พ โบ๊พ ไปที่เครื่องมือพิมพ์แล้วกดขึ้นหรือลง และทำการเปลี่ยนแปลงที่เกี่ยวข้องกับแต่ละรายการ
อดัม: ดังนั้นแต่ละคนจะเขยิบขึ้นหนึ่งหรือลงหนึ่งอัน และนั่นไม่ใช่สิ่งที่ DevTools ทำได้ง่ายมาก ใช่ มันมีพลังพิเศษบางอย่างแบบนั้น เพราะมันไม่เชื่อเรื่องพระเจ้ามากกว่า และพร้อมที่จะวนซ้ำในอาร์เรย์เสมอ ใช่.
Drew: ที่มาของ VisBug คืออะไร? และตอนนี้มันเป็นเพียงโครงการส่วนตัวหรือไม่? หรือเป็นโครงการของ Google? หรือสถานะมันคืออะไร?
อดัม: ครับ ก่อนอื่น สถานะคือ เป็นโครงการของ Google เป้าหมายหลักคือการเป็นสถานที่สำหรับสร้างต้นแบบและสำรวจก่อนที่สิ่งต่างๆ จะเข้าสู่ DevTools อย่างน้อยก็จากด้าน Google ของสิ่งต่าง ๆ แต่จากด้านส่วนตัวของฉัน ฉันยังคงมองว่ามันเป็นที่สำหรับทำขนมในงานทั่วไป หรืออบในการเพิ่มประสิทธิภาพบางอย่างเพื่อทำงานทั่วไป และเพียงเพื่อให้ผู้ชมมีวิธีการมองเข้าไปใน DOM ได้กว้างขึ้น
อดัม: ฉันคิดว่า DevTools นั้นทรงพลังมาก แต่ก็น่ากลัวมาก เพียงแท็บเดียวก็สามารถเรียนรู้อาชีพได้ ฉันยังคงเรียนรู้สิ่งต่างๆ ใน DevTools และใช้งานตลอดเวลา ใช่แล้ว นี่เป็นผู้ชมที่แตกต่างกันในบางแง่มุม มันเป็นมากกว่าของผู้เริ่มต้น คนที่เข้ามา หรือแม้กระทั่งคนอย่าง PMs ผู้จัดการ ที่ไม่เคยตั้งใจเขียนโค้ดแต่สนใจในผลลัพธ์ ดังนั้นมันจึงทำให้พวกเขา ใช่ แค่เครื่องมือเบา ๆ เพื่อเข้าไปที่นั่น
ดรูว์: เป็นจุดที่น่าสนใจที่คุณพูดถึง เพราะโดยส่วนตัวแล้วฉันมักจะพบว่าฉันประสบปัญหาในการหาขั้นตอนการทำงานที่สะดวกสบายในการจัดการ DevTools ทุกประเภท และคุณมีแผงหน้าต่างเล็กๆ ที่ดูอึดอัดทั้งหมด และคุณสามารถแยกมันเข้ากับหน้าต่างอื่นได้ แต่คุณต้องคอยติดตามหน้าต่างสองบานที่แตกต่างกัน และเมื่อคุณเปิดหน้าต่างเบราว์เซอร์สองสามบานแล้ว คุณจะไม่สามารถ... คุณโฟกัสไปที่หน้าต่างใดบานหนึ่งและคุณไม่รู้ว่า DevTools ใดเป็นของมัน
ดรูว์: และภายในพาเนลนั้นเอง มันเป็นแบบแผนของส่วนต่อประสานผู้ใช้แบบ Wild West คุณจะเลื่อนดูและสิ่งต่าง ๆ จะเริ่มทำสิ่งแปลก ๆ ที่คุณไม่คาดคิด และในแง่ของประสบการณ์ผู้ใช้ ฉันรู้สึกว่าทุกอย่างมันยุ่งเหยิงไปหมด
อดัม: นั่นสินะ ใช่.
Drew: คุณคิดว่ามันหลีกเลี่ยงไม่ได้เหรอ? จะดีกว่าไหม?
อดัม: ฉันมีความคิดที่นี่อย่างแน่นอน และใช่ ฉันคิดว่าดี… สมมติว่าคุณมีผู้ฟังในตอนนี้ แบบว่า “ฉันค่อนข้างจะเข้าใจเกี่ยวกับ DevTools ฉันไม่คิดว่าพวกเขาจะบ้าขนาดนั้น” ฉันจะพูดว่า “โอเค ไปเปิด Android Studio หรือ Xcode เริ่มโครงการ และดู DevTools ดูที่ผลลัพธ์ ตอนนี้คุณรู้สึกคุ้นเคยแค่ไหน” น่าจะต่างชาติมาก คุณกำลังมองว่า "นี่คือขยะ ทำไมพวกเขาถึงทำเช่นนี้? ทำไมแผงนี้ถึงอยู่ที่นี่?” และจิตใจของคุณก็เริ่มแข่งกับคำถามเหล่านี้ว่าทำไมและความสับสน
อดัม: และทุกคนก็รู้สึกแบบนั้นเมื่อเปิด DevTools เป็นครั้งแรก ดังนั้นคุณต้องเห็นอกเห็นใจกับสิ่งนั้นจริงๆ
Drew: หลีกเลี่ยงไม่ได้หรือว่า… เราทำได้ดีกว่านี้ไหม? หรือนี่เป็นเพียงการเรียงลำดับของสิ่งต่าง ๆ ตามธรรมชาติ?
อดัม: นี่คือสิ่งที่ฉันคิดในตอนนี้ คือฉันคิดว่าความซับซ้อนนั้นง่ายมากที่จะพบว่าตัวเองเข้าไปยุ่ง และ DevTools ก็เป็นหนึ่งในนั้น พวกมันซับซ้อนโดยธรรมชาติ ไม่มี UI ที่ดีที่จะอำนวยความสะดวกในสิ่งเหล่านี้มากมาย หลายสิ่งหลายอย่างเหล่านี้สร้างขึ้นโดยนักพัฒนาซอฟต์แวร์ และฉันคิดว่า devs building tools สำหรับ devs นั้นใช้ได้ เพราะคุณจะต้องมี... หากมันเป็นทางเดียว หรือแม้ว่ามันจะเป็นวิธีที่ดี คุณจะได้เรียนรู้มัน และคุณจะเก่ง แล้วคุณจะสบายใจกับมัน
อดัม: และ DevTools ทั้งหมดนั้นค่อนข้างแปลก เพราะมันถูกสร้างขึ้นมาสำหรับกรณีการใช้งานที่แปลกประหลาดใช่ไหม พัฒนาการเป็นเรื่องแปลก ขอเพียงแค่มีความซื่อสัตย์ เราสร้างฟันเฟืองที่มองไม่เห็นและล่องหนทีละสี่ส่วน และเราสร้างบ้านโดยพื้นฐานแล้ว ด้วยชิ้นส่วนเสมือนที่มองไม่เห็น ใช่แล้ว เราต้องการเครื่องมือแปลกๆ เพื่อตรวจสอบสิ่งเหล่านี้ และเพื่อบอกเราว่าพวกเขากำลังส่งออกอะไร
อดัม: อย่างที่พูดไปแล้ว สิ่งที่ VisBug ทำ และสิ่งที่ฉันค่อยๆ เคลื่อนสิ่งต่างๆ เข้าสู่ DevTools ก็คือเครื่องมือขนาดเล็กที่เน้นมากกว่าเครื่องมือขนาดใหญ่ที่อ้างว่าทำสิ่งต่างๆ ได้มาก ฉันคิดว่ามันยากสำหรับหลายๆ อย่างที่จะทำได้ดีจริงๆ และนี่คือข้อโต้แย้งแบบคลาสสิกใช่ไหม นี่คือดาราทั้งหมด ผู้เชี่ยวชาญกับผู้ทั่วไป ไม่มีอะไรสมบูรณ์แบบเสมอไป
อดัม: แต่สิ่งที่ VisBug พยายามทำคือทำให้ผู้เชี่ยวชาญ ดังนั้นเครื่องมือไกด์จึงเป็นเพียงไกด์เท่านั้น และเครื่องมือนั้นจะไม่รั่วไหลไปยังเครื่องมืออื่นๆ ของหน้า ดังนั้นฉันจึงพยายามทำสิ่งนั้นให้มากขึ้นด้วย DevTools ซึ่ง DevTools ต้องการช่วยนักออกแบบมากขึ้น ซึ่งเป็นสิ่งที่ VisBug ได้ช่วยสร้างแรงบันดาลใจให้ DevTools ได้เห็น และวิธีที่ฉันแนะนำสิ่งต่างๆ ต่อไปคือ แทนที่จะสร้างตัวแก้ไขกริด ที่ซึ่งคุณสามารถ… “พลังทั้งหมดของกริดในการซ้อนทับเดียว” ใช่ไหม “คุณสามารถเพิ่มแทร็ก ลบแทร็ก บลา บลา บลา”
อดัม: และฉันก็แบบ “ฟังดูเจ๋งและซับซ้อนจริงๆ ด้วย” 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. ดังนั้น…
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.
อดัม: ฉันมีม็อดเมื่อคุณเปิด VisBug จะใช้เอกสาร HTML ทั้งหมดและย่อลงในอาร์ตบอร์ด ดูเหมือนอาร์ตบอร์ด มันลอยอยู่บนเงาบนพื้นที่สีเทา คุณสามารถเลื่อนไปรอบๆ ได้ไม่จำกัด คุณจึงสามารถเลื่อนออกจากพื้นที่หน้าของคุณได้ และสิ่งที่คุณทำได้คือ ดู สมมติว่าคุณมีหน้าที่ยาวมาก และคุณต้องการวัดบางอย่างจากบนลงล่าง คุณก็ทำได้ในตอนนี้ แต่คุณจะสูญเสียบริบทไปบ้าง
อดัม: ในสถานการณ์สมมติการซูมแบบใหม่ของ VisBug คุณกดตัวเลือกหรือ alt บนแป้นพิมพ์ คุณใช้วงล้อเมาส์ หรือกดบวกลบด้วยคำสั่งของคุณ และคุณสามารถซูมหน้าเว็บของคุณราวกับว่าเป็นอาร์ตบอร์ด และฉันพยายามทำให้มันราบรื่นอย่างที่มันเป็น ดังนั้นคุณจะเข้าและออก และคุณเลื่อนลง คุณเข้าและออก วัดจาก... และ VisBug ก็ไม่สนใจ มันยังคงวาดภาพซ้อนทับที่คำนวณได้ คุณสามารถเปลี่ยนระยะห่างได้
อดัม: เพราะฉันคิดว่ามันสำคัญมากในฐานะนักออกแบบที่จะเห็นตานกในหน้าของคุณแบบสด แอนิเมชั่นยังเล่นอยู่นะ พื้นที่ที่เลื่อนได้ยังคงเลื่อนได้ใช่ไหม มันเจ๋งจริงๆ. คุณชอบ "ทั้งหน้าของฉันในมุมมองเดียว" อย่างไรก็ตาม มันเกือบจะเสร็จแล้ว มันอยู่ใน-
Drew: ฟังดูแย่จัง
อดัม: มันแย่มาก ฉันต้องแน่ใจว่ามันทำงานข้ามเบราว์เซอร์ได้ เพราะเห็นได้ชัดว่ามันทำบางสิ่งที่ยุ่งยากบางอย่างเพื่อทำให้หน้าสดของคุณรู้สึกแบบนั้น แต่ใช่
ดริว : น่าทึ่งมาก มันคือ... ฉันหมายความว่า ฉันเดาว่า VisBug ได้รับการอัปเดตอย่างสม่ำเสมอและกำลังดำเนินการอยู่ สิ่งที่เราอาจคาดหวังที่จะเห็นในอนาคตคืออะไร?
อดัม: ใช่ นั่นเป็นหนึ่งในคุณสมบัติที่ฉันกำลังดำเนินการอยู่ ฉันมีคุณสมบัติที่... ดังนั้น เมื่อคุณคลิกบางสิ่ง คุณจะได้รับการซ้อนทับกับสิ่งที่ดูเหมือนแฮนเดิลใช่ไหม และมันเป็นภาพลวงตา มันควรจะทำให้คุณรู้สึกสบายใจ และจุดประสงค์ก็คือต้องการให้ที่จับเหล่านั้นลากได้ในที่สุด แต่ฉันมีสิ่งพื้นฐานบางอย่างที่ฉันต้องแก้ไขก่อน เช่น องค์ประกอบในเบราว์เซอร์ไม่มีความกว้าง ดังนั้นหากคุณเพิ่งเริ่มจับความกว้าง ฉันต้องทำงานเพื่อทำให้ภาพลวงตานั้นถูกต้อง
อดัม: และคุณอาจไม่ได้ผลลัพธ์ที่ต้องการด้วยซ้ำ เพราะมันอาจเป็นองค์ประกอบระดับบล็อกที่คุณกำลังดึงความกว้างให้เล็กลง และคุณไม่ได้รับการจัดเรียงใหม่ของรายการข้างๆ และคุณอาจสงสัยว่าทำไม ดังนั้นฉันจึงมีต้นแบบที่คุณสามารถลากมุม ลากองค์ประกอบไปรอบๆ แต่ฉันต้องเน้นจริงๆ ว่าเครื่องมือออกแบบกำลังทำสิ่งนี้อย่างไร พวกเขามีปุ่มสลับนี้เสมอ และมันเหมือนกับว่า… ดูสิ สวิตช์นี้เรียกว่าอะไร?
อดัม: แต่โดยพื้นฐานแล้วมันเหมือนกับการหดตัว… ฉันเรียกมันว่าหดห่อ หดห่อองค์ประกอบของฉัน มันเป็นความกว้างขององค์ประกอบนี้คือความกว้างของเนื้อหา เทียบกับนี่คือความกว้างขององค์ประกอบของฉัน ติดบางอย่างในนั้น ดังนั้น ฉันต้องการสิ่งนั้นในเบราว์เซอร์ ซ้อนทับบนองค์ประกอบ เพื่อให้คุณสามารถเลือกระหว่างสิ่งเหล่านี้ และบางทีแม้แต่บางสิ่งที่ให้คุณเลือกระหว่างบล็อกและอินไลน์ เพื่อให้คุณได้ผลลัพธ์ที่คุณต้องการ
อดัม: แต่เป้าหมายสุดท้ายที่นี่คือ VisBug ไม่ต้องการให้มีการขับเคลื่อนด้วยคีย์บอร์ดทั้งหมด ฉันต้องการให้คุณลากระยะห่าง หากคุณเห็นระยะห่างขอบ 12 ด้านบน คุณควรเข้าถึงและคว้ามัน ในขณะที่ตอนนี้คุณต้องกดบนแป้นพิมพ์เพื่อระบุด้านบนของกล่องต้องเพิ่มระยะขอบ
อดัม: ใช่แล้ว ฉันมีนิสัยใจคอสองสามอย่างที่ต้องแก้ไข ในแง่ของกลยุทธ์ แต่เป้าหมายก็คือการทำให้เครื่องมือออกแบบใกล้เคียงกับเครื่องมือออกแบบมากขึ้นไปอีก และบางทีแม้ฉันจะก้มลงไป เหมือนกับว่า ถ้าคุณต้องการเปลี่ยนความกว้าง และคุณจะได้การออกแบบที่แปลก ๆ มีวิธีที่จะเอามันออกไปด้วย VisBug เสมอ เช่นเดียวกับเครื่องมือกำหนดตำแหน่งที่ให้คุณหลีกหนีกระแสได้จริงๆ ดังนั้นความลื่นไหลทำลายความคิดของคุณ เครื่องมือตำแหน่งช่วยให้คุณหลบหนีได้
อดัม: แล้วก็มี… ถ้ามีใครเข้าใจ VisBug มากจริง ๆ พวกเขาจะระเบิดความคิดของผู้คน เพราะมันไม่จำกัด และเช่น คุณจะเอาอะไรมาที่โต๊ะ มันมีองค์ประกอบนิพจน์อยู่ มีกลยุทธ์ที่แสดงออกอย่างแน่นอน แต่อย่างไรก็ตาม เรื่องสั้นโดยย่อก็คือ ภาพลวงตาคือ ฉันแค่อยากทำให้มันเล็กลง เล็กลงเรื่อยๆ ฉันต้องการให้ภาพลวงตาเป็นแบบ "ว้าว ฉันรู้สึกเหมือนเป็นเครื่องมือออกแบบจริงๆ"
อดัม: และใช่ การปรับปรุงบางอย่างในการส่งออกคงจะดี แต่การเพิ่มประสิทธิภาพการส่งออกสำหรับ DevTools ก็คงจะดี และนั่นไม่ได้หยุดเราจริงๆ ฉันก็เลยไม่รู้ มีปัญหามากมาย ไปลงคะแนนกับพวกเขาอย่างแน่นอน ฉันคิดว่าคุณลักษณะสำคัญอย่างหนึ่งต่อไปที่ฉันอยากทำคือเส้นสีเขียว ดังนั้น แทนที่จะแสดงการช่วยสำหรับการเข้าถึงแบบซ้อนทับบนโฮเวอร์เพื่อระบุบางสิ่งด้วยเส้นสีเขียวจริงๆ และเปิดเผยเพิ่มเติม และแสดงข้อมูลเพิ่มเติม ซึ่งฉันไม่รู้ ใช่.
Drew: กำลังคิดเกี่ยวกับกระบวนการสร้างส่วนขยาย Chrome แบบนี้ สมมติว่ามีการใช้งาน JavaScript ทั้งหมด เช่นเดียวกับการพัฒนาเว็บทั่วไป การสร้างส่วนขยายของ Chrome
อดัม: นั่นเป็นคำถามที่ดี มันคือ… วุ้ย นี่มันยากอย่างหนึ่ง มันแปลก อย่างแรกเลย สภาพแวดล้อมที่คุณเปิดใช้โค้ดไม่ใช่เบราว์เซอร์ พวกเขาไม่ได้ให้คุณเข้าถึงได้อย่างเต็มที่ที่นั่น คุณสามารถทำได้ ถ้าคุณยุ่งยากกับมันจริง ๆ ซึ่ง VisBug ต้องก้าวเข้าสู่สถานการณ์ที่ยุ่งยากกว่านี้ ตอนนี้ฉันเคยดำเนินการใน... สิ่งนี้จะคลุมเครือเร็วมาก
อดัม: เนื่องจากมีหลายแซนด์บ็อกซ์สำหรับส่วนขยายของคุณ สำหรับปัญหาด้านความเป็นส่วนตัว และพวกเขาทำให้ยากต่อการรันสคริปต์บนหน้าจริงใช่ไหม เพราะคุณไม่ต้องการให้ใครมาส่งแบบฟอร์มของคุณเมื่อคุณเปิดสิ่งของหรือสิ่งของ ส่งให้ตัวเองหรืออะไรก็ตาม มันสามารถทำลายล้างได้จริงๆ มันจึงมีนิสัยใจคอแบบนั้น มีสะพานที่คุณต้องข้าม และหนึ่งในนั้นที่ก่อกวน VisBug คือ VisBug เคยใช้...
อดัม: ดังนั้น มันคือองค์ประกอบที่กำหนดเองทั้งหมด และองค์ประกอบที่กำหนดเองช่วยให้คุณส่งข้อมูลที่สมบูรณ์ไปยังองค์ประกอบเหล่านั้นเป็นคุณสมบัติได้ คุณกำลังพูดว่า customelement.foo=myrichobject เต็มไปด้วยอาร์เรย์หรืออะไรก็ตาม และองค์ประกอบที่กำหนดเองเพิ่งได้รับเป็นข้อมูลบางส่วนบนโหนดเอง แต่เนื่องจากฉันอยู่ในโลกแซนด์บ็อกซ์เล็กๆ ที่แปลกประหลาดนี้ หากฉันพยายามตั้งค่าบางอย่างที่ไม่เหมือนใครบนวัตถุของฉัน มันก็จะกรองออกไปโดยพื้นฐานแล้ว พวกเขาได้กำหนดว่าบางสิ่งไม่สามารถทำได้... ดังนั้นฉันสามารถส่งสตริงไปยังองค์ประกอบที่กำหนดเองได้ แต่ฉันไม่สามารถส่งผ่านวัตถุที่มีรูปแบบสมบูรณ์ได้
อดัม: แต่ใช่ นอกจากนิสัยใจคอเล็กๆ แบบนั้น เมื่อคุณได้กระแสแล้ว และถ้าคุณใช้เวลาเพื่อให้ได้สถานการณ์สมมติ ซึ่งจะใช้เวลาหนึ่งชั่วโมงหรือมากกว่านั้น เพื่อให้คุณมอบ LiveReload ให้กับสิ่งที่คุณทำ ก็สามารถสวยเป็นธรรมชาติได้ ฉันคิดว่า Firefox มีประสบการณ์ในการพัฒนาส่วนขยายที่ดีที่สุดโดยสุจริต หากคุณเข้าใจ CLI เป็นอย่างดี คุณสามารถสร้างบางสิ่งขึ้นมาได้ด้วยคำสั่งเดียว และติดตั้ง ให้คุณสมบัติ LiveReload เหล่านี้แก่คุณ และให้เครื่องมือดีบั๊กแก่คุณ เป็นการจับมือของคุณผ่านมันได้ดีจริงๆ
อดัม: แต่ท้ายที่สุด มันก็แปลกไปหน่อย นั่นเป็นเหตุผลที่ฉันทำงานมากมายบนไซต์สาธิตที่ดูเหมือนอาร์ตบอร์ด เพราะส่วนใหญ่ฉันไม่ต้องการเว็บเพจจริงเป็นส่วนใหญ่ เพื่อทำการทดสอบ VisBug ตราบใดที่ฉันมีอาร์ตบอร์ดที่ จำลองปัญหาต่างๆ หรือมีสิ่งที่จะดูได้ และให้เนื้อหาที่ฉันต้องการดูแก่ฉัน ฉันทำงานหลายอย่างในเบราว์เซอร์ราวกับว่ามันเป็นเพียงเว็บแอปพลิเคชันทั่วไป ดังนั้นประสบการณ์การพัฒนาของ VisBug นั้นง่ายมาก เว้นแต่ว่าคุณกำลังพยายามทดสอบมันในเบราว์เซอร์ แล้วมันก็จะยุ่งๆ และอะไรก็ตาม
Drew: นั่นเป็นข้อมูลเชิงลึกที่น่าสนใจจริงๆ วันนี้ฉันได้เรียนรู้ทุกอย่างเกี่ยวกับ VisBug แล้ว คุณเรียนรู้อะไรเกี่ยวกับอะไรบ้างเมื่อเร็ว ๆ นี้อดัม?
อดัม: ฉันยังคงพัฒนาทักษะการทำกระทะอยู่ ดังนั้นฉันจึงอยากเป็น wok man และฉันไม่ได้หมายถึงเครื่องเล่นเทปยุค 90 ฉันต้องการพลิกผักและปล่อยให้มันติดไฟนิดหน่อยในอากาศ คลุมด้วยเครื่องเทศอร่อย ๆ และเพียงแค่ทำให้กระเทียมสุกแล้วทำให้มันกรอบอร่อย แล้ววางลงบนเตียงข้าวน้อยแล้วเลื่อนเข้าหาตัวและดูว่าท่านคิดอย่างไร
อดัม: ตอนนี้ฉันตื่นเต้นมากสำหรับฤดูร้อน เพราะนั่นหมายความว่าฉันต้องตีกระทะและกลับเข้าไปในสภาพแวดล้อมการทำอาหารที่ร้อนจัดและเร่งรีบ และมันก็สนุกจริงๆ
ดริว : น่าทึ่งมาก ฟังดูน่าอร่อย หากคุณผู้ฟังที่รัก ต้องการทราบข้อมูลเพิ่มเติมจาก Adam คุณสามารถติดตามเขาได้ทาง Twitter ซึ่งเขาคือ @argyleinc และค้นหาเว็บไซต์ส่วนตัวของเขาที่ nerdy.dev หากคุณต้องการทดลองใช้ VisBug คุณสามารถค้นหาได้ใน Chrome เว็บสโตร์ และคุณสามารถลองใช้เวอร์ชันแซนด์บ็อกซ์ได้ที่ visbug.web.app ขอบคุณที่เข้าร่วมกับเราในวันนี้อดัม คุณมีคำพรากจากกันไหม
อดัม: ไม่ คุณเป็นคนดีจริงๆ นี่มันหวานจริงๆ ขอบคุณที่มีฉัน ฉันซาบซึ้งจริงๆ