การแจ้งเตือนแบบ Toast เป็น UX ที่แย่

 (maxschmitt.me)
2 คะแนน โดย GN⁺ 2024-08-21 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • จุดอ่อนสำคัญของการแจ้งเตือนแบบ Toast คือ จุดที่ผู้ใช้กำลังโฟกัส กับตำแหน่งที่แสดงฟีดแบ็กถูกแยกจากกัน จึงเชื่อมโยงผลลัพธ์ของการกระทำที่เพิ่งทำไปได้ยาก
  • ในโฟลว์การบันทึกของ YouTube สายตาต้องย้ายจากปุ่ม Save ด้านขวา ไปยังโมดัลตรงกลาง และต่อไปยัง Toast มุมล่างซ้าย ทำให้การโต้ตอบขาดตอน และยังไม่มีตัวแสดงการโหลดระหว่างที่รอ
  • หลังเปลี่ยนสถานะเช็กบ็อกซ์ ผู้ใช้ต้องรอให้ Toast ก่อนหน้าหายไปก่อน จึงจะเห็นข้อความยืนยันล่าสุดได้ และปุ่ม Undo บน Toast ก็ไม่จำเป็นในกรณีที่เพียงกดเช็กบ็อกซ์ซ้ำอีกครั้งก็ได้
  • วิธีที่ดีกว่าคือวางฟีดแบ็กไว้ในตำแหน่งเดียวกับการกระทำ โดยแสดงเพลย์ลิสต์ไว้ใต้ปุ่ม และใช้ ตัวแสดงการโหลด เพื่อบอกสถานะระหว่างที่มีการเปลี่ยนแปลงเช็กบ็อกซ์
  • สิ่งที่แย่กว่า Toast คือการไม่มีฟีดแบ็กเลย ดังนั้นหากยังไม่มีเวลาพอจะออกแบบหรือทำฟีดแบ็กที่ดีกว่า Toast ก็ยังดีกว่าไม่มีอะไรเลย

ปัญหาพื้นฐานของ Toast

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

ปัญหาของโฟลว์การบันทึกใน YouTube

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

วิธีแก้โดยไม่ใช้ Toast

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

กรณีของ Gmail และฟีดแบ็กการคัดลอก

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

ถึงอย่างนั้น ฟีดแบ็กก็ยังจำเป็น

  • สิ่งที่แย่กว่า Toast คือ การไม่มีฟีดแบ็กเลย
  • หากยังไม่มีเวลาพอจะออกแบบหรือพัฒนากลไกฟีดแบ็กที่ดีกว่า Toast, Toast ก็ยังดีกว่าไม่มีอะไรเลย

วิธีที่ Cakedesk หลีกเลี่ยงการใช้ Toast

  • Cakedesk เป็นแอปออกใบแจ้งหนี้แบบ offline-first ไม่มีค่าสมาชิก และสามารถส่งอีเมลได้ภายในแอป
  • หลังจากกดปุ่ม Send ของอีเมล แทนที่จะให้ฟีดแบ็กผ่าน Toast ระบบถูกออกแบบให้การเปลี่ยนสถานะต่อเนื่องอยู่ในโฟลว์เดิม
    • ใบแจ้งหนี้ที่ยังไม่ถูกส่งจะมีปุ่ม Send อยู่ในรายการ
    • ระหว่างส่งอีเมล โมดัลจะยังคงเปิดอยู่ และปุ่มส่งจะแสดงสถานะว่ากำลังส่ง
    • เมื่อส่งสำเร็จ อีเมลจะเคลื่อนออกนอกหน้าจอด้วยแอนิเมชัน เพื่อสื่อว่าการส่งเสร็จสิ้นแล้ว
    • ปุ่ม Send ในรายการจะเปลี่ยนเป็นเช็กบ็อกซ์ Paid เพื่อยืนยันว่าอีเมลถูกส่งแล้ว และพาไปสู่การกระทำถัดไปที่มีประโยชน์
  • ผู้ใช้ยังสามารถกดปุ่มตามบริบทเพื่อตรวจสอบได้ด้วยว่าอีเมลถูกส่งไปแล้วหรือไม่

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

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

 
wkang586 2024-08-26

