हर फ्रेम को परफेक्ट बनाना

• UI लगभग एकमात्र सतह है जिससे उपयोगकर्ता ऐप की गुणवत्ता को परखते हैं, और किसी भी क्षण स्क्रीनशॉट लेने पर स्क्रीन की स्थिति समझ में आने वाली होनी चाहिए, तभी भरोसा बनता है
• उच्च-गुणवत्ता वाला UI इस बात का संकेत है कि डेवलपर ने उसे निखारने में समय लगाया है, और यह भी एक तार्किक heuristic बनता है कि कोड क्वालिटी को भी उसी तरह निखारा गया होगा
• वास्तविक मानक यह है कि स्क्रीन ट्रांज़िशन के बीच सफेद फ्लैश, partial loading, loading के दौरान relayout, state messages में असंगति, और गलत animation न हों
• शुरुआत और अंत की स्थिति अच्छी होने पर भी अगर बीच के फ्रेम बिगड़े हों, तो यह components के unsynced होने का एहसास देता है, और Photos के उदाहरण की तरह ऐसे ट्रांज़िशन में भी झूठा अहसास पैदा कर सकता है जहाँ वास्तव में कोई बदलाव नहीं हुआ हो
• animation को ट्रांज़िशन समझने में मदद करनी चाहिए, और सिर्फ शुरुआत व अंत नहीं बल्कि बीच के हर फ्रेम को नियंत्रित करने पर ही UI एक precision tool जैसा बनता है

---

मुख्य सिद्धांत

• Wayland का स्पष्ट लक्ष्य “every frame is perfect” आधुनिक GPU stack की जटिलता के बीच नियंत्रण वापस पाने का एक तकनीकी लक्ष्य है
• यही सिद्धांत UI पर भी लागू होता है, और ऐप के किसी भी क्षण का स्क्रीनशॉट लेने पर स्क्रीन स्वाभाविक और सुसंगत दिखनी चाहिए
• उपयोगकर्ता कोड नहीं देख सकते, इसलिए UI ही ऐप की गुणवत्ता को परखने की एकमात्र सतह बन जाता है
• अगर UI अच्छी तरह polished है, तो यह संकेत देता है कि डेवलपर ने polishing में समय लगाया है, और इससे यह धारणा बनती है कि कोड भी लगभग उसी स्तर तक निखारा गया होगा

वास्तविक मानक और उदाहरण

• परफेक्ट फ्रेम के लिए स्क्रीन के बीच सफेद फ्लैश नहीं होना चाहिए, और न ही content का partial loading state या loading के दौरान layout reshuffling होना चाहिए
• UI के अंदरूनी states सुसंगत होने चाहिए; ऐसा नहीं होना चाहिए कि एक हिस्सा “1 update available” कहे और दूसरा हिस्सा “Checking for updates...”
• animation को अक्सर भुला दिया जाता है; शुरुआत और अंत की स्थिति अच्छी होने पर भी अगर बीच का हिस्सा अटपटा हो, तो बीच का स्क्रीनशॉट ऐसा फ्रेम बन जाता है जो समझ में नहीं आता
• Safari के उदाहरण में placeholder text बीच से चलता है, लेकिन cursor बाईं ओर की स्थिति से animate होता है, जिससे दोनों components के बीच sync न होने का एहसास पैदा होता है
• Photos के उदाहरण में Crop और Adjust modes के बीच स्विच करते समय फोटो तुरंत अपनी जगह पर चली जाती है, लेकिन crop border animate होता रहता है, जिससे mode switch के दौरान कुछ सूक्ष्म रूप से बदलने का झूठा एहसास बनता है
• search UI के उदाहरण में ट्रांज़िशन को समझाने में मदद करने वाला animation उल्टा magnifying glass की movement को ट्रैक करना मुश्किल बना देता है
• Youtube के उदाहरण में एक rectangle को एक जगह से दूसरी जगह ले जाने जैसे सरल काम में भी अजीब movement दिखती है, और वजह चाहे जो हो, नतीजा परफेक्ट न होने वाला फ्रेम ही होता है
• Preview ऐप की zoom animation सहित, मुख्य बात यह है that केवल शुरुआत और अंत की स्थिति ही नहीं, बल्कि उनके बीच के हर क्षण पर भी ध्यान देना चाहिए

