มีดโกนของไฟน์แมน

 (defenderofthebasic.substack.com)
3 คะแนน โดย GN⁺ 2024-06-09 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • คำอธิบายทางเทคนิค แม้จะคำนึงถึงผู้เริ่มต้น ก็ควรทิ้ง เบาะแสที่ถูกต้องแม่นยำ ไว้ให้ผู้ที่มีความสามารถพอเข้าใจสามารถจับสภาพจริงได้
  • ข้อความผิดพลาดของ Outlook บอกว่าสามารถคัดลอกเนื้อหาของ “ข้อความที่ไม่มีอยู่แล้ว” ได้ จึงนำเสนอ โมเดลที่ขัดแย้งกันเอง ให้ผู้ใช้
  • หากไม่ซ่อนคำอย่าง server และ cache ผู้ใช้ที่สนใจก็สามารถค้นหาและเรียนรู้ได้ ส่วนผู้ใช้ที่รู้อยู่แล้วก็เข้าใจปัญหาได้เร็วขึ้น
  • การแสดงสถานะที่คุ้นเคยแต่ไม่ถูกต้องอย่าง loading… บดบังว่าระบบกำลังทำอะไรอยู่จริง ๆ และควรพูดตรง ๆ ว่า “กำลังรอให้ป้อนข้อมูลเสร็จ” มากกว่า
  • การทำให้ง่ายเกินไปจะขัดขวางการอนุมานของผู้ใช้ ดังนั้นอย่างน้อยควรทิ้ง เงื่อนงำที่นำไปสู่ความจริง ไว้ เช่น รหัสข้อผิดพลาดและการดำเนินการที่ทำได้

คำอธิบายง่าย ๆ ก็ไม่ควรผิด

  • “มีดโกนของไฟน์แมน” คือเกณฑ์ในการอธิบายเนื้อหาทางเทคนิคแก่ผู้ใช้ทั่วไปว่า หากแม้แต่ คนที่มีความสามารถพอจะเข้าใจ ก็ยังเข้าใจไม่ได้ นั่นไม่ใช่คำอธิบายที่ดี
  • Richard Feynman กล่าวไว้ในบทความหนังสือพิมพ์ว่า แค่ข้อมูลว่าเป็น “เครื่องจักรหนัก 7 ตัน” ยังไม่ทำให้รู้ได้ว่าเป็นเครื่องจักรอะไร และเขาก็ไม่รู้ว่า “atomic bullet” หมายถึงอะไร
  • แก่นสำคัญไม่ใช่ว่าคำอธิบายดูง่ายเพียงใด แต่คือเมื่อผู้อ่านมีความสามารถพอจะเข้าใจเรื่องนั้น เขาสามารถเข้าใจได้จริงหรือไม่

ความสับสนที่เกิดจากข้อความผิดพลาดของ Outlook

  • ในการอภิปรายบน Hacker News ข้อความผิดพลาดต่อไปนี้ถูกล้อเลียน
    • “This message can't be saved because it no longer exists. It can only be discarded. Make sure you copy the contents of the message before you discard if you want to use them later.”
  • ผู้ใช้จึงได้รับการบอกว่าสามารถคัดลอกเนื้อหาของ ข้อความที่ไม่มีอยู่แล้ว ได้ แต่ไม่สามารถบันทึกได้
  • ปัญหาไม่ได้อยู่ที่ผู้ใช้ทั่วไปไม่รู้ศัพท์เทคนิค แต่อยู่ที่การไม่อธิบายสถานะจริงให้แม้แต่ผู้ใช้ที่เข้าใจได้ฟัง

วิธีที่ไม่ซ่อน server และ cache

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

พูดสถานะของซอฟต์แวร์ตามความเป็นจริง

  • เครื่องมือ substack-proxy สร้าง URL สำหรับหลบเลี่ยงการเซ็นเซอร์ของ Twitter โดยอิงจาก URL โพสต์ Substack ที่ผู้ใช้คัดลอกและวาง
  • ขณะผู้ใช้ป้อนหรือแก้ไข URL มีคำขอไปยังเซิร์ฟเวอร์เกิดขึ้นมากเกินไป จึงเพิ่มการหน่วงเวลาประมาณ 1 วินาที
  • ข้อความสถานะแรกคือ loading… แต่จริง ๆ แล้วไม่ใช่กำลังโหลด หากเป็นสถานะที่กำลังรอให้ผู้ใช้ป้อนข้อมูลให้เสร็จ
  • “กำลังรอให้ป้อนข้อมูลเสร็จ” สะท้อนสถานะจริงของเครื่องได้แม่นยำกว่า
  • แม้ในกรณีที่หยุดค้างเพราะข้อผิดพลาด การค้างอยู่ที่ “กำลังรอให้ป้อนข้อมูลเสร็จ” ก็เผยให้เห็น สถานะปัญหา ได้ดีกว่า loading…

