UI เชิงคาดการณ์คืออะไรและควรใช้เมื่อใด

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

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

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

ส่วนติดต่อผู้ใช้แบบคาดการณ์ผลสำเร็จไม่เหมาะกับการดำเนินการที่มีความเสี่ยงสูงหรือย้อนกลับไม่ได้ โปรด NOT ใช้กับกรณีต่อไปนี้: ธุรกรรมทางการเงิน (แสดงว่าการชำระเงินสำเร็จก่อนเซิร์ฟเวอร์ยืนยัน), การลบระเบียนอย่างถาวร, การสร้างระเบียนที่ต้องผ่านการตรวจสอบฝั่งเซิร์ฟเวอร์ (เช่น ชื่อผู้ใช้ที่ไม่ซ้ำกันหรือรหัสเชิญ) หรือการดำเนินการใด ๆ ที่ความสำเร็จเท็จอาจทำให้ข้อมูลเสียหาย

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

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

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

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

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

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

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

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