เว็บที่ดี ควรจะเคารพการตั้งค่าของผู้ใช้งาน จริงมั้ย?

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

เธอเลื่อนดูสองสามหน้าจอ แล้วหันไปมองอย่างอื่นสักพัก ก่อนจะบอกว่าเดี๋ยวค่อยดูต่อ

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

ค่านี้ไม่ได้แปลว่า "เขาไม่ชอบแอนิเมชัน" นะครับ

เพื่อน ๆ รู้มั้ยครับว่า prefers-reduced-motion คือค่าที่ระบบปฏิบัติการส่งต่อมาบอกเว็บของเราว่าผู้ใช้ขอให้ลดการเคลื่อนไหวลง และคนที่เปิดค่านี้ส่วนใหญ่ไม่ได้เปิดเพราะรำคาญเลยครับ

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

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

จุดร่วมของคนทั้งหมดนี้คือ เขาไปตั้งค่าไว้ในเครื่องของตัวเองเรียบร้อยแล้วครับ เขาไม่ได้นั่งรอให้เว็บของเราเดินไปถามเขาใหม่ทีละเว็บ

แล้วสวิตช์ตัวนี้อยู่ตรงไหนของแต่ละระบบ

บนไอโฟนและไอแพด อยู่ที่ Settings แล้วไป Accessibility จากนั้น Motion แล้วเปิด Reduce Motion

บนแมค อยู่ที่ System Settings แล้วไป Accessibility จากนั้น Display แล้วเปิด Reduce motion

บนวินโดวส์ 11 อยู่ที่ Settings แล้วไป Accessibility จากนั้น Visual effects แล้วปิด Animation effects

บนแอนดรอยด์ อยู่ที่ Settings แล้วไป Accessibility แล้วมองหาหัวข้อลักษณะ Remove animations ซึ่งข้อความและตำแหน่งต่างกันไปตามผู้ผลิตเครื่อง ตรงนี้เราไม่ควรพูดเหมือนว่าทุกยี่ห้อเหมือนกันครับ เพราะมันไม่เหมือนกันจริง ๆ

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

ถ้าอย่างนั้น เราควรตอบสนองยังไงถึงจะถูก

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

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

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

ไม่ใช่แค่ซ่อนไว้ แต่ไม่สร้างมันขึ้นมาเลย

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

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

พอคอมโพเนนต์ไม่ถูกสร้าง ค่าที่ใช้เปิดสวิตช์ให้ CSS ก็ไม่ถูกตั้งตามไปด้วย เอฟเฟกต์จึงไม่ได้นั่งรออยู่ที่ความโปร่งใสศูนย์ครับ แต่ไม่เคยถูกวาดเลยแม้แต่เฟรมเดียว

เขียนไว้ใน no-preference ปลอดภัยกว่าไปไล่แก้ใน reduce

ค่านี้มีสองด้านครับ reduce คือผู้ใช้ขอให้ลด ส่วน no-preference คือเขาไม่ได้ขอ

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

การเขียนแอนิเมชันไว้ข้างใน no-preference จะกลับด้านความเสี่ยงให้เรา เพราะเบราว์เซอร์จะเล่นแอนิเมชันก็ต่อเมื่อมันเข้าใจคิวรีนี้ และตอบได้ชัดเจนว่าผู้ใช้ไม่ได้ขอให้ลด กรณีที่ไม่แน่ใจทั้งหมดจะตกไปอยู่ฝั่งนิ่ง ซึ่งเป็นฝั่งที่ปลอดภัยกว่าเสมอ น่าสนใจมากเลยแหละครับ ที่การสลับที่เขียนแค่นี้เปลี่ยนผลลัพธ์ได้ขนาดนั้น

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

แล้วผลิตภัณฑ์ของคุณล่ะครับ

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

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

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

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

ถ้าเพื่อน ๆ อยากคุยเรื่องผลิตภัณฑ์ของคุณ ติดต่อเราได้ เลยนะครับ