अनुमति के लिए UX

PushSubscription पाने और उसे सेव करने के बाद, एक सामान्य कदम है एक पुश मैसेज को ट्रिगर करना, लेकिन एक ऐसी चीज़ है जिसे मैंने साफ़-साफ़ ज़ाहिर किया है. उपयोगकर्ता से पुश मैसेज भेजने के लिए, उसकी अनुमति मांगने पर उपयोगकर्ता अनुभव.

अफ़सोस की बात यह है कि बहुत कम साइटें इस बात पर काफ़ी ध्यान देती हैं कि वे किस तरह लोगों से अनुमति मांगती हैं. इसलिए, चलिए एक तरफ़ अच्छे और बुरे UX के बारे में बात करते हैं.

सामान्य पैटर्न

कुछ ऐसे सामान्य पैटर्न उभर रहे हैं जिनसे आपको यह तय करने में मदद मिल सकती है कि आपके उपयोगकर्ताओं के लिए क्या सबसे अच्छा है और क्या इस्तेमाल करना चाहिए.

खास बात

उपयोगकर्ताओं को ऐसे समय में पुश करने के लिए सदस्यता लेने के लिए कहें जब फ़ायदा साफ़ तौर पर हो.

उदाहरण के लिए, किसी उपयोगकर्ता ने हाल ही में किसी ऑनलाइन स्टोर से आइटम खरीदा है और चेकआउट फ़्लो पूरा किया है. इसके बाद, साइट डिलीवरी की स्थिति के बारे में अपडेट दे सकती है.

ऐसी कई स्थितियां हैं जिनमें यह तरीका काम करता है:

  • कोई खास आइटम स्टॉक में नहीं है. क्या आपको इसके अगली बार उपलब्ध होने पर सूचना चाहिए?
  • यह ताज़ा खबर नियमित रूप से अपडेट की जाएगी, जैसे-जैसे कहानी आगे बढ़ेगी, क्या आपको इसके बारे में सूचना मिलेगी?
  • आप सबसे ज़्यादा बोली लगाने वाले हैं. अगर आपकी बोली अच्छी नहीं है, तो क्या आपको इसकी सूचना चाहिए?

ये सभी पॉइंट उस जगह पर होते हैं जहां उपयोगकर्ता ने आपकी सेवा में निवेश किया है. साथ ही, पुश नोटिफ़िकेशन चालू करने के लिए, साफ़ तौर पर यह सुविधा उपलब्ध है.

ओवेन कैंपबेल-मूर पुश के लिए अच्छे UX का उदाहरण हैं.

इस तरीके को दिखाने के लिए, हमने एक काल्पनिक एयरलाइन वेबसाइट का एक मॉक तैयार किया.

जब उपयोगकर्ता फ़्लाइट बुक कर लेता है, तब वह पूछता है कि क्या उसे फ़्लाइट में होने वाली देरी की सूचनाएं चाहिए.

ध्यान दें कि यह इस वेबसाइट का एक कस्टम यूज़र इंटरफ़ेस (यूआई) है.

ओवेन कैंपबेल-मूर ने अनुमति देने के लिए एक अच्छे UX का उदाहरण दिया है.

ओवेन के डेमो में एक और अच्छी बात यह है कि अगर लोग सूचनाएं चालू करने के लिए क्लिक करते हैं, तो अनुमति का अनुरोध दिखने पर, साइट पूरे पेज पर सेमी-पारदर्शी ओवरले जोड़ देती है. इससे लोगों का ध्यान अनुमति के प्रॉम्प्ट पर आ जाता है.

इस उदाहरण के अलावा, अनुमति मांगने के लिए खराब UX का मतलब है, एयरलाइन की साइट पर उपयोगकर्ता के आते ही अनुमति का अनुरोध करना.

ओवेन कैंपबेल-मूर का पुश्तैनी UX (उपयोगकर्ता अनुभव) खराब रहने का उदाहरण.

इस तरीके से इस बात का कोई संदर्भ नहीं मिलता कि उपयोगकर्ता के लिए सूचनाओं की ज़रूरत क्यों है या वे उपयोगकर्ता के लिए क्यों फ़ायदेमंद हैं. अनुमति के इस अनुरोध से, उपयोगकर्ता को अपना मूल काम (जैसे- फ़्लाइट बुक करना) भी नहीं मिल पाता.

दोहरी अनुमति