[GN⁺]

Hacker News की राय

• लेखक ने जो कुछ उदाहरण दिए हैं, उनमें से कुछ वाकई खराब animation हैं, लेकिन लेख की बुनियादी धारणा से सहमत होना मुश्किल है
  computer graphics ऐसा क्षेत्र है जो मानव visual system की विशेषताओं का उपयोग करता है, और गतिशील चीज़ें व स्थिर चीज़ें अलग तरह से perceive होती हैं। अलग करके देखने पर जो frame “गलत” लगे, वही असली समय-प्रवाह में सबसे अच्छा दिख सकता है
  फ़िल्म के उदाहरण से कहें तो तेज़ tracking shot में motion blur की वजह से अलग-अलग frame खराब दिख सकते हैं, और wide-angle shot में distortion की वजह से वस्तुएँ “गलत” लग सकती हैं, लेकिन अगर थिएटर में वे इच्छित कलात्मक प्रभाव पैदा करें तो वही सही चुनाव है

  • शुरुआत में मुझे लगा “Every Frame Perfect” का मतलब है motion में stutter या jerk को सख़्ती से टालना, और उस बात से मैं पूरी तरह सहमत हूँ। लेकिन फ़िल्म, video और 3D तकनीक के नज़रिए से देखें तो motion blur जैसे temporal artifact मानव visual system को सबसे “सही” लगते हैं और समझने में भी सबसे आसान रूप होते हैं
    सही blur को motion में जोड़ने पर चीज़ ज़्यादा sharp महसूस हो सकती है, लेकिन स्थिर image में देखने पर वह स्वाभाविक रूप से ज़्यादा sharp नहीं लगेगी। मुख्य बात यह है कि सही motion blur यह सुनिश्चित करता है कि उस गति पर इंसान जितना moving detail perceive कर सकता है, image उतनी ही sharp दिखे। इसलिए स्थिर motion-blur frame को sharpness या interpretability के आधार पर आँकना ग़लत है
    लेख का बाकी हिस्सा implementation detail पर केंद्रित है, लेकिन शुरू में ही यह पूछने का मौका चूक जाता है कि ऐसी animation में से कुछ का होना ज़रूरी भी है या नहीं। motion सीमित रूप में इस्तेमाल हो तो अच्छा affordance बन सकता है, लेकिन अब इसका अति-उपयोग user की नज़र और cognitive load पर भी अतिक्रमण करने लगा है। designer और PM इसे “परिष्कृत modern UX” की निशानी समझते हैं, लेकिन कई बार यह अच्छे design की जगह अच्छे design की नकल करने वाली चलताऊ सजावट बनकर रह गया है
  • अगर यह लेख अच्छे use case भी साथ में दिखाता, तो इसकी दलील और मज़बूत होती। फिर भी मैं इस बात से सहमत हूँ कि हर frame से ज़्यादा transition का समग्र एहसास अहम है
    दिखाए गए कुछ animation निश्चित रूप से बेहतर किए जा सकते हैं। ऐसे छोटे-छोटे आनंद को आगे बढ़ाने में AI काफ़ी उपयोगी लगती है, क्योंकि पहले इसकी priority कम होने से इस पर समय लगाना मुश्किल था
  • यह analogy थोड़ा ज़्यादा खिंची हुई लगती है। फ़िल्म के उलट UI वास्तविकता को record नहीं करता; स्क्रीन का हर pixel हमारी तय की हुई स्थिति का नतीजा है, इसलिए इससे ज़्यादा क़रीबी तुलना cartoon से है। cartoon के in-between pose अपूर्ण frame नहीं होते, बल्कि बहुत सोच-समझकर बनाए गए पूर्ण frame होते हैं
    animation के बीच का frame थोड़ा “अजीब” दिखे लेकिन तर्कसंगत रूप से सही हो, यह अलग बात है; और intermediate state वास्तव में बेमानी हो और बस इस बात की परवाह न की गई हो कि animation के दौरान क्या हो रहा है, यह अलग बात है। दूसरे मामले में तो animation हटा देना या उसे और सरल बना देना ही बेहतर है
  • आख़िरी Preview app zoom animation इसका उल्टा उदाहरण भी दिखाती है। लेखक जैसा चाहता है, वैसे सभी frame अलग-अलग देखने पर परिपूर्ण हैं, लेकिन समस्या motion में देखने पर सामने आती है
  • animation को frame-दर-frame खोलकर देखने पर वह हमेशा consistent होना चाहिए, यह विचार मुझे बहुत ठोस नहीं लगता। user वास्तव में उसे इस तरह नहीं देखते
    UI की finish को software quality का proxy metric मानने वाला लेख का नज़रिया अच्छा है, और खराब animation की ओर इशारा भी सही है। बस frame-by-frame consistency, animation की “अच्छाई” मापने का सबसे अच्छा पैमाना नहीं है

