การขัด UI

 (blog.jim-nielsen.com)
2 คะแนน โดย GN⁺ 2024-09-22 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ความสมบูรณ์ของ UI ไม่ได้ดีขึ้นทันทีหลังลงมือทำเสร็จ แต่จะดีขึ้นจาก กระบวนการคลิกซ้ำๆ อย่างต่อเนื่องในการใช้งานจริง และบทความนี้เปรียบสิ่งนั้นกับการขัดไม้
  • การเปลี่ยนหน้าและการนำทางควรถูกตรวจสอบผ่าน หลายเส้นทางในการเข้าถึง เช่น การคลิก ปุ่มย้อนกลับของเบราว์เซอร์ การคลิกขวาแล้วเลือก “Back” ปุ่มย้อนกลับภายในแอป และคีย์ลัดบนคีย์บอร์ด
  • เมื่อนำ label และ input type="radio" มาเรียงด้วย flexbox แล้วใส่ gap จะพบ dead zone ที่คลิกไม่ได้อยู่ระหว่างปุ่มวิทยุกับ label
  • วิธีแก้คือเอา gap ออกแล้วใส่ padding ให้ label แทน ซึ่งยังคงระยะห่างในเชิงภาพไว้ได้ พร้อมกับขยาย พื้นที่ที่คลิกได้
  • แม้ข้อบกพร่องเล็กๆ ในการโต้ตอบจะดูไม่สำคัญ แต่เมื่อสะสมมากขึ้นก็ทำลายประสบการณ์ใช้งานได้ จึงควรใช้งาน UI ซ้ำๆ และขัดเกลามันจนไม่เหลือ “เสี้ยน” ให้สะดุดอีก

ค้นหาจุดหยาบของ UI ด้วยการคลิกซ้ำ

  • งานทำ UI คือการสร้างบางอย่างขึ้นมา แล้ว คลิกมันให้มาก แก้ไข จากนั้นก็กลับไปคลิกอีกครั้ง เป็นวงจรแบบนี้ซ้ำๆ
  • การตรวจสอบการเปลี่ยนหน้าโดยดูแค่ flow เดียวไม่เพียงพอ ต้องลองย้อนกลับและตรวจสอบด้วยหลายวิธี
    • คลิกแล้วใช้ปุ่มย้อนกลับของเบราว์เซอร์
    • คลิกแล้วใช้ “Back” จากเมนู context menu ที่ได้จากการคลิกขวา
    • ใช้การนำทางย้อนกลับภายในแอป
    • ใช้คีย์ลัดบนคีย์บอร์ดเพื่อย้อนกลับ
  • กระบวนการนี้คล้าย QA แบบ “ลองคลิกให้พังดู” แต่ความรู้สึกจริงๆ ใกล้เคียงกับการใช้กระดาษทรายขัดงานไม้เพื่อหา จุดหยาบและเสี้ยน มากกว่า
  • UI ของซอฟต์แวร์อาจมี สถานะและตัวแปรมากเกินไป จึงต้องขัดเกลาผ่านการใช้งานซ้ำๆ จนไม่เหลือ “เสี้ยน” ให้จับได้อีก

