GitHub अब Toasts का उपयोग नहीं करता

 (primer.style)
16 पॉइंट द्वारा GN⁺ 2025-12-12 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Toast notification UI अब accessibility समस्याओं के कारण GitHub में अनुशंसित नहीं है
  • अपने-आप गायब होने वाली अस्थायी notification संरचना visual और functional accessibility मानकों (WCAG) का उल्लंघन करने का जोखिम रखती है
  • GitHub ने banner और dialog जैसे स्थायी और सुलभ feedback तरीकों को विकल्प के रूप में सुझाया है
  • Toast में बड़ी स्क्रीन, multitasking, banner अनदेखी होने की प्रवृत्ति जैसी कई usability समस्याएँ भी शामिल हैं
  • accessibility और एकसमान user experience के लिए Primer design system भर में Toast का उपयोग बंद

Toasts का अवलोकन

  • Toast स्क्रीन के निचले कोने में थोड़ी देर के लिए दिखने वाली छोटी आयताकार notification विंडो है, जो user या system action से trigger होती है
  • यह एक निश्चित समय के बाद अपने-आप गायब हो जाती है, इसलिए इसमें accessibility और usability समस्याएँ निहित हैं
  • GitHub इसी कारण ज़्यादा स्थिर और सुलभ communication तरीकों की सिफारिश करता है

Toast के विकल्प

  • उपयोग के उद्देश्य के अनुसार उपयुक्त UI चुनना आवश्यक है
    • साधारण success notification के लिए अलग feedback की आवश्यकता नहीं; result screen से ही पुष्टि की जा सकती है
    • जटिल कार्यों में banner या progressive content disclosure के जरिए success state बताई जा सकती है
    • असफल कार्यों के लिए banner या dialog के माध्यम से error जानकारी दें
  • form submission के मामले में साधारण form के लिए अलग confirmation आवश्यक नहीं, जबकि जटिल form के लिए intermediate confirmation page या banner का उपयोग करें
  • input validation के लिए Primer के मौजूदा form validation components का उपयोग करें
  • लंबे समय तक चलने वाले कार्यों के लिए banner या email·push notification जैसे अन्य channels के माध्यम से completion status बताएं
  • session desynchronization होने पर dialog या banner से refresh की आवश्यकता बताएं

accessibility विचार (Accessibility Considerations)

  • Toast UI कई WCAG success criteria का उल्लंघन कर सकता है
    • 2.2.1 Timing Adjustable (A) : इसे तब तक बना रहना चाहिए जब तक user स्वयं बंद न करे
    • 1.3.2 Meaningful Sequence (A) : DOM क्रम और visual क्रम में अंतर होने पर assistive technology उपयोग के दौरान भ्रम हो सकता है
    • 2.1.1 Keyboard (A) : keyboard से toast के भीतर interactions को नियंत्रित किया जा सकना चाहिए
    • 4.1.3 Status Messages (AA) : assistive technology को इसकी उपस्थिति बिना बाधा के बताई जानी चाहिए
  • इसके अतिरिक्त जिन मानकों के उल्लंघन की संभावना है
    • 1.4.4 Resize text (AA) : text size बदलने पर screen ढकने या overflow का जोखिम
    • 1.4.10 Reflow (AA) : horizontal scroll के समय keyboard accessibility सुनिश्चित करनी होगी
    • 2.4.3 Focus Order (A) : focus order में भ्रम संभव
    • 3.2.4 Consistent Identification (AA) : code consistency बनाए रखना आवश्यक

usability विचार (Usability Considerations)

  • बड़ी स्क्रीन पर toast दृश्य क्षेत्र से बाहर हो सकता है और नज़र ही न आए
  • अपने-आप हटने पर, यदि user किसी अन्य काम में व्यस्त हो तो message छूट सकता है
  • UI ढकने की समस्या: toast नीचे के buttons जैसे महत्वपूर्ण elements को ढक सकता है
  • screen zoom उपयोगकर्ता zoom किए गए क्षेत्र के बाहर का toast नहीं देख पाएंगे
  • working memory समस्या: अपने-आप गायब होने से जानकारी दोबारा जाँची नहीं जा सकती
  • banner अनदेखा होने की प्रवृत्ति: अत्यधिक उपयोग से user उसे नज़रअंदाज़ करने लगते हैं
  • स्थान असंगति: trigger हुए UI और toast के बीच भौतिक दूरी से उनके संबंध को लेकर भ्रम हो सकता है
  • गलत dismiss व्यवहार: Esc key दबाने पर अन्य UI भी साथ में बंद हो सकते हैं