आपको लग सकता है कि आपकी साइट में पुश मैसेज सेवा के इस्तेमाल का उदाहरण है. इसलिए, आपको उपयोगकर्ता से जल्द से जल्द अनुमति लेनी है.

उदाहरण के लिए, फटाफट मैसेज सेवा और ईमेल क्लाइंट. किसी नए मैसेज या ईमेल के लिए मैसेज दिखाना, अलग-अलग प्लैटफ़ॉर्म पर उपयोगकर्ताओं के लिए आसानी से बनाया जा सकता है.

इस तरह के ऐप्लिकेशन के लिए, डबल अनुमति वाले पैटर्न को ध्यान में रखना बेहतर होता है.

सबसे पहले अनुमति के अनुरोध को अनुमति देने या उसे अनदेखा करने के बटन वाले नकली अनुमति का प्रॉम्प्ट दिखाएं. यह आपकी वेबसाइट को कंट्रोल करता है. अगर उपयोगकर्ता अनुमति पर क्लिक करता है, तो अनुमति का अनुरोध करें और ब्राउज़र की अनुमति का अनुरोध ट्रिगर करें.

इस तरीके से, आपके वेब ऐप्लिकेशन में कस्टम अनुमति का अनुरोध दिखता है जो लोगों से सूचनाएं चालू करने के लिए कहता है. ऐसा करके, उपयोगकर्ता आपकी वेबसाइट को हमेशा के लिए ब्लॉक किए जाने का जोखिम उठाए बिना चालू या बंद करने का विकल्प चुन सकता है. अगर उपयोगकर्ता कस्टम यूज़र इंटरफ़ेस (यूआई) पर 'चालू करें' चुनता है, तो असली अनुमति का प्रॉम्प्ट दिखाएं या फिर कस्टम पॉप-अप छिपाएं और कुछ और समय पूछें.

इसका एक अच्छा उदाहरण है . जब आप साइन इन करके यह पूछते हैं कि क्या आपको सूचनाएं पाने की सुविधा चालू करनी है, तो वे अपने पेज पर सबसे ऊपर एक प्रॉम्प्ट दिखाते हैं.

सेटिंग पैनल

नोटिफ़िकेशन को सेटिंग पैनल में ले जाया जा सकता है, जिससे उपयोगकर्ताओं को अपने वेब ऐप्लिकेशन के यूज़र इंटरफ़ेस (यूआई) को व्यवस्थित किए बिना, पुश मैसेज को चालू और बंद करने का आसान तरीका मिल जाता है.

पेज को पहली बार लोड करने पर, कोई सूचना नहीं दिखती है.

इसका एक अच्छा उदाहरण है . जब पहली बार Google I/O साइट को लोड किया जाता है, तो आपसे कुछ भी करने के लिए नहीं कहा जाता है. उपयोगकर्ता को साइट को एक्सप्लोर करने के लिए छोड़ दिया जाता है.

पुश मैसेज भेजने के लिए Google IO के वेब ऐप्लिकेशन का सेटिंग पैनल.

कुछ विज़िट के बाद, दाईं ओर मेन्यू आइटम पर क्लिक करने पर एक सेटिंग पैनल दिखता है. इससे, उपयोगकर्ता सूचनाओं को सेट अप और मैनेज कर सकते हैं.

Google IO का वेब ऐप्लिकेशन, जिस पर अनुमति का अनुरोध दिख रहा है.

चेकबॉक्स पर क्लिक करने से, अनुमति का अनुरोध दिखता है. कोई छिपा हुआ उपहार नहीं.

अनुमति मिलने के बाद, चेकबॉक्स पर सही का निशान लगाया जाता है और उपयोगकर्ता इस्तेमाल के लिए तैयार है. इस यूज़र इंटरफ़ेस (यूआई) की सबसे अच्छी बात यह है कि लोग वेबसाइट पर एक ही जगह से सूचनाओं को चालू और बंद कर सकते हैं.

पैसिव अप्रोच शॉट

किसी उपयोगकर्ता को पुश नोटिफ़िकेशन देने के सबसे आसान तरीकों में से एक है, बटन या टॉगल स्विच का इस्तेमाल करना, जो पेज पर एक ऐसी जगह पर पुश मैसेज को चालू / बंद करता है जो साइट पर एक जैसी होती है.