• कुछ devices पर अभी भी Sonoma है, और बस यही लगता है कि चीज़ें लगातार regress कर रही हैं
  save dialog थोड़ा हिलता है, लेकिन उदाहरण जितना उलझाऊ नहीं है। Notes के button panels के बीच पूरी तरह smooth चलते हैं। Safari bar को बार-बार focus और unfocus करने पर कभी-कभी animation टूटती है, लेकिन cursor का timing text के साथ बिल्कुल सटीक रहता है और text के बाएँ खिसकना खत्म होने के बाद ही fade-in होता है। Preview bug भी हाल की समस्या लगती है, और reproduce नहीं हो रही
  https://streamable.com/kx7op6
  Apple, Sony, IBM जैसी कंपनियाँ जब बहुत छोटे detail पर ध्यान देती थीं, वह दौर याद आता है। खासकर Apple ने iPhone से आज की अपनी हैसियत पाई, लेकिन उस समय Windows Mobile या Symbian PDA की तुलना में उसने कोई असाधारण feature नहीं दिया था; बल्कि feature के लिहाज़ से कुछ मामलों में पीछे भी था। फिर भी वह ऐसा all-touch device था जिसे कुछ मिनट इस्तेमाल करके दीवार पर फेंकने का मन नहीं करता था। आज की ऐसी animation ठीक वही Windows Mobile और Symbian वाली भावना वापस ले आती हैं
  याद है Steve को OS X animation कितनी पसंद थीं। वह मंच पर कई बार उन्हें दोबारा, slow motion में चलाता था। आज की चीज़ें तो ऐसी लगती हैं कि iPhone 4 antenna वाले व्यक्ति को जो हश्र मिला, वैसा ही इन्हें बनाने वालों के साथ भी हो तो अजीब नहीं लगेगा

  • छोटी video में animation सचमुच ज़्यादा व्यवस्थित और कम अव्यवस्थित लग रही है। हो सकता है Apple ने Sonoma में AppKit इस्तेमाल किया हो और अब SwiftUI पर आ गया हो

• ऐसा लगता है कि ऐसे UI जिनमें ये अपूर्ण frame न हों, वे बेहतर महसूस होंगे, लेकिन अब कोई इन clips को ठीक करके यह दिखाए कि वे वास्तव में कैसे दिखेंगे
  साथ ही यह भी सवाल है कि हर चीज़ में motion की ज़रूरत ही क्यों है। मेरी समझ से motion तब इस्तेमाल होनी चाहिए जब UI में हल्का बदलाव उस जगह से अलग क्षेत्र में हो जहाँ user ने action शुरू किया था, जैसे toast
  यहाँ दिखाए गए कई transition अनावश्यक लगते हैं, और तुरंत बदलाव के साथ immediate reflow भी काफ़ी अच्छा महसूस हो सकता है

  • Safari search box का “अपूर्ण frame” व्यावहारिक रूप से ठीक है, और उसे screenshot में बेहतर दिखाने वाला तरीका उल्टा बुरा हो सकता है
    cursor बाएँ इसलिए दिखता है क्योंकि user वास्तव में वहीं से typing शुरू करता है। UI को जानने वाला व्यक्ति शायद वहीं देखेगा। cursor को पहले स्क्रीन के बीच में दिखाकर फिर खिसकाना अनावश्यक और ध्यान भटकाने वाला होगा
    placeholder text का बाएँ सरकना कम अनुभवी user का ध्यान खींचने के लिए है
  • slot machine में हमेशा कुछ-न-कुछ चलना चाहिए, और ज़रूरत से ज़्यादा dynamic Apple animation भी वही काम करती है। सामान्य UI animation उन आम users की मदद करती है जिन्हें स्क्रीन का अचानक बदल जाना कठिन लगता है, और यह frame rate को smooth दिखाने या API call / backend processing delay छिपाने में भी मदद करती है
  • अगर आप अच्छे UI वाला game खेलें, तो देखेंगे कि animation हर जगह इस्तेमाल होती है। instant transition सिर्फ़ सिद्धांत में अच्छी लगती है
  • हर चीज़ में motion की ज़रूरत नहीं होती। ज़्यादातर में नहीं होती। इस तरह का फ़ालतू काम कुछ लोगों के लिए नौकरी बनाता है, और कुछ लोगों को यह शेख़ी बघारने का बहाना देता है कि $BRAND की design language विकल्पों से श्रेष्ठ है
    ज़्यादातर उदाहरण animation के बिना शायद बेहतर लगेंगे। button दबाया है तो नतीजा दिखा दीजिए। नाच-गाना करवाकर नहीं, बस सीधे दिखाइए
  • transition के बाद दिशा-बोध वापस पाने में motion अहम होती है
    motion न हो तो कई बार हर refresh पर दिमाग़ को पूरे page को फिर से scan करना पड़ता है

