ถ้าเป็นปุ่ม งานที่ต้องทำก็มีอยู่แค่อย่างเดียว

• แม้แต่ปุ่มง่าย ๆ อย่างการหมุนรูป ก็ทำให้ประสบการณ์ใช้งานต่างกันมากได้ ขึ้นอยู่กับว่าจะจัดการกับ การป้อนซ้ำอย่างรวดเร็ว อย่างไร
• บน iPhone ระบบจะจำการกด หมุน 90 องศา หลายครั้งไว้ และเมื่อแอนิเมชันจบก็จะหมุนครั้งถัดไปต่อทันที
• บน Nothing Phone/Android แม้จะมีแรงสั่นและเสียงยืนยันการแตะ แต่ การแตะที่ตามมาระหว่างแอนิเมชันหมุนจะถูกมองข้าม
• ในสถานการณ์ที่ต้องหมุนภาพเอกสารหลายใบ แม้แต่ UI แต่งภาพแบบทั่วไปก็ยังต้องการการควบคุมที่เร็วและคาดเดาได้มากขึ้น
• แทนที่จะบังคับให้ผู้ใช้รอจนแอนิเมชันจบ ปุ่มควรรับอินพุตด้วยการบัฟเฟอร์การแตะ หรือหยุด/เร่งแอนิเมชันระหว่างทาง

---

วิธีที่ปุ่มหมุนรูปจัดการกับการป้อนซ้ำ

• ปุ่มหมุนรูปเป็นคอนโทรลมาตรฐานที่เมื่อกดหนึ่งครั้ง มักจะ หมุนทวนเข็มนาฬิกา 90 องศา และเมื่อกดอีกครั้งก็จะทำซ้ำแบบเดิม
• แอนิเมชันการหมุนช่วยแสดงกระบวนการเปลี่ยนทิศของรูป เพื่อให้ผู้ใช้ไม่เสียการรับรู้ทิศทาง
• ถ้ากดหมุน 90 องศาแบบเร็ว ๆ 8 ครั้ง ภาพก็ควรหมุนครบสองรอบแล้วกลับมาที่ทิศเดิม เหมือนสิ่งที่วิศวกรเรียกว่า “no op”
• บน iPhone ความคาดหวังนี้เกิดขึ้นจริง
  • ระบบจำอินพุตการแตะอย่างรวดเร็วไว้
  • เมื่อการหมุนก่อนหน้าจบ ก็จะทำการหมุนถัดไปที่รออยู่
• บน Nothing Phone/Android ผลลัพธ์กลับต่างออกไป
  • ปุ่มให้การยืนยันการแตะผ่านแรงสั่นและเสียง
  • หากแอนิเมชันการหมุนก่อนหน้ายังไม่จบ การแตะใหม่จะถูกมองข้าม

แม้แต่ UI แบบทั่วไปก็ต้องการการจัดการอินพุตที่แข็งแรงขึ้นเมื่อทำงานซ้ำ

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

[GN⁺]

ความคิดเห็นจาก Hacker News

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

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

  • ตามบทความระบุว่า:

    The Nothing Phone button gives you a tap confirmation via both haptics and sound, and then ignores the tap if a previous rotation is still animating.

    นี่แหละคือปัญหา จำนวนครั้งที่แอปยืนยันว่ารับอินพุตจากปุ่มแล้ว ควรเท่ากับจำนวนการกระทำที่เกิดขึ้นจริง Debouncing เป็นแนวปฏิบัติที่ดี แต่ถ้าจะใช้ ก็ไม่ควรให้ ฟีดแบ็ก กับการแตะที่ถูก debounce ทิ้ง

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

  • แม้ตอนนี้จะไม่ใช่แฟนบอย Apple/Mac/Jobs แบบเมื่อก่อนแล้ว แต่ก็คิดถึง งานเปิดตัวของ Apple ที่ให้ความรู้สึกว่าคนบนเวทีอยากโชว์อะไรเจ๋ง ๆ
    งานเปิดตัว Apple ช่วงหลังแข็งทื่อและไร้ความเป็นมนุษย์เกินไป เหมือนจัดโดยคนใส่สูท จนดูไม่จบ ทุกคนดูเหมือนหุ่นยนต์ที่ซ่อนอารมณ์และความเป็นมนุษย์ไว้ เพราะกลัวว่าถ้าออกนอกบทศักดิ์สิทธิ์แล้วจะโดนไล่ออก
    อาจจะนอกประเด็นไปบ้าง แต่ทำให้นึกได้ว่าการพรีเซนต์สดแบบค่อนข้างยุ่งเหยิงของ Jobs ยังสนุกแค่ไหน

  • ถ้าจะพูดว่า “แล้วกรณีแบบนี้ล่ะ?” สถานการณ์นี้ชัดเจนว่าไม่ใช่แบบนั้น มีสองเหตุผล:

    1. “The Nothing Phone button gives you a tap confirmation via both haptics and sound, and then ignores the tap […]”
    2. มีเหตุผลที่ดีในการ กดปุ่มนี้ต่อเนื่อง 3 ครั้ง

