अगर आप एक बटन हैं, तो आपका काम बस एक ही है

• फोटो को घुमाने जैसे साधारण बटन में भी तेज़ दोहराए गए input को कैसे handle किया जाता है, इससे user experience काफी बदल जाता है
• iPhone कई बार दबाए गए 90-degree rotate input को याद रखता है और animation खत्म होते ही अगला rotation जारी कर देता है
• Nothing Phone/Android haptics और sound से tap confirm करता है, लेकिन rotation animation के दौरान आए बाद के taps को ignore कर देता है
• document photos की कई images rotate करनी हों, तो casual photo-editing UI से भी तेज़ और predictable controls की उम्मीद होती है
• बटन को user से animation खत्म होने तक इंतज़ार करवाने के बजाय tap buffering या animation interrupt/acceleration के जरिए input स्वीकार करना चाहिए

---

फोटो rotate बटन repeated input को कैसे handle करता है

• photo rotate button को एक बार दबाने पर आम तौर पर counterclockwise 90-degree rotation होता है, और फिर दबाने पर वही action repeat होता है—यह एक standard control है
• rotation animation यह दिखाता है कि photo की orientation कैसे बदल रही है, जिससे user अपना sense of direction न खोए
• अगर आप तेजी से 8 बार 90-degree rotation दबाएँ, तो engineers जिसे “no op” कहते हैं, वैसा होना चाहिए: image दो चक्कर लगाकर अपनी original orientation में लौट आए
• iPhone पर यह उम्मीद सच में पूरी होती है
  • यह fast tap inputs को याद रखता है
  • पिछला rotation खत्म होते ही queued अगला rotation execute करता है
• Nothing Phone/Android पर नतीजा अलग आता है
  • button haptics और sound से tap confirmation देता है
  • अगर पिछला rotation animation खत्म नहीं हुआ है, तो नया tap ignore कर देता है

casual UI में भी repeated tasks के लिए मजबूत input handling चाहिए

• Situational disability यह concept है कि disability सिर्फ कुछ लोगों को ही नहीं होती; कोई भी व्यक्ति किसी खास स्थिति में effectively disability experience कर सकता है
• photo लेना आम तौर पर casual use के करीब है, लेकिन phone camera नीचे की ओर करके shoot करते समय photo orientation को लेकर भ्रमित हो सकता है
• अगर कई landscape document photos लेने के बाद हर एक को rotate करना पड़े, तो user को photos को एक-एक करके दर्जनों बार rotate करना पड़ सकता है
• ऐसे में, button को अपनी इच्छित speed पर तीन बार दबाने पर भी predictable तरीके से काम करना ज्यादा pleasant और कम झंझट वाला होता है
• पर्याप्त लंबे समय या बड़े user group को देखें, तो casual interfaces को भी ऐसे moments मिलते हैं जहाँ उन्हें ज्यादा गंभीरता से लेना पड़ता है
  • ऐसी “situational power-user-ness” phone photo editing या GarageBand जैसे examples में भी दिखती है
• समाधान जरूरी नहीं कि tap buffering ही हो
  • interrupt-style tap आने पर animation को रोका या तेज भी किया जा सकता है
  • मूल बात यह है कि user को animation खत्म होने का इंतज़ार करने के लिए मजबूर न किया जाए

[GN⁺]

Hacker News राय

