अनुमति देने के अनुरोध, वेब का मुख्य तरीका है. इसकी मदद से उन क्षमताओं को बचाया जा सकता है जो उपयोगकर्ताओं की निजता और सुरक्षा के लिए खतरनाक हो सकती हैं. अनुमति देने के निर्देशों की मदद से, ब्राउज़र का मकसद यह पक्का करना होता है कि उपयोगकर्ता, अनुरोध करने वाली वेबसाइट को वह सुविधा ऐक्सेस करने की अनुमति देना चाहता है जिसके बारे में शिकायत की गई है. अनुमति के प्रॉम्प्ट का इस्तेमाल कई एपीआई के लिए किया जाता है. इनमें मीडिया कैप्चर (कैमरा और माइक्रोफ़ोन), जियोलोकेशन, स्टोरेज का ऐक्सेस, एमआईडीआई, और सूचनाएं शामिल हैं. ज़्यादा जानकारी के लिए, एमडीएन पर अनुमतियां एपीआई के दस्तावेज़ देखें.
इस गाइड में, Chrome के इस्तेमाल के आंकड़े और उपयोगकर्ताओं पर की गई रिसर्च के आधार पर, उपयोगकर्ताओं को अनुमति मांगने के सबसे सही तरीके बताए गए हैं. इन सबसे सही तरीकों का पालन करते समय, उपयोगकर्ताओं को गै़र-ज़रूरी निर्देशों का कम सामना करना पड़ेगा. इससे, डेवलपर को "ब्लॉक करने" के फ़ैसले कम मिलते हैं. इस लेख के आखिर में, कुछ कोड पैटर्न के बारे में बताया गया है. ये पैटर्न, अनुमति की पाबंदी वाले एपीआई के साथ काम करते हैं. साथ ही, उन सबसे सही तरीकों की जानकारी देते हैं जिनकी मदद से उपयोगकर्ता, ब्लॉक की गई स्थिति से रिकवर कर सकते हैं.
सबसे सही तरीके बताना
आपको लोगों से इंटरैक्शन के बाद अनुमति लेनी चाहिए. जब उपयोगकर्ता यह समझ जाए कि आप क्यों पूछ रहे हैं और अनुमति देने से उन्हें क्या फ़ायदा होगा. जहां भी हो सके, उपयोगकर्ताओं को इस सुविधा को पूरा करने के लिए दूसरे तरीकों का इस्तेमाल करने की भी अनुमति देनी चाहिए. एक सामान्य दिशा-निर्देश के तौर पर, बहुत कम बार अनुमति मांगने के लिए, प्रॉम्प्ट के सही पल चुनने से उपयोगकर्ताओं के ब्लॉक होने की संभावना कम हो जाती है. यहां दिए गए सबसे सही तरीकों में, इन सभी सुझावों के बारे में ज़्यादा जानकारी दी गई है.
पेज लोड होने पर या उपयोगकर्ता के इंटरैक्शन के बिना कभी न पूछें
उपयोगकर्ताओं से पेज लोड होने की अनुमति मांगना, ठीक वैसे ही है जैसे किसी दुकान में जाते समय किसी ग्राहक से कोई संवेदनशील जानकारी मांगी जाती है. अनुमति का प्रॉम्प्ट (जैसे, न्यूज़लेटर के लिए साइनअप करने और कुकी के लिए सहमति देने से जुड़े अन्य प्रॉम्प्ट के साथ) देखना बहुत मुश्किल काम होता है. उपयोगकर्ता यह नहीं समझ पाएंगे कि उनसे क्यों पूछा जा रहा है और उन्हें इससे क्या फ़ायदा होगा.
भले ही आपका वेब ऐप्लिकेशन किसी खास सुविधा के ऐक्सेस के बिना काम न कर सकता हो, लेकिन आपको उपयोगकर्ताओं को यह समझने का मौका देना चाहिए कि इसकी ज़रूरत क्यों है. उदाहरण के लिए, अनुमति के प्रॉम्प्ट को खुद प्रॉम्प्ट के साथ दिखाना, जिससे उपयोगकर्ताओं को सुविधा की ज़रूरत के बारे में पता चलता हो और उपयोगकर्ताओं को विकल्प दिया जाता है. उदाहरण के लिए, जहां मुमकिन हो, उस सुविधा को पूरा करने के लिए अन्य तरीके उपलब्ध कराकर. अगर पेज लोड होने के बजाय, अनुमति मांगने का सबसे अच्छा समय नहीं है, तो इस गाइड में आगे इसके कुछ उदाहरण दिए गए हैं.
अनुमति मांगने की एक ही खराब स्थिति है. इस स्थिति में, उपयोगकर्ता के साथ पहले कोई इंटरैक्शन नहीं किया जाता. इसे उपयोगकर्ता के इंटरैक्शन को अस्थायी तौर पर ऐक्टिवेट करना भी कहा जाता है. Chrome की टेलीमेट्री से पता चलता है कि डेस्कटॉप पर, Chrome की अनुमतियों के 77% प्रॉम्प्ट, उपयोगकर्ता के इंटेंट के बुनियादी सिग्नल के बिना दिखाए जाते हैं. इस वजह से, इस तरह के सिर्फ़ 12% प्रॉम्प्ट को अनुमति दी जाती है. उपयोगकर्ता के इंटरैक्शन के बाद, इसकी दरों को 30% तक बढ़ा दिया जाता है. इसलिए, सिर्फ़ तब अनुमति लें, जब उपयोगकर्ता किसी फ़ॉर्म में पेज से इंटरैक्ट कर ले.
सिर्फ़ तब पूछें, जब लोग यह समझ सकें कि आपके सवाल क्यों पूछे जा रहे हैं
अनुमति से जुड़े फ़ैसले आम तौर पर, निजता से जुड़े फ़ैसले होते हैं. कॉन्टेक्स्ट के हिसाब से इंटिग्रिटी फ़्रेमवर्क के आधार पर, हम जानते हैं कि निजता से जुड़े फ़ैसले बहुत अहम होते हैं. ऐक्सेस ज़रूरी होने की वजह को समझना, उसका एक अहम पहलू हो सकता है. इसलिए, आपको सिर्फ़ ऐसी क्षमताओं का अनुरोध करना चाहिए जो आपको उपयोगकर्ताओं को काम की जानकारी देने के लिए ज़रूरी हों (और जहां उपयोगकर्ता इस बात से सहमत हों कि उन्हें वाकई अपने फ़ायदे मिलेंगे). इसके अलावा, आपको उस समय अनुमति लेनी चाहिए, जब उपयोगकर्ता को साफ़ तौर पर पता चल जाए कि यह सुविधा आपके लिए मददगार क्यों है. इसका मकसद आपके उपयोगकर्ताओं के लिए, इस्तेमाल के संदर्भ को समझना आसान बनाना है.
उपयोगकर्ताओं पर की गई हमारी रिसर्च से पता चलता है कि जब उपयोगकर्ता यह समझ पाते हैं कि किसी साइट को ऐक्सेस क्यों चाहिए और वे उसके लिए कितने फ़ायदेमंद हैं, तो उस साइट को ऐक्सेस करने की अनुमति देने की संभावना काफ़ी बढ़ जाती है. हमने यह भी पाया है कि उपयोगकर्ता सबसे पहले अनजान साइटों को एक्सप्लोर करने की उम्मीद करते हैं. इससे वे यह समझ पाते हैं कि ऐक्सेस देने के बदले, उन्हें क्या फ़ायदा मिल सकता है. इस दौरान, वे अक्सर अनुमति वाले प्रॉम्प्ट को खारिज या अनदेखे कर सकते हैं. एक बार दी जाने वाली अनुमतियों के साथ, हो सकता है कि वे पहले एक विज़िट की अनुमति दें. आपके ऐप्लिकेशन को इन गतिविधियों का समर्थन करना चाहिए.
जहां तक हो सके, इस सुविधा को पूरा करने के लिए दूसरे तरीके उपलब्ध कराएं
ऐसा हो सकता है कि कुछ सुविधाओं के नतीजे, उपयोगकर्ताओं के लिए मददगार न हों. उदाहरण के लिए, बिना जीपीएस सेंसर वाले डेस्कटॉप डिवाइस की जियोलोकेशन की वजह से गलत जगह दिख सकती है. इसकी वजह यह है कि वह व्यक्ति वीपीएन से कनेक्ट है. ऐसा हो सकता है कि अन्य उपयोगकर्ता क्लिपबोर्ड का ऐक्सेस न दें, क्योंकि वे कंट्रोल में रहना चाहते हैं और इन इवेंट को, कुंजी के कॉम्बिनेशन से मैन्युअल तौर पर ट्रिगर करना पसंद करते हैं. इस तरह की स्थितियों में, एक जैसे नतीजे पाने के लिए, दूसरे तरीके उपलब्ध कराना ज़रूरी होता है. उदाहरण के लिए, अगर भौगोलिक स्थान की अनुमति का अनुरोध किया जा रहा है, तो ऐसा टेक्स्ट फ़ील्ड दें जिसमें आपके उपयोगकर्ता खुद को पिन कोड या पता डाल सकें. क्लिपबोर्ड की मदद से, पक्का करें कि कॉपी किए जाने वाले एलिमेंट को भी एक की-कॉम्बिनेशन या संदर्भ मेन्यू से चुना और कॉपी किया जा सकता हो. नोटिफ़िकेशन से, लोगों को पुश नोटिफ़िकेशन के बजाय ईमेल मिलने की सुविधा दें.
वैकल्पिक यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करना भी एक अच्छा पैटर्न है. इससे यह पता चलता है कि ऐक्सेस क्यों फ़ायदेमंद हो सकता है. उपयोगकर्ताओं को जियोलोकेशन एपीआई को ट्रिगर करने वाले बटन के बगल में जगह की जानकारी डालने का विकल्प दिखने पर, उन्हें इस पर कंट्रोल रहेगा. ऐसा इसलिए, क्योंकि उन्हें पता है कि वे सिर्फ़ अपना पता टाइप भी कर सकते हैं. इसी तरह, अगर पुश या ईमेल से सूचनाएं पाने या कैमरे और माइक्रोफ़ोन के ऐक्सेस की अनुमति के बिना मीटिंग में शामिल होने का विकल्प चुना जा रहा है, तो उपयोगकर्ता इससे होने वाले फ़ायदों को बेहतर तरीके से समझ सकते हैं.
खुद को किसी ब्लॉक स्थिति में न आने दें, क्योंकि इससे बाहर निकलना मुश्किल होता है
जब कोई उपयोगकर्ता अनुमति-गेट की गई क्षमता के ऐक्सेस को हमेशा के लिए न देने का फ़ैसला ले लेता है, तो ब्राउज़र उस फ़ैसले के मुताबिक काम करते हैं. अगर मुमकिन होता कि ऐक्सेस के लिए बार-बार अनुरोध किया जा सकता था, तो नुकसान पहुंचाने वाली साइटें, उपयोगकर्ताओं पर बार-बार निशाना लगाती रहेंगी. इसलिए, किसी सुविधा की ब्लॉक की गई स्थिति से वापस आने के लिए, उपयोगकर्ता को जान-बूझकर थोड़ी मेहनत करनी पड़ती है. इसी वजह से, ऐसी स्थितियों में उपयोगकर्ताओं से अनुमति न मांगें जहां यह संभावना हो कि कई उपयोगकर्ता इसे ऐक्सेस करने की अनुमति न दें.
ऐसा करने का एक सामान्य तरीका यह है कि आप तथाकथित पहले अनुरोध का इस्तेमाल करें, जहां आप अपने उपयोगकर्ताओं को बताते हैं कि आगे क्या होने वाला है और आपके ऐप्लिकेशन को ऐसी क्षमता की ज़रूरत क्यों है जिसका आप अनुरोध करने जा रहे हैं. ब्राउज़र की अनुमति के अनुरोध को सिर्फ़ तब ट्रिगर करें, जब उपयोगकर्ता ऐसे प्रॉम्प्ट पर सकारात्मक प्रतिक्रिया देता हो. कुछ स्थितियों में उपयोगकर्ताओं को उस स्थिति से हटना पड़ सकता है. इस बारे में ज़्यादा जानकारी के लिए, ब्लॉक किए गए स्टेटस से लोगों को रिकवर होने में मदद करना सेक्शन देखें.
तीसरे-पक्ष के कॉन्टेंट पर ध्यान देना
अनुमति वाले प्रॉम्प्ट का एक ऐसा सोर्स है जिसके बारे में आपको जानकारी होनी चाहिए. अपनी साइट पर तीसरे पक्ष की स्क्रिप्ट शामिल करने पर, वे अनुमति के ऐसे अनुरोध ट्रिगर कर सकती हैं जिन्हें आपको नहीं दिखाना है. इससे आपकी वेबसाइट पर लोगों को बेहतर अनुभव देने पर असर पड़ सकता है. खास तौर पर तब, जब इस तरह के प्रॉम्प्ट, पहले से बताए गए सबसे सही तरीक़ों का पालन नहीं करते. अपने उपयोगकर्ताओं के अनुभव को कंट्रोल करने के लिए, आपको उन सभी तीसरे पक्ष की लाइब्रेरी और स्क्रिप्ट के दस्तावेज़ ध्यान से पढ़ने चाहिए जिन्हें आपने अपने कोड में जोड़ा है.
अनुमति कब लेनी चाहिए
यहां कुछ ऐसे पलों के उदाहरण दिए गए हैं जिन्हें ऐक्सेस करने के लिए, अनुमति लेनी पड़ती है. इनमें सबसे सही तरीके भी बताए गए हैं, जो पहले से बताए गए हैं:
- जब कोई उपयोगकर्ता मैन्युअल रूप से पता डालने के लिए, फ़ॉर्म फ़ील्ड के बगल में मौजूद "मेरे जगह की जानकारी का इस्तेमाल करें" बटन पर क्लिक करता है.
- जब कोई उपयोगकर्ता किसी वीडियो चैनल या पोस्ट के सदस्य बन जाता है और एक डायलॉग बॉक्स पर दिए गए पॉज़िटिव बटन पर क्लिक करता है, जिसमें बताया जाता है कि अपडेट, उसके फ़ोन या डेस्कटॉप पर ईमेल या सूचनाओं के तौर पर डिलीवर किए जा सकते हैं.
- जब कोई उपयोगकर्ता ऐसे पेज पर पहुंचता है जहां उसे वीडियो कॉल में शामिल होने के लिए तैयार किया जाता है और वह कॉल में शामिल होने के लिए सकारात्मक तौर पर जवाब देता है कि उपयोगकर्ता उसे दिखाना चाहता है और पहले से सूचना दी जाती है (Google Meet की यह केस स्टडी देखें).
अनुमति मांगने के लिए कोड पैटर्न
एपीआई का इस्तेमाल करने की अनुमति पाने के तरीके, एपीआई के हिसाब से अलग-अलग होते हैं. कुछ (आम तौर पर पुराने) एपीआई ऐसे मॉडल का इस्तेमाल करते हैं जिसमें पहली बार एपीआई का इस्तेमाल करने पर, ब्राउज़र अपने-आप ही अनुमति मांगता है. navigator.geolocation.getCurrentPosition() को कॉल करते समय, जियोलोकेशन एपीआई इसका एक उदाहरण है.
try {
navigator.geolocation.getCurrentPosition((pos) => console.log(pos));
} catch (error) {
console.error(error);
}
अन्य एपीआई ऐसे मॉडल का इस्तेमाल करते हैं जहां आपको स्टैटिक तरीके से, पहले अनुमति के लिए अनुरोध करना होगा. इसका एक अच्छा उदाहरण है, Notification.requestPermission() सूचनाओं को अनुमति देना या आम तौर पर DeviceOrientationEvent.requestPermission() नहीं, जो डिवाइस ओरिएंटेशन इवेंट एपीआई का हिस्सा है. ध्यान दें कि कुछ ब्राउज़र दिए गए एपीआई को
अपने-आप अनुमति दे सकते हैं. उदाहरण के लिए, Chrome हमेशा डिवाइस के ओरिएंटेशन को ऐक्सेस करने देता है, जबकि Safari एक प्रॉम्प्ट दिखाता है.
const result = await DeviceOrientationEvent.requestPermission();
console.log(`The user's decision when prompted to use the Device Orientation
Events API was: ${result}.`);
if (result === 'granted') {
/* Use the API. */
}
अनुमतियों की स्थिति देखने का तरीका
यह देखने के लिए कि किसी खास एपीआई का इस्तेमाल किया जा सकता है या नहीं, अनुमतियां एपीआई में दिए गए navigator.permissions.query() तरीके का इस्तेमाल करें.
const result = await navigator.permissions.query({ name: 'geolocation' });
console.log(`The result of querying for the Geolocation API is:
${result.state}.`);
if (result.state === 'granted') {
// Use the API.
}
ब्लॉक किए गए लोगों को रिकवर होने में मदद करना
ऐक्सेस से जुड़ी समस्याओं को हल करने में उपयोगकर्ताओं की मदद करने के लिए, पता लगाएं कि उन्होंने अनुमतियां एपीआई का इस्तेमाल करके ऐक्सेस ब्लॉक कर दिया है. साथ ही, उन्हें सेटिंग बदलने का तरीका बताएं. उदाहरण के लिए, जब उपयोगकर्ता ऐसे यूज़र इंटरफ़ेस (यूआई) एलिमेंट के साथ इंटरैक्ट करते हैं जो अनुमतियों की पाबंदी वाली सुविधा से जुड़े होते हैं, तो पिछले सेक्शन में बताए गए पैटर्न का इस्तेमाल करें और समस्या हल करने वाला डायलॉग बॉक्स खोलें. अनुमति की स्थिति बदलने के सटीक तरीके, ब्राउज़र के हिसाब से अलग-अलग होते हैं. इसलिए, हो सकता है कि आप उपयोगकर्ता एजेंट स्ट्रिंग और आपके प्रॉडक्ट में सबसे ज़्यादा इस्तेमाल किए जाने वाले ब्राउज़र के आधार पर, मिलती-जुलती जानकारी देना चाहें.
Chrome में, उपयोगकर्ताओं को पता बार की बाईं ओर मौजूद "ट्यून" आइकॉन पर क्लिक करके, साइट कंट्रोल पर जाना होगा. यहां वे इससे जुड़ी अनुमति को टॉगल कर सकते हैं. कुछ मामलों में, उन्हें सुविधा का इस्तेमाल करने से पहले पेज को फिर से लोड करना पड़ सकता है. ऐसे में उस विंडो के सबसे ऊपर एक मैसेज बार दिखेगा, जो उससे जुड़े बटन पर क्लिक करने पर, फिर से लोड करने का विकल्प देगा.
दूसरे ब्राउज़र में अनुमतियों को कंट्रोल करने के मिलते-जुलते यूज़र इंटरफ़ेस (यूआई) मौजूद हैं (उदाहरण के लिए, देखें कि यह Firefox में कैसे काम करता है).