dead zone จาก gap ของ flexbox

  • ในรายการตัวเลือกแบบ radio มีการวาง <label> และ <input type="radio"> ที่เชื่อมกันไว้ในแถวเดียวกัน
  • CSS เป็นโครงสร้างง่ายๆ ที่กำหนด display: flex, flex-direction: row, align-items: center, gap: .5rem ให้กับคอนเทนเนอร์
  • ระหว่างการคลิกซ้ำๆ พบว่าเมื่อกดพื้นที่ระหว่างปุ่มวิทยุกับ label คอนโทรลจะไม่สลับสถานะ เกิดเป็น dead spot
  • สาเหตุมาจาก gap ของ flexbox
    • gap ช่วยสร้างระยะห่างในเชิงภาพได้ง่าย
    • แต่ไม่ได้รวมอยู่ในพื้นที่คลิกของ label หรือ input จึงกลายเป็นช่องว่างที่โต้ตอบไม่ได้
  • วิธีแก้คือเอา gap ออกแล้วใส่ padding ให้ label แทน
    • ระยะห่างยังคงอยู่
    • พื้นที่คลิกของ label กว้างขึ้น ทำให้ dead zone หายไป
  • ข้อบกพร่องเล็กๆ เพียงอย่างเดียวอาจดูไม่สำคัญ แต่ถ้า “เสี้ยนเล็กๆ” แบบนี้มีมากขึ้น ประสบการณ์ของ UI ก็อาจกลายเป็นเรื่องน่าทรมานได้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-09-22
