ออกแบบ UX ที่สัมผัสได้ด้วย Lottie: เมื่อการควบคุมเฟรมชนะการจำลองฟิสิกส์

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

ทำไมถึงไม่เลือก physics engine

ข้อสรุปหลักของบทความคือสถาปัตยกรรมทางเทคนิคควรรับใช้ทิศทางของงานออกแบบ ไม่ใช่กลับกัน เมื่อโจทย์คือแอนิเมชันที่นักออกแบบตั้งใจกำหนดจังหวะไว้ทุกเฟรม การใช้ physics engine จะให้ผลลัพธ์ที่เกิดขึ้นเองจากการคำนวณ ซึ่งควบคุมให้ตรงกับที่ออกแบบไว้ได้ยาก ทีมจึงเลือกควบคุม Lottie โดยตรงเพื่อให้ได้ผลลัพธ์ที่คาดเดาได้แน่นอนทุกครั้ง

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

ควบคุม Lottie ด้วยช่วงเฟรมแทนการจำลอง

วิธีทำคือกำหนดช่วงเฟรม (segment) แยกไว้สำหรับแต่ละสถานะ เช่น สถานะพักที่วนลูป สถานะตอบสนองเมื่อถูกบีบ และสถานะคลายตัว เมื่อผู้ใช้คลิก โค้ดจะสั่งกระโดดไปเล่นช่วงเฟรมที่ตรงกับสถานะนั้นด้วยเมธอด playSegments ทำให้ควบคุมได้ทีละเฟรมอย่างแน่นอน

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

ทำให้การกดแม่นด้วยคณิตศาสตร์ง่าย ๆ

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

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

ประสิทธิภาพคือส่วนหนึ่งของงานออกแบบ

เมื่อใช้ Lottie หลายตัวพร้อมกัน ต้นทุนด้านประสิทธิภาพจะสูงขึ้นเร็วมาก ทีมจึงใช้หลายเทคนิคประกอบกัน ได้แก่ การโหลดไฟล์แบบเรียงลำดับเพื่อไม่ให้เกิดการยิงคำขอเครือข่ายพร้อมกันเป็นก้อนใหญ่ การลดคุณภาพการเรนเดอร์ตามบริบท เช่น ใช้คุณภาพ 50% เมื่อต้องแสดงแอนิเมชัน 21 ตัวพร้อมกันบนหน้ารวม แต่ใช้ 100% บนหน้าที่ผู้ใช้โฟกัสตัวเดียว การทำลายและสร้างแอนิเมชันที่กินทรัพยากรใหม่ตามความจำเป็นเพื่อคืนหน่วยความจำ และการเฝ้าดูการโหลดที่ใช้เวลาเกินห้าวินาทีเพื่อจัดการกับผู้ใช้ที่เชื่อมต่อช้า

สรุปแนวปฏิบัติสำหรับทีมไทย

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

ข้อแนะนำเพิ่มเติมจากทีมของเราสำหรับงานที่ทำให้ผู้ใช้ไทยคือ ควรตรวจสอบสองเรื่องเสมอ เรื่องแรกคือขนาดไฟล์แอนิเมชันเมื่อเปิดผ่านเครือข่ายมือถือ เพราะประสบการณ์ที่ลื่นบนไวไฟอาจกลายเป็นหน้าจอว่างเปล่านานหลายวินาทีบน 4G เรื่องที่สองคือการเคารพการตั้งค่า prefers-reduced-motion ของระบบปฏิบัติการ โดยเตรียมสถานะภาพนิ่งไว้ให้ผู้ใช้ที่ตั้งค่าลดการเคลื่อนไหว ซึ่งเป็นข้อกำหนดพื้นฐานด้านการเข้าถึงที่มักถูกลืมในงานที่เน้นแอนิเมชัน