• अगर उपयोगकर्ता गलती से बहुत ज़्यादा क्लिक कर दे, या उसे लगे कि पहला क्लिक दर्ज ही नहीं हुआ, तो क्या करना चाहिए?
  अभी भी Steve Jobs का वह keynote याद आता है जिसमें वह दिखा रहे थे कि नए macOS में PDF दस्तावेज़ कितनी तेज़ी से दिखते हैं। इंजीनियरों ने स्क्रीन पर PDF स्क्रॉल करने के लिए एक बटन बना रखा था, लेकिन Jobs ने गलती से उसे एक से ज़्यादा बार दबा दिया और कहा, “क्या यह दो बार अंत तक स्क्रॉल करेगा?” और सचमुच व्यवहार buffer हो गया। आखिरकार उन्हें ऊपर वापस जाना पड़ा और दूसरे स्क्रॉल के खत्म होने तक इंतज़ार करना पड़ा
  Jobs ने बात संभालते हुए कहा, “दस्तावेज़ को दूसरी बार सरसरी तौर पर देखने में लगने वाला समय जोड़ दें, तब भी यह पिछले OS के PDF से तेज़ है”

  • Debouncing किसी वजह से मौजूद है। कुछ मामलों में बटन को दो बार दबाने पर वह दो बार चलना चाहिए, और कुछ में नहीं। किस स्थिति में कौन-सा व्यवहार बेहतर है, यह तय करना आसान नहीं है
    कम-से-कम यह तो सोचना चाहिए कि किस स्थिति में कौन-सी हैंडलिंग सही है। UI में कुछ बटन ऐसे होते हैं जहाँ एक पक्ष साफ़ तौर पर सही लगता है, और कुछ में उल्टा साफ़ होता है, लेकिन कुछ मामले धुंधले होते हैं, जहाँ दोनों व्यवहार का बचाव किया जा सकता है, और तब नतीजा असंगत UI बनता है
    अच्छा समाधान क्या है, यह पक्का नहीं पता

  • लेख के मुताबिक:

    The Nothing Phone button gives you a tap confirmation via both haptics and sound, and then ignores the tap if a previous rotation is still animating.

    यही समस्या है। ऐप ने जितनी बार बटन इनपुट दर्ज होने की पहचान दी है, उतनी ही बार वास्तविक कार्रवाई भी होनी चाहिए। Debouncing अच्छी प्रैक्टिस है, लेकिन अगर इसका इस्तेमाल करना है, तो debounced tap पर feedback नहीं देना चाहिए

  • “अगर उपयोगकर्ता गलती से बहुत ज़्यादा क्लिक कर दे, या उसे लगे कि पहला क्लिक दर्ज नहीं हुआ?” वाले हिस्से में accessibility की बात आने से मैं काफ़ी उलझ गया। क्योंकि मेरे मन में तुरंत ऐसे व्यक्ति का ख़याल आया जिसके हाथ काँपते हों और जो एक बार दबाने की कोशिश में दो बार दबा दे
    और कुछ लोग हर बटन को double-click भी करते हैं। ऐसे मामलों को संभालने के लिए onclick में submit बटन को disable करना बहुत आम है

  • मैं पहले जैसा Apple/Mac/Jobs fanboy नहीं रहा, लेकिन मुझे वे Apple प्रस्तुतियाँ याद आती हैं जो ऐसे लगती थीं जैसे कोई सचमुच कुछ शानदार दिखाना चाहता हो
    हाल की Apple प्रस्तुतियाँ बहुत कठोर, गैर-मानवीय, और सूट पहने लोगों द्वारा चलाई जा रही चीज़ जैसी लगती हैं, इसलिए मैं उन्हें अंत तक देख भी नहीं पाया। सब लोग ऐसे रोबोट लगते हैं जो भावनाएँ और इंसानीपन छिपा रहे हों, मानो पवित्र स्क्रिप्ट से हटे तो नौकरी से निकाल दिए जाएँगे
    हो सकता है यह विषय से हटकर हो, लेकिन इससे याद आता है कि Jobs की थोड़ी बिखरी हुई तात्कालिक प्रस्तुतियाँ भी कितनी आनंददायक थीं

  • “तो फिर ऐसे मामले का क्या?” कहने के लिए यह स्थिति बिल्कुल सही उदाहरण नहीं है। इसके दो कारण हैं:

    1. “The Nothing Phone button gives you a tap confirmation via both haptics and sound, and then ignores the tap […]”
    2. इस बटन को लगातार 3 बार दबाने की अच्छी वजह मौजूद है