• मुझे लगता है कि इस लेख का तर्क कमज़ोर तरीके से रखा गया है। न कोई बेहतर विकल्प दिया गया है, न यह सच में समझाया गया है कि बताई गई चीज़ें users के लिए क्यों नकारात्मक हैं। वे नकारात्मक हो सकती हैं, लेकिन यह कुछ वैसा ही लगता है जैसे media के smear frame या transition point दिखाकर उनकी खोखली आलोचना करना।
  “हर frame का समझ में आना चाहिए” वाला मानदंड भी संभालना मुश्किल है। मुझे यह असंभव लगता है, और मैं पूछना चाहूँगा कि window resize करते समय भी हर frame को पूरी तरह सही कैसे रखा जाएगा।
  ऐसा भी लगता है कि लेखक खुद अपने बताए मानदंड पर चलने की बजाय defect वाले frames की ओर इशारा करना आसान समझते हैं। ब्लॉग के header link पर क्लिक करें तो click खत्म होने के बाद animation चलती है। उनके अपने UI project में भी ऐसी जगहें हैं जहाँ text और object container के भीतर नहीं रहते। अगर आप कहते हैं कि ऐसे principles का पालन होना चाहिए, तो आपको खुद भी इसे दिखा पाना चाहिए।
  अगर लेख बेहतर लिखा गया होता, तो वह इस पर ध्यान देता कि बताई गई चीज़ें end user के लिए क्यों खराब हैं और उनके बजाय क्या किया जाना चाहिए। अच्छी आलोचना में सिर्फ “क्या” नहीं, बल्कि क्यों और कैसे भी होना चाहिए।

  • उलटे, यह आलोचना ही यहाँ सबसे ज़्यादा खोखली लगती है।
    लेख समाधान नहीं, बल्कि ideas पेश कर रहा है। इसे न देख पाना और फिर कई strawman arguments खड़े करके आलोचना करना गलत है।
    इससे भी ज़्यादा महत्वपूर्ण बात यह है कि लेख निर्णायक लहजे में लिखा ही नहीं गया था। “I think”, “Next thought:”, “Probably”, “So yeah.” जैसी सावधानी भरी भाषा इस्तेमाल की गई थी। यह एक व्यक्ति द्वारा अपने विचार साझा करना है, और यह काफ़ी परिपक्व विचार है—इतना कि कई समझदार लोग इसी दिशा में सोचने लगें।
    सिर्फ इसलिए कि लेखक ने समाधान नहीं दिया, इसका मतलब यह नहीं कि उन्हें देना ही चाहिए था। ऐसा मानदंड अजीब और अनुचित है।
    लेखक की site पर हमला करना भी अच्छा नहीं लगता। taste का अंतर अच्छी तरह जाना-पहचाना है, और conceptual contribution को practical skill से आगे होने के कारण सज़ा देना काफ़ी असहज करने वाला है।
    बेहतर आलोचना होती तो इस community की भावना के अनुरूप ज़्यादा उदार होती।

