1 คะแนน โดย GN⁺ 3 시간 전 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • UI คือพื้นผิวแทบจะเพียงอย่างเดียวที่ผู้ใช้ใช้ตัดสินคุณภาพของแอป และไม่ว่าจะจับภาพหน้าจอในจังหวะไหน สถานะของหน้าจอ ก็ควรสมเหตุสมผลเพื่อสร้างความเชื่อมั่น
  • UI ที่เก็บรายละเอียดมาอย่างดีเป็นสัญญาณว่านักพัฒนาได้ใช้เวลาขัดเกลา และกลายเป็น ฮิวริสติกที่สมเหตุสมผล ว่าโค้ดก็น่าจะถูกขัดเกลาในระดับใกล้เคียงกัน
  • เกณฑ์จริงคือการกำจัด แสงวาบสีขาว ระหว่างการเปลี่ยนหน้าจอ การโหลดแบบบางส่วน การจัดเลย์เอาต์ใหม่ระหว่างโหลด ข้อความสถานะที่ไม่สอดคล้องกัน และ แอนิเมชัน ที่ไม่แม่นยำ
  • ต่อให้สถานะเริ่มต้นและสถานะสุดท้ายดูดี แต่ถ้าเฟรมระหว่างทางผิดจังหวะ ก็จะทำให้รู้สึกว่าองค์ประกอบต่าง ๆ ไม่ได้ซิงก์กัน และในกรณีของ Photos ก็อาจสร้าง ความรู้สึกหลอก ได้แม้จะเป็นการเปลี่ยนผ่านที่แทบไม่มีอะไรเปลี่ยนจริง
  • แอนิเมชันควรช่วยให้เข้าใจการเปลี่ยนผ่าน และต้องดูแลไม่ใช่แค่จุดเริ่มต้นกับจุดสิ้นสุด แต่รวมถึงทุกเฟรมระหว่างนั้นด้วย จึงจะทำให้ UI ให้ความรู้สึกเหมือน เครื่องมือที่แม่นยำ

หลักการสำคัญ

  • เป้าหมายที่ประกาศไว้อย่างชัดเจนของ Wayland คือ “every frame is perfect” ซึ่งเป็นเป้าหมายทางเทคนิคในการทวงคืนการควบคุมท่ามกลางความซับซ้อนของสแตก GPU สมัยใหม่
  • หลักการเดียวกันนี้ใช้กับ UI ได้เช่นกัน โดยไม่ว่าจะจับภาพหน้าจอของแอปในช่วงเวลาใด หน้าจอก็ควรดูเป็นธรรมชาติและสอดคล้องกัน
  • ผู้ใช้มองไม่เห็นโค้ด ดังนั้น UI จึงกลายเป็นพื้นผิวเดียวที่ใช้ตัดสินคุณภาพของแอป
  • ถ้า UI ถูกขัดเกลามาอย่างดี ก็เป็นสัญญาณว่านักพัฒนาได้ใช้เวลาเก็บรายละเอียด และนำไปสู่การตัดสินว่าโค้ดก็น่าจะถูกขัดเกลาในระดับใกล้เคียงกัน

