अब तक, जब कोई उपयोगकर्ता किसी ऐसी साइट पर जाता था जो अनुमति का अनुरोध करती थी, तो उपयोगकर्ता से फ़ैसला लेने के लिए कहने के लिए एक बबल पॉप-अप होता था. उदाहरण के लिए, आपको Chrome के 96 वर्शन तक, जगह की जानकारी की अनुमति का प्रॉम्प्ट दिख सकता है. (इस और अन्य अनुमतियों को हमारी डेमो साइट permission.site पर आज़माया जा सकता है.)
Chrome के टेलीमेट्री डेटा से पता चलता है कि अनुमति के लिए दिखाए गए कई अनुरोधों को अनदेखा कर दिया जाता है. Chrome के यूज़र एक्सपीरियंस की रिपोर्ट में, सूचना की अनुमति से जुड़ा डेटा खुद देखा जा सकता है. फ़िलहाल, नीचे दी गई टेबल देखें. इससे पता चलता है कि Windows के उपयोगकर्ताओं ने साइटों पर सूचना वाले प्रॉम्प्ट पर किस तरह प्रतिक्रिया दी. साथ ही, यह भी पता चलता है कि जगह की जानकारी वाले प्रॉम्प्ट को भी इसी तरह खारिज या अनदेखा किया गया.
इस बात को ध्यान में रखते हुए कि करीब 85% उपयोगकर्ता प्रॉम्प्ट को अनदेखा या खारिज करते हैं और खास तौर पर, प्रॉम्प्ट कितना अलग दिखता है और उपयोगकर्ताओं से तुरंत फ़ैसला लेने के लिए कहता है, ब्राउज़र के हिसाब से ज़रूरत के लेवल और उपयोगकर्ता की फ़ैसला लेने में देरी करने की प्राथमिकता के बीच विरोधाभास है. इससे यह धारणा बनती है कि किसी साइट के लिए अनुमति मांगना "परेशान करने वाला" है, क्योंकि उपयोगकर्ताओं को कई और चीज़ों पर प्रतिक्रिया देनी होती है, जैसे कि कुकी की सहमति वाले बैनर, न्यूज़लेटर के लिए साइन अप वगैरह.
नया डिज़ाइन
इसलिए, हमने Chrome 98 से ऐनिमेशन वाला चिप यूज़र इंटरफ़ेस (यूआई) जोड़ा है. यह यूआई, अनुमति का अनुरोध किए जाने पर लॉक के बगल में दिखता है. इसमें एक आइकॉन और लेबल होता है, जिसमें उस अनुमति के बारे में जानकारी होती है जिसके लिए अनुरोध किया जा रहा है. हमारा मकसद, वेब ब्राउज़िंग का अनुभव बेहतर बनाना था. साथ ही, अनुमति के ऐसे अनुरोधों से बचना था जो ज़्यादातर उपयोगकर्ताओं के लिए आम तौर पर ज़रूरी नहीं होते और जिन्हें अक्सर अनदेखा या खारिज कर दिया जाता है.
अनुरोध करने के लिए बने चिप पर क्लिक करने पर, मौजूदा प्रॉम्प्ट बबल दिखेगा. अगर यह पहले से नहीं दिख रहा है, तो यह दिखेगा. साथ ही, अनुरोध करने के लिए बने यूज़र इंटरफ़ेस (यूआई) में, अनुरोध बबल अपने-आप जुड़ जाएगा. यह इन हेयुरिस्टिक्स के आधार पर होता है:
- अनुमति, साइट से इंटरैक्ट करते समय उपयोगकर्ता के जेस्चर से ट्रिगर हुई थी, न कि साइट से अपने-आप ट्रिगर हुई थी.
- यह अनुमति ज़रूरी मानी जाती है और आम तौर पर यह स्पैम नहीं होती. इसमें कैमरा, माइक्रोफ़ोन, और माइक्रोफ़ोन के साथ जोड़ा गया कैमरा शामिल है.
नए डिज़ाइन को लागू करना
यह रोल आउट धीरे-धीरे किया जा रहा है. इसलिए, इन फ़्लैग को टॉगल करके, नए डिज़ाइन को तुरंत चालू किया जा सकता है:
chrome://flags/#permission-chipchrome://flags/#permission-chip-gesturechrome://flags/#permission-chip-request-type
नए डिज़ाइन का फ़्लो
उपयोगकर्ता के जेस्चर के हिसाब से काम करने की सुविधा के बिना
ज़रूरी नहीं होने वाली अनुमतियों के लिए, अब प्रॉम्प्ट साइट के कॉन्टेंट में नहीं दिखता. साथ ही, तुरंत फ़ैसला लेने के लिए भी नहीं कहता. उपयोगकर्ता, अनुरोध वाले चिप को तब तक अनदेखा कर सकता है, जब तक उसके पास फ़ैसला लेने के लिए ज़रूरी जानकारी न हो.
बिना इंटरैक्शन के
अगर कोई इंटरैक्शन नहीं होता है, तो कुछ देर बाद अनुरोध वाला चिप अपने-आप छोटा हो जाएगा और सिर्फ़ ब्लॉक किए गए आइकॉन में बदल जाएगा. इससे यह पता चलता है कि अनुमति कुछ समय के लिए ब्लॉक की गई है. इसके बाद, यह चिप पूरी तरह से हट जाएगा. इसका मकसद, उन उपयोगकर्ताओं को परेशानी से बचाना है जो कोई फ़ैसला नहीं लेना चाहते.
कम समय के लिए होने वाला असर
कुछ समय के लिए और जब तक उपयोगकर्ता नए यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करना नहीं सीख जाते, तब तक साइट के मालिकों को साइटों के लिए अनुमति मिलने की दरें कम दिख सकती हैं. ऐसा खास तौर पर उन साइटों के लिए होगा जो उपयोगकर्ता के जेस्चर के बिना या प्राइमिंग के बिना, अनुमतियों का अपने-आप अनुरोध करती हैं. इसे बुरा तरीका माना जाता है. हालांकि, इस कमाई के मुकाबले दर्शकों को लाइव स्ट्रीम के दौरान कम विज्ञापन दिखेंगे.
सबसे सही तरीके
यह साइट पर निर्भर करता है कि वह ज़रूरी जानकारी देती है या नहीं. साथ ही, यह भी कि वह सिर्फ़ सही और सही समय पर अनुमतियों का अनुरोध करती है या नहीं. जिन अनुमतियों को कुछ समय के लिए ब्लॉक किया गया है उनके लिए, उपयोगकर्ता उसी सेशन में फिर से अनुरोध कर सकता है. ऐसा तब होता है, जब उपयोगकर्ता अनुरोध को अनदेखा करता है या प्रॉम्प्ट को खारिज करता है. ऐसा सिर्फ़ तब करें, जब साइट या सुविधा के काम करने के लिए अनुमति ज़रूरी हो. ऐसा न करने पर, उपयोगकर्ताओं को परेशानी हो सकती है और साइट अपने-आप ब्लॉक हो सकती है. ऐसे मामलों में, हम साइलेंट मैसेजिंग की सुविधा दिखाते हैं. इसे Chrome 80 में लॉन्च किया गया था. सामान्य दिशा-निर्देशों के बारे में ज़्यादा जानने के लिए, अनुमति के लिए यूज़र एक्सपीरियंस देखें.
Outlook और नतीजे
आने वाले समय में, यूज़र इंटरफ़ेस (यूआई) और यूज़र एक्सपीरियंस (यूएक्स) को और बेहतर बनाने के लिए काम किया जा रहा है. Chrome की टीम इन समस्याओं पर पहले से ही काम कर रही है. साथ ही, वह ऐप्लिकेशन के पिछले व्यवहार के आधार पर, अनुमतियों को अपने-आप ब्लॉक करने की ज़्यादा बेहतर सुविधा पर भी काम कर रही है. इन प्लान के पूरा होने के बाद, आपको इस बारे में यहां जानकारी मिलेगी.
आखिर में, नए यूज़र इंटरफ़ेस (यूआई) से किसी फ़ैसले पर जोर देने की ज़रूरत कम हो जाती है. साथ ही, ब्राउज़ करने का अनुभव बेहतर होता है. ज़्यादातर अनुमति के अनुरोधों को ब्लॉक किया जाता है या अनदेखा किया जाता है. इसलिए, हमारा मकसद ब्राउज़िंग के सामान्य अनुभव को बेहतर बनाना था. साथ ही, अनुमति का अनुरोध दिखाते समय उपयोगकर्ताओं के फ़्लो को न तोड़ना था. ऐसा खास तौर पर उन मामलों में ज़रूरी है जहां किसी इस्तेमाल के उदाहरण को पूरा करने के लिए अनुमतियां ज़रूरी हैं.
Acknowledgements
इस दस्तावेज़ की समीक्षा जो मेडली ने की है.