• मैं दूसरी जगह उठे “Debouncing का क्या?” वाले तर्क का समर्थन करना चाहता हूँ, और लेखक को इसे यूँ ही नज़रअंदाज़ नहीं करना चाहिए
  लेकिन मुझे you had one job meme भी पसंद नहीं, और मैं इसके बिना सोचे-समझे इस्तेमाल का विरोध करना चाहता हूँ। ज़्यादातर मामलों में यह meme ग़लत होता है, और बटनों के मामले में भी आम तौर पर यही सच है। एक सामान्य user interface में कोई खास बटन एक साथ कई भूमिकाएँ निभाता है:

  • बटन दबाने पर कौन-सी कार्रवाई होगी, यह बताना
  • कभी-कभी सिस्टम के किसी हिस्से की मौजूदा स्थिति बताना, जैसे mode on/off करने वाला बटन वर्तमान mode को दृश्य रूप से दिखाता है
  • क्लिक होने पर इच्छित कार्रवाई चलाना
  • कभी-कभी यह बताना कि कमांड मिल चुकी है और उस पर काम चल रहा है, जैसे मूल उदाहरण में rotation animation के दौरान बटन disable कर देना ताकि भ्रम न हो
  • you had one job meme के पीछे लगभग हमेशा यह जोड़ा जा सकता है: “क्योंकि मैंने तुम्हारे काम की वास्तविक जटिलता पर विचार करने से इनकार कर दिया”
  • यह अच्छी बात है, और खासकर इसलिए कि यह रेखांकित करती है कि अलग-अलग लोगों की अपेक्षाएँ बटन को लेकर अलग होती हैं—क्या बटन है और क्या नहीं। हर बिंदु क्रमशः label वाले button, toggle वाले button, वास्तविक button, और progress indicator का वर्णन करता है। उपयोगकर्ता के हिसाब से ये सब “बटन” हो सकते हैं
  • अगर सवाल “Debouncing का क्या?” है, तो क्या बटन की functionality को touch start की बजाय touch release पर चलाना बेहतर नहीं होगा?

• बटन के लिए “सिर्फ़ एक काम” वाली अभिव्यक्ति बहुत फ़िट नहीं बैठती। बटन को सिर्फ़ क्लिक करने लायक होना ही नहीं, बल्कि कई काम करने होते हैं
  क्लिक होने पर feedback, mouse hover पर feedback, loading state, disabled state, और इन सबके संयोजन होते हैं। यह बहुत निराशाजनक भी लग सकता है। उदाहरण के लिए, अगर आप backend service से जुड़े बटन को दबाते हैं और कोई visual feedback नहीं मिलता, तो आपको पता ही नहीं चलता कि बटन दबा भी या नहीं। अगर loading state भी न हो, तो यह भी नहीं पता चलता कि पीछे कुछ प्रोसेस हो रहा है, और फिर आप उसे बार-बार दबाते रहते हैं

• लेखक चाहता है कि किसी भी गति से तीन बार क्लिक करने पर हमेशा वही फ़ंक्शन लगातार चले। वह तेज़ी से तस्वीरें पलटते हुए हर एक को अनुमानित तरीके से rotate करना चाहता है, और यह वाजिब है

  And it would be so much more predictable and pleasant if you could just tap the button three times at any pace you wanted without thinking, without paying attention, without getting your UI blocked by an animation that no longer helps you.

लेखक इसे accessibility के आधार पर सही ठहराता है
लेकिन पूरी तरह उलटा तर्क भी कल्पना किया जा सकता है। उदाहरण के लिए, जिन लोगों को motor impairment या Parkinson's disease है, वे तब ऐसा व्यवहार जो अतिरिक्त clicks को अनदेखा कर दे ज़्यादा पसंद कर सकते हैं, जब उनका इरादा पहले ही तय हो चुका हो
इसे सही तरीके से बनाना मुश्किल है

• iOS में Ignore Repeats नाम का accessibility option है, लेकिन वह पूरे system की setting है, इसलिए यह बेहतर तरीका लगता है। जिन लोगों को ऐसी correction चाहिए, उन्हें इसका लाभ on-screen keyboard जैसी जगहों पर भी मिल सकता है, और बाकी सभी लोगों की typing भी धीमी करने की ज़रूरत नहीं पड़ती

• मुझे नहीं लगता कि हर UI widget को ऐसी चीज़ों तक सोचना चाहिए
  इसे शायद device-wide setting के रूप में संभाला जा सकता है। उदाहरण के लिए, 50px के भीतर वाले taps अगर 100ms के अंदर दोहराए जाएँ तो उन्हें ignore कर दिया जाए