• อยากสนับสนุนประเด็นที่คนอื่นยกขึ้นมาว่า “แล้ว debouncing ล่ะ?” และผู้เขียนไม่ควรแค่เมินมันไป
  แต่ก็ไม่ชอบมีม you had one job และอยากค้านการใช้แบบไม่คิด ส่วนใหญ่มีมนี้ผิด และกับปุ่มก็โดยมากเป็นแบบนั้นเช่นกัน ในอินเทอร์เฟซผู้ใช้ทั่วไป ปุ่มหนึ่งปุ่มมักมีบทบาทหลายอย่างพร้อมกัน เช่น:

  • สื่อสารว่ากดปุ่มแล้วจะเกิดการกระทำอะไร
  • บางครั้งสื่อสารสถานะปัจจุบันของส่วนหนึ่งในระบบ เช่น ปุ่มเปิด/ปิดโหมดที่แสดงโหมดปัจจุบันด้วยภาพ
  • เมื่อคลิกแล้วเรียกใช้การกระทำที่ตั้งใจไว้
  • บางครั้งสื่อสารว่าได้รับคำสั่งแล้วและกำลังดำเนินการอยู่ เช่น ในกรณีต้นฉบับ อาจปิดใช้งานปุ่มระหว่างแอนิเมชันหมุนเพื่อหลีกเลี่ยงความสับสน
  • หลังมีม you had one job แทบจะเติมต่อได้เสมอว่า “เพราะฉันปฏิเสธที่จะพิจารณาความซับซ้อนจริง ๆ ของงานของคุณ”
  • เป็นข้อสังเกตที่ดี และชอบเป็นพิเศษที่เน้นว่าความคาดหวังของแต่ละคนต่อสิ่งที่เป็น ปุ่ม และสิ่งที่ไม่ใช่ปุ่มนั้นต่างกัน แต่ละข้อกำลังอธิบายปุ่มที่มีป้ายกำกับ ปุ่มที่มี toggle ปุ่มจริง และตัวแสดงความคืบหน้า สำหรับผู้ใช้บางคน ทั้งหมดนี้อาจเป็น “ปุ่ม” ได้
  • ถ้าพูดถึง “แล้ว debouncing ล่ะ” งั้นเรียกใช้ฟังก์ชันของปุ่มตอน ปล่อยนิ้วออก แทนที่จะเป็นตอน เริ่มแตะ ไม่ได้หรือ?

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

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

  And it would be so much more predictable and pleasant if you could just tap the button three times at any pace you wanted without thinking, without paying attention, without getting your UI blocked by an animation that no longer helps you.

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

• iOS มีตัวเลือกการเข้าถึงชื่อ Ignore Repeats ซึ่งเป็นการตั้งค่าทั้งระบบ จึงดูเป็นแนวทางที่ดีกว่า คนที่ต้องการการปรับแก้แบบนี้ก็จะได้ใช้กับที่อย่างคีย์บอร์ดบนหน้าจอด้วย และคนอื่น ๆ ทั้งหมดก็ไม่จำเป็นต้องพิมพ์ช้าลง

