GitHub ไม่ใช้ Toasts อีกต่อไป

 (primer.style)
16 คะแนน โดย GN⁺ 2025-12-12 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • UI การแจ้งเตือนแบบ Toast ไม่ได้รับการแนะนำจาก GitHub อีกต่อไปเนื่องจากปัญหาด้านการเข้าถึง
  • โครงสร้างการแจ้งเตือนชั่วคราว ที่หายไปเองอัตโนมัติมีความเสี่ยงที่จะละเมิดเกณฑ์การเข้าถึงทั้งด้านการมองเห็นและการใช้งาน (WCAG)
  • GitHub เสนอ banner และ dialog ซึ่งเป็น วิธีให้ฟีดแบ็กที่คงอยู่และเข้าถึงได้ เป็นทางเลือก
  • Toast ยังมีปัญหาด้านการใช้งานอีกหลายอย่าง เช่น หน้าจอขนาดใหญ่ การทำหลายอย่างพร้อมกัน และภาวะเพิกเฉยต่อแบนเนอร์
  • เพื่อการเข้าถึงและประสบการณ์ผู้ใช้ที่สม่ำเสมอ จึง ยุติการใช้ Toast ทั่วทั้งระบบออกแบบ Primer

ภาพรวมของ Toasts

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

ทางเลือกแทน Toast

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

ข้อพิจารณาด้านการเข้าถึง (Accessibility Considerations)

  • UI แบบ Toast อาจละเมิด เกณฑ์ความสำเร็จของ WCAG หลายข้อ
    • 2.2.1 Timing Adjustable (A) : ควรคงอยู่จนกว่าผู้ใช้จะปิดเอง
    • 1.3.2 Meaningful Sequence (A) : ความไม่สอดคล้องกันระหว่างลำดับ DOM และลำดับที่มองเห็นอาจทำให้ผู้ใช้เทคโนโลยีช่วยเหลือสับสน
    • 2.1.1 Keyboard (A) : ต้องควบคุมการโต้ตอบภายใน toast ได้ด้วยคีย์บอร์ด
    • 4.1.3 Status Messages (AA) : ต้องแจ้งการมีอยู่ของมันต่อเทคโนโลยีช่วยเหลือโดยไม่รบกวน
  • นอกจากนี้ยังอาจละเมิดเกณฑ์ต่อไปนี้ได้
    • 1.4.4 Resize text (AA) : เมื่อปรับขนาดข้อความอาจเกิดการบังหน้าจอหรือข้อความล้น
    • 1.4.10 Reflow (AA) : ต้องคงการเข้าถึงด้วยคีย์บอร์ดไว้เมื่อมีการเลื่อนแนวนอน
    • 2.4.3 Focus Order (A) : อาจทำให้ลำดับโฟกัสสับสน
    • 3.2.4 Consistent Identification (AA) : ต้องรักษาความสม่ำเสมอของโค้ด

ข้อพิจารณาด้านการใช้งาน (Usability Considerations)

  • บน หน้าจอขนาดใหญ่ toast อาจอยู่พ้นสายตาจนไม่ถูกสังเกต
  • เมื่อ หายไปอัตโนมัติ หากผู้ใช้กำลังทำอย่างอื่นอยู่ ก็มีความเสี่ยงที่จะพลาดข้อความ
  • การบัง UI: toast อาจทับองค์ประกอบสำคัญ เช่น ปุ่มด้านล่าง
  • ผู้ใช้ที่ ขยายหน้าจอ อาจมองไม่เห็น toast ที่อยู่นอกบริเวณที่ขยาย
  • ปัญหาความจำขณะทำงาน: เมื่อหายไปอัตโนมัติจะไม่สามารถกลับมาตรวจสอบข้อมูลได้อีก
  • ภาวะเพิกเฉยต่อแบนเนอร์: การใช้มากเกินไปทำให้ผู้ใช้มีแนวโน้มจะมองข้าม
  • ตำแหน่งไม่สอดคล้องกัน: ระยะห่างทางกายภาพระหว่าง UI ที่เป็นตัวทริกเกอร์กับ toast อาจทำให้สับสนว่าเกี่ยวข้องกันอย่างไร
  • การปิดที่ผิดพลาด: อาจเกิดปัญหาที่การกดปุ่ม Esc ปิด UI อื่นไปพร้อมกันด้วย