• पूरी तरह सहमत। Parkinson's disease तक बात न भी जाए, तब भी बहुत ज़्यादा बुज़ुर्ग न होते हुए भी उम्रदराज़ लोगों को फोन और touchscreen इस्तेमाल करते देखो, तो समझ आता है कि छोटे button को सही जगह दबाना और “मैंने दबाया” जैसा एहसास पाना अक्सर मुश्किल होता है
  इसलिए accessibility के नज़रिए से Nothing Phone का व्यवहार कहीं ज़्यादा उपयुक्त लगता है। ऐसे users किसी image को किसी खास जगह रखने के लिए गिन-गिनकर 6 बार click नहीं करते। और मौजूदा position पर ठीक-ठीक लौटने के लिए पहले से 8 बार click करना भी खास मतलब नहीं रखता
  इस मामले में सोचने का तरीका ज़्यादा “click करो, इंतज़ार करो, फिर देखो कि जगह सही है या नहीं, फिर दोबारा click करो” जैसा होता है। इसके उलट, input को buffer करने वाला संवेदनशील button overshooting पैदा कर सकता है, जिसमें चीज़ आगे निकल जाती है और फिर बहुत पीछे लौट आती है। यह वैसा ही है जैसे list में मनचाही जगह तक scroll करने की कोशिश करते हुए बार-बार चूक जाना
  iPhone का तरीका उन युवा लोगों या tech enthusiasts के लिए ज़्यादा ठीक है जो बिना रुके तेज़ी से काम करना चाहते हैं। यह वैसा ही है जैसे computer keyboard पर latency की वजह से पहला अक्षर screen पर दिखने से पहले ही कई अक्षर टाइप कर दिए जाएँ

• मैंने पहले एक physical button वाला device इस्तेमाल किया था, जिसमें दबाने पर beep होती थी और समय में 30 सेकंड जुड़ते थे। लेकिन कभी beep सुनाई देती थी और 30 सेकंड नहीं जुड़ते थे, और कभी बिना आवाज़ के 30 सेकंड जुड़ जाते थे। इसलिए मुझे हमेशा धुंधले display को आँखें सिकोड़कर देखना पड़ता था कि यह सच में काम हुआ या नहीं
  मुझे यह असामान्य रूप से खराब design लगा था, लेकिन उसके बाद मैंने अनगिनत बार pure software buttons में भी यही टूटा हुआ व्यवहार दोहराया हुआ देखा। screen पर button का रंग बदलना और माँगी गई action का सचमुच होना, इन दोनों का रिश्ता बहुत ढीला होता है। ऐसा क्यों है? आखिर इसे implement कैसे किया गया है?

  • मैं इसे दो काम करने की समस्या कहता हूँ
    आप imperative code लिखते हैं और दो commands देते हैं, और दोनों अपने-अपने तरीके से fail हो सकती हैं
    इसे “हो गया” जैसा दिखाने के कई तरीके हैं
    सबसे पहले, tests सब pass हो जाते हैं, इसलिए ज़्यादातर developers यहीं सोचना बंद कर सकते हैं
    हो सकता है वे exceptions पकड़कर सिर्फ log छोड़ देना ही काफी समझें, लेकिन इससे चीज़ ठीक नहीं होती
    यह भी हो सकता है कि वे इसे production में कुछ समय चलाकर देखें कि समस्या आती है या नहीं। आखिरकार जब समस्या आती भी है, तो developer दोबारा कोशिश करेगा, और दूसरी बार शायद यह काम कर जाए, तो वह फिर सोचना बंद कर सकता है
    कुछ दिन पहले outbox pattern पर भी बड़ी चर्चा हुई थी। उसमें पहले काम को दो हिस्सों में बाँटकर atomically संभाला जाता है, और दूसरा काम consumer पर छोड़ दिया जाता है
    मुझे लगता है कि वास्तविक दुनिया में यह समस्या बार-बार इसलिए दिखती है क्योंकि developers “ऐसा होता ही नहीं”, “मैंने इसे ठीक कर दिया”, और “इसे ठीक किया ही नहीं जा सकता” जैसी quantum superposition में रहते हैं
  • यह ज़्यादातर UI frameworks में साझा की गई दो design विशेषताओं की वजह से बहुत आम है:
    button का रंग बदलने वाला code “button” component का internal व्यवहार होता है, इसलिए इसे हर button में अलग से implement नहीं करना पड़ता। लेकिन इसका मतलब यह भी है कि यह असली action करने वाले code से कुछ हद तक अलग रहता है। अगर on click handler में मूल पोस्ट की तरह कोई अंतिम जाँच हो, जैसे “rotation animation चल रही हो तो image को rotate न करो”, तो अक्सर button को यह बताने का तरीका ही नहीं होता कि रंग बदलना cancel कर दे। उल्टा, रंग बदलने वाली animation ठीक से न भी चले, तब भी on click handler चल सकता है
    button आम तौर पर mouse button दबाते ही रंग बदल लेता है, लेकिन action mouse button छोड़ने पर होती है। यह तरीका जानबूझकर यह मौका देता है कि button दबाए रखते हुए उसे बाहर drag करके आख़िरी क्षण में cancel किया जा सके, और mobile पर interaction को click के बजाय scroll के रूप में दोबारा समझा जा सके। दूसरी स्थितियों में यह सिर्फ ऐसे मौकों की संख्या बढ़ाता है, जहाँ रंग तो बदल चुका होता है लेकिन action को बाद में रोका जाता है
  • lift में यह काफी लगातार दिखता है। अगर button को बहुत हल्के से दबाओ, तो दबाए रखने तक light जलती है, लेकिन वास्तव में button input register नहीं होती
  • button के रंग का बदलना यह दिखाता है कि press सफल रही। अगर यह तुरंत न हो, तो ज़्यादातर लोग दोबारा कोशिश करने के लिए conditioned हो चुके होते हैं। यह खासकर कमजोर motor control वाले लोगों के लिए महत्वपूर्ण है
    यह इस बात से पूरी तरह स्वतंत्र है कि मौजूदा software state में वह press उपयोगी input है या नहीं। अच्छी तरह लिखा गया software तो पहले से जानता होता कि input नहीं लिया जा सकता और button को disabled कर देना चाहिए था, और ठीक-ठाक लिखा software भी action process हो रही है या cancel हो गई है, इसकी लगभग तुरंत feedback दे देना चाहिए
  • शायद testing की कमी और इस धारणा की वजह से कि action failures इतने दुर्लभ हैं कि उन पर सोचने की ज़रूरत नहीं। लेकिन यह pattern interfaces पर भरोसा करना और उन्हें कुशलता से इस्तेमाल करना कठिन बना देता है

