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