• ผมไม่คิดว่าวิดเจ็ต UI ทุกตัวต้องคำนึงถึงเรื่องพวกนี้ถึงขนาดนั้น
  น่าจะจัดการได้ด้วยการตั้งค่าทั้งอุปกรณ์ เช่น หากมีการแตะซ้ำภายในระยะ 50px จากกันภายใน 100ms ก็ให้ละเว้นไป

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

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

  • เรียกสิ่งนี้ว่า ปัญหาการทำสองอย่าง
    คุณเขียนโค้ดเชิงคำสั่งแล้วสั่งสองคำสั่ง ซึ่งทั้งสองอย่างล้มเหลวแยกกันได้
    มีหลายวิธีในการแสร้งว่า “จัดการแล้ว”
    อย่างแรก เทสต์ทั้งหมดก็คงผ่าน ดังนั้นนักพัฒนาส่วนใหญ่ก็หยุดคิดต่อได้ทันที
    อาจคิดว่าจับ exception แล้วแค่ log ไว้ก็พอ แต่ปัญหาก็ไม่ได้ถูกแก้
    จะปล่อยให้รันใน production สักพักแล้วดูว่ามีปัญหาไหมก็ได้ สุดท้ายถ้าเกิดปัญหา นักพัฒนาก็จะลองใหม่ และครั้งที่สองก็น่าจะทำงานได้ จึงหยุดคิดอีกครั้ง
    เมื่อไม่กี่วันก่อนก็มีการถกเถียงใหญ่เรื่อง outbox pattern ด้วย คือแบ่งงานแรกออกเป็นสองครึ่งแล้วจัดการแบบ atomic ส่วนงานที่สองปล่อยให้ผู้อ่านจัดการเอง
    ผมคิดว่าเหตุผลที่ปัญหานี้ยังเกิดขึ้นซ้ำ ๆ ในโลกจริง เพราะนักพัฒนาอยู่ในสถานะซ้อนทับเชิงควอนตัมระหว่าง “เรื่องแบบนั้นไม่เกิดขึ้นหรอก”, “ผมแก้แล้ว”, และ “แก้ไม่ได้”
  • เรื่องนี้พบได้บ่อยมากเพราะคุณลักษณะการออกแบบสองอย่างที่เฟรมเวิร์ก UI ส่วนใหญ่มีร่วมกัน:
    โค้ดที่เปลี่ยนสีปุ่มเป็นพฤติกรรมภายในของคอมโพเนนต์ “ปุ่ม” จึงไม่ต้อง implement แยกในทุกปุ่ม แต่นั่นก็หมายความว่ามันแยกออกจากโค้ดที่ทำงานจริงในระดับหนึ่ง หากใน handler on click มีการตรวจสอบด่านสุดท้ายแบบในต้นฉบับ เช่น “ถ้าอยู่ระหว่างแอนิเมชันหมุน ก็ไม่หมุนภาพ” มักไม่มีวิธีบอกปุ่มให้ยกเลิกการเปลี่ยนสี ในทางกลับกัน แม้แอนิเมชันเปลี่ยนสีจะเล่นไม่ถูกต้อง handler on click ก็ยังอาจถูกเรียกได้
    ปุ่มมักเปลี่ยนสีเมื่อกดปุ่มเมาส์ลง แต่การกระทำจะเกิดตอนปล่อยปุ่มเมาส์ วิธีนี้ตั้งใจให้มีโอกาสยกเลิกในวินาทีสุดท้ายด้วยการลากออกนอกปุ่มขณะยังกดอยู่ และบนมือถือก็อาจตีความ interaction ใหม่ว่าเป็นการเลื่อน ไม่ใช่การคลิก แต่ในบางครั้งมันก็แค่เพิ่มโอกาสให้เกิดกรณีที่สีเปลี่ยนไปแล้วแต่การกระทำถูกกันไว้
  • เห็นเรื่องนี้ในลิฟต์ค่อนข้างสม่ำเสมอ ถ้ากดปุ่มสั้นมาก ๆ ไฟจะติดตอนกดอยู่ แต่จริง ๆ แล้ว อินพุตของปุ่มไม่ได้ถูกลงทะเบียน
  • การเปลี่ยนสีปุ่มแสดงว่าการกดสำเร็จ ถ้าไม่ทำทันที คนส่วนใหญ่ถูกฝึกให้ลองกดซ้ำ โดยเฉพาะสำคัญกับคนที่ควบคุมการเคลื่อนไหวได้ไม่ดี
    สิ่งนี้เป็นอิสระโดยสิ้นเชิงจากว่าการกดนั้นเป็นอินพุตที่มีประโยชน์ต่อสถานะซอฟต์แวร์ปัจจุบันหรือไม่ ซอฟต์แวร์ที่เขียนดีควรรู้ว่าไม่สามารถรับอินพุตได้และควรปิดใช้งานปุ่มไว้แล้ว และแม้แต่ซอฟต์แวร์ที่ทำมาพอใช้ได้ก็ควรให้ ฟีดแบ็กแทบจะทันที ว่ากำลังประมวลผลการกระทำหรือถูกยกเลิกแล้ว
  • น่าจะเป็นเพราะการทดสอบไม่เพียงพอ และสมมติฐานว่าการทำงานล้มเหลวเกิดขึ้นน้อยเกินไปจนไม่คุ้มพิจารณา แต่แพตเทิร์นแบบนี้ทำให้เชื่อถืออินเทอร์เฟซและใช้งานอย่างมีประสิทธิภาพได้ยาก

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

  • อยากขยายคำอธิบายที่ว่า “ปกปิดเวลาโหลดและทำให้การเปลี่ยนจากสถานะหนึ่งไปอีกสถานะหนึ่งลื่นไหล” ให้มากขึ้น ถ้าใช้ดี ๆ มันจะแสดงให้เห็นว่า การเปลี่ยนสถานะ กำลังเกิดขึ้นโดยตรงจากการกระทำบางอย่างของผู้ใช้ และยังบอกเป็นนัยถึงวิธีย้อนกลับหรือแก้ไขสิ่งนั้นด้วย
    จริง ๆ แล้วผมไม่เห็นด้วยกับคำว่า “ปกปิด” การที่อะไรบางอย่างโผล่ขึ้นมาทันทีโดยไม่มีเบาะแสว่ามันปรากฏขึ้นเพราะอะไร เป็น anti-pattern ที่ชัดเจนบนหน้าจอสัมผัส
  • แอนิเมชันไม่ได้มีไว้เพื่อจุดประสงค์นั้นเท่านั้น มันยังมีส่วนสร้างสรรค์ต่อ ความรู้สึก ตอนใช้แอปด้วย
  • Apple เมื่อก่อนเคยรู้เรื่องนี้ หลังจากรายการหายไปแล้วจึงใส่แอนิเมชัน แต่หลีกเลี่ยงแอนิเมชันก่อนแสดงรายการ
    Apple ยุคเก่าเข้าใจว่าดีไซน์เป็นมากกว่าการทำให้สวย Apple ยุคกระจกทุกวันนี้สนใจแค่ว่าตอนเดโมจะดูเป็นอย่างไร
  • แอนิเมชันแทบจะรู้สึกว่าไม่จำเป็นเสมอ ผมปิดมันทุกครั้งที่แอปหรือระบบอนุญาต
  • ผมปิดแอนิเมชันทั้งหมดบน Android แล้วรู้สึกดีขึ้นมาก โดยเฉพาะ แอนิเมชัน overscroll ที่ทั้งหน้าจอยืดออกเมื่อพยายามเลื่อนเกินขอบ ซึ่งผมเกลียดมาก