• लोग अक्सर भूल जाते हैं कि animation पूरी तरह सहायक चीज़ है; animation खुद लक्ष्य नहीं है
  animation का काम loading time को छिपाना और एक state से दूसरी state में सहज बदलाव कराना है। इसी कारण इसका इस्तेमाल किया जाता है
  लगता है यह समझ कहीं खो गई, और अब ऐसा code बन गया है जिसमें animation खत्म होने तक इंतज़ार करना पड़ता है
  यह cargo cult का एक और चौंकाने वाला उदाहरण है

  • मैं “loading time को छिपाना और एक state से दूसरी state में सहज बदलाव कराना” वाली बात को थोड़ा और बढ़ाना चाहूँगा। सही इस्तेमाल होने पर यह दिखाता है कि user की किसी खास action की वजह से state change सीधे हो रही है, और यह भी संकेत देता है कि उसे वापस कैसे लिया जा सकता है या बदला कैसे जा सकता है
    सच कहूँ तो “छिपाना” शब्द से मैं सहमत नहीं हूँ। touchscreen पर बिना किसी संकेत के कुछ अचानक दिख जाना, कि वह क्यों आया, एक स्पष्ट anti-pattern है
  • animation सिर्फ उसी काम के लिए नहीं होती। यह app इस्तेमाल करते समय उसके feel में रचनात्मक रूप से योगदान भी देती है
  • Apple पहले यह समझता था। item गायब होने के बाद animation जोड़ता था, लेकिन item दिखाने से पहले animation से बचता था
    पुराने Apple को समझ थी कि design सिर्फ चीज़ों को सुंदर बनाने से बढ़कर है। आज का काँच-जैसा Apple सिर्फ इस बात पर अटका है कि demo में वह कैसा दिखे
  • animation लगभग हमेशा अनावश्यक लगती है। app या system जहाँ भी अनुमति दे, मैं उसे बंद कर देता हूँ
  • Android पर मैंने सारी animations बंद कर रखी हैं और यह बहुत बेहतर लगता है। खासकर वह overscroll animation जिसमें ज़रूरत से ज़्यादा scroll करने पर पूरी screen फैलती हुई लगती है, वह मुझे सच में नापसंद है

