अब तक, जब कोई उपयोगकर्ता किसी ऐसी साइट पर जाता था जिस पर अनुमति का अनुरोध किया जाता है, तो उपयोगकर्ता से फ़ैसला लेने के लिए कहने के लिए एक बबल पॉप-अप होता था. उदाहरण के लिए, जियोलोकेशन की अनुमति के अनुरोध को 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 की टीम इन समस्याओं पर पहले से ही काम कर रही है. साथ ही, वह पहले के व्यवहार के आधार पर, अनुमतियों को अपने-आप ब्लॉक करने की ज़्यादा बेहतर सुविधा पर काम कर रही है. इन प्लान के पूरा होने के बाद, आपको इस बारे में यहां जानकारी मिलेगी.
आखिर में, हम यह बताना चाहते हैं कि नए यूज़र इंटरफ़ेस (यूआई) की मदद से, किसी फ़ैसले पर जल्दी फ़ैसला लेने की ज़रूरत नहीं पड़ती. साथ ही, इससे ब्राउज़ करने का अनुभव भी बेहतर होता है. ज़्यादातर अनुमति के अनुरोधों को ब्लॉक किया जाता है या अनदेखा किया जाता है. इसलिए, हमारा मकसद ब्राउज़िंग के सामान्य अनुभव को बेहतर बनाना था. साथ ही, अनुमति का अनुरोध दिखाते समय उपयोगकर्ता के फ़्लो को न तोड़ना था. ऐसा खास तौर पर उन मामलों में ज़रूरी है जहां किसी इस्तेमाल के उदाहरण को पूरा करने के लिए अनुमतियां ज़रूरी हैं.
धन्यवाद
इस दस्तावेज़ की समीक्षा जो मेडली ने की है.