एनिमेशन की अवधि और लोडिंग UX गाइडलाइन

UI एनिमेशन कितने लंबे होने चाहिए?

छोटे। Material Design की मूल motion गाइडेंस के अनुसार मोबाइल पर ट्रांज़िशन आमतौर पर लगभग 300 ms लेते हैं, और यह ज़्यादा सटीक वैल्यू भी देती है:

यही गाइडेंस बताती है कि 400 ms से ज़्यादा के ट्रांज़िशन बहुत धीमे लग सकते हैं। जाने वाले ट्रांज़िशन आने वालों से तेज़ होते हैं, क्योंकि यूज़र आगे बढ़ने का फ़ैसला पहले ही कर चुका होता है।

Material 3 इसे duration tokens के रूप में दिखाता है, short1 पर 50 ms से लेकर extraLong4 पर 1,000 ms तक, 600 ms तक 50 ms के स्टेप में और फिर 700-1,000 ms। इनके साथ जुड़ा नियम: "एनिमेशन का क्षेत्र/दूरी जितनी बढ़े, duration उतना बढ़ना चाहिए।" checkbox का टिक छोटे सिरे पर आता है। फ़ुल-स्क्रीन container transform लंबे सिरे के पास आता है।

ये नंबर उन इंटरफ़ेस ट्रांज़िशन के लिए हैं जो यूज़र के अगले कदम को रोकते हैं। बैकग्राउंड में चलने वाले कैरेक्टर लूप अलग हैं, और उनकी बात नीचे की गई है।

0.1 s, 1 s और 10 s की सीमाओं का क्या मतलब है?

Nielsen Norman Group द्वारा प्रकाशित Jakob Nielsen की तीन response-time सीमाएँ, इंतज़ार कैसा महसूस होता है, इसका मानक संदर्भ हैं:

• 0.1 सेकंड: लगभग वह सीमा जिसमें यूज़र को लगता है कि सिस्टम तुरंत प्रतिक्रिया दे रहा है। नतीजा दिखाने के अलावा किसी फ़ीडबैक की ज़रूरत नहीं।
• 1 सेकंड: लगभग वह सीमा जिसमें यूज़र के विचारों का flow बिना रुकावट बना रहता है। उन्हें देरी महसूस होती है, लेकिन ध्यान बना रहता है।
• 10 सेकंड: लगभग वह सीमा जिसमें ध्यान काम पर टिका रहता है। इसके बाद लोग इंतज़ार करते हुए दूसरे काम करने लगते हैं।

इन्हें डिज़ाइन की सीमाओं की तरह इस्तेमाल करें। 0.1 s से कम में press स्टेट काफ़ी है। लगभग 1 से 10 सेकंड के बीच दिखाएँ कि कुछ हो रहा है। 10 सेकंड से ज़्यादा पर दिखाएँ कि कितना बाकी है, और बेहतर हो कि यूज़र जाकर वापस आ सके।

इन सीमाओं से यह भी समझ आता है कि लंबे UI ट्रांज़िशन नुकसान क्यों करते हैं। अगर हर टैप पर 600 ms का स्क्रीन ट्रांज़िशन चलता है, तो कोई भी कंटेंट दिखने से पहले ही 1 सेकंड के बजट का आधे से ज़्यादा हिस्सा सजावट में चला जाता है।

स्पिनर, प्रोग्रेस बार या लोडिंग एनिमेशन कब दिखाना चाहिए?

Nielsen Norman Group की progress indicator गाइडेंस इंतज़ार की अवधि के हिसाब से साफ़-साफ़ लागू होती है:

लोडिंग मैस्कॉट एक लूपिंग इंडिकेटर ही है, बस ज़्यादा व्यक्तित्व के साथ। यह 2-10 सेकंड वाले इंतज़ार के लिए सही है, जैसे अपलोड, सर्च या AI का जवाब। लंबे कामों में यह प्रोग्रेस बार की जगह नहीं ले सकता, क्योंकि लूप यूज़र को यह नहीं बता सकता कि काम कितना आगे बढ़ा है। लंबे इंतज़ार के लिए कैरेक्टर के साथ असली प्रतिशत वाला प्रोग्रेस बार दिखाएँ।

स्केलेटन स्क्रीन तीसरा विकल्प है, उस कंटेंट के लिए जो पहले से तय layout में लोड होता है। ये आने वाले कंटेंट के आकार के ग्रे placeholder ब्लॉक दिखाती हैं, जिससे यूज़र को पता चलता है कि क्या आने वाला है, न कि कितना समय लगेगा। इन्हें फ़ीड और लिस्ट के लिए इस्तेमाल करें, और यूज़र द्वारा शुरू किए गए एक्शन के लिए कैरेक्टर लूप रखें।