• पहली तुलना देखते समय, सच कहूँ तो मुझे लगा समस्या iPhone वाले उदाहरण में ही है। हर बार rotate बटन दबाने पर इमेज के नीचे वाले बटन और slider गायब होकर फिर fade-in होते हैं, यह व्यवहार मैंने iOS के कई apps में देखा है और यह लगातार परेशान करता है। खासकर Screenshot app से मुझे व्यक्तिगत रूप से बड़ी शिकायत है
  अगर कोई UX element interaction से पहले और बाद, दोनों समय इस्तेमाल किया जा सकता है, तो चाहे transformation हो या processing, उसे उस दौरान भी दिखाई देता रहना चाहिए। iPhone में rotate करते समय इन बटनों को छिपाने से UX में क्या फायदा होता है? यह बेहतर भी नहीं लगता। हाँ, हाल के Apple software ने अक्सर वास्तविक UX सुधारों को बाहरी रूप-रंग की वेदी पर बलि चढ़ाया है
  लेकिन इस बात से मैं सहमत हूँ कि ऐसे tap को animation से स्वतंत्र रूप से handle किया जाना चाहिए

  • अच्छा होगा अगर software apps के लिए भी computer chips जैसी tape-out rules हों। chip design करते समय programs design की समीक्षा करते हैं और “X metal और Y metal की wiring Z दूरी के भीतर नहीं होनी चाहिए” जैसे 300 पन्नों के नियमों से मिलान करते हैं
    UX के लिए भी कुछ ऐसा बनाया जा सकता है। यानी design pattern constraints का ऐसा संग्रह, जो किसी जाने-पहचाने UX flaw वाली स्थिति में release करने की कोशिश पर warning दिखाए

• इससे मुझे वह समय याद आ गया जब मैंने बच्चों के इस्तेमाल के लिए बनाया गया BabyButton implement किया था। सामान्य click action की जगह मैंने touchdown event इस्तेमाल किया था, ताकि बच्चा तुरंत देख सके कि कुछ हुआ है, और अगर वह बटन को बहुत देर तक दबाए रखे या दबाकर उंगली हिलाए, तब भी कोई समस्या न हो
  क्या उस उम्र के लिए system बनाया जाना चाहिए, यह बिल्कुल अलग विषय है, लेकिन मुझे लगा कि यह user की ज़रूरतों के हिसाब से design करने की एक अच्छी चुनौती थी

  • यह दिलचस्प है कि हम इस बात के कितने आदी हो चुके हैं कि GUI बटन mouse button छोड़ने पर ही चलें, और दबाए रखते हुए बटन क्षेत्र से बाहर जाना और फिर वापस आना जैसी खास हरकतों को संभालें
    वास्तविक दुनिया के 99% से अधिक बटन दबाते ही काम करते हैं। लेकिन GUI में अगर बटन ऐसे काम करे, तो वह अजीब लगेगा

• लेखक जो कहना चाह रहा है, उसके अधिक करीब असली लेख यह है: https://aresluna.org/show-your-hands-honor/

• कॉल के दौरान iPhone का screen on/off बटन दबाने पर कभी कॉल कट जाती है, और कभी सिर्फ स्क्रीन बंद होती है — ऐसा क्यों होता है?
  मुझे अब तक इसका pattern समझ नहीं आया, लेकिन iPhone को जेब में रखने से पहले वह बटन दबाकर मैंने कभी-कभी गलती से कॉल काट दी है

  • speakerphone/hands-free mode में हो तो सिर्फ स्क्रीन बंद होती है। कान से लगाकर बात करते समय स्क्रीन अपने-आप बंद हो जाती है, इसलिए शायद यह मान लिया गया है कि आप lock बटन नहीं दबाएँगे। समस्या यह है कि कभी-कभी bug की वजह से स्क्रीन चालू रहती है, या शांत कमरे में लोग hands-free की तरह इस्तेमाल भी करते हैं

[GN⁺]

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

• हल्का-सा तंज है, लेकिन अगर अच्छे UI/UX की बात करें तो बिना controls और बिना संकेत वाला video embed सबसे खराब है
  कई लोग autoplay को default रूप से बंद रखते हैं, और मैं भी लगभग एक जैसी दो images देखते हुए काफी देर तक “तो फर्क क्या है?” सोचता रहा

  • “वीडियो था?” ऐसा सोचा, लगता है मैं भी चूक गया
  • समझ नहीं आया कि यह “सबसे खराब” क्यों है। क्या तुम थोड़ा नीचे scroll करके समस्या का description पढ़े बिना बस “तो क्या?” ही सोचते रहे?
  • इस विषय पर, यह मानना पड़ेगा कि GitHub animated GIFs पर playback controls दिखाता है। ऐसा और जगहों पर लगभग नहीं दिखता
  • यह browser का फर्क भी हो सकता है। Android पर Vivaldi में बड़ा play button और progress bar दिखा था