• ตอนดูการเปรียบเทียบแรก พูดตามตรง ผมคิดว่าปัญหาอยู่ที่ตัวอย่างของ iPhone ทุกครั้งที่กดปุ่มหมุน ปุ่มกับสไลเดอร์ใต้ภาพจะหายไปแล้วค่อยเฟดกลับมา ซึ่งเป็นพฤติกรรมที่เคยเห็นในหลายแอปบน iOS และรบกวนใจไม่รู้จบ โดยเฉพาะ แอป Screenshot ที่ส่วนตัวไม่พอใจมาก
  ถ้าเป็นองค์ประกอบ UX ที่สามารถควบคุมได้ทั้งก่อนและหลังการโต้ตอบ ไม่ว่าจะเป็นการแปลงหรือการประมวลผล ก็ควรปล่อยให้มันแสดงอยู่ตลอดระหว่างนั้น การซ่อนปุ่มเหล่านี้ระหว่างหมุนบน iPhone ให้ประโยชน์ด้าน UX อะไร? มันก็ไม่ได้ดูดีขึ้นด้วย แน่นอนว่าซอฟต์แวร์ของ Apple ช่วงหลัง ๆ ได้เอาการปรับปรุง UX จริง ๆ ไปสังเวยบนแท่นบูชาของรูปลักษณ์อยู่แล้ว
  แต่ผมเห็นด้วยกับข้ออ้างของผู้เขียนที่ว่าแท็บแบบนี้ควรถูกจัดการแยกจากแอนิเมชัน

  • อยากให้แอปซอฟต์แวร์มีกฎ tape-out เหมือนชิปคอมพิวเตอร์บ้าง ตอนออกแบบชิป โปรแกรมจะตรวจทานดีไซน์แล้วเทียบกับกฎยาว 300 หน้า เช่น “การเดินสายของโลหะ X กับโลหะ Y ต้องไม่อยู่ภายในระยะ Z”
    UX ก็น่าจะทำอะไรคล้ายกันได้ เป็นชุดข้อจำกัดของ design pattern ที่คอยเตือนเมื่อกำลังจะปล่อยออกมาพร้อมข้อบกพร่องด้าน UX ที่เป็นที่รู้จัก

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

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