लूप और वन-शॉट रिएक्शन की टाइमिंग कैसी होनी चाहिए?

कैरेक्टर एनिमेशन दो तरह के होते हैं, और दोनों की टाइमिंग अलग होनी चाहिए।

लूप (idle, loading, listening, talking) तब तक दोहराए जाते हैं जब तक कोई स्टेट ऐक्टिव रहती है। इनमें साइकिल की लंबाई से ज़्यादा स्मूदनेस मायने रखती है। कुछ सेकंड का लूप, जिसका जोड़ दिखाई न दे और मूवमेंट हल्की हो, शांत लगता है। छोटे और तेज़ लूप बेचैन लगते हैं। लूप का काम बस इतना कहना है कि "अभी भी यहीं हूँ" या "अभी भी काम चल रहा है", बिना कंटेंट से ध्यान हटाए।

वन-शॉट (success, error, yes, no, enter, exit) एक बार चलते हैं और फिर मौजूदा लूप पर लौट आते हैं। ये कोई नतीजा बताते हैं, इसलिए इन्हें जल्दी अपनी बात कहनी चाहिए। success एनिमेशन की कोई आधिकारिक मानक लंबाई नहीं है। उसके समझ में आने वाले हिस्से को एक सेकंड से काफ़ी कम रखने पर वह Nielsen की 1 सेकंड वाली flow सीमा के अंदर रहता है, और Material 3 का सबसे लंबा duration token 1,000 ms है।

Rive स्टेट मशीन इस बँटवारे को अच्छी तरह संभालती है। Charmotion सेट में mood नाम का नंबर इनपुट (0-9) ऐक्टिव लूप चुनता है, और ट्रिगर वन-शॉट फ़ायर करते हैं जो खत्म होने पर मौजूदा मूड पर लौट आते हैं। आपका कोड बस यह बताता है कि क्या हुआ, टाइमिंग फ़ाइल खुद संभालती है। पूरी लिस्ट के लिए मैस्कॉट एनिमेशन स्टेट देखें।

attention एनिमेशन कितनी देर चलना चाहिए?

हमेशा नहीं। attention लूप, जैसे किसी नए notification के पास हाथ हिलाता मैस्कॉट, इसलिए काम करता है क्योंकि बाकी सब रुका होता है और सिर्फ़ वही हिलता है। अगर यह कभी न रुके, तो लोग इसे नज़रअंदाज़ करना सीख जाते हैं, और यह उस चीज़ से होड़ करने लगता है जिसे वे पढ़ने की कोशिश कर रहे हैं।

इसमें compliance का पहलू भी है। WCAG 2.2 SC 2.2.2 Pause, Stop, Hide (Level A) उस मूविंग कंटेंट पर लागू होता है जो अपने आप शुरू होता है, पाँच सेकंड से ज़्यादा चलता है और दूसरे कंटेंट के साथ दिखता है। एक व्यावहारिक तरीका यह है कि attention लूप को कुछ सेकंड चलाएँ, कुल समय पाँच सेकंड से कम रखें, फिर कुछ नया होने तक idle या स्थिर पोज़ पर लौट आएँ।

यही सोच लोडिंग पर भी लागू होती है। काम खत्म होते ही लूप रोक दें, और एक वन-शॉट नतीजे के साथ खत्म करें, ताकि यूज़र को अचानक कट की जगह परिणाम दिखे। अगर इंतज़ार 10 सेकंड से ज़्यादा हो जाए, तो लूप से प्रोग्रेस इंडिकेटर पर स्विच करें।

आखिर में, prefers-reduced-motion का सम्मान करें। जो यूज़र कम मोशन चाहते हैं, उनके लिए attention एक रंग बदलाव, बैज या स्थिर पोज़ हो सकता है। इसे लागू करने का तरीका reduced-motion गाइड में है।

लोडिंग एनिमेशन को धीमा महसूस होने से कैसे बचाएँ?