यह उपयोगकर्ताओं को पुश नोटिफ़िकेशन चालू करने के लिए नहीं कहता है, लेकिन उपयोगकर्ताओं को आपकी वेबसाइट में दिलचस्पी लेने के लिए ऑप्ट-इन और ऑप्ट-आउट करने का भरोसेमंद और आसान तरीका उपलब्ध कराता है. ब्लॉग जैसी साइटों के लिए, जिनके कुछ नियमित दर्शक हो सकते हैं और बाउंस रेट भी ज़्यादा. यह एक बढ़िया विकल्प है, क्योंकि यह वेबसाइट पर आने वाले लोगों को परेशान किए बिना नियमित दर्शकों को टारगेट करता है.

मेरी निजी साइट पर, फ़ुटर में पुश मैसेज सेवा के लिए टॉगल स्विच है.

फ़ुटर में, Guntface.com के पुश नोटिफ़िकेशन टॉगल का उदाहरण

ऐसा करना आम बात नहीं है, लेकिन नियमित तौर पर वेबसाइट पर आने वाले लोगों के लिए इसे काफ़ी ध्यान देना चाहिए, जो कि अपडेट पाने की इच्छा रखते हैं. एक बार आने वाले लोगों पर कोई असर नहीं पड़ता.

अगर कोई उपयोगकर्ता पुश मैसेज की सदस्यता लेता है, तो टॉगल स्विच की स्थिति बदल जाती है और पूरी साइट पर बनी रहती है.

ऐसे Garntface.com का उदाहरण
जिसमें सूचनाएं हैं

खराब UX

ये कुछ सामान्य व्यवहार हैं जिन्हें मैंने वेब पर देखा है. अफ़सोस की बात यह है कि एक आम बात है.

सबसे खराब बात यह है कि जैसे ही उपयोगकर्ता आपकी साइट पर आते हैं, उन्हें अनुमति वाला डायलॉग दिखाया जा सकता है.

उन्हें इस बात की कोई जानकारी नहीं है कि उनसे अनुमति लेने के लिए क्यों कहा जा रहा है. उन्हें शायद यह पता ही न हो कि आपकी वेबसाइट किस काम के लिए है, वह क्या करती है या वह क्या ऑफ़र करती है. परेशानी की वजह से कभी-कभी अनुमतियों को ब्लॉक करना भी कोई बड़ी बात नहीं है. इस पॉप-अप की वजह से लोगों को उनके काम में रुकावट आ रही है.

याद रखें, अगर कोई उपयोगकर्ता अनुमति के अनुरोध को ब्लॉक कर देता है, तो आपका वेब ऐप्लिकेशन उसे फिर से अनुमति नहीं मांग सकता. ब्लॉक किए जाने के बाद अनुमति पाने के लिए, उपयोगकर्ता को ब्राउज़र के यूज़र इंटरफ़ेस (यूआई) में अनुमति बदलनी होगी. ऐसा करना उपयोगकर्ता के लिए आसान, साफ़ तौर पर समझ में आने वाला या मज़ेदार नहीं होता.

चाहे जो भी हो, उपयोगकर्ता के आपकी साइट खोलते ही अनुमति न मांगें, कुछ ऐसे यूज़र इंटरफ़ेस (यूआई) या तरीके पर विचार करें जो उपयोगकर्ता से अनुमति देने के लिए बढ़ावा देते हों.

बाहर निकलने का रास्ता बताएं

किसी उपयोगकर्ता को पुश करने के लिए, उसकी सदस्यता लेने के लिए UX को ध्यान में रखने के साथ-साथ, कृपया यह भी सोचें कि उपयोगकर्ता को किस तरह सदस्यता छोड़नी चाहिए या पुश मैसेज से ऑप्ट आउट करना चाहिए.

ऐसी साइटें जो पेज लोड होते ही अनुमति मांगती हैं और फिर पुश नोटिफ़िकेशन बंद करने के लिए कोई यूज़र इंटरफ़ेस (यूआई) न ऑफ़र करती हैं, इसकी संख्या अद्भुत है.

आपकी साइट पर आपके उपयोगकर्ताओं को यह समझाना चाहिए कि वे पुश नोटिफ़िकेशन को कैसे बंद कर सकते हैं. अगर ऐसा नहीं किया जाता है, तो हो सकता है कि लोग न्यूक्लियर विकल्प अपना लें और अनुमति को हमेशा के लिए ब्लॉक कर दें.

आगे कहां जाना है

कोड लैब