• “animation खत्म होने तक user को कभी wait न कराओ” से मैं पूरी तरह सहमत हूँ
  अगर app है, तो सुंदर दिखने से ज्यादा user command को हमेशा priority मिलनी चाहिए

• मुझे लगता है यह principle games पर भी लागू होता है। कुछ games में menu खोलने के बाद input register होने तक बहुत छोटी delay होती है
  अगर किसी game में flashy menu animation हो और आप pause और down arrow जल्दी-जल्दी दबाएँ, तो menu खुलने के बाद दूसरा item selected होना चाहिए या नहीं—यही समस्या है
  games में input buffering सूक्ष्म विषय है, लेकिन menu operation में आम तौर पर यह खराब महसूस होने के cases कम ही होते हैं

• video information convey करने का तरीका अच्छा नहीं था। button को लगातार कई बार दबाए जाने का moment notice करने के लिए ध्यान से देखना पड़ता था
  असली मुद्दे पर आएँ तो, यह भी अस्पष्ट है कि Android phone सच में गलत कर रहा है या नहीं। जल्दी-जल्दी 8 बार दबाकर desired result पाना चाहने की frustration समझ में आती है, लेकिन desktop OS में accidental double-click detection याद आता है
  आखिरकार यह manufacturer की usability की सोच और user को महसूस होने वाली convenience के फर्क जैसा लगता है। अगर तुलना करनी ही हो, तो iPhone का animation के दौरान भी “Done” button दिखाना मुझे ज्यादा distracting लगता है

• यह कहना मुश्किल है कि Android पूरी तरह गलत है। धीमे respond करने वाले UI की वजह से मैंने कोई action गलती से दो बार execute किया है
  शायद सबसे अच्छा तरीका यह हो सकता है कि animation खत्म होने तक button disable रखा जाए

  • तब वही problem पैदा होती है जो लेख में दिखाई गई है। screen देखे बिना 90 degrees counterclockwise rotation करना लगभग असंभव हो जाता है
    “तीन clicks” काम नहीं करता, और animation के दौरान extra clicks ignore हो जाते हैं। click करना, screen देखते हुए animation खत्म होने का wait करना, फिर click करना और फिर wait करना—यह process धीमा है और user का काफी ध्यान मांगता है
    बेहतर solution शायद UI में immediate feedback देना है। button state को तुरंत render किया जा सकता है कि click process हो गया है, या slow full animation आने से पहले temporary रूप से screen को जल्दी redraw करके current progress दिखाया जा सकता है

• पूरे लेख से जोरदार सहमति है। मैं इसे ऐसे कहना चाहूँगा कि animation ने Hippocratic oath तोड़ी है
  animation का पहला principle “पहले नुकसान मत पहुँचाओ”, यानी “पहले user input में बाधा मत डालो” होना चाहिए

• क्या कभी ऐसा rotary encoder इस्तेमाल किया है जो follow नहीं कर पाता? मेरे headphone amp का volume knob बहुत तेजी से घुमाओ तो कुछ भी नहीं होता
  अगर मैं एक दिन के लिए President बनूँ तो…

