ขั้นตอนปกติหลังจากได้รับ PushSubscription และบันทึกลงในเซิร์ฟเวอร์ของเราคือการเรียกให้แสดงข้อความ Push แต่มีสิ่งหนึ่งที่ฉันละเลยอย่างโจ่งแจ้ง ประสบการณ์ของผู้ใช้เมื่อขอสิทธิ์จากผู้ใช้เพื่อส่งข้อความ Push
แต่น่าเสียดายที่มีเว็บไซต์เพียงไม่กี่แห่งที่พิจารณาอย่างถี่ถ้วนเกี่ยวกับวิธีขอสิทธิ์จากผู้ใช้ ดังนั้นเรามาลองดู UX ทั้งที่ดีและไม่ดีกันสักครู่
รูปแบบที่พบบ่อย
เราได้พบรูปแบบทั่วไปบางอย่างที่ควรใช้เป็นแนวทางและช่วยคุณเมื่อต้องตัดสินใจว่าสิ่งใดดีที่สุดสําหรับผู้ใช้และกรณีการใช้งาน
การนำเสนอคุณค่า
ขอให้ผู้ใช้สมัครรับการพุชในเวลาที่เห็นได้ชัดว่ามีประโยชน์
เช่น ผู้ใช้เพิ่งซื้อสินค้าในร้านค้าออนไลน์และทำตามขั้นตอนการชำระเงินจนเสร็จสิ้น จากนั้นเว็บไซต์จะแสดงข้อมูลอัปเดตเกี่ยวกับสถานะการนำส่งได้
แนวทางนี้ใช้ได้ในหลายสถานการณ์ ดังนี้
- สินค้าบางรายการหมด คุณต้องการรับการแจ้งเตือนเมื่อสินค้าพร้อมจำหน่ายอีกครั้งไหม
- เรื่องราวข่าวด่วนนี้จะได้รับการอัปเดตเป็นประจำ คุณต้องการรับการแจ้งเตือนเมื่อเรื่องราวมีการพัฒนาไหม
- คุณเป็นผู้เสนอราคาสูงสุด คุณต้องการรับการแจ้งเตือนหากมีผู้เสนอราคาสูงกว่าไหม
ทั้งหมดนี้คือจุดที่ผู้ใช้ลงทุนในบริการของคุณและมีข้อเสนอแนะที่ชัดเจนเพื่อให้ผู้ใช้เปิดใช้ Push Notifications
ได้สร้างเว็บไซต์จำลองของสายการบินสมมติเพื่อสาธิตแนวทางนี้
หลังจากผู้ใช้จองเที่ยวบินแล้ว ระบบจะถามว่าผู้ใช้ต้องการรับการแจ้งเตือนเกี่ยวกับความล่าช้าของเที่ยวบินหรือไม่
โปรดทราบว่านี่เป็น UI ที่กําหนดเองจากเว็บไซต์
อีกสิ่งที่น่าสนใจในเดโมของ Owen คือหากผู้ใช้คลิกเพื่อเปิดใช้การแจ้งเตือน เว็บไซต์จะเพิ่มการซ้อนทับแบบโปร่งแสงครึ่งหนึ่งในทั้งหน้าเมื่อแสดงข้อความแจ้งสิทธิ์ ซึ่งดึงดูดความสนใจของผู้ใช้ให้ไปที่ข้อความแจ้งสิทธิ์
ตัวอย่างทางเลือกสำหรับกรณีนี้ ซึ่งเป็นUX ที่ไม่เหมาะสมสำหรับการขอสิทธิ์คือการขอสิทธิ์ทันทีที่ผู้ใช้เข้าสู่เว็บไซต์ของสายการบิน
แนวทางนี้ไม่มีบริบทว่าเหตุใดจึงจำเป็นต้องมีการแจ้งเตือนหรือแจ้งเตือนเพื่อประโยชน์ใดแก่ผู้ใช้ นอกจากนี้ ระบบยังบล็อกไม่ให้ผู้ใช้ทำภารกิจเดิม (เช่น จองเที่ยวบิน) ได้ด้วยข้อความแจ้งสิทธิ์นี้
สิทธิ์แบบคู่
คุณอาจรู้สึกว่าเว็บไซต์มี Use Case ที่ชัดเจนสำหรับข้อความ Push และต้องการขอสิทธิ์จากผู้ใช้โดยเร็วที่สุด
เช่น โปรแกรมรับส่งข้อความและอีเมล การแสดงข้อความสำหรับอีเมลหรือข้อความใหม่เป็นประสบการณ์ของผู้ใช้ที่พบได้ทั่วไปในแพลตฟอร์มต่างๆ
สําหรับแอปในหมวดหมู่เหล่านี้ คุณควรพิจารณารูปแบบสิทธิ์แบบคู่
ก่อนอื่นให้แสดงข้อความแจ้งสิทธิ์ปลอมที่เว็บไซต์ของคุณควบคุม ซึ่งประกอบด้วยปุ่มให้อนุญาตหรือละเว้นคำขอสิทธิ์ หากผู้ใช้คลิก "อนุญาต" ระบบจะส่งคําขอสิทธิ์ ซึ่งจะทริกเกอร์ข้อความแจ้งสิทธิ์ของเบราว์เซอร์จริง
แนวทางนี้ช่วยให้คุณแสดงข้อความแจ้งสิทธิ์ที่กําหนดเองในเว็บแอปซึ่งขอให้ผู้ใช้เปิดใช้การแจ้งเตือน ซึ่งจะช่วยให้ผู้ใช้เลือกเปิดหรือปิดได้โดยไม่ต้องเสี่ยงที่เว็บไซต์จะถูกบล็อกอย่างถาวร หากผู้ใช้เลือก "เปิดใช้" ใน UI ที่กําหนดเอง ให้แสดงข้อความแจ้งสิทธิ์จริง ไม่เช่นนั้น ให้ซ่อนป๊อปอัปที่กําหนดเองและขออนุญาตในภายหลัง
ตัวอย่างที่ดีของกรณีนี้คือ โดยแอปจะแสดงข้อความแจ้งที่ด้านบนของหน้าเมื่อคุณลงชื่อเข้าใช้เพื่อถามว่าต้องการเปิดใช้การแจ้งเตือนหรือไม่
แผงควบคุมการตั้งค่า
คุณสามารถย้ายการแจ้งเตือนไปยังแผงการตั้งค่าเพื่อให้ผู้ใช้เปิดและปิดใช้การรับส่งข้อความ Push ได้อย่างง่ายดายโดยไม่ต้องทำให้ UI ของเว็บแอปรก
ตัวอย่างที่ดีของกรณีนี้คือ เมื่อโหลดเว็บไซต์ Google I/O เป็นครั้งแรก ระบบจะไม่ขอให้คุณดำเนินการใดๆ ผู้ใช้จะสำรวจเว็บไซต์ได้อย่างเต็มที่
หลังจากเข้าชม 2-3 ครั้ง การคลิกรายการเมนูทางด้านขวาจะแสดงแผงการตั้งค่าที่ช่วยให้ผู้ใช้ตั้งค่าและจัดการการแจ้งเตือนได้
การคลิกช่องทําเครื่องหมายจะแสดงข้อความแจ้งสิทธิ์ ไม่มีค่าใช้จ่ายแอบแฝง
หลังจากให้สิทธิ์แล้ว ระบบจะเลือกช่องทำเครื่องหมายและผู้ใช้ก็พร้อมใช้งาน สิ่งยอดเยี่ยมเกี่ยวกับ UI นี้คือผู้ใช้สามารถเปิดและปิดใช้การแจ้งเตือนได้จากที่เดียวในเว็บไซต์
แนวทางแบบไม่โต้ตอบ
วิธีที่ง่ายที่สุดวิธีหนึ่งในการแสดง Push แก่ผู้ใช้คือการมีปุ่มหรือสวิตช์เปิด/ปิดที่เปิด/ปิดข้อความ Push ในตําแหน่งในหน้าเว็บที่สอดคล้องกันทั่วทั้งเว็บไซต์
การดำเนินการนี้ไม่ได้กระตุ้นให้ผู้ใช้เปิดใช้ข้อความ Push แต่ให้วิธีที่เชื่อถือได้และง่ายดายสำหรับผู้ใช้ในการเลือกใช้หรือไม่เลือกใช้การมีส่วนร่วมกับเว็บไซต์ สําหรับเว็บไซต์อย่างบล็อกที่อาจมีผู้ชมทั่วไปอยู่บ้างและอัตราตีกลับสูง ตัวเลือกนี้เป็นตัวเลือกที่ยอดเยี่ยมเนื่องจากจะกําหนดเป้าหมายไปยังผู้ชมทั่วไปโดยไม่รบกวนผู้เข้าชมแบบสุ่ม
ในเว็บไซต์ส่วนตัวของฉัน ฉันมีปุ่มเปิด/ปิดสำหรับข้อความ Push ที่ส่วนท้าย
ตำแหน่งนี้ค่อนข้างจะไม่ค่อยสะดวกนัก แต่ผู้เข้าชมทั่วไปควรสนใจพอที่จะอ่านข้อมูลอัปเดต ผู้เข้าชมแบบครั้งเดียวจะไม่ได้รับผลกระทบใดๆ ทั้งสิ้น
หากผู้ใช้สมัครรับข้อความ Push สถานะของปุ่มสลับจะเปลี่ยนไปและคงสถานะไว้ตลอดทั้งเว็บไซต์
UX ที่แย่
ตัวอย่างแนวทางปฏิบัติทั่วไปที่เราสังเกตเห็นบนเว็บมีดังนี้ แต่น่าเสียดายที่ยังมีแนวทางปฏิบัติที่ไม่ถูกต้องซึ่งพบได้ทั่วไป
สิ่งที่แย่ที่สุดที่คุณทําได้คือแสดงกล่องโต้ตอบสิทธิ์ต่อผู้ใช้ทันทีที่ผู้ใช้เข้าสู่เว็บไซต์
ผู้ใช้ไม่มีบริบทใดๆ ว่าเหตุใดจึงมีการขอสิทธิ์จากตน และอาจไม่รู้ด้วยซ้ำว่าเว็บไซต์ของคุณมีไว้เพื่ออะไร ทำอะไร หรือเสนออะไร การบล็อกสิทธิ์ในตอนนี้เนื่องจากความหงุดหงิดนั้นไม่ใช่เรื่องแปลก เนื่องจากการปรากฏขึ้นของป๊อปอัปนี้ทำให้ผู้ใช้ทำสิ่งที่ต้องการไม่ได้
โปรดทราบว่าหากผู้ใช้บล็อกคำขอสิทธิ์ เว็บแอปของคุณจะขอสิทธิ์ไม่ได้อีก หากต้องการรับสิทธิ์หลังจากถูกบล็อก ผู้ใช้ต้องเปลี่ยนสิทธิ์ใน UI ของเบราว์เซอร์ ซึ่งไม่ใช่เรื่องง่าย ชัดเจน หรือสนุกสนานสำหรับผู้ใช้
ไม่ว่าในกรณีใดก็ตาม อย่าขอสิทธิ์ทันทีที่ผู้ใช้เปิดเว็บไซต์ของคุณ ให้พิจารณา UI หรือแนวทางอื่นๆ ที่มีสิ่งจูงใจให้ผู้ใช้ให้สิทธิ์
เสนอวิธีแก้ปัญหา
นอกจากการพิจารณา UX เพื่อสมัครรับข้อความ Push ของผู้ใช้แล้ว โปรดพิจารณาวิธีที่ผู้ใช้ควรยกเลิกการสมัครรับหรือเลือกไม่รับข้อความ Push
จำนวนเว็บไซต์ที่ขอสิทธิ์ทันทีที่หน้าเว็บโหลดและไม่มี UI สำหรับการปิดใช้ข้อความ Push นั้นน่าตกใจ
เว็บไซต์ควรอธิบายให้ผู้ใช้ทราบถึงวิธีปิดใช้ Push หากไม่ดำเนินการดังกล่าว ผู้ใช้มีแนวโน้มที่จะใช้ตัวเลือกขั้นสูงสุดและบล็อกสิทธิ์อย่างถาวร
ขั้นตอนถัดไป
- ภาพรวมข้อความ Push บนเว็บ
- วิธีการทำงานของ Push
- การติดตามผู้ใช้
- UX ของสิทธิ์
- การส่งข้อความด้วยไลบรารี Web Push
- Web Push Protocol
- การจัดการเหตุการณ์ Push
- การแสดงการแจ้งเตือน
- ลักษณะการทํางานของการแจ้งเตือน
- รูปแบบการแจ้งเตือนที่พบบ่อย
- คำถามที่พบบ่อยเกี่ยวกับข้อความ Push
- ปัญหาที่พบได้ทั่วไปและการรายงานข้อบกพร่อง