• मैंने कुछ प्रतिक्रियाएँ देखीं जिनमें कहा गया कि लेखक को समाधान के उदाहरण भी शामिल करने चाहिए थे। उन्होंने हाल ही में इस लेख से बहुत मिलता-जुलता एक लेख लिखा था, जिसमें यहाँ की तरह animation की समस्याओं को विस्तार से बताया गया था और यह भी समझाया गया था कि उन्होंने उन्हें कैसे सुधारा।
  अगर दिलचस्पी हो, तो यहाँ देख सकते हैं: https://www.thisischris.dev/projects/project-6/

  • Android के mobile Chrome में animation शायद काम नहीं कर रही है।

• बाद में मिलने वाले perfect frame से बेहतर अभी का imperfect frame है। हर UI में latency सर्वोच्च प्राथमिकता होनी चाहिए। अगर latency काफ़ी कम हो, तो चीज़ अपने शरीर के हिस्से जैसी लगने लगती है और cognitive load कम होता है। animation यहाँ खास तौर पर बुरी है, क्योंकि वह सैकड़ों milliseconds की देरी जोड़ देती है।

  • मुझे लगता है यह गलत द्वंद्व है। लेखक ने जो उदाहरण दिए हैं, वे सही ढंग से implement किए जाएँ तो बिल्कुल भी धीमे नहीं होंगे।
  • हो सकता है आपने शीर्षक देखकर सोचा हो कि यह Wayland के बारे में है, और वह सोचना सही भी होता। लेकिन यह Wayland के बारे में नहीं है।

• अच्छा होता अगर नकारात्मक उदाहरणों के साथ सकारात्मक उदाहरण भी होते। अभी जो निष्कर्ष निकलता है, वह बस इतना है कि animation से बचना चाहिए, जबकि शायद लेखक का असली मतलब यह नहीं है।

  • “animation से बचना चाहिए” वाला निष्कर्ष सबसे खराब सीख नहीं है। आम तौर पर animation for animation’s sake से बचना चाहिए। उदाहरण के लिए, सोचिए कि phone keyboard पर हर अक्षर टाइप करते समय वह उड़कर text input box में चला जाए।

• अच्छी animation का हर frame में perfect दिखना ज़रूरी नहीं; अक्सर वह चलते समय थोड़ी visual trickery का सहारा लेती है। cartoon के smear frame की तरह—रोककर देखें तो अजीब लगता है, लेकिन पूरी animation के भीतर वही movement को visually believable बनाता है।

  • smear frame इस तरह की animation में आम तौर पर इस्तेमाल होने वाली तकनीक नहीं है। यह लगभग पूरी तरह frame-by-frame animation के लिए खास है, और इस लेख में smear frame है ही नहीं।
  • फ़र्क यह है कि blur frame पूरे effect के लिए जानबूझकर इस्तेमाल किया जाता है। यहाँ की animations ज़्यादा तराशे न गए app को उजागर करने वाली accidental jank के क़रीब हैं।
  • मुझे यह उपमा सही नहीं लगती। blur frame चलते समय अच्छा दिखता है, लेकिन ब्लॉग पोस्ट के frames चलते समय भी भयानक लगते हैं। पहला उदाहरण इतना खराब था कि जब मैंने पहली बार देखा तो लगा ऊपर तीन button बचेंगे, और जब समझ आया कि आख़िर में सिर्फ दो ही हैं, तो वह अजीब और दिशाभ्रम पैदा करने वाला लगा।
  • macOS में, जब Apple ने OS और apps में SwiftUI का इस्तेमाल शुरू किया, तब visual quality और animation quality में बड़ा बदलाव महसूस हुआ।
    मैं developer नहीं हूँ, लेकिन मुझे ऐसे हिस्से महसूस हुए जहाँ icons या windows पहले की तरह—या जिस तरह स्वाभाविक रूप से होना चाहिए—उस तरह placed या moved नहीं लगते थे।
    यह patchwork जैसा एहसास समय के साथ भी नहीं बदला। पूरे OS और apps में इतने उदाहरण हैं कि मन करता है कह दूँ “हमेशा से ऐसा ही था”, लेकिन असल में ऐसा नहीं था। Apple ने एक मानक बनाया था, वह मानक ऊँचा था, और quality शानदार थी।
    ऐसा लगता है कि SwiftUI में वही UI layout या animation हासिल करने के लिए बहुत सारे hacks लगाने पड़ते हैं।
    और आख़िर में, एक बात जो मैं अक्सर सोचता हूँ, वह यह है कि analog सृजन पहले भी बहुत कठिन था और आज भी है। digital में हम अक्सर सोचते रहे कि बाद में लौटकर इसे सुधार लेंगे, लेकिन व्यवहार में हम ऐसा नहीं करते, और अफ़सोस की बात है कि कई बार बुरी चीज़ के ऊपर उससे भी बुरी चीज़ चढ़ाते जाते हैं।
  • Overwatch एक काफ़ी शानदार आधुनिक उदाहरण है [1]। उसमें बहुत ही smooth animations हैं, लेकिन अगर आप frame रोककर देखें, तो वे सचमुच बहुत अजीब दिखती हैं।
    [1]: https://youtu.be/vIdeGmN__Pw?t=550