แหล่งข้อมูลอ้างอิงเพิ่มเติม

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

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

 
GN⁺ 2025-12-12
ความคิดเห็นบน Hacker News
  • ระหว่างบรรยายเรื่องการเข้าถึง ได้เจอสถานการณ์ที่หลังคลิกแล้วมีดีเลย์ 3 วินาทีจนรู้สึกเหมือนไม่มีอะไรตอบสนอง
    • พอกดแบนเนอร์ก็ต้องรอโดยไม่มีสัญญาณใด ๆ แล้วสุดท้ายค่อยพาไปหน้าอื่นที่ไม่เกี่ยวกัน ทำให้อึดอัดมาก
    • คิดว่าปัญหาคือการไม่มีฟีดแบ็กบอกว่ากำลังโหลดอยู่
    • บางคนบอกว่านั่นก็เป็นแค่ลิงก์ `` ธรรมดา และที่ช้าเป็นเพียงเพราะหน้าเว็บใหญ่เกินความจำเป็น
    • อีกคนบอกว่าบน 4G ช้าก็ยังตอบสนองทันที จึงอาจเป็นปัญหาที่เบราว์เซอร์หรือเครือข่าย
  • อ่านเอกสารของ GitHub Primer แล้วรู้สึกน่าสนใจ
    • ถึงจะไม่ได้เห็นด้วยกับทุกอย่าง แต่ก็มีอะไรให้เรียนรู้ และดีกว่าการทำไปตามความรู้สึกมาก
    • ทั้ง Apple และ Android เองก็มี design guidelines ของแต่ละฝั่งเช่นกัน
  • หวังว่าในที่สุดเทรนด์แบบนี้จะเริ่มแพร่หลาย
    • พลาดข้อความไปเยอะมากเพราะการแจ้งเตือนแบบ toast
    • ผู้ใช้อีกคนบอกว่าเห็นด้วยเต็มที่กับประโยคที่ว่า “ไม่แนะนำให้ใช้ toast เพราะมีปัญหาด้าน accessibility” และย้ำว่าถ้ามีศูนย์การแจ้งเตือนก็คงยังพอไหว แต่ก็ยังเป็นวิธีที่ไม่ดีอยู่ดี
  • ฉันชอบ toast สำหรับใช้เป็นการยืนยันแบบไม่รบกวน แต่คิดว่าไม่เหมาะกับการสื่อสารข้อมูลสำคัญ
    • อีกคนอธิบายบริบทการใช้ toast แยกไว้ค่อนข้างละเอียด
      • ตอบสนองทันทีหลังคลิกปุ่ม → ให้ฟีดแบ็กที่ตัวปุ่มเองจะดีกว่า
      • การตอบสนองต่อคีย์ลัด → ใช้ได้
      • การแจ้งว่างานที่ใช้เวลานานเสร็จแล้ว → ใช้ได้ แต่ต้องมีกล่องการแจ้งเตือนแบบถาวรด้วย
      • แสดงคำเตือนเมื่อเข้าเพจ → ถ้าสำคัญก็ควรแสดงเป็นการแจ้งเตือนถาวรภายในหน้า
    • ใน React การเรียก toast() แบบ global ทำได้ง่ายจนมีแนวโน้มถูกใช้พร่ำเพรื่อ แต่มีคนเสนอว่าการเปลี่ยนไปใช้โครงสร้างอย่าง useAlerts() จะดีกว่ามาก
  • สำหรับฉัน toast เป็นเหมือนสายรัดห้ามเลือด
    • มีประโยชน์สำหรับอุดปัญหาเฉพาะหน้าชั่วคราว แต่ไม่ควรปล่อยให้คงอยู่ระยะยาว
    • เวลามีโปรเจ็กต์ใหม่ที่ฟีดแบ็กยังไม่พอ ก็อาจติดมันไว้ชั่วคราว แล้วค่อย ๆ เอาออกทีละอย่างระหว่างปรับปรุง UI
    • องค์กรใหญ่แบบ GitHub อาจไม่จำเป็นต้องใช้ทางแก้ชั่วคราวแบบนี้ แต่ทีมเล็กอาจต่างออกไป
  • ชอบส่วนในเอกสาร GitHub ที่บอกว่า “การสร้าง Issue จำนวนมากต้องมีฟีดแบ็กเพิ่มเติม”
    • อยากให้มีฟีดแบ็กแบบนี้ใน GitHub Actions ด้วย เพราะหลังรันแล้วกว่าผลจะขึ้นใช้เวลานานเกินไป
  • ชอบไอเดียการใช้ toast เป็นบันทึกการกระทำของ UI โดยรวม
    • แทนที่จะเป็นฟีดแบ็กที่หายไปทุกครั้งที่คลิก ก็มีตัวอย่างที่ทำได้ดีอย่าง Sonner
  • ดูเหมือนถึงเวลาที่ควรพิจารณาให้เบราว์เซอร์มีการรองรับ toast แบบเนทีฟแล้ว
    • น่าจะช่วยปรับปรุง accessibility ได้ เช่น การควบคุมเวลา ศูนย์การแจ้งเตือน และการทำงานร่วมกับ screen reader
    • ในเชิงภาพถือว่าโอเค แต่บ่อยครั้งมันหายเร็วเกินไปจนพลาด
    • อาจเข้าใจปัญหาที่ผู้พิการทางสายตาเจอได้ไม่เต็มที่ แต่ก็อยากฟังว่ามีวิธีไหนที่ช่วยเพิ่ม accessibility ให้พวกเขาได้บ้าง
  • ข้อดีของ toast คือทำได้ง่ายและภาระด้านดีไซน์ต่ำ
    • ข้อเสียคือพลาดได้ง่าย และเสี่ยงไปซ้อนทับข้อมูลอื่น
    • ถ้ามีเวลาเหลือพอ ก็น่าจะดีกว่าถ้ากำจัด toast ออกไปทั้งหมด
    • อีกคนชี้ว่า “เพราะมันทำได้ง่าย เลยถูกใช้เกินเหตุในฐานะการแก้ปัญหาแบบประคับประคองที่ดูเหมือนแก้แล้ว”
    • อีกคนบอกว่าเคยใช้ toast เป็นแค่ฟีดแบ็กเพื่อให้ผู้ใช้สบายใจ
    • ในทางกลับกัน บางคนแย้งว่า “toast เป็นเครื่องมือที่มีประโยชน์สำหรับให้ฟีดแบ็กทันทีต่อเหตุการณ์ความสำคัญต่ำ” และมีประสิทธิภาพกว่าทั้ง modal หรือพื้นที่แบบตรึงค้าง
    • มีการวิจารณ์แนวคิดแบบมองโลกขาวดำที่ตัดเครื่องมือทิ้งไปเลยเพียงเพราะมันถูกใช้ผิดวิธี
  • เห็นบทความที่บอกว่า “การเลิกใช้ toast ของ GitHub เป็นข่าวร้ายต่อ accessibility”
    • บางคนรู้สึกว่าข้ออ้างนั้นแปลก
      • มองว่าการบอกว่า GitHub ควรเลิกใช้ toast แล้วไปสร้างมาตรฐานเบราว์เซอร์ผ่าน W3C แทนนั้นเป็นการสรุปที่กระโดดเกินไป
      • แค่ให้รายการแสดงไอเท็มที่ถูกสร้างแล้ว ก็ถือว่าเป็นฟีดแบ็กที่เพียงพอแล้ว
    • อีกคนบอกว่า “ถ้าบอกว่า toast แย่ต่อ accessibility และ UX แต่กลับตำหนิ GitHub ที่ไม่ได้ทำให้มันเป็นมาตรฐานในเบราว์เซอร์ ก็เป็นตรรกะที่ขัดแย้งกันเอง”