तुम्ही एंडपॉइंट ऑप्टिमाइझ केला आहे. तुमचा resend-email API अर्ध्या सेकंदाच्या आत प्रतिसाद देतो. तरीही वापरकर्ते 'लिंक कधीच आली नाही' असे सांगणारे सपोर्ट तिकीट काढतात. ते दोनदा क्लिक करतात. इनबॉक्स तपासण्यापूर्वीच ते प्रक्रिया सोडून देतात. तरीही काहीतरी बिघडल्यासारखे वाटते.
ही विसंगती बहुधा इन्फ्रास्ट्रक्चरमध्ये नसून इंटरफेसमध्ये असते. बॅकएंड ४०० मिलीसेकंदात 200 OK परत करू शकते, परंतु जर फ्रंटएंडने हलणारा लेआउट (jumping layout) आणि चमकणारा बॅनर दाखवला, तर वापरकर्त्याला तरीही अपयशी झाल्याचाच अनुभव येतो. जेव्हा एखादी व्यक्ती बटणावर क्लिक करते आणि त्यांच्या कर्सरखाली स्क्रीन हलते, तेव्हा ते फीडबॅक लूप किंवा नेटवर्क लॅटन्सीबद्दल विचार करत नाहीत. त्यांना वाटते की ॲपमध्ये काहीतरी बिघाड झाला आहे.
खरी समस्या क्वचितच वेगाची असते
React टीम्स अनेकदा ईमेल कन्फर्मेशनकडे एक साधी 'स्टेट मशीन' (state machine) म्हणून पाहतात: idle, loading, success, error. कंपोनंट एक mutation कार्यान्वित करतो, isLoading ला true सेट करतो आणि त्यानंतर promise रिझॉल्व्ह झाल्यावर संदेश बदलतो. नेमकी हीच जागा आहे जिथे नुकसान होते. ब्राउझर लेआउटची पुन्हा गणना करतो, प्रभावित भाग पुन्हा पेंट करतो आणि कधीकधी संपूर्ण कार्ड किंवा पेजचा रिफ्लो (reflow) करतो. वापरकर्त्याला जिथे स्थिरता अपेक्षित होती, तिथे त्यांना हालचाल दिसते. त्यांच्यासाठी, ॲपने कृतीची पुष्टी केली नाही, तर तो थरथरला (convulsed).
म्हणूनच वेगापेक्षा 'अनुभूती' (perception) अधिक महत्त्वाची ठरते. दोनशे मिलीसेकंद घेणारा अस्थिर इंटरफेस यापेक्षा पाचशे मिलीसेकंद घेणारा स्थिर इंटरफेस अधिक वेगवान आणि सुरक्षित वाटतो. वापरकर्ते लॅटन्सी मोजू शकत नाहीत, पण ते आत्मविश्वास मोजू शकतात. जेव्हा UI डगमगते, तेव्हा त्यांना वाटते की विनंती (request) देखील त्यासोबतच डगमगली आहे.
खराब फीडबॅकमुळे विश्वास कमी होण्याचे तीन मार्ग
खराब कन्फर्मेशन फीडबॅक सहसा तीन जाळ्यात अडकतो, जे एकदा तुम्हाला काय शोधायचे आहे हे समजले की ओळखणे सोपे जाते.
अंतर (Distance). वापरकर्त्याने फॉर्मच्या तळाशी क्लिक केले असताना, जर यश (success) संदेश फॉर्मच्या वरच्या बाजूला ग्लोबल बॅनरमध्ये दिसला, तर तो व्हिज्युअल प्रवाह तोडतो. डोळे फिरतात; हात थांबतो; मेंदूला वाटते की क्लिक चुकले आहे. फीडबॅक हा ज्या कृतीमुळे निर्माण झाला आहे, त्याच जवळ असावा.
गोंधळ (Noise). शून्यापासून पूर्ण आकारात वाढणारे स्पिनर्स, उड्या मारणारे चेकमार्क्स किंवा नियमित ईमेल पाठवल्याचा आनंद साजरा करण्यासाठी येणारे मॉडेल्स (modals) - हे सर्व असा लक्ष वेधून घेतात ज्याची गरज नसते. ते एका साध्या कन्फर्मेशनचे नाट्यमय सादरीकरणात रूपांतर करतात. वेस्टिब्युलर डिसऑर्डर (vestibular disorders) असलेल्या वापरकर्त्यांसाठी, जास्त हालचाल केवळ त्रासदायक नसते, तर ती शारीरिकदृष्ट्या अस्वस्थ करणारी असते.
लेआउट शिफ्ट (Layout shift). बटणाच्या खाली नवीन परिच्छेद टाकल्यामुळे पुढचे फॉर्म फील्ड खाली ढकलले जाते. फुटर हलते. स्क्रीनच्या खालच्या भागातील मजकूर आपली जागा बदलतो. यामुळे वापरण्यायोग्यता (usability) आणि सुलभता (accessibility) या दोन्ही गोष्टींवर परिणाम होतो. स्विच डिव्हाइस किंवा अचूक आय-ट्रॅकिंग वापरणारी व्यक्ती पुढच्या टार्गेटकडे सरकण्यास सुरुवात केली असेल, आणि ते अचानक हलले तर अडचण येते. जरी तुमचे बॅकएंड ४००ms मध्ये प्रतिसाद देत असले, तरी डगमगणाऱ्या UI मुळे ही प्रक्रिया संथ आणि असुरक्षित वाटते. तुमचे ॲप शांत आणि स्पष्ट संकेत देण्यास अपयशी ठरल्यामुळे वापरकर्ते स्वतःहून त्यांचा इनबॉक्स तपासू शकतात.
प्रक्रियेकडे 'वाचन क्रमा'च्या (Reading Sequence) दृष्टीने पहा
ईमेल कन्फर्मेशनकडे केवळ 'loading' आणि 'success' स्टेट्समधील बदल म्हणून पाहणे थांबवा. त्याकडे वापरकर्त्याने एका नजरेत समजून घेणारा 'वाचन क्रम' म्हणून पहा. स्वतःला चार विशिष्ट प्रश्न विचारा.
क्लिक केल्यावर लगेच व्यक्तीला काय दिसते? जर उत्तर 'काहीच नाही' असे असेल, किंवा बटण फक्त गोठले (freeze) असेल, तर तुम्ही त्यांना आधीच गमावले आहे. सिस्टिमने इनपुट स्वीकारले आहे हे सांगणारा एक त्वरित, स्थानिक बदल तिथे असणे आवश्यक आहे.
स्क्रीन रीडर काय घोषित करतो? एक सभ्य, अडथळा न आणणारे अपडेट वापरकर्त्याला कोणताही मोठा गोंधळ न करता त्यांच्या सध्याच्या कामात चालू ठेवण्यास मदत करते. ही घोषणा एखाद्या सायरनसारखी नसून 'फुटनोट'सारखी वाटली पाहिजे.
प्रतीक्षा करत असताना लेआउट किती हलतो? आदर्शपणे, शून्य. वेटिंग स्टेटने (waiting state) आधीच राखून ठेवलेली जागा व्यापली पाहिजे.
ईमेलला वेळ लागल्यास कोणता संकेत दृश्यमान राहतो? नेटवर्कमध्ये अडथळे येऊ शकतात. जर विनंती काही सेकंदांपेक्षा जास्त वेळ घेत असेल, तर काहीतरी प्रक्रिया सुरू आहे हे वापरकर्त्याला समजते का, की या शांततेमुळे ते अस्वस्थ होतात? एक सतत दिसणारा, शांत इंडिकेटर भीती किंवा गोंधळ टाळतो.
शांत कन्फर्मेशन फीडबॅकसाठी चार नियम
चार व्यावहारिक मर्यादांचे पालन करून तुम्ही बहुतेक कन्फर्मेशन फ्लो सुधारू शकता.
संदेश कृतीजवळ एका निश्चित भागात ठेवा. फीडबॅकची गरज पडण्यापूर्वीच त्यासाठी जागा राखून ठेवा. min-height असलेला कंटेनर किंवा मेसेज स्लॉटसाठी CSS ग्रिड रो (grid row) वापरा. जेव्हा मजकूर दिसतो, तेव्हा त्याने आजूबाजूचा मजकूर ढकलला जाऊ नये. कन्फर्मेशन तिथेच असावे जिथे वापरकर्त्याची मूळ कृती घडली आहे.
ॲक्सेसिबिलिटीसाठी (accessibility) role="status" सोबत aria-live="polite" वापरा. तुमच्या मार्कअपमध्ये पहिल्या रेंडरपासून अस्तित्वात असणारा एक 'live region' तयार करा. जेव्हा स्टेट (state) बदलते, तेव्हा React त्या रिजनमधील टेक्स्ट नोड अपडेट करते. स्क्रीन रीडर्स कीबोर्ड फोकस चोरल्याशिवाय किंवा वापरकर्त्याला व्यत्यय आणल्याशिवाय बदल जाहीर करतील. नियमित कन्फर्मेशनसाठी कधीही aria-live="assertive" वापरू नका. हे ओरडण्यासारखे आहे.
बटण अनमाउंट (unmount) करू नका. मेसेज दाखवण्यासाठी जेव्हा तुम्ही बटण DOM मधून काढून टाकता, तेव्हा तुम्ही कीबोर्ड वापरकर्त्यांची दिशाभूल करता. त्यांचा फोकस नाहीसा होतो. स्क्रीन रीडर्स अज्ञात 'ancestors' वर पोहोचतात. त्याऐवजी, बटण माउंटेड (mounted) ठेवा. ते aria-disabled ने डिसेबल करा, त्याचे लेबल "Sending..." किंवा "Sent" मध्ये बदला, किंवा त्याऐवजी काउंटडाउन टाइमर वापरा. एलिमेंट त्याच जागी राहते, फक्त त्याची स्टेट बदलते.
prefers-reduced-motion चा आदर करा. प्रत्येकाला 'सेलिब्रेशन' नको असते. कोणत्याही ट्रान्झिशन्सना (transitions) मीडिया क्वेरीमध्ये (media query) गुंडाळा. जर वापरकर्त्याने त्यांच्या ऑपरेटिंग सिस्टमला मोशन (motion) कमी करण्यास सांगितले असेल, तर त्यांना त्वरित टेक्स्ट बदल किंवा हलका 'opacity fade' द्या. कोणतेही बाऊन्स, स्पिन किंवा स्लाईड्स नकोत. 'Reduced motion' म्हणजे अर्थ कमी करणे नव्हे.
एक प्रभावी आणि स्थिर पॅटर्न (Stable Pattern)
सर्वोत्तम पॅटर्न हा कंटाळवाणा असतो आणि तोच मुख्य उद्देश आहे.
पहिल्या रेंडरपासूनच मेसेजसाठी जागा राखून ठेवा. बटणाच्या अगदी खाली एक लहान, दृश्य स्वरूपात रिकामे कंटेनर ठेवा. त्याला एक निश्चित किंवा किमान उंची द्या जेणेकरून येणारा मजकूर पुढील सेक्शन खाली ढकलणार नाही. ग्लोबल टोस्ट्स (global toasts) वापरण्याऐवजी फीडबॅक बटणाजवळच ठेवा. टोस्ट्स सिस्टिम-व्यापी त्रुटींसाठी उपयुक्त असतात, परंतु नियमित ईमेल कन्फर्मेशनसाठी ते लक्ष विचलित करतात आणि डोळ्यांना इकडे-तिकडे फिरावे लागते.
हालचाल किमान ठेवा. जर तुम्हाला ॲनिमेट करणे आवश्यक असेल, तर ट्रान्झिशन्स दोनशे मिलीसेकंदपेक्षा कमी ठेवा आणि ते केवळ 'opacity' किंवा हलक्या 'color shift' पर्यंत मर्यादित ठेवा. लेआउट रिकॅल्क्युलेशन (layout recalculation) करण्यास भाग पाडणारे ब्लॉक-लेव्हल एलिमेंट्स टाकणे किंवा काढून टाकणे टाळा. जर तुम्हाला बटणामध्येच लोडिंग स्टेट दाखवायची असेल, तर साधा टेक्स्ट स्वॅप किंवा स्टॅटिक आयकॉन वापरा. बटणाचे स्केल बदलू नका, ते हलवू नका आणि स्क्रीन फ्लॅश करू नका.
जेव्हा सक्सेस स्टेट (success state) येते, तेव्हा एक छोटा, कायमस्वरूपी संकेत (hint) दृश्यमान ठेवा. "Check your inbox" पुरेसे आहे. ते तीन सेकंदांनंतर आपोआप काढून (auto-dismiss) टाकू नका. चुकीच्या वेळी नजर हटवणाऱ्या वापरकर्त्याला काय झाले असावे, असा विचार करावा लागू नये.
यामुळे खरोखर वेळ कसा वाचतो
जेव्हा तुम्ही या छोट्या तपशीलांवर काम करता, तेव्हा तुम्हाला असे वास्तविक परिणाम दिसतात ज्याचा तुमच्या इन्फ्रास्ट्रक्चर बजेटशी काहीही संबंध नसतो.
एकाच बटणावर कमी डबल क्लिक्स होतील. डिसेबल स्टेट आणि स्थानिक फीडबॅकमुळे पहिला क्लिक नोंदवला गेला आहे हे स्पष्ट होते.
'Send' वर क्लिक केल्यानंतर कमी वापरकर्ते प्रक्रिया सोडून जातील. शांत संकेत मेंदूला सांगतात की सिस्टिम काम करत आहे, त्यामुळे वापरकर्ते थांबून राहतात.
ईमेल प्रत्यक्षात आल्यावरही तो मिळालेला नाही, असे सांगणारे सपोर्ट तिकीट कमी होतील. त्यातील बहुतेक तिकीट इंटरफेसमुळे निर्माण झालेल्या गोंधळामुळे (panic) असतात, ईमेल हरवल्यामुळे नाही.
वेगवान जाणवणारी कामगिरी (perceived performance). एक स्थिर UI नेहमीच गोंधळलेल्या UI पेक्षा वेगवान वाटते, जरी दोन्हीची लॅटन्सी (latency) सारखीच असली तरीही.
हे ट्रॅक करण्यासाठी तुम्हाला जटिल साधनांची गरज नाही. डुप्लिकेट विनंत्यांसाठी तुमचे एरर लॉग्स (error logs) तपासा. तुमच्या सपोर्ट क्यू (support queue) कडे लक्ष द्या. कन्फर्मेशन स्क्रीनवरील साध्या रिटेंशनद्वारे (retention) वापरकर्त्याची स्थिरता मोजा. एक शांत, अंदाज लावण्यायोग्य इंटरफेस हे दर्शवतो की सिस्टिमला काय करायचे आहे हे माहित आहे. हीच 'predictability' विश्वास निर्माण करते.