ความคิดเห็นจาก Hacker News

  • ถ้าเป็นนักพัฒนาที่เป็น ผู้ใช้ตัวยงของผลิตภัณฑ์ที่ตัวเองกำลังสร้าง ด้วย ก็จะได้เปรียบมากในการหาปัญหาเล็ก ๆ แบบนี้
    เพราะก่อนที่ผู้ใช้จะสะดุดเอง นักพัฒนาจะสังเกตเห็นความขัดใจเล็กน้อยได้ด้วยตัวเอง และก็อยู่ในตำแหน่งที่จะแก้ได้ทันทีด้วย
    เพราะแบบนี้ ทีมเล็กที่มี ownership สูง จึงดูมีประสิทธิภาพมาก ถ้ามีความเป็นเจ้าของผลิตภัณฑ์ ก็จะรู้สึกว่าความไม่สะดวกเล็กน้อยที่ผู้ใช้เจอเป็นเรื่องของตัวเอง และการทำให้ UX ลื่นไหลที่สุดก็กลายเป็นเรื่องของศักดิ์ศรี

    • นี่จึงเป็นเหตุผลที่บริษัทต่าง ๆ ทำ dogfooding กับผลิตภัณฑ์ของตัวเองและเปิด internal beta เมื่อทำได้
      ถ้าไม่ใช่กรณีอย่างผลิตภัณฑ์สำหรับองค์กรที่ใช้งานภายในได้ยาก อย่างน้อยถึง ownership โดยตรงจะอ่อนกว่า แต่ก็ยังมีส่วนได้ส่วนเสียกับความสำเร็จของผลิตภัณฑ์

  • สงสัยว่า UI ที่ขัดเกลามาดีที่สุดคืออะไร
    ระดับ FAANG น่าจะมีเงินมากพอจนดูเหมือน UI/UX คงดีพอตัว แต่คนที่เคยใช้ Amazon.com, AWS, GCP หรือ Azure น่าจะรู้สึกต่างออกไป
    ส่วนตัวคิดว่า mcmaster.com คือ UI/UX ที่ขัดเกลามาดีที่สุด หาสิ่งที่ต้องการได้ภายในไม่กี่นาที
    ตรงกันข้าม เว็บร้านใหญ่ ๆ อย่าง Home Depot หรือ Lowe’s ใช้เวลาหาอย่างพวกสกรูหรือไม้ให้ได้ขนาดตรงเป๊ะทีละ 10–15 นาที และบนมือถือยิ่งแย่กว่า

    • RockAuto เป็นเว็บไซต์ที่ชอบที่สุด
      มันเรียบง่ายและใช้งานได้จริงจนน่าเหลือเชื่อ แต่ก็ทรงพลังมาก สามารถค่อย ๆ ไล่กรองชิ้นส่วนหรือค้นหาได้ การเทียบราคาก็ทำให้อัตโนมัติ และยังจัดกลุ่มช่วงราคา/คุณภาพได้มีประโยชน์
      ถ้าเจอหมายเลขชิ้นส่วนแล้ว ก็จะดูความเข้ากันได้กับปี/ผู้ผลิต/รุ่น คำอธิบายสั้น ๆ รูปภาพ และยังดูได้ด้วยว่าจัดส่งจากคลังเดียวกับชิ้นส่วนอื่นในตะกร้าหรือไม่ ทั้งหมดนี้ทำได้ในหน้าเดียวแบบแทบไม่มีแรงเสียดทาน และทำงานได้เร็วมากบนทุกแพลตฟอร์ม
    • FastMail เป็นหนึ่งในเว็บแอปที่ให้ความรู้สึกดีที่สุดเท่าที่เคยใช้
      ตอบสนองเร็วมาก และไม่เคยเจอบั๊กระหว่างใช้งานเลย มันยกระดับมาตรฐานในหัวว่าควรคาดหวังอะไรจากเว็บแอปได้บ้าง
    • Linear มี UI ที่ขัดเกลามาดีมาก
      ถึงขั้นเคยมีช่วงเวลาที่ตั้งใจไว้เพื่อแก้เฉพาะปัญหาด้านการใช้งานจริง ๆ
      https://linear.app/changelog/2022-12-01-polishing-season-202...
      https://web.archive.org/web/20231003205004/https://linear.ap...
    • บน Facebook พอจะยกตัวอย่างฟีเจอร์ที่พังมาหลายเดือนได้หลายอย่าง
      โดยเฉพาะ รูปโปรไฟล์ชั่วคราว ที่น่าหงุดหงิดที่สุด มันทำงานไม่ถูกต้องมาเกือบปีแล้ว และไม่กลับไปเป็นรูปเดิม
      ดูเหมือนว่าจะไม่มีใครคอยขัดเกลาอะไรอยู่ตรงนั้นเลย
    • ตอนนี้เป็นช่วงเวลาที่ทุกคนมองเห็นได้ว่าความประณีตแบบช่างฝีมือปรากฏอยู่ในรายละเอียดเล็ก ๆ
      https://littlebigdetails.com ก็เป็นสถานที่แบบนั้นพอดี

  • วิธีแก้พื้นฐานของปัญหาเฉพาะนี้คือ ใส่องค์ประกอบ input ไว้ข้างใน label

    • Bootstrap เปลี่ยนโครงสร้างของ radio/checkbox จากแบบใน 4.0 ไปเป็นอีกแบบหนึ่งใน 5.0 [1]
      ตอนแรกก็สงสัยว่าทำไม แต่เดาว่าน่าจะเพราะทำให้การใส่ธีมง่ายขึ้นเวลาอยากปรับตำแหน่ง/padding ของ label หรือ input
      [1] https://getbootstrap.com/docs/5.3/forms/checks-radios/
    • ถึงจะซ้อนกันอยู่ ก็ยังต้องมีแอตทริบิวต์ for/id เพื่อการเข้าถึงสำหรับ ซอฟต์แวร์สั่งงานด้วยเสียง ทั่วไป: https://www.tpgi.com/should-form-labels-be-wrapped-or-separa...
    • นี่ก็เป็นสิ่งแรกที่นึกถึงเหมือนกัน
      radio หรือ checkbox ไม่ควรถูกสลับสถานะได้แค่ที่กล่องกับ padding เท่านั้น แต่ควรกดที่ ข้อความ label ทั้งหมด ได้ด้วย
    • เมื่อก่อนด้วยเหตุผลบางอย่างเคยคิดว่าวิธีนี้เป็นข้อห้าม อาจเป็นเพราะใน XHTML เคยบังคับ ความสัมพันธ์แบบหนึ่งต่อหนึ่ง ระหว่าง label กับ input
      Flexbox ดูจะเกินความจำเป็นไปหน่อย ต่อให้เป็นไวยากรณ์แบบไม่ซ้อนกันก็น่าจะวางแบบ inline อยู่แล้ว และแค่เพิ่ม padding ในแบบเดียวกันก็น่าจะพอ
    • ในเฟรมเวิร์กอย่าง React วิธีนี้อาจทำให้เกิดข้อผิดพลาดที่แพร่กระจายเวลาใช้สิ่งอย่าง Google Translate บนเว็บไซต์
      ถ้าจะบรรเทา ก็ควรห่อ Foo ด้วยองค์ประกอบแยกต่างหาก

  • เรื่องแบบนี้หายไปมากเกินใน Agile
    วิศวกรควรมีเวลาเกลาผลิตภัณฑ์ แต่ความเป็นจริงคือไม่มีเลย ถ้า QA ไม่เปิด ticket เรื่องช่องว่างผิดเพี้ยน มันก็จะไม่มีวันถูกแก้
    ลูกค้าอาจสังเกตเห็นเรื่องพวกนี้ แต่การที่พวกเขาจะรายงานเข้ามาก็แทบเป็นปาฏิหาริย์ แล้วการที่มันจะกลายเป็น ticket ก็เป็นอีกปาฏิหาริย์หนึ่ง และการที่ใครสักคนจะให้ลำดับความสำคัญจนได้แก้ก็เป็นปาฏิหาริย์อีกต่อ
    ในความเป็นจริง issue board ของบริษัทส่วนใหญ่ทึบแสงเกินไปจากมุมมองของลูกค้า จนถ้าเจอปัญหาเล็กๆ หรือบั๊ก ก็ต้องเสียเวลาไปๆ มาๆ เป็น 50 ชั่วโมงเพื่อพิสูจน์ว่ามันเป็นบั๊กและใส่ ticket เข้า tracker ซึ่งน่าหงุดหงิดมาก

    • ไม่รู้ว่าเกี่ยวอะไรกับ Agile
      คุณคิดว่า waterfall model ระบุเวลาให้ทดสอบและเกลา UI ไว้อย่างชัดเจนงั้นเหรอ?
      ปกตินี่เป็นกระบวนการที่ผู้จัดการผลิตภัณฑ์ต้องจัดลำดับความสำคัญ แล้วทำงานร่วมกับ UX engineer หรือดีไซเนอร์ที่เก่งพอ ถ้าต้องการ คุณก็ใส่ลำดับความสำคัญนี้เข้าไปในวิธีพัฒนาแบบไหนก็ได้ ดังนั้น Agile ไม่เกี่ยวในที่นี้
    • Discord มีฟีเจอร์โพสต์ที่ทำงานเหมือนฟอรัม แต่เวลาเขียนโพสต์ ปุ่ม HOME/END ใช้งานเพี้ยนไปหมด เลือกข้อความด้วย Shift ก็ไม่ได้ และการขยับทีละคำด้วย Ctrl ก็ไม่ได้เช่นกัน
      ผมรายงานเรื่องนี้มาหลายครั้งตลอด 3 ปีที่ผ่านมา เพราะการแก้ไขข้อความขณะเขียนนั้นยากและน่าหงุดหงิดสุดๆ
      ในฐานะนักพัฒนาเว็บ ผมสงสัยมาตั้งแต่แรกว่าของแบบนี้พังได้ยังไง ไม่รู้ว่าต้องไร้ความสามารถระดับไหนถึงทำให้สิ่งที่ควรทำงานได้ตามปกติพังลงได้ นี่เป็นการแก้ที่ไม่น่าใช้เวลาเกิน 30 นาที และจะทำให้ประสบการณ์ผู้ใช้ของทุกคนดีขึ้น 1000 เท่า แต่ผ่านไป 3 ปีหลังจากรายงานแล้วก็ยังเหมือนเดิม
      ใน Teams ผมก็เคยรายงานบั๊กที่ช่องกรอกหมายเลขโทรศัพท์ใช้ปุ่ม HOME/END ไม่ได้ ผ่าน Microsoft Premiere Support แต่คำตอบที่ได้คือ “ทำงานตามที่ออกแบบไว้”
      ไม่น่าแปลกใจเลยที่ลูกค้าจะเลิกรายงานบั๊กพวกนี้ เพราะทั้งพนักงาน/นักพัฒนาและบริษัทเองก็ไม่ได้สนใจอยู่ดี
    • จริงมาก
      ผมเป็นหัวหน้านักพัฒนาของผลิตภัณฑ์ และมีปัญหาเล็กๆ น้อยๆ อยู่เต็มไปหมด ความรู้สึกที่ต้องรับผิดชอบบางอย่างแต่ไม่มีอำนาจจะแก้มัน ไม่ใช่ความรู้สึกที่ดีเลย
      จากมุมมองธุรกิจ มันกลายเป็นตรรกะว่า ถ้าไม่กระทบรายได้หรือแบรนด์โดยตรง จะเสียเวลาและเงินไปแก้ทำไม แม้ระยะยาวมันจะกระทบแบรนด์ก็ตาม แต่คนส่วนใหญ่ก็ย้ายบทบาทหรือย้ายบริษัทภายใน 5 ปี เลยไม่สนใจ
    • ผมเป็นคนรายงานบั๊กบ่อย แต่เจ้าหน้าที่ฝ่ายสนับสนุนลูกค้าหลายคนดูเหมือนมองว่างานของตัวเองคือปกป้องวิศวกรจากรายงานบั๊กและปัดความรับผิดชอบออกไป
      แค่ได้คำตอบกลับมาก็ยังถือว่าดีกว่าหลายกรณีแล้ว
    • แนวคิดของ “Agile” คือการสังเกตเห็นสิ่งที่ใช้ไม่ได้ผลแล้วปรับปรุงมัน
      เห็นได้ชัดว่ามีกระบวนการบางอย่างที่ไม่ตอบโจทย์ความต้องการของลูกค้า ก็แก้มันร่วมกับทีมได้เลย
      ถ้ามีพิธีการแบบ Scrum ก็อาจหยิบขึ้นมาใน retrospective ได้ แต่จริงๆ แล้วทำได้ทุกเมื่อ retrospective เป็นแค่ช่วงเวลาที่ตั้งใจทบทวนหลายสัปดาห์ที่ผ่านมา ส่วนสิ่งที่สังเกตเห็นระหว่างทางก็ควรพยายามแก้ระหว่างทาง

  • การมีคนที่มีเซนส์พอจะรายงานและแก้ปัญหา UX เล็กๆ น้อยๆ ได้นั้นสำคัญมาก
    ในงานออกแบบ UX มักเปรียบสิ่งนี้กับแผลกระดาษบาดที่เกิดกับผู้ใช้ มันไม่ถึงตาย แต่ค่อยๆ บั่นทอนความพึงพอใจของผู้ใช้
    ขอเสริมผู้เขียนว่า radio button นั้นไม่ทำตามธรรมเนียมที่ใช้จุดแทนเครื่องหมายถูกเพื่อบอกสถานะที่ถูกเลือก ผู้ใช้อาจเข้าใจผิดตั้งแต่แรกเห็นว่าเลือกได้หลายข้อ หรือไม่เลือกเลยก็ได้

    • สิ่งที่ผมเจอใน GitHub และ Jira คือปัญหาที่เวลา drag เพื่อเลือกข้อความใน dialog แล้วปล่อยเมาส์ด้านนอก ป๊อปอัปจะปิด
      น่าจะเป็นผลข้างเคียงของฟีเจอร์ที่ตั้งให้คลิกข้างนอกแล้วปิด
    • เห็นด้วย
      ถ้าฝั่งลบมี “Papercuts” ฝั่งบวกก็มีJuice ซึ่งเพิ่งมีพูดถึงใน HN เมื่อไม่นานนี้
      1. https://garden.bradwoods.io/notes/design/juice

  • บทความนี้แสดงให้เห็นชัดว่าทำไมผมถึงเกลียดการเขียนโปรแกรม UI
    มันมีเรื่องที่คาดเดาไม่ได้และเพี้ยนเล็กๆ น้อยๆ ได้มากเกินกว่าความอดทนของผม ผมยังพอสนุกกับการคิดว่าบางอย่างจะล้มเหลวได้อย่างไรแล้วเขียนเทสต์ แต่การคลิกสุ่มๆ ไปเรื่อยเพื่อดูว่ามันพังไหมนั้นทั้งเสียสมาธิและน่ารำคาญ
    ผมสงสัยว่าการทำ UI นั้นซับซ้อนโดยเนื้อแท้จริงๆ หรือว่าเรายังหาโมเดลการเขียนโปรแกรมที่ถูกต้องไม่เจอ บางครั้งผมก็สงสัยว่าการคาดหวังให้มันแสดงผลและทำงานตามที่ตั้งใจตั้งแต่แรกนั้น unreasonable ไหม?

    • นั่นแหละคือเหตุผลที่มีdesign system
      การเกลา UI ควรทำแค่ตอนสร้างคอมโพเนนต์ครั้งแรก บางครั้งอาจต้องเอาคอมโพเนนต์ไปประกอบกันในรูปแบบอื่น หรือมีงานทำครั้งเดียวเฉพาะกิจบ้าง
      พูดตามตรง ถ้ารู้ว่ากำลังทำอะไรอยู่ มันไม่ได้ใช้เวลานานขนาดนั้น design engineer ที่เก่งคือผู้เชี่ยวชาญของงานลักษณะนี้
    • นี่ไม่ใช่การเขียนโปรแกรม UI แต่คือการออกแบบ UI บน HTML และ CSS
      มันมีอิสระมากเกินไป และองค์ประกอบพื้นฐานอย่างฟอร์มก็ควรทำงานได้ดีด้วยค่าปริยายอยู่แล้ว
    • มันไม่ได้ซับซ้อนขนาดนั้น
      วิธีแสดง UI ให้ดีผ่านโค้ดมีอยู่แล้ว ปัญหาคือเกมผลรวมเป็นศูนย์ฝั่งธุรกิจ UI ข้ามแพลตฟอร์มมีต้นทุนแพงเกินไปถ้าไม่ทำด้วยสแตก UI ที่ดูแย่ที่สุดอย่างHTML/CSS/JS
    • เมื่อก่อนเคยมีแพลตฟอร์มที่ค่อนข้างดีอยู่บ้าง ซึ่งโดยพื้นฐานแล้วช่วยดูแลรายละเอียดแทนให้
      แต่แพลตฟอร์มเว็บนั้นพอใช้กับเอกสารได้โอเค ทว่าระดับนามธรรมไม่เหมาะกับแอป เลยทำให้ UI บนเว็บถูกประดิษฐ์ใหม่ซ้ำๆ ทุกปีด้วย abstraction ที่รั่วแบบใหม่เสมอ
    • สำหรับเว็บ นี่คือผลลัพธ์ของการที่threshold ต่ำเกินไป โดยไม่มีอะไรมาช่วยนักพัฒนาที่ใส่ใจกับ UI ที่ถูกต้อง
      แค่ตามให้ทันก็มีงานมากเกินพอแล้ว
      ด้านอื่นก็คล้ายกัน ถ้าไม่มีวิธีง่ายๆ ในการส่ง request หรือใส่พารามิเตอร์ลงใน query ผู้คนก็จะถูกแรงกดดันตามธรรมชาติบีบให้ประดิษฐ์วิธีครึ่งๆ กลางๆ สารพัดขึ้นมา ต่อให้พยายามระวังแล้วก็ตาม
      แพลตฟอร์มเว็บนั้นล้ำหน้ามากในด้านกราฟิก แต่แย่มากในฐานะ UI และไม่มีใครยอมรับแล้วลงมือเปลี่ยน คนเชื่อแค่ส่วนหน้า ขณะที่ legacy และความซับซ้อนของเบราว์เซอร์ขัดขวางการเปลี่ยนแปลง ถ้าทำเป็นไลบรารี มันก็ “ไม่ใช่มาตรฐาน” เลยไม่มีใครสนใจ

  • ขณะเดียวกัน UI บางแบบก็ใช้radio button เป็นกล่องสี่เหลี่ยม
    มีปุ่มที่ถูกเน้นอยู่แต่กด Enter แล้วไม่ทำงาน
    แล้วยังมีเมนูอีกสามชุดที่ซ่อนอยู่หลังสัญลักษณ์คนละแบบกัน ทั้งจุดไข่ปลา แฮมเบอร์เกอร์ และเคบับ
    คุณภาพต่างกันมาก คนที่คอยเกลา UI เป็นคนที่น่าขอบคุณจริงๆ

    • ปุ่มที่มีโฟกัสอยู่ ปกติคีย์ที่ใช้สั่งทำงานแบบคลิกมักเป็นSpace มากกว่า Enter
    • ดูเหมือนตอนนี้ radio button ก็กำลังมุ่งไปเป็นมาตรฐานแบบสี่เหลี่ยมหรือสี่เหลี่ยมมุมมนแล้ว
      แม้แต่ Apple ก็ยังทำแบบนี้ :(

  • ไม่เข้าใจว่าทำไมวิธีเอาองค์ประกอบ input ไปไว้ข้างใน label ถึงไม่ค่อยได้รับความนิยม
    ถ้าทำแบบนี้ปัญหาก็หายไปหมด และไม่ต้องสร้าง id ที่ไม่ซ้ำไว้ใช้กับ for ด้วย

    • ผมว่ามันไม่ใช่ “ไม่ค่อยได้รับความนิยม” แต่ตรงกันข้ามมากกว่า
      เพียงแต่ยังมีเทคโนโลยีช่วยการเข้าถึงบางตัวที่ขึ้นชื่อว่ายังตีความแพตเทิร์นมาตรฐานแบบใหม่ที่ใช้ได้ไม่ออก ดังนั้นการยึดตาม มาตรฐานยุคสำริด จึงกลายเป็นแนวปฏิบัติที่ดีที่สุด [1]

      Dragon Naturally Speaking บน Windows และ Voice Control บน macOS/iOS ไม่รู้จักการเชื่อมโยงแบบ implicit ดังนั้น [วิธีซ้อน input ไว้ใน label โดยไม่อ้างอิง for-id แบบ explicit] จึงใช้งานไม่ได้
      มีคนบอกว่า Naturally Speaking ถูกบริษัทชื่อ “Microsoft” เข้าซื้อไป ส่วน Voice Control ก็เกี่ยวข้องกับบริษัทชื่อ “Apple”
      [1] https://www.tpgi.com/should-form-labels-be-wrapped-or-separa...

    • ถ้าสร้าง checkbox ด้วย Rails helper มันจะวาง hidden field ที่มีค่า “off” ไว้ข้างๆ เพื่อให้มีการ POST ค่านั้นเสมอ
      เฟรมเวิร์กอื่นก็น่าจะคล้ายกัน ถ้าเอา input สองตัวนั้นไปครอบด้วยองค์ประกอบ label ก็จะไม่เป็น HTML ที่ valid อีกต่อไป
      กับ radio button ไม่ใช่ปัญหา แต่บางคนเหมือนจะเจอเรื่องนี้แล้วเลยทำแบบนั้นเพื่อ “ให้ชัวร์ไว้ก่อน” คล้ายการใส่ semicolon ท้ายบรรทัดใน JavaScript คือแทบไม่จำเป็น แต่เพราะไม่รู้แน่ชัดว่าตอนไหนจำเป็น ก็เลยใส่มันไปทุกที่
    • ผมทำแบบนี้มาอย่างน้อย 15 ปี หรืออาจจะ 20 ปีแล้ว
      สำหรับกรณีใช้งานทั่วไปของ checkbox/radio button ไวยากรณ์ก็ดูสะอาดกว่ามาก
      ครอบ input ด้วย label แล้วถ้าอยากใส่สไตล์ให้ข้อความก็แค่เอาข้อความไปไว้ใน span จะทำ label เป็น display:flex และจัดตำแหน่งข้อความแบบนั้นก็ได้
    • เพราะหลักคำสอนของ Semantic Web

  • ตอน bug bash เราใช้วิธีนี้ แล้วได้ ticket มากกว่าคนที่ทำเมทริกซ์ชุดกรณีทดสอบแบบผลคูณคาร์ทีเซียนหลายมิติเสียอีก
    การรู้จักเทสต์เคสแบบนั้นเป็นจุดเริ่มต้นก็ดี แต่ถ้าจะหาปัญหาเล็กๆ การทดสอบแบบสุ่ม จะทิ้งการทดสอบตามแผนไว้ข้างหลังอย่างรวดเร็ว
    การทดสอบตามแผนมักหยุดอยู่ที่ happy path หรือข้อผิดพลาดที่คาดไว้ วิธีขัดเกลาแบบนี้หา bug ตามขอบมุมได้เร็วกว่ามาก

    • บางครั้ง โดยเฉพาะเวลาที่เหนื่อยเกินกว่าจะทำฟีเจอร์ทั้งก้อน ผมจะ คลิกมั่วๆ ไปทั่วในเกมแล้วลองทำสิ่งที่ปกติไม่เคยทำ
      สุดท้ายก็จะเจอปัญหาหรือจุดปรับปรุงเล็กๆ อยู่เสมอ ซึ่งเป็นสิ่งที่การทดสอบตามแผนคงไม่ได้เจอบ่อยนัก

  • ผมขัดเกลาเว็บไซต์ส่วนตัว(https://dustinbrett.com) มาเกือบ 4 ปีแล้ว และรู้สึกว่ามันอาจจะไม่มีวันจบก็ได้
    โชคดีที่ผมยังสนุกกับการทำมันอยู่

    • พูดกันตรงๆ ก็สงสัยว่าจากเวลาที่ใช้ไปกับสิ่งนี้ มีเท่าไรที่เกิดขึ้นระหว่างเวลางาน 9 โมงถึง 5 โมงและใช้เงินเจ้านาย
      หวังว่าคงทั้งหมดนะ :-)
    • อันนี้ดีจริงๆ
      เวลาเห็น “เดสก์ท็อป OS บนเว็บเพจ” ส่วนใหญ่จะให้ความรู้สึกว่าทำค้างไว้ครึ่งๆ กลางๆ และพูดตรงๆ ว่ามันเริ่มมีเยอะเกินไปแล้ว แต่นี่กลับตรงกันข้าม คือแน่นมากและขัดเกลามาดีมาก
    • สนุกมากที่จะไล่ดู
      ทำออกมาได้ดีจริงๆ และสร้างแรงบันดาลใจด้วย แค่คิดว่าทำทุกอย่างนี้ขึ้นมายังไงก็น่าสนุกมากแล้ว
    • ลื่นมาก และตอบสนองความต้องการที่ผมเองก็ไม่รู้ว่ามีอยู่
      นั่นคือความอยากใช้ OS แบบมีหน้าต่าง บนมือถือ
    • ดูเจ๋งจริงๆ
      ถ้าจะหาสิ่งที่ขาดไปอย่างหนึ่งก็คือใน explorer ใช้ mouse4/mouse5 ไม่ได้ “การขัดเกลา” นี่มันดำเนินต่อไปได้ตลอดกาลจริงๆ