เกณฑ์จริงและตัวอย่าง

  • เพื่อให้ได้เฟรมที่สมบูรณ์แบบ จะต้องไม่มี แสงวาบสีขาว ระหว่างหน้าจอ และไม่มีสถานะที่คอนเทนต์โหลดมาเพียงบางส่วนหรือมีการจัดเลย์เอาต์ใหม่ระหว่างโหลด
  • สถานะภายในของ UI ต้องสอดคล้องกัน โดยไม่ควรมีส่วนหนึ่งบอกว่า “1 update available” ขณะที่อีกส่วนบอกว่า “Checking for updates...”
  • แอนิเมชันมักถูกมองข้าม และถึงแม้สถานะต้นทางกับปลายทางจะดี แต่ถ้าระหว่างทางดูแปลก เฟรมกลาง ๆ ที่ถูกจับภาพไว้ก็จะกลายเป็นเฟรมที่ดูไม่สมเหตุสมผล
  • ในกรณีของ Safari ข้อความ placeholder เคลื่อนที่จากกึ่งกลาง แต่เคอร์เซอร์กลับแอนิเมตจากตำแหน่งด้านซ้าย ทำให้สององค์ประกอบนี้ให้ความรู้สึกเหมือนไม่ได้ซิงก์กัน
  • ในกรณีของ Photos ตอนสลับระหว่างโหมด Crop และ Adjust รูปภาพจะย้ายกลับเข้าที่ทันที แต่กรอบครอปยังคงแอนิเมตอยู่ จึงสร้าง ความรู้สึกหลอก ว่ามีบางอย่างเปลี่ยนไปอย่างละเอียดอ่อนระหว่างการสลับโหมด
  • ในกรณีของ UI ค้นหา แอนิเมชันที่ควรช่วยให้เข้าใจการเปลี่ยนผ่านกลับทำให้การตามการเคลื่อนไหวของไอคอนแว่นขยายยากขึ้น
  • ในกรณีของ Youtube แม้แต่การย้ายสี่เหลี่ยมผืนผ้าจากตำแหน่งหนึ่งไปอีกตำแหน่งหนึ่งซึ่งเป็นงานง่าย ๆ ก็ยังเกิดการเคลื่อนไหวแปลก ๆ และไม่ว่าเหตุผลคืออะไร ผลลัพธ์ก็คือเฟรมที่ไม่สมบูรณ์แบบ
  • แม้กระทั่งแอนิเมชันการซูมของแอป Preview ประเด็นสำคัญก็คือ ต้องใส่ใจไม่ใช่แค่สถานะเริ่มต้นและสถานะสุดท้าย แต่รวมถึงทุกช่วงเวลาระหว่างนั้นด้วย

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

 
GN⁺ 2 시간 전
ความเห็นจาก Hacker News
  • ตัวอย่างบางส่วนที่ผู้เขียนยกมาเป็น แอนิเมชันที่แย่ จริง แต่ก็ยากจะเห็นด้วยกับสมมติฐานตั้งต้นของบทความ
    คอมพิวเตอร์กราฟิกเป็นสาขาที่อาศัยคุณลักษณะของระบบการมองเห็นของมนุษย์ และสิ่งที่เคลื่อนไหวกับสิ่งที่หยุดนิ่งถูกรับรู้ต่างกัน หากแยกออกมาดูทีละเฟรม เฟรมที่ดูว่า “ผิด” ก็อาจเป็นเฟรมที่ดูดีที่สุดเมื่ออยู่ในกระแสเวลาจริง
    ถ้าเปรียบกับภาพยนตร์ ช็อตติดตามที่เร็วมากอาจทำให้แต่ละเฟรมดูแย่เพราะ motion blur และช็อตมุมกว้างอาจทำให้วัตถุดู “ผิด” เพราะความบิดเบี้ยว แต่ถ้ามันสร้างผลทางศิลป์ตามที่ตั้งใจไว้ในโรงภาพยนตร์ ก็ถือว่าเป็นตัวเลือกที่ถูกต้อง

    • ตอนแรกผมนึกว่า “Every Frame Perfect” หมายถึงการหลีกเลี่ยงอาการกระตุกหรือสะดุดของการเคลื่อนไหวอย่างเคร่งครัด ซึ่งผมเห็นด้วยเต็มที่ แต่ถ้ามองจากมุมภาพยนตร์ วิดีโอ และเทคโนโลยี 3D แล้ว temporal artifacts อย่าง motion blur ไม่ได้แค่ดู “ถูกต้อง” ที่สุดสำหรับระบบการมองเห็นของมนุษย์ แต่ยังเป็นรูปแบบที่ตีความได้ง่ายที่สุดด้วย
      ถ้าเติม blur ที่ถูกต้องให้การเคลื่อนไหว มันจะรู้สึกคมชัดขึ้น แต่ถ้าหยุดดูเป็นภาพนิ่งก็แน่นอนว่าจะไม่ได้คมชัดขึ้น ประเด็นสำคัญคือ motion blur ที่ถูกต้องจะทำให้ภาพดูคมชัดเท่ากับรายละเอียดของการเคลื่อนไหวที่มนุษย์รับรู้ได้จริงที่ความเร็วนั้น ดังนั้นการเอาเฟรม motion blur ที่หยุดค้างไว้มาตัดสินด้วยเกณฑ์ความคมชัดหรือความอ่านออกจึงเป็นวิธีที่ผิด
      ส่วนที่เหลือของบทความโฟกัสกับรายละเอียดการทำงาน แต่พลาดโอกาสที่จะตั้งคำถามตั้งแต่ต้นว่าแอนิเมชันบางแบบเหล่านี้ควรมีอยู่หรือไม่ การเคลื่อนไหวอาจเป็น affordance ที่ดีเมื่อใช้อย่างจำกัด แต่ตอนนี้หลายกรณีเลยจากคำว่าใช้มากเกินไป ไปถึงขั้นรบกวนสายตาและภาระการรับรู้ของผู้ใช้ นักออกแบบและ PM มองว่านี่เป็นสัญลักษณ์ของ “UX สมัยใหม่ที่ดูขัดเกลา” แต่ในความเป็นจริงมันเสื่อมสภาพกลายเป็นเครื่องประดับตามกระแสที่เลียนแบบงานออกแบบที่ดี มากกว่าจะเป็นงานออกแบบที่ดีจริง
    • บทความนี้น่าจะทำให้ข้อโต้แย้งแข็งแรงขึ้นถ้าแสดงตัวอย่างการใช้งานที่ดีมาด้วย ถึงอย่างนั้นก็เห็นด้วยว่า ความรู้สึกรวมของทรานซิชัน สำคัญกว่าการดูทีละเฟรม
      แอนิเมชันบางส่วนที่ยกมาดูชัดเจนว่ายังปรับปรุงได้ และ AI ก็ดูเหมาะมากสำหรับการผลักดันความพึงพอใจเล็ก ๆ แบบนี้ เพราะเมื่อก่อนมันมักมีลำดับความสำคัญต่ำเกินกว่าจะเอาเวลามาลง
    • อุปมานี้เหมือนจะก้าวเลยไปอีกขั้น ไม่เหมือนภาพยนตร์ UI ไม่ได้บันทึกความจริง แต่ทุกพิกเซลบนหน้าจอคือผลลัพธ์ที่เราวางไว้ ดังนั้นอุปมาที่ใกล้กว่าคือ การ์ตูน เฟรมคั่นกลางของการ์ตูนไม่ใช่เฟรมที่ไม่สมบูรณ์ แต่เป็นเฟรมที่ตั้งใจทำอย่างพิถีพิถันและเสร็จสมบูรณ์จริง ๆ
      การที่เฟรมคั่นกลางของแอนิเมชันดู “แปลก” เล็กน้อยแต่ยังสมเหตุสมผล กับกรณีที่สภาวะตรงกลางมันไร้เหตุผลจริง ๆ และเป็นเพียงผลจากการไม่สนใจว่าจะเกิดอะไรขึ้นระหว่างแอนิเมชัน เป็นคนละเรื่องกัน ถ้าเป็นอย่างหลัง ผมว่าเอาแอนิเมชันทิ้งไปเลยหรือทำให้เรียบง่ายกว่านี้จะดีกว่า
    • แอนิเมชันซูมของแอป Preview ตัวสุดท้ายยังแสดงตัวอย่างโต้แย้งด้วย ทุกเฟรมเมื่อดูแยกกันสมบูรณ์แบบตามที่ผู้เขียนต้องการ แต่ปัญหากลับปรากฏเมื่อดูเป็นการเคลื่อนไหว
    • แนวคิดที่ว่าแอนิเมชันควรต้องสอดคล้องกันเสมอเมื่อผ่าออกมาดูระดับเฟรม ฟังดูไม่ค่อยน่าเชื่อเท่าไร เพราะผู้ใช้ไม่ได้เห็นมันแบบนั้นจริง ๆ
      มุมมองของบทความที่ใช้ความประณีตของ UI เป็นตัวชี้วัดแทนคุณภาพซอฟต์แวร์นั้นดี และการชี้ว่าแอนิเมชันบางอย่างแย่ก็ถูกต้อง แต่ความสอดคล้องรายเฟรมไม่ใช่ไม้บรรทัดที่ดีที่สุดในการวัดว่าแอนิเมชัน “ดี” หรือไม่
  • บางเครื่องยังใช้ Sonoma อยู่ และพูดได้แค่ว่ามันถดถอยลงเรื่อย ๆ
    กล่องโต้ตอบบันทึกไฟล์อาจสั่นนิดหน่อย แต่ไม่ได้ชวนสับสนแบบในตัวอย่าง ปุ่มใน Notes เคลื่อนระหว่างพาเนลได้ลื่นไหลสมบูรณ์ Safari bar ถ้าโฟกัสแล้วเลิกโฟกัสซ้ำ ๆ แอนิเมชันบางครั้งก็พัง แต่เคอร์เซอร์ยังจับจังหวะกับข้อความได้พอดี และข้อความจะค่อย ๆ ปรากฏหลังจากเลื่อนไปทางซ้ายเสร็จแล้วเท่านั้น บั๊กใน Preview ก็ดูเหมือนเป็นปัญหาใหม่ และผมยังทำให้เกิดซ้ำไม่ได้
    https://streamable.com/kx7op6
    คิดถึงยุคที่บริษัทอย่าง Apple, Sony, IBM ใส่ใจกับรายละเอียดเล็กมาก ๆ โดยเฉพาะ Apple ที่ได้มูลค่าแบบทุกวันนี้จาก iPhone ซึ่งตอนนั้นเมื่อเทียบกับ Windows Mobile หรือ Symbian PDA ก็ไม่ได้มีความสามารถว้าวอะไรเป็นพิเศษ แถมบางด้านยังด้อยกว่าด้วยซ้ำ แต่เป็นอุปกรณ์จอสัมผัสล้วนที่คุณใช้ไปไม่กี่นาทีแล้วไม่อยากขว้างใส่กำแพง แอนิเมชันแบบตอนนี้ทำให้นึกถึงความรู้สึกแบบ Windows Mobile และ Symbian กลับมาแบบตรงเป๊ะ
    ยังจำได้ว่า Steve ชอบแอนิเมชันใน OS X แค่ไหน บนเวทีเขาเปิดซ้ำหลายครั้ง แถมเปิดแบบสโลว์โมชันด้วย ของตอนนี้อยู่ในระดับที่ถ้าเอาไปให้คนที่เคยรับผิดชอบเรื่องเสาอากาศของ iPhone 4 ก็ยังไม่แปลก

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

    • “เฟรมไม่สมบูรณ์” ของช่องค้นหา Safari ในทางปฏิบัติก็โอเค และวิธีทำให้มันดูดีขึ้นในสกรีนช็อตอาจกลับแย่กว่าเดิม
      เหตุผลที่เคอร์เซอร์ไปโผล่ทางซ้ายก็เพราะผู้ใช้จะเริ่มพิมพ์จากจุดนั้นจริง ๆ คนที่คุ้นกับ UI ก็น่าจะมองตรงนั้นอยู่แล้ว การทำให้เคอร์เซอร์โผล่กลางจอแล้วค่อยย้ายตำแหน่งเป็นสิ่งไม่จำเป็นและทำให้เสียสมาธิ
      ส่วนข้อความ placeholder ที่เลื่อนไปทางซ้ายก็มีไว้ดึงความสนใจของผู้ใช้ที่ยังไม่คุ้นเคย
    • สล็อตแมชชีนต้องมีอะไรหมุนอยู่ตลอด และ แอนิเมชันของ Apple ที่ไดนามิกเกินไปก็ทำหน้าที่แบบนั้น แอนิเมชัน UI ทั่วไปช่วยผู้ใช้ทั่วไปที่รับมือกับการเปลี่ยนเนื้อหาบนจอแบบฉับพลันได้ไม่ดีนัก อีกทั้งยังช่วยให้เฟรมเรตดูนุ่มนวลขึ้น หรือซ่อนความหน่วงจาก API call และการประมวลผลฝั่งแบ็กเอนด์ได้ด้วย
    • ถ้าคุณเล่นเกมที่ UI ดี ๆ จะเห็นว่าแอนิเมชันถูกใช้ไปทั่ว การสลับแบบทันที ฟังดูดีแค่ในทางทฤษฎี
    • ไม่ใช่ว่าทุกอย่างจำเป็นต้องมีการเคลื่อนไหว ส่วนใหญ่ไม่จำเป็นด้วยซ้ำ งานเหลวไหลแบบนี้สร้างงานให้คนไม่กี่คน และยังเปิดช่องให้บางคนเอาไปอวดว่า design language ของ $BRAND เหนือกว่าทางเลือกอื่น
      ตัวอย่างส่วนใหญ่นี้มีแนวโน้มว่าจะรู้สึกดีกว่าถ้าไม่มีแอนิเมชัน กดปุ่มแล้วก็แค่แสดงผลลัพธ์ออกมา ไม่ต้องเต้นก่อนแล้วค่อยโชว์ แค่โชว์มาเลย
    • การเคลื่อนไหวสำคัญต่อ การกู้คืนการรับรู้ทิศทาง หลังทรานซิชัน
      ถ้าไม่มีการเคลื่อนไหว หลายครั้งสมองจะต้องกวาดดูทั้งหน้าใหม่ทุกครั้งที่รีเฟรช
  • ผมคิดว่าข้อโต้แย้งของบทความนี้ถูกนำเสนออย่างอ่อนมาก ไม่มีทางเลือกที่ดีกว่ามาเสนอด้วย และก็ไม่ได้อธิบายจริง ๆ ว่าสิ่งที่ยกมานั้นส่งผลเสียต่อผู้ใช้อย่างไร มันอาจแย่ได้ แต่ก็คล้ายกับการวิจารณ์แบบกลวง ๆ ที่ชี้ไปที่ smear frame ของสื่อหรือจุดเปลี่ยนผ่านต่าง ๆ
    มาตรฐานที่ว่า “ทุกเฟรมต้องสมเหตุสมผล” ก็รับมือได้ยากมาก ผมมองว่าเป็นไปไม่ได้ และอยากถามว่าถ้าต้องรักษาทุกเฟรมให้สมบูรณ์แบบแม้ในระหว่างการปรับขนาดหน้าต่าง จะทำอย่างไร
    ดูเหมือนว่าแม้แต่ตัวผู้เขียนเองก็ยังทำตามมาตรฐานที่ตัวเองพูดไม่ได้ และการชี้ข้อบกพร่องของเฟรมที่มีปัญหานั้นง่ายกว่า ถ้ากดลิงก์ส่วนหัวของบล็อก จะเห็นว่าแอนิเมชันเล่นหลังจากคลิกเสร็จแล้ว พอดูโปรเจกต์ UI ของเจ้าตัวเอง ก็มีจุดที่ข้อความกับวัตถุไม่อยู่ภายในคอนเทนเนอร์เหมือนกัน ถ้าจะบอกว่าควรยึดหลักแบบนี้ ก็ควรแสดงให้เห็นได้ด้วยตัวเอง
    ถ้าเป็นบทความที่เขียนได้ดีกว่านี้ น่าจะโฟกัสว่าทำไมสิ่งที่ยกมาจึงแย่ต่อผู้ใช้ปลายทาง และควรจัดการแทนอย่างไร การวิจารณ์ที่ดีควรมีไม่ใช่แค่ “อะไร” แต่รวมถึง ทำไมและอย่างไร ด้วย

    • คำวิจารณ์นี้ต่างหากที่ดูว่างเปล่าที่สุดในที่นี้
      บทความนี้กำลังเสนอแนวคิด ไม่ใช่วิธีแก้ปัญหา แต่กลับมองจุดนั้นไม่เห็นและสร้าง ข้อโต้แย้งหุ่นฟาง หลายอันขึ้นมาวิจารณ์แทน
      ที่สำคัญกว่านั้นคือบทความนี้ไม่ได้เขียนแบบฟันธง มีถ้อยคำระมัดระวังอย่าง “I think”, “Next thought:”, “Probably”, “So yeah.” บทความนี้เป็นเพียงคนคนหนึ่งที่แชร์ความคิดของตัวเอง และเป็นความคิดที่ตกผลึกพอสมควรจนทำให้คนมีเหตุผลหลายคนคิดไปในทิศทางคล้ายกันได้
      แค่เพราะผู้เขียนไม่ได้เสนอวิธีแก้ ก็ไม่ได้แปลว่าจำเป็นต้องทำเช่นนั้น มาตรฐานแบบนั้นทั้งแปลกและไม่สมเหตุสมผล
      การโจมตีเว็บไซต์ของผู้เขียนก็ดูไม่ค่อยดีนัก ความต่างด้านรสนิยมเป็นเรื่องที่รู้กันอยู่แล้ว และการลงโทษคนเพราะผลงานเชิงแนวคิดมาก่อนทักษะเชิงปฏิบัติจริงก็น่ารังเกียจทีเดียว
      ถ้าจะวิจารณ์ให้ดีกว่านี้ ก็ควรใจกว้างกว่านี้ให้สมกับจิตวิญญาณของคอมมูนิตี้นี้
  • ผมเห็นหลายคอมเมนต์ที่บอกว่าอยากให้ผู้เขียนใส่ตัวอย่างวิธีแก้ไว้ด้วย ไม่นานมานี้เขาเพิ่งเขียนบทความที่คล้ายกับบทความนี้มาก และอธิบายทั้งปัญหาของแอนิเมชันอย่างละเอียดรวมถึงวิธีที่เขาปรับปรุงมันด้วย
    ถ้าสนใจก็ดูได้ที่นี่: https://www.thisischris.dev/projects/project-6/

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

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

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

    • smear frame ไม่ใช่เทคนิคที่ใช้บ่อยกับแอนิเมชันประเภทนี้ มันแทบจะเฉพาะกับแอนิเมชันแบบทีละเฟรม และในบทความนี้ก็ไม่มี smear frame ด้วย
    • ความต่างคือ blur frame ถูกใช้อย่างจงใจเพื่อเอฟเฟกต์โดยรวม แต่แอนิเมชันที่ยกมาในที่นี้ใกล้เคียงกับ อาการสะดุดโดยไม่ตั้งใจ ที่เผยให้เห็นแอปที่ยังขัดเกลาไม่ดีมากกว่า
    • ผมคิดว่าอุปมานี้ไม่ตรงนัก blur frame ดูดีเมื่อเห็นตอนเคลื่อนไหว แต่เฟรมในโพสต์บล็อกนี้ดูแย่มากแม้ตอนเคลื่อนไหว ตัวอย่างแรกแย่มากจนตอนเห็นครั้งแรกผมนึกว่าจะมีปุ่มเหลืออยู่ด้านบนสามปุ่ม แล้วพอรู้ว่าจริง ๆ มีแค่สองปุ่มก็ให้ความรู้สึกประหลาดและเสียการรับรู้ทิศทาง
    • บน macOS ตอนที่ Apple เริ่มใช้ SwiftUI กับทั้ง OS และแอปต่าง ๆ ผมรู้สึกเลยว่าคุณภาพด้านภาพและคุณภาพแอนิเมชันเปลี่ยนไปมาก
      ผมไม่ใช่นักพัฒนา แต่รู้สึกได้ว่ามีหลายบริเวณที่ไอคอนหรือหน้าต่างไม่ได้ถูกจัดวางหรือเคลื่อนไหวเหมือนเมื่อก่อน หรือไม่เป็นไปในแบบที่ควรจะเป็นตามธรรมชาติ
      ความรู้สึกเหมือนงานปะผุแบบนี้ก็ไม่เปลี่ยนไปแม้เวลาจะผ่านไปแล้ว มีตัวอย่างมากพอทั่วทั้ง OS และแอปต่าง ๆ จนอยากพูดว่า “มันก็เป็นแบบนี้มาตลอด” แต่จริง ๆ แล้วไม่ใช่ Apple เคยตั้งมาตรฐานไว้ และมาตรฐานนั้นสูงมากพร้อมคุณภาพที่ยอดเยี่ยม
      มันให้ความรู้สึกราวกับว่าการจะทำ layout UI หรือแอนิเมชันแบบเดิมให้ได้ด้วย SwiftUI ต้องใช้การแฮ็กหลายอย่าง
      สุดท้ายสิ่งที่ผมคิดอยู่บ่อย ๆ คือ งานสร้างสรรค์แบบอนาล็อกนั้นยากมากจริง ๆ และตอนนี้ก็ยังยากอยู่ ในโลกดิจิทัลเราเคยคิดว่าเดี๋ยวค่อยกลับมาเก็บงานทีหลังได้ แต่ในความเป็นจริงมักไม่ทำ และน่าเสียดายที่หลายครั้งกลับเอาของแย่มาซ้อนทับบนของที่แย่อยู่แล้ว
    • Overwatch เป็นตัวอย่างสมัยใหม่ที่ยอดเยี่ยมพอสมควร [1] มีแอนิเมชันที่ลื่นไหลมากจำนวนมาก แต่ถ้าหยุดเฟรมดูจะดูแปลกมากจริง ๆ
      [1]: https://youtu.be/vIdeGmN__Pw?t=550
  • แอปที่ไม่มีแอนิเมชันเลยจะให้ความรู้สึกแย่มาก ถ้าใช้ Android ก็ลองทดสอบเองได้โดยไปที่การตั้งค่านักพัฒนาแล้วเปลี่ยนความเร็วแอนิเมชันเป็น 0x การเปลี่ยนแบบฉับพลันทันทีนั้นชวนรำคาญ และสมองกลับใช้เวลาราว 1 วินาทีในการประมวลผลว่าเกิดอะไรขึ้น ซึ่งกระบวนการนั้นอาจช้ากว่ากรณีที่มีแอนิเมชันเสียอีก
    ของผมตั้งไว้ที่ 0.5x และรู้สึกว่าเพียงพอแล้ว ยังเร็วอยู่ แต่ก็ยังมองเห็นตอนแอปเปิดและปิด

    • ผมปิดแอนิเมชันบน Android แล้วก็ใช้อย่างพอใจ นี่เป็นวิธีเดียวที่ทำให้รู้สึกว่า “ทันที” จริง ๆ ในบริบทที่มีอินพุตแล้วตามมาด้วยการเปลี่ยนแปลงของ UI ผมคิดว่า ความหน่วง แย่กว่าการไม่มี transitional state หรูหราเสมอ
    • สำหรับผมไม่ใช่แบบนั้น ผมปิดแอนิเมชันตลอด ทำแบบนั้นก็ไม่มีปัญหา และใช้งานโทรศัพท์ได้เร็วขึ้นมากเพราะไม่ต้องรอให้แอนิเมชันจบ
    • ผมก็ใช้ 0.5x เหมือนกัน
      ปัญหาของ 0x คือมันดูเหมือนจะมีผลกับแค่ประมาณ 90% ของ UI เท่านั้น บางอย่างก็ยังมีแอนิเมชันอยู่ เลยทำให้จังหวะโดยรวมรู้สึกแปลกมาก
      ที่ 0.5x สิ่งที่ได้รับผลจากการตั้งค่าความเร็วแอนิเมชันแบบแปลก ๆ จะรบกวนน้อยกว่า
      ถ้ามันทำงานได้ถูกต้อง ผมก็คงใช้ 0x
    • ผมใช้ Android มาเกือบ 10 ปี แล้วสุดท้ายก็ย้ายไป iPhone 12 Mini ตอนมันยังเป็นรุ่นใหม่อยู่ ทุกวันนี้ก็ยังคิดถึงฟีเจอร์ที่ปิดแอนิเมชันได้แบบบน Android ถ้าปิดแอนิเมชันทั้งหมดที่มีไว้เพียงเพื่อให้มีอยู่ได้ ผมมั่นใจ 110% ว่าโทรศัพท์เครื่องปัจจุบันจะเร็วขึ้น 200%
      ถ้าจำเป็น ผมยอมให้มันใช้เวลา 1 วินาทีไปกับการประมวลผลจะดีกว่า และจริง ๆ ก็ไม่คิดว่าจำเป็นด้วย มันดีกว่าการที่แอปช้าลงครั้งละ 1 วินาทีทุกครั้งที่เปลี่ยนหน้าเพราะแอนิเมชันมาก และตอนนำทางทุกอย่างก็รู้สึกหนืดเหมือนกากน้ำตาล
    • แอนิเมชันทั้งหมดก็เป็นแค่เวลาที่เสียไปในช่วงที่คุณยังโต้ตอบกับ UI อย่างเหมาะสมไม่ได้ ดังนั้นปิดมันทั้งหมดไปเลยดีกว่ามาก
  • ผมเห็นด้วยกับบทความนี้ แต่ก็อยากให้มีตัวอย่างเชิงบวกด้วย น้ำเสียงไม่ได้อ่านแล้วเหมือนบ่นก็จริง แต่ในฐานะคนที่ยังไม่ค่อยรู้เรื่องการจัดองค์ประกอบ UI ที่ดีนัก ผมก็ไม่ได้รู้สึกว่าเข้าใกล้คำตอบมากขึ้นว่าจะยึดอะไรเป็น ดาวเหนือ

    • ไม่นานมานี้ผมเพิ่งเขียนเรื่องนั้นโดยตรงเลย ก่อนอื่นผมลงรายละเอียดเกี่ยวกับความไม่สมบูรณ์แบบที่คล้ายกับบทความนี้ในเชิงแนวคิด แล้วต่อด้วยการอธิบายกระบวนการปรับปรุงที่ผมทำเอง
      ถ้าสนใจ ดูได้ที่นี่: https://www.thisischris.dev/projects/project-6/
    • หรือไม่ก็ ผู้เขียนน่าจะแสดง mockup ให้ดูว่าตัวอย่างแย่ ๆ แต่ละอัน ถ้าทำออกมาได้ถูกต้องแล้วควรมีหน้าตาเป็นอย่างไร
 
