ทำให้สั้นกว่าที่คิดไว้

  • ทรานซิชันเดี่ยวควรอยู่ที่ 0.15–0.4 วินาที
  • เร่งให้เร็วขึ้นจนรู้สึกว่าเร็วเกินไป แล้วค่อย ๆ ลดลงทีละนิด

จับแอ็กชันให้เข้ากับเส้นโค้ง

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

การเร่งและการชะลอ

  • ถ้าแอนิเมชันดูไม่เป็นธรรมชาติ มักเป็นเพราะมันเริ่มหรือจบแบบกะทันหัน
  • แม้จะเล็กน้อยก็ควรใส่ easing-in/out ลงในเส้นโค้ง cubic-bezier
  • ถ้าอยากให้ดูเหมือนจริง แนวคิดเรื่อง "แรงเฉื่อย(Inertia)" ก็ช่วยได้

น้อยกว่าคือดีกว่า

  • ยิ่งมีการเปลี่ยนแปลงขององค์ประกอบมากระหว่างแอนิเมชัน ก็ยิ่งเสี่ยงที่จะดูมากเกินไป
  • ถ้าความโปร่งใสเปลี่ยนจาก 0 เป็น 1 ลองใช้ 0.4 แทน 1 ถ้าจะเปลี่ยนขนาด ก็ลองเริ่มจากขนาดที่เล็กลงเพียงเล็กน้อย
  • ในกรณีส่วนใหญ่ แอนิเมชันที่เคลื่อนกลับเข้าตำแหน่งควรขยับอยู่ในช่วง 5–40 พิกเซล

หลีกเลี่ยงค่าเริ่มต้นของเบราว์เซอร์

  • เบราว์เซอร์มีเส้นโค้งที่ฝังมาให้ เช่น linear, ease, ease-in, ease-out, ease-in-out
  • มันสะดวกและมีประโยชน์ในบางสถานการณ์ แต่ก็ทั่วไปเกินไปจนทุกอย่างดูคล้ายกันไปหมด (เหมือนเว็บไซต์ที่ทำด้วย Bootstrap/Tailwind แล้วหน้าตาคล้าย ๆ กัน)
  • ลองใช้ค่า autocomplete ของเส้นโค้ง cubic-bezier ที่มีใน VS Code
  • หรือเปิดเครื่องมือสำหรับนักพัฒนาในเบราว์เซอร์ แล้วลองใช้ตัวแก้ไขเส้นโค้ง

หลายคุณสมบัติ หลาย easing

  • ไม่ได้มีประโยชน์เสมอไป แต่เมื่อคุณต้องเปลี่ยนหลายคุณสมบัติพร้อมกัน (เช่น transform กับ opacity)
    • บางครั้งใช้เส้นโค้ง cubic-bezier เดียวกันแล้วก็ดูโอเค แต่ในความเป็นจริงก็ไม่ได้เป็นแบบนั้นเสมอไป
    • เส้นโค้งที่ทำงานได้ดีกับ transform อาจไม่เข้ากับการ fade ก็ได้
    • ในกรณีนี้ควรเลือก easing ที่ต่างกันให้เหมาะกับแต่ละ CSS property
  • สามารถแยก @keyframes animation ตามแต่ละ property หรือใช้หลาย transition ก็ได้
    • สำหรับ opacity ใช้ linear, ส่วน transform ใช้ cubic-bezier(.5, 0, .5, 1)

ใช้การหน่วงเวลาแบบเหลื่อมกัน

  • เวลา transition หลายองค์ประกอบ อย่าประเมินผลของ animation-delay หรือ transition-delay ต่ำเกินไป

In ออกไป, Out เข้ามา

  • easing curve มีอยู่ 3 แบบ
    • ease in (เริ่มช้า)
    • ease out (จบช้า)
    • in-out (เร็วตรงกลาง และช้าตอนเริ่มกับตอนจบ)
  • จุดที่ยากของทรานซิชันคือ บ่อยครั้งเรากลับอยากให้ in เป็น ease-out และ out เป็น ease-in
    • แอนิเมชันที่มีอันหนึ่งออกไปและอีกอันหนึ่งเข้ามา สำหรับผู้ใช้จะดูเหมือนเป็นการเปลี่ยนครั้งเดียว แต่ภายในจริง ๆ คือการเปลี่ยนสองครั้ง
    • สิ่งที่ออกไปควรช้า จึงต้องใช้ ease-in และสิ่งที่เข้ามาควรเป็น ease-out

พึ่งพา hardware acceleration

  • ไม่ใช่ว่าทุก CSS property จะทำงานได้ลื่นไหลบนทุกอุปกรณ์และทุกเบราว์เซอร์
  • คุณสมบัติที่ hardware acceleration รองรับเสมอ
    • transform (translate, scale, rotate ทั้งหมด รวมถึงเวอร์ชัน 3D)
    • opacity
  • คุณสมบัติที่อาจรองรับ hardware acceleration แล้วแต่กรณี
    • SVG properties บางตัว
    • filter (ขึ้นอยู่กับเบราว์เซอร์และชนิดของ filter)
  • Canvas และ WebGL ก็ใช้ hardware acceleration ได้เช่นกัน แต่ไม่ได้กล่าวถึงที่นี่
  • ดังนั้น ถ้าจะย้าย ปรับขนาด หรือหมุน ให้ใช้ CSS tranform property เสมอ
  • ไม่ว่าจะทำอะไร อย่าเปลี่ยนขนาดหรือตำแหน่งขององค์ประกอบโดยตรง
    • ถ้าเปลี่ยน property ที่ส่งผลต่อ page layout โดยตรง เช่น height, width, border, margin, padding ก็มีความเสี่ยงที่ความเร็วของหน้าจะช้าลงอย่างเห็นได้ชัด

ใช้ will-change เมื่อจำเป็น

  • ในทางทฤษฎีแอนิเมชันควรลื่นไหลและมีประสิทธิภาพดี แต่ถ้ายังดูไม่เป็นธรรมชาติ ให้ลองใช้ property will-change
  • เพราะมันบอกล่วงหน้าว่าอะไรจะเปลี่ยน ทำให้ข้ามการคำนวณบางอย่างได้

โบนัส: เคารพความชอบของผู้ใช้

  • ผู้ใช้สามารถกำหนดได้จากการตั้งค่าอุปกรณ์ว่าต้องการ "reduced motion" หรือไม่
  • สามารถตรวจจับค่านี้ผ่าน media query หรือ JavaScript แล้วตอบสนองให้เหมาะสมได้

ยังไม่มีความคิดเห็น

ยังไม่มีความคิดเห็น