• बिना किसी animation वाला app बहुत खराब महसूस होगा। अगर आपके पास Android है, तो developer settings में animation speed को 0x पर बदलकर इसे खुद आज़मा सकते हैं। अचानक होने वाला बदलाव खटकता है, और दिमाग को समझने में कि क्या हुआ, उल्टा लगभग 1 सेकंड लग जाता है, और वह प्रक्रिया animation होने की तुलना में और धीमी भी लग सकती है
  मेरी setting 0.5x है, और वह काफी लगती है। फिर भी तेज़ है, लेकिन app का खुलना और बंद होना दिखता है

  • मैं Android पर animation बंद करके संतुष्ट होकर इस्तेमाल करता हूँ। कम से कम चीज़ों को “तुरंत” महसूस कराने का यही एक तरीका है। input से UI change तक के संदर्भ में, मेरा मानना है कि चमकदार transitional state न होने से latency हमेशा ज़्यादा बुरी होती है
  • मेरे लिए ऐसा नहीं है। मैं हमेशा animation बंद रखता हूँ। फिर भी सब ठीक चलता है, और animation खत्म होने का इंतज़ार नहीं करना पड़ता, इसलिए मैं फ़ोन को बहुत तेज़ी से चला पाता हूँ
  • मैं भी 0.5x पर इस्तेमाल करता हूँ
    0x की समस्या यह है कि लगता है यह UI के केवल लगभग 90% हिस्से पर ही लागू होता है। कुछ चीज़ों में अब भी animation रहता है, और नतीजे में rhythm बहुत अजीब लगती है
    0.5x पर वे चीज़ें कम खटकती हैं जो animation speed setting से अजीब तरह से प्रभावित नहीं होतीं
    अगर यह सही से काम करे, तो मैं 0x इस्तेमाल करूँगा
  • लगभग 10 साल Android इस्तेमाल करने के बाद, जब iPhone 12 Mini नया था, तब आखिरकार मैं उस पर चला गया। Android की तरह animation बंद करने की सुविधा आज भी याद आती है। मुझे 110% यक़ीन है कि अगर सिर्फ़ मौजूद रहने के लिए मौजूद सभी animation बंद कर पाता, तो मेरा मौजूदा फ़ोन 200% ज़्यादा तेज़ लगता
    ज़रूरत पड़े तो processing में 1 सेकंड लगना मुझे बेहतर लगेगा, और सच कहूँ तो मुझे नहीं लगता कि उसकी भी ज़रूरत है। हर बार app के page बदलने पर animation की वजह से 1 सेकंड धीमा होना उससे कहीं बुरा है, और navigate करते समय सब कुछ गुड़ जैसा भारी लगता है
  • हर animation बस वह समय है जो तब बर्बाद होता है जब आप UI के साथ ठीक से interact नहीं कर सकते, इसलिए सब कुछ बंद कर देना कहीं बेहतर है

• यह लेख relatable लगा, लेकिन काश इसमें कुछ positive examples भी होते। tone शिकायत जैसी नहीं लगी, लेकिन अच्छे UI composition के बारे में ज़्यादा न जानने वाले की हैसियत से मुझे यह एहसास नहीं हुआ कि अब मैं किसे north star मानूँ

  • मैंने हाल ही में ठीक इसी बारे में लिखा था। पहले इस लेख जैसी conceptually similar कमियों को विस्तार से कवर किया, फिर उसके बाद खुद किए गए improvement process को समझाया
    अगर जिज्ञासा हो, तो यहाँ देख सकते हैं: https://www.thisischris.dev/projects/project-6/
  • या फिर अच्छा होता अगर लेखक हर खराब example के लिए mockup दिखाता कि अगर उसे सही तरह implement किया गया होता, तो वह कैसा दिखना चाहिए था