แม้ไม่ต้องสอนทุกอย่าง ก็ต้องซื่อตรง

  • ซอฟต์แวร์ไม่จำเป็นต้องสอนทุกอย่างให้ผู้ใช้ทุกคน
  • ผู้ใช้มักไม่ได้อยากรู้สาเหตุ แค่อยากให้มันทำงานได้ถูกต้อง
  • ถึงอย่างนั้น หากจะให้คำอธิบาย ก็ไม่ควรให้โมเดลที่แปลกหรือไม่ถูกต้องเกี่ยวกับวิธีทำงานของคอมพิวเตอร์
  • แนวทางที่ให้เพียงรหัสข้อผิดพลาดแบบเรียบง่ายและสิ่งที่ทำได้ก็เป็นไปได้
    • Error code 1027: file cannot be saved.
    • [Copy contents]
    • [Delete file]
  • ผู้ใช้ที่สนใจสามารถค้นหารหัสข้อผิดพลาดได้ ส่วนผู้ใช้ที่ไม่สนใจก็เห็นตัวเลือกที่ทำได้ทันที

เกณฑ์ของการทำให้ง่าย

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

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

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

 
GN⁺ 2024-06-09
ความคิดเห็นใน Hacker News

  • ตัวอย่าง message-doesn't-exist ดูเหมือนจะเป็นความผิดพลาดที่เกิดขึ้นบ่อยเมื่อผู้เขียนลืม บริบท มากกว่าจะเกิดจากการ ทำให้ง่ายเกินไป
    จากมุมมองของโปรแกรมเมอร์ ระบบพยายามดึงบางอย่างจากเซิร์ฟเวอร์ แล้วเซิร์ฟเวอร์ตอบว่าไม่มี ดังนั้นจะบอกว่า “ไม่มีอยู่” ก็อาจถูกได้
    แต่ในบริบทที่ผู้ใช้กำลังเห็นข้อความนั้นอยู่ตรงหน้า คำว่า “ไม่มีอยู่” เป็นเท็จอย่างชัดเจน
    ควรจัดบริบทใหม่ เช่น “ข้อความนั้นไม่มีอยู่บนเซิร์ฟเวอร์แล้ว ตอนนี้อยู่บนคอมพิวเตอร์ของคุณชั่วคราวเท่านั้น ดังนั้นให้คัดลอกเก็บไว้”
    แม้ผู้ใช้จะไม่รู้ว่า “เซิร์ฟเวอร์” คืออะไร แต่ถ้ามีข้อมูลว่า “ไม่มีอยู่ที่ไหนสักแห่ง” ประโยคก็จะสมเหตุสมผลขึ้นมาก
    ถ้าช่างซ่อมรถชี้ไปที่รถทั้งคันแล้วบอกว่า “อันนี้จะถูกเปลี่ยน” ก็จะสับสน แต่ถ้าบอกว่า “xxx จะถูกเปลี่ยน” แม้ไม่รู้ว่า xxx คืออะไร ก็ยังพอเข้าใจได้

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

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

    • สักวัน Google อาจออกอัลกอริทึม เวอร์ชัน Classic เหมือน Coca-Cola ก็ได้
    • ถ้าออกแบบระบบเพื่อคนโง่ สุดท้ายก็จะมีแต่ คนโง่เท่านั้น ที่ใช้มัน
    • มีเรื่องเล่าว่าอุปกรณ์ของนักบินทหารถูกออกแบบโดยอิงจาก คนโดยเฉลี่ย อยู่ช่วงหนึ่ง แต่ต่อมาพบว่าจริง ๆ แล้วคนส่วนใหญ่เบี่ยงเบนจากค่าเฉลี่ยอย่างมากอย่างน้อยหนึ่งด้าน
      จึงทำให้อุปกรณ์ปรับได้ และประสิทธิภาพก็ดีขึ้นมาก ความผิดพลาดก็ลดลง
      แต่ในวงการเทคโนโลยี ไม่เข้าใจว่าทำไมกลับพูดในทางตรงกันข้ามว่า ยิ่งปรับให้เข้ากับผู้ใช้เฉลี่ยในจินตนาการมากเท่าไร ก็ยิ่งดีหรือทำเงินได้มากขึ้นเท่านั้น
      สงสัยว่าทำไมถึงทำเหมือนว่าความหลากหลายของแต่ละบุคคลไม่จำเป็นต้องสนใจ

  • ที่คิดถึง Norton Disk Doctor ไม่ใช่เพราะทำงานกู้คืนไดรฟ์ แต่เพราะมันมี อินเทอร์เฟซที่เคารพสติปัญญาของผู้ใช้
    ระบบอื่น ๆ ที่เกี่ยวกับอุปกรณ์จัดเก็บข้อมูลมักโยนข้อความที่ถอดความหมายไม่ได้มาให้ เช่น “Mode 5/7? [Y]” หรือถามคำถามที่ทำให้โง่เกินไปอย่าง “Are you sure? [N]”
    ไม่รู้ว่าต้องมั่นใจเรื่องอะไร, mode 5 คืออะไร, เป็น 7 หรือเป็นทั้งคู่กันแน่
    ในทางกลับกัน Norton อธิบายเป็นหลายย่อหน้าว่าแต่ละตัวเลือกหมายถึงอะไร อธิบายแนวคิดในบริบท พร้อมบอกข้อดีและความเสี่ยง
    มันทำให้เลือกโดยมีข้อมูล แทนที่จะกด Y ไปเรื่อย ๆ แล้วปล่อยให้เป็นเรื่องของโชค
    ความเคารพต่อผู้อ่านและผู้ใช้แบบนี้ใช้ได้กับงานเขียนเชิงเทคนิคทุกอย่าง ไม่ว่าจะเป็นคู่มือ อินเทอร์เฟซผู้ใช้ บล็อกโพสต์ หรือเอกสาร API
    แทนที่จะทำให้งานเขียนโง่ลงเพื่อ “คนทั่วไป” ผมคิดว่าควรให้ความรู้จนผู้อ่านทุกคนที่อ่านและเข้าใจเติบโตทางเทคนิคขึ้นอีกเล็กน้อยจะดีกว่า
    อนึ่ง “Mode 5/7?” เป็นข้อความที่พบจริงในอาร์เรย์ Hitachi SAN ที่เก็บข้อมูลทั้งหมดของหน่วยงานรัฐบาลแห่งหนึ่ง และคู่มือก็อธิบายอย่างใจดีเพียงว่า ตัวเลือกนี้ใช้เปิดหรือปิด mode 5/7
    ถ้าเลือกผิด อาร์เรย์อาจล้างข้อมูลตัวเองและแมวอาจตาย หรืออาจไม่มีอะไรเกิดขึ้นเลยก็ได้ ใครจะรู้

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

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

    • การไล่ล่าคลิกทำให้ปัญหาแย่ลงอย่างแน่นอน แต่ดังที่ Murray Gell-Man กล่าวไว้ วารสารศาสตร์กับการทำให้ง่าย แทบจะเป็นคำพ้องความหมายกัน
      https://www.goodreads.com/quotes/65213-briefly-stated-the-ge...
    • ไม่เคยนึกถึงมุมมองเรื่อง การลดคำขอซัพพอร์ต มาก่อน แต่น่าพิจารณา
    • สำหรับทฤษฎีเรื่องการมีส่วนร่วมและการสร้างรายได้ เราไม่ควรแค่ไม่เห็นด้วย แต่ควรเริ่ม ต่อต้านอย่างรุนแรง
      ต้องทำให้การตัดสินใจไล่ตามเป้าหมายแบบนั้นกลายเป็นทางเลือกที่มีความเสี่ยงจริง ๆ สำหรับคนที่ตัดสินใจทำ

  • ในงานต้องต่อสู้กับปัญหานี้อยู่มาก
    ไม่สามารถสมมติได้ว่าผู้อ่านเชี่ยวชาญภาษาอังกฤษ เข้าใจหัวข้อ หรือแม้แต่สนใจจะเข้าใจ
    ดังนั้นจึงเลือกใช้ การเขียนที่เรียบง่ายและไม่กำกวม และตอนนี้กำลังทดลองรูปแบบที่แค่กวาดตาดูก็จับใจความได้
    ส่วนตัวคิดว่า nhs.uk เป็นตัวอย่างที่ดีที่สุดที่ควรเรียนรู้
    คนไม่ได้โง่ แต่ยุ่ง เหนื่อย ขี้เกียจ หรือแค่ไม่ได้สนใจรายละเอียดมากนัก
    มีสมดุลระหว่างการเคารพสติปัญญาของผู้อ่านกับ การเคารพเวลาของผู้อ่าน

    • อาจข้าม nhs.uk แล้วไปดู แนวทางการเขียน ของ uk.gov โดยตรงก็ได้
      https://www.gov.uk/guidance/content-design/writing-for-gov-u...
    • สงสัยว่าทำไมถึงหลีกเลี่ยง รูปย่อของคำ ทั้งหมด ยกเว้นแค่ “can’t”

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

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

  • ที่ว่า “คอมเมนต์ที่ผมชอบที่สุดคือของ lisper...” นี่เท่ดีนะ มีคนจำผมได้
    ผมกำลังตั้งใจเขียนซีรีส์บล็อกเกี่ยวกับวิธีการทางวิทยาศาสตร์ แต่แทบไม่ได้รับฟีดแบ็กเลย เลยรู้สึกแปลกที่ คอมเมนต์เบา ๆ แบบนี้กลับได้รับความสนใจ
    ชีวิตก็ตลกเป็นบางครั้ง

    • ลิงก์โปรไฟล์เสียอยู่ จะตามอ่านเพิ่มเติมได้ที่ไหน? ถ้าจะโปรโมตตัวเอง คุณอยากให้เราอ่านอะไร? ตรงนี้ให้เป็น ไวลด์การ์ด แล้วกัน

  • ผู้เขียนเองก็ยังถ่ายทอดคำพูดของ Feynman ได้ไม่ถูกต้อง
    ไม่ใช่ “And there are not sixty two kinds of particles” แต่ต้องเป็น “And there are now sixty two kinds of particles”

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

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

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

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