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