• ऐसी चीजें देखते समय मैं हमेशा सोचता हूँ कि मेरे GUI toolkit में यह कैसे होगा। मेरा toolkit Windows platform से उधार लिए behavior की तरह दो तेज clicks को double-click मानता है, और यह कभी-कभी पागल कर देता है
  double-click अपने-आप में आम convention है और click से अलग इसकी value है। ideally click events को idempotent बनाना चाहिए ताकि दो बार होने पर भी problem न हो। जैसे अगर click item selection है और double-click default action execute करना है, तो same item को दो बार select करना हानिकारक नहीं है। लेकिन reality हमेशा ऐसी नहीं होती
  problem यह है कि button को बहुत तेजी से click करने पर button सिर्फ एक बार execute हो सकता है, और उसके बाद वाला event double-click event में जाकर कुछ भी न करे। इसलिए fast press करने पर आधे clicks ignore होने जैसा behavior बन जाता है
  इसी problem की वजह से मैंने triggersOnMultiClick नाम का boolean बनाया, और इसे true set करने पर double-click जैसे तेज multi-click में भी trigger event emit होता है। हालांकि backward compatibility के कारण default false रखा था, लेकिन अब new major release का समय आ गया है, इसलिए लेख की दलील सही मानते हुए default को अब true में बदलने का सोच रहा हूँ
  “2 जुलाई 2021 को जोड़ा गया, default false। 5 जुलाई 2026 (v13.0) में default को true में बदल दिया गया ताकि buttons के सभी clicks default रूप से trigger हों। अगर पुराना behavior चाहिए तो double-click event override करें या parent constructor call के बाद triggersOnMultiClick = false set करें” इस तरह लिखा जा सकता है
  animation implementation में भी similar behavior अनजाने में पैदा हो सकता है। अगर object के अंदर animation position variable हो और click पर value set की जाती हो, तो double-click होने पर मोटे तौर पर दो choices हैं। बाकी animation skip करके सीधे next internal state पर जाना, या visual smoothness बनाए रखने के लिए if(animationCounter) return; की तरह event ignore करना। लेख के Android developer ने शायद दूसरा विकल्प चुना
  Apple side ने शायद तीसरा तरीका इस्तेमाल किया है, यानी pending animation queue रखकर events को उसमें डालना। curiosity यह है कि internal state queue में डालते समय बदलती है, completion पर बदलती है, या सच में image को animation से rotate किया जाता है। अगर बीच में animation interrupt करके save करें तो क्या 45-degree rotated image मिल सकती है? अगर मैं करता, तो EXIF को atomically 90 degrees update करता और transition animation अलग से चलाता
  implementation simplicity, visual fidelity, और UI behavior के बीच कई reasonable choices हो सकती हैं। personally मुझे यह तरीका भी पसंद है कि second press animation का wait किए बिना तुरंत new state पर snap हो जाए। शायद मैं animation queue तक नहीं बनाऊँगा
  लगभग इसी समय code बदलना मजेदार है। पिछला modification भी 2 जुलाई को था और यह संयोग से 5 जुलाई है। ऐसी history को documentation comments में सीधे लिख देना मुझे पसंद है। बाद में बदलाव करते समय यादों की तरह पढ़ना भी अच्छा लगता है
  Apple शायद default animation queue provide करता होगा, लेकिन state change का timing फिर भी अलग issue है। web में शायद state को atomically update करके CSS transform transition जैसी purely visual animation अलग रखी जाएगी। layout recalculation भी avoid हो सकता है, इसलिए implementation आसान और efficient लगेगा। animation से faster class name बदलने पर jump होगा या queue होगा, यह बाद में experiment करके देखना चाहूँगा

• शायद उम्र बढ़ने की वजह से, गलती से दो बार tap करने पर ऐसे behavior से कई बार irritation हुई है
  उसी जगह के button या double-tap को confirmation mechanism बनाना भयानक है। अगर सच में confirmation चाहिए तो accidental confirmation आसानी से हो सके ऐसा नहीं बनाना चाहिए
  हालांकि इस example में fast repeated input accept करना अच्छा idea लगता है। दूसरी cases में ऐसा जरूरी नहीं। physical buttons में कुछ ऐसे होते हैं जो किसी चीज के “खत्म” होने तक intentionally second press रोकते हैं, और भले ही यह हमेशा conscious design न हो, कभी-कभी यह सही choice होती है
  बहुत से लोगों को laggy devices या खराब devices इस्तेमाल करने पड़ते हैं, और अगर हाथ या उंगलियों में tremor जैसी health issues हों तो input limit करने में फायदा हो सकता है
  यह example ऐसा case लगता है जहाँ दोनों sides ठीक मानी जा सकती हैं। ऐसे examples भी हैं जहाँ wait करना ज्यादा annoying है, और ऐसे examples भी निश्चित रूप से हैं जहाँ animation हो या कोई और condition, input limiting होना अच्छा लगता

• mobile browser search results का मेरी उंगली के नीचे update होकर जिस option को मैं tap करने वाला था उसे दूसरी जगह धकेल देना सच में लगातार irritate करता है
  मैंने खुद को ज्यादा wait करने के लिए train तो कर लिया है, लेकिन यह कोई sensible बात नहीं कि UI interaction उन background asynchronous tasks के प्रति sensitive हो जिनका completion time reception state की वजह से बदलता रहता है