• บทความจริงที่ใกล้เคียงกับประเด็นหลักที่ผู้เขียนต้องการสื่อมากกว่าคืออันนี้: https://aresluna.org/show-your-hands-honor/

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

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

[GN⁺]

ความคิดเห็นจาก Lobste.rs

• เป็นการเหน็บแนมเบา ๆ แต่ถ้าจะคุยเรื่อง UI/UX ที่ดีแล้ว การฝังวิดีโอที่ไม่มีทั้งปุ่มควบคุมและตัวบอกสถานะใด ๆ นี่แย่มาก
  คนจำนวนมากตั้งค่าให้ปิดเล่นอัตโนมัติไว้เป็นค่าเริ่มต้น และฉันก็นั่งมองภาพสองภาพที่แทบเหมือนกันเป๊ะอยู่นานว่า “แล้วมันต่างกันตรงไหน?”

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

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

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

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

• จะบอกว่า Android ผิดไปหมดก็คงยาก ฉันเคย เผลอสั่งงานซ้ำสองครั้ง เพราะ UI ตอบสนองช้า
  วิธีที่ดีที่สุดอาจเป็นการปิดปุ่มไว้จนกว่าแอนิเมชันจะจบ

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

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

• เคยเจอ rotary encoder ที่ตามไม่ทันไหม? ปุ่มหมุนปรับเสียงบนแอมป์หูฟังของฉันถ้าหมุนเร็วเกินไปจะไม่เกิดอะไรขึ้นเลย
  ถ้าฉันได้เป็นประธานาธิบดีสักหนึ่งวัน...