งั้นก็หมายความว่า toast ที่แย่ต่างหากที่แย่ใช่ไหม??
 
GN⁺ 2024-08-21
ความเห็นจาก Hacker News

  • https://en.wikipedia.org/w/index.php?title=Toast_(computing)

  • ยังไม่ถูกโน้มน้าว ประเด็นส่วนใหญ่ดูเหมือนจะบอกว่า UX ที่ซ้ำซ้อน คือ UX ที่แย่
    ตัวอย่างเช่น เมื่อเก็บอีเมลเข้าคลังแล้วมันหายไปจากรายการ จึงสื่อเป็นนัยอยู่แล้วว่าสำเร็จ หรือปุ่มมีเครื่องหมายถูกแล้วจึงไม่จำเป็นต้องมี toast ผมเห็นด้วยอย่างหนักแน่นได้ยาก การสื่อสารสิ่งเดียวกันพร้อมกันด้วยวิธีต่างกันไม่ใช่บั๊ก แต่เป็นฟีเจอร์ และมีอยู่ในภาษามนุษย์โดยทั่วไปด้วย เพราะมันช่วยให้ข้อความถูกส่งถึงได้แม้ในเงื่อนไขที่ไม่สมบูรณ์แบบ
    toast แจ้งสถานะของทุกการกระทำด้วยวิธีมาตรฐานเดียว และถ้าเป็นไปได้ก็ให้ undo ด้วย จึงช่วยให้ผู้ใช้เรียนรู้แพตเทิร์นได้เร็ว เครื่องหมายเพิ่มเติมใกล้ตำแหน่งที่กระทำก็มีคุณค่าเช่นกัน แต่หลายครั้งความหมายจะชัดขึ้นเมื่ออยู่ร่วมกับ toast หากตัด toast ออกแล้วแทนที่ด้วยตัวบ่งชี้เฉพาะหลายแบบ ผู้ใช้ต้องเรียนรู้จากบริบทเพียงอย่างเดียวว่าการแสดงออกหลายแบบนั้นหมายถึง “เสร็จแล้ว” ซึ่งอาจไม่ดีเป็นพิเศษสำหรับผู้สูงอายุ ผู้พิการทางสายตา และเด็ก
    ตราบใดที่มันไม่ได้รบกวนจริง ๆ toast ก็ไม่ใช่ UX ที่แย่ แต่เป็น UX ที่ซ้ำซ้อน และนักออกแบบ UX ไม่ควรหมกมุ่นกับการกำจัดความซ้ำซ้อน

    • น่าเสียดายที่สองอย่างนั้นไม่ได้สื่อสารสิ่งเดียวกัน
      ในตัวอย่าง YouTube ช่องทำเครื่องหมายเป็น optimistic update 100% ส่วนการแจ้งเตือนแบบ toast หมายถึงคำขอที่ส่งไปยังแบ็กเอนด์แบบ async สำเร็จแล้ว การเก็บอีเมลเข้าคลังก็เช่นเดียวกัน ข้อความถูกลบออกจากรายการแบบ optimistic และ toast แสดงว่ามันถูกเก็บเข้าคลังจริงแล้ว
      ถ้าเป็นไปได้ ผมอยากได้ toast เฉพาะเมื่อ commit การเปลี่ยนแปลงล้มเหลวมากกว่า โดยปกติการที่ toast เด้งวาบขึ้นมาจะดึงความสนใจออกจากสิ่งที่ผมกำลังทำ และถ้ามันอยู่ไกลจากตำแหน่งที่ผมกระทำบนหน้าจอก็ยิ่งทำให้เสียสมาธิมากขึ้น
    • ไม่เลย toast แย่ ข้อความที่อยู่บริเวณขอบเขตการมองเห็นหรือความสนใจของผม เช่น ข้อความที่เด้งขึ้นที่ด้านหนึ่งของจอไวด์สกรีน ทำให้สับสนอย่างชัดเจน ผมกำลังจัดการปัญหานี้อยู่ตรงนี้ แต่มีอะไรบางอย่างวาบขึ้นตรงโน้น พอผมย้ายโฟกัสไปอ่าน ครึ่งหนึ่งก็หายไปแล้ว
      ควรวางข้อความไว้ในที่ที่ ความสนใจของผู้ใช้อยู่แล้ว UI นำสายตาผมไปที่นั่นแล้ว ก็ให้แสดงตรงนั้น
    • ผมใช้คอมพิวเตอร์โดยหลักเป็น เครื่องมือขยาย โดยขยายข้อความและบริเวณรอบเคอร์เซอร์เมาส์/นิ้ว toast และการแจ้งเตือนส่วนใหญ่ไม่ได้อยู่ในตำแหน่งที่ผมทำงาน จึงแทบพลาดไปหมด ในวิธีใช้งานของผม ฟีดแบ็กใกล้รายการที่กำลังโต้ตอบอยู่เท่านั้นที่มีคุณค่า
    • แม้จะบอกว่า “ความซ้ำซ้อนในการสื่อสารเป็นฟีเจอร์ ไม่ใช่บั๊ก” แต่ถ้ามีข้อมูลรบกวนมากเกินไป ผู้ใช้จะถูกฝึกให้เพิกเฉยต่อสิ่งเหล่านั้น และปัญหาจะเกิดขึ้นเมื่อบางครั้งมีข้อมูลที่สำคัญจริง ๆ ปะปนเข้ามา
      บทเรียนคือ อย่าส่งข้อมูลที่ไม่จำเป็นอย่างเคร่งครัดไปยังผู้ใช้
      อ่านเพิ่มเติม:
      https://en.wikipedia.org/wiki/Banner_blindness
      https://en.wikipedia.org/wiki/Alarm_fatigue
      https://en.wikipedia.org/wiki/Inattentional_blindness
      https://en.wikipedia.org/wiki/Habituation
    • ผมคิดว่าสิ่งที่ข้อเสนอการปรับปรุงต้องการสื่อคือแบบนี้ หากกังวลว่าองค์ประกอบ UI ที่ผู้ใช้โต้ตอบอยู่ไม่สามารถสื่อสารสถานการณ์ปัจจุบันได้เพียงพอ ก็ไม่ควรเพิ่มองค์ประกอบที่สองที่แบ่งความสนใจของผู้ใช้และบังคับให้รีบอ่านเพื่อเชื่อมโยงเอง แต่ควรปรับปรุงองค์ประกอบนั้นเอง ควรสื่อสารความล้มเหลวภายในบริบทขององค์ประกอบที่ผู้ใช้โต้ตอบด้วย เพื่อให้ความเชื่อมโยงชัดเจน
      ในกรณีเลวร้ายที่สุด toast พอจะสมเหตุสมผลในฐานะทางเลือกสุดท้ายที่ต้องส่งสารถึงผู้ใช้โดยไม่มีบริบท เช่น ถ้าผู้ใช้เอาเครื่องหมายถูกออกจากเพลย์ลิสต์ แล้วปิดรายการเพลย์ลิสต์ระหว่างที่กำลังบันทึก แต่การบันทึกล้มเหลว บริบทของการกระทำหายไปแล้ว ดังนั้น toast ที่แสดงข้อมูลในตำแหน่งใดตำแหน่งหนึ่งบนหน้าจอแบบค่อนข้างสุ่มก็พอเข้าใจได้
      ถึงอย่างนั้น หากต้องการให้ผู้ใช้เข้าใจข้อผิดพลาดอย่างถูกต้อง toast ก็มีแนวโน้มไม่ใช่วิธีที่ดีที่สุด ในแอปที่อิงโฆษณาอย่าง YouTube ซึ่งผู้ใช้คือสินค้า อาจไม่ค่อยสนใจนักหากผู้ใช้พลาดข้อผิดพลาดแบบนี้ หรืออาจถึงขั้นต้องการแบบนั้นด้วยซ้ำ แต่ถ้าเป็นแอปสำหรับงาน คุณคงไม่อยากเสี่ยงให้ผู้ใช้พลาด toast หรือสับสนกับข้อผิดพลาดอื่น โดยปกติแล้ว การเปิดองค์ประกอบนั้นขึ้นมาอีกครั้งและแสดงข้อผิดพลาดในบริบทจะช่วยผู้ใช้ได้มากกว่า อาจเปิดรายการเพลย์ลิสต์และใส่อนิเมชันดึงความสนใจไปที่ความจริงว่าการเปลี่ยนแปลงยังไม่ได้ถูกบันทึก นี่อาจเป็นอุดมคติที่ทำให้เป็นระบบได้ยาก แต่ในอุดมคติแล้วควรเห็น ข้อผิดพลาดในบริบท เสมอ

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

    • เพิ่มเติมคือ toast บางอันแสดงข้อมูลสำคัญที่ผู้ใช้ต้องใช้ แต่หายไปเร็วเกินไป และเพราะข้อจำกัดด้านขนาดของ toast เนื้อหาจึงไม่ครบถ้วนด้วย
      ผมมักต้องเข้าไปที่การแจ้งเตือนเพื่อดูสิ่งที่พลาดไป เพราะมันดูสำคัญแต่มีเวลาไม่พอให้อ่านจนจบ เมื่อกดรายการที่ดูเหมือนข้อความถูกตัดตรงนั้น ก็หวังว่ามันจะพาไปยังบริบทเต็ม แต่จริง ๆ แล้วการแจ้งเตือนหายไปเฉย ๆ และแค่เปิดแอปขึ้นมา โดยไม่ได้ deep link ไปยังปัญหานั้น จากนั้นก็ต้องไล่หาใน UI มาตรฐานของแอปว่าปัญหาที่ว่าอาจจะปรากฏอยู่ตรงไหน หรืออาจไม่ปรากฏเลยก็ได้
      เจอเรื่องแบบนี้มานับครั้งไม่ถ้วน และทุกครั้งก็โมโหคนที่ออกแบบระบบแบบนี้
    • toast ทำให้รู้สึกเหมือนน่าจะมี event log อยู่ที่ไหนสักแห่งให้ย้อนกลับไปดูได้ว่าเกิดอะไรขึ้น แต่ในความเป็นจริงไม่มี event log ที่เข้าถึงได้ และเมื่อข้อความ toast หมดเวลาหายไป มันก็หายไปตลอดกาล
    • ลองคิดเป็น thought experiment ว่า toast ควรอยู่บนหน้าจอนานแค่ไหน? ต้องให้เวลาผู้ใช้อ่าน แต่เราไม่รู้ว่าผู้ใช้จะเงยหน้ามองเมื่อไร และไม่รู้ความเร็วในการอ่านของเขา จึงไม่มีเพดานบนที่ปลอดภัย
      วันนี้ผมเจอปัญหานี้กับลูกชาย เขากำลังฝึกความเร็วในการอ่านและเรากำลังใช้แอปใหม่ด้วยกัน แต่ toast โผล่มาเรื่อย ๆ จนเขาตามไม่ทันและเสียสมาธิ สุดท้ายผมต้องอ่านออกเสียงให้ฟัง ถ้าเป็นข้อความที่ค้างอยู่นานกว่านี้ เขาน่าจะทำสำเร็จได้โดยไม่ต้องให้ช่วยเพิ่มเติม
    • ทางแก้ที่ดีกว่าคือสมมติว่าการทำงานสำเร็จ และแสดงข้อความแบบนี้ เฉพาะเมื่อเกิดข้อผิดพลาด เท่านั้น
    • การใช้งาน toast ที่แย่ที่สุดคือแบบที่บังองค์ประกอบ UI จริง ๆ ทำให้มองไม่เห็นและคลิกไม่ได้จนกว่า toast จะหายไป

  • YouTube มีตัวอย่างที่ดีกว่านี้
    ไปที่ https://www.youtube.com/feed/history แล้วกด “Comments” ทางขวา จากนั้นลองลบคอมเมนต์หนึ่งรายการ จะมี toast หนึ่งอันแจ้งว่ากำลังจะลบ และหลังจากนั้น 1–2 วินาทีก็มี toast อีกอันแจ้งว่าลบแล้ว
    ถ้าลบคอมเมนต์หลายรายการต่อเนื่องกันอย่างรวดเร็ว จะมี toast แจ้งว่ากำลังจะลบหลายอันขึ้นมาก่อน แล้วหลังจากหน่วง 1–2 วินาที toast ยืนยันแต่ละอันจะขึ้นมาตามลำดับ การลบจริงก็ดำเนินไปทีละรายการเช่นกัน จึงต้องรอ toast ยืนยันทั้งหมด แม้จะกดลบคอมเมนต์ 10 รายการได้ภายใน 2–3 วินาที แต่การยืนยันจะใช้เวลามากกว่า 10 วินาที
    คอมเมนต์ไลฟ์ก็เหมือนกัน:
    https://myactivity.google.com/page?page=youtube_live_chat&co...

  • โดยทั่วไปไม่เห็นด้วยกับส่วนที่ว่า “ปุ่ม Undo ใน toast ไม่จำเป็น เพราะผู้ใช้แค่คลิก checkbox อีกครั้งก็พอ” หากเผลอคลิกที่ไหนสักแห่งโดยไม่รู้แน่ชัดว่าตรงไหน และยังไม่รู้จักแอปดีพอที่จะย้อนกลับได้ง่าย ๆ จากข้อความอย่างเดียว การเลิกทำ นั้นมีประโยชน์มาก

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

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

    • อยากเพิ่มอีกหนึ่งสถานการณ์ คือกรณีที่องค์ประกอบ UI ที่จะใช้ให้ฟีดแบ็กมักถูกลบไปแล้ว แต่ยังอยากแสดงฟีดแบ็กอยู่
      ถ้าลบงานออกจากบอร์ดไปแล้ว ก็ไม่สามารถแสดงวิธีย้อนกลับไว้บนงานนั้นได้ แม้จะ undo ด้วยคีย์ลัดได้ แต่ผู้ใช้จะรู้ได้อย่างไรในเชิงภาพ?
      ในรายการงานควรมีแต่งานเท่านั้น จึงไม่ควรใส่โน้ตแทนงาน และจะไม่สร้างสิ่งที่เหมือนงานย่อยที่มีไว้แสดงข้อความอย่างเดียวด้วย เพราะนั่นเท่ากับยัดเจตนาที่ไม่มีฟังก์ชันลงไปในคอมโพเนนต์งาน และก็ไม่อยากไม่บอกผู้ใช้เลยด้วย เพราะแม้จะเห็นชัดว่างานถูกลบไปแล้ว แต่ไม่ชัดว่าจะย้อนกลับการกระทำที่น่ากังวลซึ่งเกิดจากคลิกเดียวได้อย่างไร อีกทั้งก็ไม่อยากบังคับให้ยืนยันก่อนลบงานทุกครั้งให้น่ารำคาญ เพราะนี่เป็นฟังก์ชันหลักของรายการงาน จึงควรทำได้ทันทีและยกเลิกได้ทันที
      เคสเฉพาะเล็ก ๆ แบบนี้น่าจะมีอยู่มากมาย toast ถูกคิดค้นขึ้นมาด้วยเหตุผลบางอย่าง การที่คนเอาไปใช้พร่ำเพรื่อแบบน่ารัก ๆ ไม่ได้แปลว่ามันไม่มีประโยชน์อย่างเฉพาะเจาะจงในบางสถานการณ์
    • แล้วในงานแบบโมดัลที่หลังจากผู้ใช้เริ่มงานแล้ว 99% ของกรณี ผู้ใช้อยากส่งงานนั้นไปทำงานใน เบื้องหลัง แล้วไปทำอย่างอื่น ควรให้ฟีดแบ็กแบบนั้นไว้ตรงไหน?
    • ยังมีตัวอย่างที่เกี่ยวข้องกับการกระทำปัจจุบันของผู้ใช้ แต่เกิดอยู่นอกขอบเขตหน้าจอที่มองเห็นอยู่ เช่น การเสียบ USB flash drive หรือใช้งานฟีเจอร์เกี่ยวกับฮาร์ดแวร์อื่น ๆ
      การกระทำแบบนี้ไม่มีบริบทบนหน้าจอ และบ่อยครั้งต้องมีการกระทำเพิ่มเติม ต่อให้ไม่มีการกระทำเพิ่มเติม การยืนยันว่าตรวจพบการกระทำของผู้ใช้แล้วก็มีประโยชน์อย่างชัดเจน
    • ไม่ได้หมายความว่า Growl เป็นผู้คิดค้นการแจ้งเตือนแบบระบบปฏิบัติการ Growl ออกมาในปี 2004 ส่วน Windows XP มีการแจ้งเตือนตั้งแต่ปี 2001 แล้ว ถ้านับข้อความของ Clippy เป็นการแจ้งเตือน ก็อาจย้อนกลับไปได้อย่างน้อยถึง Microsoft Bob (1995)

  • สำหรับคนที่สับสน บทความนี้ไม่ได้เกี่ยวกับขนมปังปิ้ง [1] แต่เกี่ยวกับ UI widget ประเภทหนึ่ง [2]
    [1] https://en.wikipedia.org/wiki/Toast_(food)
    [2] https://en.wikipedia.org/w/index.php?title=Toast_(computing)

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

  • สำหรับประเด็นที่ว่า “ปุ่ม Undo ใน toast ไม่จำเป็น เพราะผู้ใช้แค่คลิก checkbox อีกครั้งก็ได้” ผมกลับรู้สึกขอบคุณฟีเจอร์นี้เป็นพิเศษ หลายครั้งมากที่ผมคิดว่าเก็บอีเมลเข้าคลังแล้ว แต่ toast บอกว่าผมกดปุ่มรายงานสแปม ถ้าไม่มีมันก็คงไม่รู้เลย
    อีกปัญหาพื้นฐานของ toast ที่ต้นฉบับมองข้ามคือ งานบนเว็บเป็นแบบ อะซิงโครนัส เราไม่รู้ว่างานสำเร็จ ล้มเหลว หรือแม้แต่ถูกบันทึกบนเซิร์ฟเวอร์หรือยัง toast ให้การอัปเดตแบบอะซิงโครนัสเกี่ยวกับสถานะของเซิร์ฟเวอร์
    แน่นอนว่าผมเห็นด้วยว่า toast บางแบบน่ารำคาญ และบางครั้งก็บังเนื้อหา UI สำคัญแถมปิดไม่ได้

    • ต้นฉบับพลาดประเด็นของ toast ไปอย่างสิ้นเชิง การกระทำบางอย่างของผู้ใช้ 1) อาจเกิดจากความผิดพลาด และ 2) มักทำซ้ำบ่อย จึงไม่เหมาะกับกล่องยืนยัน
      ดังนั้นถ้าเผลอกดอะไรสักอย่างแล้วอีเมลหายไปจาก inbox ทันที ก็ต้องมี toast พร้อมปุ่ม undo หากอยู่เฉย ๆ แล้วตัวไปพิงปุ่มจน toast โผล่ขึ้นมา คุณจะรู้สึกโชคดีที่มีมันอยู่ ถ้าเป็นไปได้ควรมีคำอธิบายการกระทำที่เกิดขึ้นและปุ่ม undo
      ใน Gimp เมื่อกด Tab UI ทั้งหมดจะถูกซ่อนไป และถ้าไม่รู้คีย์ลัดก็ไม่มีวิธีกลับมา สำหรับศิลปินที่อยากโฟกัสดูภาพ นี่เป็นฟีเจอร์ที่ดี แต่ตอนที่เผลอกดแล้วต้องค้นหา “gimp how to fix interface disappeared” ผมถึงกับรู้สึกว่าอยากได้ toast ที่มีปุ่ม undo มากแค่ไหน นึกไม่ออกเลยว่าคนที่ไม่คุ้นกับคอมพิวเตอร์จะตอบสนองอย่างไร

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

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

    • ถ้าผู้ใช้รู้อยู่แล้ว และมีไม่เกิน 1 แผงหลักกับ 2 sidebar ผมคิดว่า UX แบบสไลด์ซ้ายขวาเพื่อเปิด sidebar ก็โอเค
      แอป Discord บนมือถือเคยใช้วิธีนี้ทั้งกับ sidebar ซ้ายและขวา แต่ถึงจุดหนึ่งมีใครบางคนเกิดไอเดีย “ยอดเยี่ยม” ว่า gesture “ปัดเพื่อตอบกลับ” สำคัญกว่าการนำทางในแอป ตอนนี้ถ้าจะดู sidebar ขวาต้องกดปุ่มเล็ก ๆ ที่คลุมเครือแทน
    • จำได้ว่าทันทีที่ติดตั้ง Snapchat ก็รู้เลยว่ามันแย่แค่ไหน มีฟังก์ชันต่างกันอยู่ตามมุมต่าง ๆ เรื่องแบบนี้ควรผิดกฎหมาย
    • เห็นด้วยเต็มที่ iOS ก็เต็มไปด้วยอะไรแบบนี้แน่นอน แม้แต่บนแท็บเล็ตที่มีพื้นที่หน้าจอเหลือเฟือก็ยังเป็น
    • “toast” ส่วนใหญ่—ตอนนี้รู้คำเรียกแล้ว—ผมคิดว่ามันซ้ำซ้อนและไร้ประโยชน์ ปกติก็พลาดไปโดยสิ้นเชิง โดยทั่วไปมองว่าไม่ได้เป็นอันตราย แต่ไม่ควรใช้เพื่อส่งข้อมูลสำคัญ
      ส่วน “แผงที่ซ่อนอยู่” ผมคิดมาตลอดว่ามันเป็นบั๊ก แต่บางคนอาจเคยคิดว่ามันเป็นไอเดียที่ดีก็ได้
      ผมใช้แอป Apple Connect สำหรับจัดการแอปใน App Store บ่อย ๆ เวลาใช้ iPad Mini ในโหมดแนวตั้งแล้วเลือกแอปหนึ่งของตัวเอง ปุ่มย้อนกลับมักจะหายไป จากนั้นก็เลือกบัญชีอื่น หรือเลือกแอปอื่นในบัญชีปัจจุบันไม่ได้
      จนกว่าจะหมุน iPad เป็นแนวนอนจริง ๆ เมื่อนั้น navigator จะปรากฏทางซ้าย และสามารถเลือกแอปอื่นหรือเปลี่ยนบัญชีได้
      พูดตรง ๆ ผมค่อนข้างผิดหวังกับ UX ทั้งหมดของ backend ของ Apple App Store ส่วน frontend ก็ไม่ได้ชอบนักเหมือนกัน แต่ backend คือที่ที่ต้องใช้ตลอด พอนึกถึงว่าพวกเขาใส่ใจกับประสบการณ์ผู้ใช้ในส่วนอื่น ๆ ของแพลตฟอร์มมากแค่ไหน มันก็ค่อนข้างน่าตกใจ