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