• ทุกครั้งที่เห็นอะไรแบบนี้ ฉันจะนึกว่าถ้าเป็น GUI toolkit ของฉันเองจะเป็นยังไง toolkit ของฉันจัดการการคลิกเร็วสองครั้งเป็นดับเบิลคลิกแบบที่ยืมพฤติกรรมมาจากแพลตฟอร์ม Windows ซึ่งบางทีก็ทำให้แทบบ้า
  ตัวดับเบิลคลิกเองเป็นธรรมเนียมที่พบได้ทั่วไปและมีคุณค่าแยกจากคลิกปกติ ตามอุดมคติแล้วควรทำให้เหตุการณ์คลิกเป็นแบบ idempotent เพื่อให้เกิดสองครั้งแล้วไม่เป็นปัญหา เช่น ถ้าคลิกคือเลือกไอเท็ม และดับเบิลคลิกคือสั่งทำงานหลัก การเลือกไอเท็มเดิมสองครั้งก็ไม่ควรมีผลเสีย แต่โลกจริงไม่ได้เป็นแบบนั้นเสมอไป
  ปัญหาคือถ้าคลิกปุ่มเร็วมาก ปุ่มอาจทำงานแค่ครั้งเดียว แล้วครั้งต่อไปถูกส่งไปเป็นเหตุการณ์ดับเบิลคลิกที่ไม่ทำอะไรเลย ทำให้เมื่อกดเร็ว ๆ คลิกครึ่งหนึ่งถูกเมินไป
  เพราะปัญหานี้ ฉันเลยสร้างบูลีนชื่อ triggersOnMultiClick และถ้าตั้งเป็น true มันจะส่ง trigger event แม้เป็นการคลิกหลายครั้งเร็ว ๆ อย่างดับเบิลคลิก อย่างไรก็ตามเพื่อความเข้ากันได้ย้อนหลัง ฉันตั้งค่าเริ่มต้นไว้ที่ false แต่ตอนนี้ใกล้ออกรุ่นหลักใหม่แล้ว และคิดว่าข้อโต้แย้งในบทความนี้มีน้ำหนักพอ จึงตั้งใจจะเปลี่ยนค่าเริ่มต้นเป็น true ตอนนี้เลย
  น่าจะเขียนกำกับไว้ได้ประมาณว่า “เพิ่มเมื่อ 2 กรกฎาคม 2021, ค่าเริ่มต้น false. เมื่อ 5 กรกฎาคม 2026 (v13.0) เปลี่ยนค่าเริ่มต้นเป็น true เพื่อให้ทุกการคลิกของปุ่มถูก trigger โดยปริยาย หากต้องการพฤติกรรมเดิม ให้ override เหตุการณ์ดับเบิลคลิก หรือหลังเรียก constructor ของคลาสแม่แล้วตั้ง triggersOnMultiClick = false”
  ฝั่งการทำแอนิเมชันก็อาจเกิดพฤติกรรมคล้ายกันโดยบังเอิญได้ ถ้ามีตัวแปรตำแหน่งแอนิเมชันอยู่ในอ็อบเจ็กต์และตั้งค่ามันตอนคลิก เมื่อดับเบิลคลิกก็มีตัวเลือกหลัก ๆ สองแบบ คือข้ามแอนิเมชันที่เหลือแล้วไปยังสถานะภายในถัดไปทันที หรือไม่ก็เมินเหตุการณ์ไปเพื่อรักษาความลื่นไหลของภาพแบบ if(animationCounter) return; นักพัฒนา Android ในบทความดูเหมือนจะเลือกอย่างหลัง
  ฝั่ง Apple น่าจะใช้วิธีที่สาม คือมี คิวแอนิเมชันที่รออยู่ แล้วเอาเหตุการณ์ใส่เข้าไป สิ่งที่ผมสงสัยคือสถานะภายในเปลี่ยนตอนใส่เข้าคิว ตอนทำเสร็จ หรือจริง ๆ แล้วเขาหมุนรูปภาพด้วยแอนิเมชันเลยกันแน่ ถ้าตัดแอนิเมชันกลางทางแล้วบันทึก จะได้ภาพที่หมุน 45 องศาหรือเปล่า? ถ้าเป็นผมคงอัปเดต EXIF ทีเดียวแบบอะตอมมิกทีละ 90 องศา แล้วให้แอนิเมชันทรานซิชันทำงานแยกต่างหาก
  มันอาจมีทางเลือกที่สมเหตุสมผลได้หลายแบบระหว่างความง่ายในการ implement, ความเที่ยงตรงด้านภาพ, และพฤติกรรมของ UI โดยส่วนตัวผมก็ชอบแบบที่การกดครั้งที่สองไม่ต้องรอแอนิเมชันและ snap ไปยังสถานะใหม่ทันทีเหมือนกัน ไม่น่าจะถึงขั้นทำคิวแอนิเมชัน
  ตลกดีที่มาเปลี่ยนโค้ดช่วงเวลาใกล้กัน การแก้ครั้งก่อนก็วันที่ 2 กรกฎาคม ส่วนครั้งนี้บังเอิญเป็นวันที่ 5 กรกฎาคม ผมชอบใส่ประวัติแบบนี้ไว้ในคอมเมนต์เอกสารตรง ๆ เพราะเวลาแก้ทีหลังได้กลับมาอ่านเป็นความทรงจำด้วย
  Apple น่าจะมีคิวแอนิเมชันเริ่มต้นให้อยู่แล้ว แต่จังหวะที่สถานะเปลี่ยนก็ยังเป็นอีกประเด็นหนึ่ง บนเว็บ ผมคงอัปเดตสถานะแบบอะตอมมิก แล้วแยกแอนิเมชันเพื่อการมองเห็นอย่าง CSS transform transition ออกไปต่างหาก น่าจะทั้งทำง่ายและมีประสิทธิภาพเพราะไม่ต้องคำนวณ layout ใหม่ ถ้าเปลี่ยนชื่อคลาสเร็วกว่าแอนิเมชัน มันจะกระโดดหรือเข้าคิวไว้คงต้องลองทีหลัง

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

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