अतिरिक्त संदर्भ सामग्री

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-12-12
Hacker News टिप्पणियाँ
  • accessibility पर बात करते हुए ऐसा अनुभव हुआ कि क्लिक के बाद 3 सेकंड की देरी हुई और लगा जैसे कोई प्रतिक्रिया ही नहीं मिली
    • बैनर पर क्लिक करने के बाद बिना किसी संकेत के इंतज़ार करना पड़ा, और बाद में किसी असंबंधित पेज पर ले जाया गया, जो काफ़ी निराशाजनक था
    • मेरा मानना है कि समस्या feedback की कमी थी, जिससे पता ही नहीं चलता कि loading चल रही है
    • किसी ने कहा कि वह बस एक `` लिंक था, और देरी सिर्फ़ इसलिए थी क्योंकि पेज बेवजह बहुत भारी था
    • एक और व्यक्ति ने कहा कि धीमे 4G पर भी तुरंत प्रतिक्रिया मिलती है, इसलिए यह browser या network की समस्या हो सकती है
  • GitHub Primer के docs पढ़ना दिलचस्प लगा
    • भले हर बात से सहमत न हों, फिर भी सीखने को बहुत कुछ है, और यह अंदाज़े से काम करने से कहीं बेहतर लगता है
    • संदर्भ के लिए, Apple और Android भी अपने-अपने design guidelines देते हैं
  • उम्मीद है कि आखिरकार यह trend और फैलेगा
    • toast notifications की वजह से मैंने बहुत सारे संदेश मिस किए हैं
    • एक दूसरे उपयोगकर्ता ने “toasts को accessibility समस्याओं के कारण recommend नहीं किया जाता” इस बात से पूरी तरह सहमति जताई, और कहा कि notification center होता तो कुछ मदद मिलती, लेकिन तब भी यह खराब तरीका ही रहता
  • मुझे toast non-intrusive confirmation के लिए पसंद हैं, लेकिन महत्वपूर्ण जानकारी देने के लिए यह उपयुक्त नहीं हैं
    • किसी और ने toast के उपयोग के संदर्भ को विस्तार से बाँटकर समझाया
      • बटन क्लिक होते ही प्रतिक्रिया देनी हो → feedback बटन पर ही देना बेहतर है
      • shortcut key की प्रतिक्रिया → ठीक है
      • लंबे समय लेने वाले काम के पूरा होने की सूचना → ठीक है, लेकिन persistent notification inbox होना चाहिए
      • पेज में प्रवेश करते समय warning दिखाना → अगर महत्वपूर्ण है, तो उसे पेज के भीतर स्थायी सूचना के रूप में दिखना चाहिए
    • React में global toast() call करना आसान होने के कारण उसका overuse होता है, लेकिन useAlerts() जैसी संरचना में बदलना कहीं बेहतर होगा, ऐसा सुझाव दिया गया
  • toast मेरे लिए tourniquet जैसी चीज़ हैं
    • ये किसी तात्कालिक समस्या को अस्थायी रूप से रोकने में काम आते हैं, लेकिन इन्हें लंबे समय तक बनाए नहीं रखना चाहिए
    • नए प्रोजेक्ट में जब feedback कम हो, तब इन्हें अस्थायी रूप से जोड़कर बाद में UI सुधारते हुए एक-एक कर हटाना चाहिए
    • GitHub जैसे बड़े संगठन को शायद ऐसे अस्थायी उपाय की ज़रूरत न हो, लेकिन छोटी टीमों के लिए स्थिति अलग हो सकती है
  • GitHub docs में कहा गया “bulk Issue creation के समय अतिरिक्त feedback चाहिए” — यह बात अच्छी लगी
    • GitHub Actions में भी ऐसा feedback होना अच्छा होगा, क्योंकि run करने के बाद result दिखने में बहुत समय लगता है
  • पूरे UI में activity log की तरह toast का उपयोग करने का विचार पसंद आया
    • हर क्लिक पर गायब हो जाने वाले feedback के बजाय, Sonner जैसे अच्छे implementation के उदाहरण मौजूद हैं
  • लगता है browser स्तर पर toast के native support पर विचार करने का समय आ गया है
    • timing control, notification center, screen reader integration जैसी चीज़ों से accessibility बेहतर हो सकती है
    • दृश्य रूप से यह ठीक लगता है, लेकिन अक्सर बहुत जल्दी गायब हो जाता है और लोग इसे मिस कर देते हैं
    • दृष्टिबाधित उपयोगकर्ताओं को होने वाली समस्या को सीधे समझना आसान नहीं है, लेकिन उनकी accessibility बेहतर करने के तरीक़ों के बारे में सुनना चाहूँगा
  • toast की सबसे बड़ी ख़ूबी है इसे implement करना आसान है और design पर कम बोझ पड़ता है
    • नुकसान यह है कि इसे मिस करना आसान है, और यह दूसरी जानकारी के ऊपर चढ़ सकता है
    • अगर पर्याप्त समय और संसाधन हों, तो सभी toast हटा देना बेहतर हो सकता है
    • एक अन्य व्यक्ति ने कहा कि “इसे आसानी से बनाया जा सकता है, इसलिए इसे अक्सर समस्या-समाधान जैसा दिखने वाला अस्थायी जुगाड़ बनाकर ज़्यादा इस्तेमाल किया जाता है”
    • किसी और ने कहा कि उन्होंने toast का उपयोग सिर्फ़ reassuring feedback के लिए किया
    • वहीं एक अन्य व्यक्ति का तर्क था कि “toast कम-महत्व वाली घटनाओं पर तुरंत feedback देने का उपयोगी तरीका है”, और यह modal window या fixed area से अधिक प्रभावी हो सकता है
    • किसी टूल के overuse की वजह से उसे पूरी तरह ख़ारिज कर देने वाली black-and-white thinking की आलोचना की गई
  • मैंने “GitHub द्वारा toast हटाना accessibility के लिए बुरी ख़बर है” वाला लेख देखा
    • किसी को यह दावा अजीब लगा
      • GitHub ने toast हटाने के बजाय W3C के ज़रिए browser standard बनवाना चाहिए था — यह बात उन्हें काफ़ी बढ़ा-चढ़ाकर कही हुई लगी
      • उनका मानना था कि अगर बना हुआ item list में दिख रहा है, तो वही काफ़ी feedback है
    • एक और व्यक्ति ने कहा, “अगर toast accessibility और UX, दोनों के लिए खराब हैं, तो फिर GitHub ने उसे browser में standardize नहीं किया इस बात पर आलोचना करना विरोधाभासी है”