• 0.1 s से कम में प्रतिक्रिया दें। तुरंत press स्टेट दिखाएँ या लोडिंग एनिमेशन शुरू करें, ताकि लगे कि टैप दर्ज हो गया है।
• बहुत छोटे इंतज़ार में इंडिकेटर देर से दिखाएँ। अगर कोई request आमतौर पर एक सेकंड से कम में पूरी हो जाती है, तो स्पिनर दिखाने से पहले थोड़ा रुकें, ताकि वह झपककर गायब न हो।
• एनिमेशन के लिए नतीजे न रोकें। डेटा आते ही लूप खत्म करें। यूज़र को कभी किसी साइकिल के पूरा होने का इंतज़ार न कराएँ।
• आउट्रो छोटा रखें। success या error रिएक्शन जल्दी अपनी बात कहे, ऊपर बताई गई एक सेकंड से कम वाली गाइडेंस का पालन करें।
• लंबे कामों में प्रोग्रेस दिखाएँ। लगभग 10 सेकंड के बाद, प्रतिशत वाला प्रोग्रेस बार यूज़र को बताता है कि कितना समय बाकी है, सिर्फ़ लूप यह नहीं बता सकता।
• ट्रांज़िशन बजट के अंदर रखें। स्क्रीन बदलने के लिए लगभग 200-300 ms रखें, ताकि एनिमेशन 1 सेकंड की flow विंडो न खा जाए।

मोशन से इंतज़ार समझ में आना चाहिए, लंबा नहीं होना चाहिए। अगर किसी एनिमेशन को हटाने से प्रोडक्ट तेज़ लगे, तो वह शायद ज़रूरत से ज़्यादा लंबा है।

अक्सर पूछे जाने वाले सवाल

बटन या micro-interaction के लिए सबसे अच्छी अवधि क्या है?

लगभग 50-200 ms। Material 3 के सबसे छोटे duration token 50 ms से शुरू होते हैं, और छोटे एलिमेंट छोटी अवधि वाले हिस्से में आते हैं, क्योंकि अवधि उस एरिया के साथ बढ़नी चाहिए जिसे एनिमेशन कवर करता है। ज़्यादातर टैप पर 0.1 s के अंदर फ़ीडबैक दिखना चाहिए, यही वह सीमा है जिसे Nielsen तुरंत महसूस होने के लिए बताते हैं।

क्या 1 सेकंड के इंतज़ार के लिए स्पिनर इस्तेमाल करना चाहिए?

आमतौर पर नहीं। Nielsen Norman Group लगभग एक सेकंड से छोटे एक्शन के लिए कोई इंडिकेटर न दिखाने की सलाह देता है, क्योंकि स्पिनर बस एक पल के लिए झलकेगा और शोर बढ़ाएगा। लूपिंग इंडिकेटर लगभग 2-10 सेकंड के इंतज़ार के लिए रखें और प्रतिशत वाले प्रोग्रेस बार 10 सेकंड या उससे ज़्यादा के लिए।

क्या एनिमेटेड मैस्कॉट प्रोग्रेस बार की जगह ले सकता है?

सिर्फ़ लगभग 2-10 सेकंड के छोटे, अनिश्चित इंतज़ार के लिए। लूपिंग एनिमेशन यह नहीं दिखा सकता कि कितना काम बाकी है, इसलिए 10 सेकंड या उससे ज़्यादा के इंतज़ार के लिए NN/g प्रतिशत वाले इंडिकेटर की सलाह देता है। आप कैरेक्टर को प्रोग्रेस बार के साथ जोड़ सकते हैं।

exit एनिमेशन entrance से तेज़ क्यों चलते हैं?

Material Design स्क्रीन से बाहर जाने वाले एलिमेंट के लिए लगभग 195 ms और अंदर आने वाले के लिए 225 ms सुझाता है। यूज़र आगे बढ़ने का फ़ैसला कर चुका होता है, इसलिए तेज़ exit रास्ते से हट जाता है, जबकि entrance को नज़र में आने और समझे जाने के लिए थोड़ा ज़्यादा समय चाहिए।

इस गाइड से झटपट जवाब

• UI एनिमेशन कितने लंबे होने चाहिए?
• स्पिनर और प्रोग्रेस बार में से कब कौन-सा इस्तेमाल करें?
• 0.1, 1 और 10 सेकंड की response time सीमाएँ क्या हैं?

स्रोत

• Response Times: The 3 Important Limits, Nielsen Norman Group
• Progress Indicators Make a Slow System Less Insufferable, Nielsen Norman Group
• Duration & easing, Material Design (M1)
• Motion theming (duration tokens), Material Components for Android
• Understanding SC 2.2.2: Pause, Stop, Hide, W3C WAI
• Inputs (web runtime, legacy), Rive