[GN⁺]

Lobste.rs टिप्पणियाँ

• मुझे लगता है कि इस लेख की बुनियादी धारणा गलत है। ऐसे apps को frame-by-frame इस्तेमाल नहीं किया जाता
  सिर्फ़ बुनियादी animation क्लास लेने पर भी यह सिखाया जाता है कि movement को पहचानने का तरीका स्थिर images से अलग होता है। अगर आप "squash and stretch" demo देखें, तो frame-दर-frame किसी object के dimensions अलग-अलग देखने पर बिल्कुल बेतुके लग सकते हैं, लेकिन movement के भीतर वही बहुत खूबसूरती से काम करते हैं

  • लेख के उदाहरण चलते हुए भी सुंदर नहीं लगते
  • बात यह नहीं है कि animation बदसूरत है, बल्कि यह है कि इसने एक usable UI को काम न करने वाले animation sequence से कुछ समय के लिए बदल दिया
    cut वाले उदाहरण की तरह यह program की state को गलत भी दिखा सकता है। UI के फिर से जुड़ने तक user को लगभग एक-तिहाई सेकंड तक दिमाग बंद करके इंतज़ार करना पड़ता है, तभी वह program का इस्तेमाल जारी रख सकता है

• मुझे नहीं लगता कि Wayland project जिस frame perfectness की बात करता है, उसका मतलब यह है
  वह ज़्यादा likely window resizing जैसी low-level technical details की तरफ इशारा करता है। जैसे content का asynchronously resize होना, vertical sync के टूटने से screen tearing या अजीब diagonal artifacts आना, या damage region reporting का rectangular subregions में होना
  बेशक अच्छा होगा अगर low-level details और high-level animation दोनों ही frame स्तर पर perfect हों

  • सहमत हूँ। और लगता है लेखक भी इसे ऐसे ही देखता है

    Wayland is talking about the technical side of things (modern GPU stacks are very complex and Wayland is trying to take control back) but it could be applied to UI too.

• मान लें कि आप ऐसे animations को test करना चाहते हैं, और ऐसे tests लिखना चाहते हैं जो यह verify करें कि समय के साथ यह गुण टूटे नहीं
  आज के web apps और native apps में इस तरह के गुणों को test करने की state of the art technique क्या है? क्या event loop को control न कर पाने की वजह से कुछ खास तरह के tests practically impossible या बहुत कठिन हो जाते हैं?

  • मैं सिर्फ़ native Android apps के बारे में बोल सकता हूँ। अगर आप Jetpack Compose UI toolkit इस्तेमाल करते हैं, तो आप UI को चलाने वाली clock को ही control कर सकते हैं, इसलिए transition के किसी भी point को static screenshot test के रूप में capture किया जा सकता है
    या Paparazzi जैसे tool से पूरे transition को Animated PNG के रूप में record करके automated regression test भी किया जा सकता है
  • आदर्श रूप में size information exposed होनी चाहिए, एक general-purpose layout engine को independently test किया जा सके, और animation भी अलग होनी चाहिए
    तब आप दोनों बिंदुओं को अलग-अलग verify कर सकते हैं, और आखिर में सिर्फ final state check करनी होगी। animation समय के input से बंधी होने के बजाय बाहर से step-by-step drive की जा सकनी चाहिए

• मुझे लगता है कि YouTube वाला उदाहरण View Transitions के use case के काफ़ी क़रीब है
  यह declarative style है: “जब यह element बदले, तो इसे अपने-आप shape बदलने दो”, और नतीजतन technically impressive लेकिन थोड़ा लिसलिसा-सा transition निकलता है, जिसमें elements तैरते हुए और एक-दूसरे में deform होते दिखते हैं
  यह बहुत cool technology है, लेकिन navigation के दौरान छोटे emphasis effect के अलावा मैंने इसे शायद ही कभी शानदार दिखते देखा है। ज़्यादा distracting न हो, इसके लिए इसे बहुत संयम से इस्तेमाल करना चाहिए