GN⁺ 3 시간 전
ความคิดเห็นจาก Lobste.rs
  • ผมคิดว่าสมมติฐานพื้นฐานของบทความนี้ผิด แอปแบบนี้ไม่ได้ถูกใช้งานกันแบบ ระดับเฟรม
    แค่เรียนวิชาแอนิเมชันเบื้องต้นก็น่าจะรู้แล้วว่าการรับรู้การเคลื่อนไหวต่างจากภาพนิ่ง ลองดูเดโม "squash and stretch" จะเห็นว่าในแต่ละเฟรม ขนาดของวัตถุบางอย่างถ้าดูแยกกันจะดูไม่สมเหตุสมผลเลย แต่เมื่ออยู่ในการเคลื่อนไหวกลับทำงานได้อย่างสวยงาม

    • ตัวอย่างในบทความนี้ ต่อให้ตอนกำลังเคลื่อนไหวอยู่ก็ดูไม่สวยอยู่ดี
    • ประเด็นไม่ใช่ว่าแอนิเมชันมันน่าเกลียด แต่คือมันสร้างช่วงเวลาที่แทนที่ UI ที่ใช้งานได้ด้วย ลำดับแอนิเมชันที่ใช้งานไม่ได้
      แถมยังอาจแสดงสถานะของโปรแกรมผิดด้วย อย่างในตัวอย่างการครอบตัด ผู้ใช้ต้องเหมือนหยุดคิดไปราวหนึ่งในสามของวินาทีระหว่างที่ UI ประกอบตัวเองกลับเข้าที่ ก่อนจะใช้งานโปรแกรมต่อได้
  • ผมไม่คิดว่าสิ่งที่โปรเจกต์ Wayland พูดถึงในเรื่อง frame perfectness จะหมายถึงแบบนี้เลย
    มันน่าจะใกล้เคียงกับรายละเอียดทางเทคนิคระดับล่างกว่าอย่างการปรับขนาดหน้าต่างมากกว่า เช่น เนื้อหาถูก resize แบบอะซิงโครนัส, vertical sync พังจนเกิดภาพฉีกหรืออาร์ติแฟกต์แนวทแยงแปลก ๆ, หรือการรายงาน damaged region ที่ทำเป็นส่วนย่อยรูปสี่เหลี่ยมผืนผ้า
    แน่นอนว่าคงดีถ้าทั้งรายละเอียดระดับล่างและแอนิเมชันระดับสูงต่างก็สมบูรณ์แบบในระดับเฟรม

    • เห็นด้วย และดูเหมือนผู้เขียนก็คิดแบบนั้น

      Wayland is talking about the technical side of things (modern GPU stacks are very complex and Wayland is trying to take control back) but it could be applied to UI too.

  • สมมติว่าคุณอยากทดสอบแอนิเมชันแบบนี้ และเขียนเทสต์เพื่อให้มั่นใจว่าคุณสมบัติลักษณะนี้จะไม่พังไปเมื่อเวลาผ่านไป
    ทุกวันนี้มี เทคนิคล่าสุด อะไรบ้างในการทดสอบคุณสมบัติแบบนี้ทั้งในเว็บแอปและแอปเนทีฟ? มีกรณีที่เพราะควบคุม event loop ไม่ได้ เลยทำให้เทสต์บางหมวดที่อยากเขียนนั้นแทบเป็นไปไม่ได้หรือยากมากไหม?

    • ผมพูดได้เฉพาะแอป Android แบบเนทีฟเท่านั้น ถ้าใช้ชุดเครื่องมือ UI อย่าง Jetpack Compose คุณสามารถ ควบคุมนาฬิกา ที่ขับเคลื่อน UI ได้เลย จึงจับภาพหน้าจอแบบสถิตเพื่อนำไปทดสอบได้ ณ จุดใดก็ได้ของ transition
      หรือจะใช้เครื่องมืออย่าง Paparazzi เพื่อบันทึก transition ทั้งหมดเป็น Animated PNG สำหรับทำ regression test แบบอัตโนมัติก็ได้
    • ตามอุดมคติแล้ว ข้อมูลขนาดควรถูกเปิดเผย, layout engine แบบทั่วไปควรทดสอบแยกได้อย่างอิสระ, และแอนิเมชันก็ควรถูกแยกออกมา
      แบบนั้นก็ตรวจสอบทั้งสองส่วนแยกกันได้ แล้วตอนท้ายค่อยยืนยันแค่สถานะสุดท้าย แอนิเมชันไม่ควรถูกตรึงกับ input ด้านเวลา แต่ควรถูกขับเคลื่อนจากภายนอกแบบทีละขั้นได้
  • ผมคิดว่าตัวอย่างของ YouTube เกือบตรงกับกรณีของ View Transitions
    มันเป็นแนวทางแบบประกาศว่า “ถ้าองค์ประกอบนี้เปลี่ยน ก็ให้มันเปลี่ยนรูปทรงโดยอัตโนมัติ” และผลลัพธ์ก็คือ transition ที่น่าประทับใจในเชิงเทคนิค แต่ดูย้วย ๆ นิดหน่อย มีองค์ประกอบลอยไปลอยมาและแปลงสภาพเข้าหากัน
    เป็นเทคโนโลยีที่เจ๋งมาก แต่แทบไม่เคยเห็นกรณีที่มันดูยอดเยี่ยมจริง ๆ นอกจากเอฟเฟกต์เน้นเล็ก ๆ ตอนนำทาง ถ้าไม่อยากให้มันดูรบกวนสายตาเกินไป ก็ต้องใช้แบบ ยั้งมือมาก ๆ