क्या टॉगल बटन को मौजूदा स्थिति दिखानी चाहिए, या वह स्थिति जिसमें वह बदलेगा? (2010)

 (ux.stackexchange.com)
3 पॉइंट द्वारा GN⁺ 2024-02-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Play/Pause जैसी तुरंत चलने वाली action और Shuffle जैसी बनी रहने वाली setting को एक ही तरह के toggle से संभालने पर user मौजूदा स्थिति और अगले action में भ्रमित हो सकता है
  • About Face 2.0 सलाह देता है कि दो विकल्पों को एक control में डालने वाले flip-flop button से बचें, और मानता है कि जगह बचाने से ज्यादा महत्वपूर्ण मौजूदा स्थिति बताना है
  • समाधान Switch to portrait mode की तरह action को verb phrase में लिखने, या radio button, checkbox, status label + action button के जरिए स्थिति और बदलाव को अलग करने के ज्यादा करीब है
  • iOS-स्टाइल switch में अगर text button के अंदर हो, तो ON मौजूदा स्थिति है या अगली स्थिति, यह अस्पष्ट हो सकता है; OS X और Windows Metro-स्टाइल की तरह status text को button के बाहर रखने से ambiguity कम होती है
  • Play/Pause convention अपवाद के रूप में अगला action दिखा सकता है, लेकिन Shuffle, Like, Auto save जैसे options के लिए मौजूदा स्थिति पर जोर देना और tooltip, color, pressed state, अलग label से उसे पूरक बनाना ज्यादा सुरक्षित है

स्थिति दिखाने और action दिखाने का टकराव

  • Play/Pause, Shuffle/Regular Play जैसे दो स्थितियों के बीच आने-जाने वाले buttons में मुख्य मुद्दा यह है कि मौजूदा स्थिति दिखानी है या click के बाद बदलने वाली transition state दिखानी है
  • Play/Pause को user “playback शुरू करें” या “pause करें” जैसी action के रूप में आसानी से समझता है, इसलिए रुका होने पर Play और चल रहा होने पर Pause दिखाने की convention परिचित है
  • Shuffle/Regular Play playback mode जैसे option state के ज्यादा करीब है, इसलिए अगर बदले जाने वाली स्थिति दिखाई जाए तो यह भ्रम हो सकता है कि अभी shuffle है या sequential playback
  • Xbox 360 के built-in music player को ऐसे example के रूप में देखा गया, जिसमें shuffle mode में direct play icon दिखता था और उलटी स्थिति में भी उल्टा दिखाकर भ्रम पैदा करता था

About Face की सलाह: flip-flop button से बचें

  • About Face 2.0 इस type को “बचने योग्य choice idiom” यानी flip-flop button के रूप में classify करता है
  • जब एक ही button दो mutually exclusive options को control करता है, तो जगह तो बचती है, लेकिन control की दूसरी जिम्मेदारी, यानी मौजूदा स्थिति बताना, पूरी करना मुश्किल हो जाता है
  • अगर button पर ON दिखता है जबकि मौजूदा स्थिति off है, तो setting की स्थिति साफ नहीं रहती; और off स्थिति में OFF दिखाने पर user सोच सकता है कि ON button कहां है
  • सुझाए गए समाधान दो हैं
    • button की action को Switch to portrait mode की तरह verb phrase में लिखना
    • दो radio buttons जैसे किसी दूसरे UI technique का उपयोग करना, जिसमें state selection साफ दिखे

Action button और state button को अलग समझना

  • action button और state button को अलग तरीके से design करना चाहिए
    • Play/Pause जैसी action हो तो click करने पर क्या होगा, वह दिखाएं
    • Shuffle/Linear जैसे option हों तो मौजूदा स्थिति दिखाएं
  • अगर सिर्फ icon वाला Shuffle button है, तो shuffle icon को ही बनाए रखना और state के हिसाब से उसे active/inactive जैसा दिखाना बेहतर है
    • on state को ज्यादा bright करें या pressed button जैसा दिखाएं
    • off state में यह तुरंत पता चलना चाहिए कि sequential playback है
    • जहां hover संभव हो, वहां tooltip जोड़कर इसे और स्पष्ट बनाया जा सकता है
  • एक राय यह भी है कि Play/Pause में label बदले बिना Play button को pressed state में दिखाने से भ्रम कम हो सकता है

Button के अंदर text से बनने वाली ambiguity

  • English में ON और OFF state की तरह भी और transition action की तरह भी पढ़े जा सकते हैं, इसलिए इन्हें button के अंदर रखने पर यह status है या command, यह धुंधला हो सकता है
  • ज्यादा स्पष्ट word pairs के तौर पर ये expressions सुझाए गए
    • Enable / Disable
    • Enabled / Disabled
    • Start / Stop
    • Running / Stopped
  • सिर्फ शब्द चुनने से समस्या पूरी तरह खत्म नहीं होती
    • user को फिर भी तय करना पड़ सकता है कि button text status है या command
    • Enable और Enabled का फर्क UI के अंदर पर्याप्त रूप से स्पष्ट न हो सकता है

Button के बाहर label और status + action को अलग करना

  • button में text न डालकर button के बाहर text रखने से मौजूदा स्थिति और संभव transition state दोनों साथ दिखाए जा सकते हैं
  • OS X-स्टाइल switch में button खुद ON या OFF नहीं कहता, और switch के आसपास का text status बताता है, इसलिए “यह button मौजूदा स्थिति है या अगला action” वाला सवाल कम होता है
  • Windows Metro UI तरीका button color से मौजूदा status दिखाता है और option text के नीचे On/Off wording से मौजूदा status की फिर पुष्टि कराता है
  • Online [Go offline] की तरह status label + action button को अलग करने का तरीका भी संभव है
    • Online non-clickable मौजूदा status label है
    • Go offline clickable transition action है
    • click के बाद यह Offline [Go online] में बदल जाता है
  • यह तरीका radio buttons की तुलना में ज्यादा compact होते हुए भी status और action की visual roles को अलग कर सकता है

Checkbox, radio button, pressed state

  • Shuffle जैसे options को Shuffle label वाले checkbox के रूप में दिखाने से confusion कम होता है
  • एक ही शब्द का उपयोग करके checked state से active है या नहीं दिखाने पर कई शब्दों के बीच अर्थ समझने का बोझ घटता है
  • negative prefix वाले expressions से बचना बेहतर है
    • Not, Non-, Un-, Dis-, Im-, Mis-, In-, Il-, Ir- जैसे prefixes unchecked state के साथ मिलकर double negative जैसे पढ़े जा सकते हैं
  • Facebook Android app का Like button ऐसा example है जिसमें off होने पर grey और on होने पर blue highlight होता है
    • हालांकि सिर्फ color color-vision deficiency वाले users के लिए पर्याप्त नहीं हो सकता

असली UI examples और सावधानियां

  • Spotify web app के Shuffle button की तरह off होने पर neutral color और on होने पर accent color इस्तेमाल करने वाला compromise मौजूद है
  • Twitter-स्टाइल hover transition में पहले मौजूदा स्थिति दिखती है और mouse hover करने पर action दिखता है
    • hover वाले environments में यह काम कर सकता है, लेकिन touchscreens पर वही तरीका लागू नहीं हो सकता
  • iOS-स्टाइल switch एक ही control में दोनों states दिखाता है, लेकिन इसकी आलोचना भी होती है कि ON मौजूदा स्थिति है या दबाने पर बदलने वाली स्थिति, यह अस्पष्ट है
  • Discord settings UI checkbox-type toggle का example है, जो मौजूदा स्थिति और future state को ज्यादा स्पष्ट बनाता है
  • Evernote के mouseover toggle और airplane toilet-style handle switch जैसे examples भी हैं, जहां स्थिति और operation possibility साथ-साथ दिखती हैं

Design principles

  • जब एक control status communication और action communication दोनों की जिम्मेदारी एक साथ लेता है, तो ambiguity पैदा होती है
  • मौजूदा स्थिति किसी न किसी रूप में जरूर बताई जानी चाहिए
    • Play/Pause में music सुनाई देना या time progress होना जैसी external feedback मौजूदा स्थिति को पूरक बना सकती है
    • Shuffle में अगला song वास्तव में कैसे चुना जाता है, यह देखने तक status जानना मुश्किल है, इसलिए button का अपना status indication ज्यादा महत्वपूर्ण है
  • single button से कई states को cycle कराने का तरीका UI को compact बनाता है और mutually exclusive settings को group कर सकता है, लेकिन user को मौजूदा स्थिति जल्दी समझ आनी चाहिए
  • Play/Pause मजबूत convention के कारण अगला action दिखाने वाला exception हो सकता है, और सामान्य option toggles के लिए मौजूदा स्थिति पर जोर देना ज्यादा consistent है

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

1 टिप्पणियां

 
GN⁺ 2024-02-13
Hacker News की राय

  • आजकल Microsoft Teams की वजह से बहुत झुंझलाहट होती है। डेस्कटॉप ऐप में mute होने पर माइक्रोफोन पर कटी हुई लाइन वाला आइकन दिखता है, और unmute होने पर बिना लाइन वाला माइक्रोफोन दिखता है, इसलिए समझना आसान होता है
    लेकिन फ़ोन ऐप से जुड़ें तो वही कटी हुई लाइन वाला माइक्रोफोन आइकन यह मतलब देता है कि “अभी mute नहीं है, इस बटन को दबाओगे तो mute हो जाएगा।” दबाने के बाद भी आइकन वही रहता है, बस background उलट जाता है
    लगता है एक तरफ़ यह “माइक्रोफोन चालू करो” बटन है और दूसरी तरफ़ “mute चालू करो” बटन, इसलिए वही आइकन इस्तेमाल हो रहा है। नतीजा यह है कि मौजूदा स्थिति समझने के लिए यह जानना पड़ता है कि उलटी स्थिति में बटन कैसा दिखता है, इसलिए मैं हर बार कुछ बार दबाकर देखता हूँ कि यह ऐप कौन-सा तरीका इस्तेमाल कर रहा है
    सोचता हूँ क्या यह वास्तविक दुनिया के संदर्भ खो चुके flat UI की क़ीमत है

    • मुझे लगता है इस भ्रम का एक हिस्सा इस सोच से आता है कि माइक्रोफोन डिफ़ॉल्ट रूप से चालू होता है। “माइक्रोफोन active” को default मानना और mute को उससे विचलन मानना, यह पैटर्न टेलीकॉन्फ़्रेंस सिस्टम UI, analog फ़ोन, और उससे भी पीछे उन दिनों तक जाता है जब लोगों के बीच सचमुच तार जुड़ा होता था
      लाइव संगीत या रिकॉर्डिंग के लिए audio mixer भी आम तौर पर यही पैटर्न इस्तेमाल करते हैं। channel बंद होने पर लाल बत्ती जलाने वाला “Mute” बटन होता है, और कुछ उपकरणों में ही fader के ऊपर “ON” बटन जलकर channel के active होने को दिखाता है
      अब समय आ गया है कि मीटिंग ऐप भी audio डिफ़ॉल्ट रूप से बंद वाले approach पर जाएँ। वक्ता के बोलते समय UI element के जलने के तरीके में यह थोड़ा-थोड़ा पहले से दिख भी रहा है
    • यह ऐसा बटन है जो सचमुच भ्रमित नहीं करना चाहिए
    • Plex में भी ऐप के हिसाब से UI अलग है, इसलिए वैसी ही झुंझलाहट होती है। फ़ोन पर TV शो का season देखें तो देखे जा चुके episode पर नीला check दिखता है, लेकिन TV पर वही season देखें तो नीला check नहीं होता, और न देखे गए episode पर पीला triangle दिखता है
      हर बार डिवाइस बदलते ही दिमाग़ एक पल के लिए अटक जाता है
    • Discord इससे भी बदतर है। माइक्रोफोन mute बटन और camera off बटन एक-दूसरे के उलटे तरीके से काम करते हैं
    • माइक्रोफोन indication/control की समस्या में काफ़ी दिलचस्प पहलू हैं। अगर सीधा visual feedback न हो, तो माइक्रोफोन किस mode में है यह दूसरे लोगों के प्रतिक्रिया देने या न देने तक पता नहीं चलता
      चालू होने पर भी यह feedback latency वाला टूल है। सामने वाला रुक गया हो सकता है, या जवाब देने से पहले सोच रहा हो सकता है, इसलिए अक्सर दो-तीन बार जाँच करनी पड़ती है तब यक़ीन होता है
      यह dark mode जैसा नहीं है, जहाँ चालू-बंद करते ही तुरंत दिख जाता है। इसलिए बटन जो भी action करे, मौजूदा स्थिति दिखाने वाला visual indicator बहुत मददगार होता है, और माइक्रोफोन में ख़ास तौर पर “state” और “control” को मिलाने की कोशिशें ज़्यादा दिखती हैं, यह भी हैरानी की बात नहीं

  • Tesla मालिक इससे ज़रूर जुड़ाव महसूस करेंगे। कार के UI में toggle बटन इतने तरह के हैं कि न consistency है न कोई standard
    उदाहरण के लिए climate control बटन एक ही ऐसा बटन है जो तापमान दिखाता है, लेकिन आप उसे कैसे और कितनी देर दबाते हैं, उसके हिसाब से अलग प्रतिक्रिया मिलती है। हल्का दबाएँ तो छोटा popup आता है, थोड़ा देर दबाएँ तो पूरा climate control panel खुल जाता है, और कुछ सेकंड दबाए रखें तो चालू climate control बंद भी हो सकता है। समस्या यह है कि यह सब उस स्थिति में करना पड़ता है जब गाड़ी चलाते हुए सड़क भी देखनी होती है
    हाथ-आँख का तालमेल थोड़ा भी बिगड़ जाए, और ड्राइविंग के दौरान उबड़-खाबड़ रास्ते पर यह बहुत संभव है, तो 1mm चूकने पर भी कोई दूसरा बटन दब सकता है और अनचाहा action हो सकता है
    एक और आपदा है Bluetooth डिवाइस कनेक्शन UX। कम से कम 2012~2022 Model S का implementation उन सबसे बदतर UI मिश्रणों में से एक था जो मैंने किसी shipping product में देखे हैं। नीचे दाईं ओर का बटन कनेक्ट हो जाने के बाद भी “Connect” ही दिखाता रहता है, जबकि स्क्रीन के दूसरी तरफ़ ऊपर बाईं ओर “Connecting...” दिखता है और फिर connection complete होने का संकेत देता है
    यह भी कार का UI है, इसलिए ड्राइविंग के दौरान इसे बस एक झलक ही देख सकते हैं। सिर्फ़ Tesla के Bluetooth UI पर ही UI की किताब का एक पूरा अध्याय लिखा जा सकता है, इतनी शानदार तरह से यह ख़राब है

    • Tesla mobile app में साथ-साथ मौजूद toggle भी आपस में consistent नहीं हैं
      बंद ताला यह दर्शाता है कि दरवाज़ा locked है, और दबाने पर वह unlock हो जाता है
      ट्रंक पर लिखा “Open” यह दर्शाता है कि ट्रंक बंद है, और दबाने पर ट्रंक खुल जाता है
    • ऐसे लेख लोग ख़ुद लिखें तो अच्छा होगा। इस तरह का analysis हमेशा दिलचस्प होता है, और अगर विषय Tesla हो तो Elon की वजह से और भी ज़्यादा ध्यान मिल सकता है
    • मैं climate control बटन का इस्तेमाल ऐसे करता हूँ: पहले बटन को देखता हूँ, अगर वह थोड़ा transparent दिख रहा हो और मुझे उसे चालू करना हो, तो बस click करता हूँ और वह चालू हो जाता है। फिर से click करूँ तो पूरा control खुल जाता है, और नीचे swipe करूँ तो बंद हो जाता है
      अगर बंद करना हो, तो फिर से बटन दबाकर पूरा control खोलता हूँ और off बटन दबाता हूँ। तापमान बदलने के लिए बटन पर click करके बाएँ-दाएँ swipe करके ऊपर या नीचे करता हूँ
      मुझे यह काफ़ी intuitive लगता है। अगली बार ड्राइव करते समय long press करके बंद करने वाला तरीका भी आज़माऊँगा, वह काफ़ी उपयोगी लग रहा है
    • 2023 Model Y में Bluetooth सच में अच्छी तरह काम करता है। पुरानी Audi और Ford में ऐसा नहीं था, इसलिए यह संतोषजनक है
      implementations को बार-बार इतना ख़राब देखते हुए लगता है कि शायद Bluetooth spec में ही कोई गंभीर गड़बड़ी है
    • यह ग़ैरकानूनी होना चाहिए

  • पहले मेरे पास कुछ NASA push button switches थे, जिनके अंदर दो bulbs लगे होते थे। स्विच बंद होने पर दोनों बंद रहते, और बटन दबाने पर पीला bulb जल उठता, जो दिखाता कि स्विच ऑपरेशन दर्ज हो गया है
    फिर जब वास्तव में चालू किया जाने वाला device चालू हो जाता, तो हरी बत्ती जलती और पीली बुझ जाती। यानी पीली स्थिति इस बात की पुष्टि है कि स्विच टॉगल किया गया, और हरी इस बात की कि चाहा गया action सचमुच हुआ — यह एक दिलचस्प state feedback mechanism है

    • यह अच्छा तरीका है, और aircraft भी ऐसा ही करते हैं[1]। ऐसे मुद्दे usability को बहुत महत्व देने वाले लोग पहले ही हल कर चुके हैं, लेकिन computer industry दूसरे क्षेत्रों से ऐसी चीजें अपनाने में धीमी रही है
      स्विच के बाहर label रखने का तरीका भी अच्छी तरह काम करता है[2]
      [1]: https://my737ng.com/wp-content/uploads/2014/08/cp_mcp_header...
      [2]: https://i.pinimg.com/originals/2c/37/0a/2c370a3f4018cfa9c3ef...
    • अपने शुरुआती करियर का बड़ा हिस्सा मैंने remote hardware को control करने और उसकी स्थिति दिखाने वाला GUI software लिखने में बिताया, और जल्दी ही मैंने state को खुद संभालकर रखने वाले UI elements को पूरी तरह हटाना शुरू कर दिया। toggle, switch, checkbox, radio button जैसे elements, जो अपनी state के हिसाब से behavior बदलते हैं, उनमें interface और hardware state का mismatch होना असामान्य नहीं था
      इसके बजाय, मैंने हर option के लिए अलग button रखा, और current state वाले button को lit होने दिया। उदाहरण के लिए, on/off toggle को “on” और “off” दो buttons में बदल दिया। शुरुआत में दोनों grey रहते, और hardware से state on होने का SOH मिलता तो on button हरा हो जाता, off होने पर off button लाल
      अगर communication कुछ समय के लिए कट जाए, तो सभी रंग fade कर दिए जाते ताकि पता चले कि state पुरानी हो चुकी है। button दबाने पर, नई state वापस आने तक पुरानी state दिखती रहती, लेकिन सिर्फ उसी button group को faded दिखाया जाता
      user, UI जो भी state मान रहा हो, कभी भी सीधे on या off command दे सकता था। जबकि toggle सिर्फ “दूसरी state” में ही बदल सकता है
      radio buttons को भी state नाम वाले buttons के समूह में बदल दिया, और UI जिस item को current मानता था, सिर्फ उसी पर रंग दिखाया। ज़्यादातर neutral states के लिए नीला रंग, और जहाँ operator किसी अच्छी/चेतावनी/खराब स्थिति पर ज़ोर देना चाहता था, वहाँ हरा/पीला/लाल इस्तेमाल किया
      यह unusual design था, लेकिन operators ने आम तौर पर बिना किसी अलग training के इसे समझ लिया। buttons, buttons जैसे दिखते थे इसलिए clickable लगते थे, spacing से group साफ़ दिखता था, और 90s की UI में grey default होने के कारण अलग रंग वाला button स्वाभाविक रूप से current state के रूप में उभरकर दिखता था
      आजकल, जब UI elements में aesthetic reasons या conversion drive करने के लिए कोई भी रंग इस्तेमाल हो जाता है और सिर्फ कभी-कभार ही जानकारी दी जाती है, तब भी यह उतना कारगर होगा या नहीं, कहना मुश्किल है। NASA button की तरह command state और received state दोनों एक साथ दिखाने के experiments भी किए, लेकिन वे सब और ज़्यादा confusing निकले
    • यह पसंद आया। समझ नहीं आता कि aviation/military domains, जहाँ गलतफ़हमी लोगों की जान ले सकती है, उनसे हमारी industry ज़्यादा बार सीख क्यों नहीं लेती

  • हे checkbox, 1990~2009। तुम परफ़ेक्ट और unambiguous थे, लेकिन न जाने क्यों smartphone designers तुम्हें नापसंद करते थे

    • और मज़ेदार बात यह है कि असल में checkbox जैसी चीज़ को काफ़ी सुंदर और toggle-जैसा दिखाया जा सकता है। यह कोई बेहतरीन example नहीं है, लेकिन यह दिखाता है कि उसमें ज़रूरी नहीं कि check mark वाला चौकोर box ही हो: https://www.ranecommercial.com/legacy/hal/MobileHelp/Advance...
    • जिस medical video consultation/telemedicine system का मैं उपयोग करता हूँ, उसने checkbox को बिगाड़ दिया है। direct message interface में checkbox field का label checked है या नहीं, उसके अनुसार बदल जाता है
      unchecked होने पर “Not Urgent”, checked होने पर “Urgent” दिखता है। मैंने कई बार तेज़ी से check किया, यह सोचकर कि मैंने not urgent दिखा दिया है, और फिर send दबा दिया
    • मैं इस बात से सहमत हूँ कि checkbox परफ़ेक्ट है। हालाँकि यह इसलिए भी हो सकता है कि मैं smartphone पर forms भरना पसंद नहीं करता
      browser के default checkboxes smartphone पर अंगूठे से दबाने के लिए बहुत छोटे होते हैं, इसलिए उनका बार-बार उपयोग करना मुश्किल है
    • checkbox widget किसने बनाया था? System 1 (1984) में menu के check mark के बराबर एक “x box” था, लेकिन जहाँ तक मुझे पता है, checkbox खुद नहीं था
    • क्या Jony Ive design जगत के Thomas Midgley Jr हैं? उन्होंने iOS 7 के साथ कम-usable flat design को popular बनाया, और गोल iMac mouse तथा आसानी से टूटने वाले MacBook keyboard के लिए भी ज़िम्मेदार हैं

  • मैंने जो सबसे बुरा उदाहरण देखा है, वह Tesla dashboard screen UI है। कार की तस्वीर पर labels लगे हैं जो button जैसे नहीं दिखते, और उन पर “Open” लिखा है
    इसे साफ़ तौर पर ऐसे पढ़ा जा सकता है कि वह हिस्सा खुला हुआ है, लेकिन असली मतलब वह नहीं है। वह label उस हिस्से को खोलने का button है, और user के पास यह जानने का कोई तरीका नहीं होता

    • सही है। मैंने इस weekend किराए की Tesla चलाई, और कई बार भ्रमित और परेशान हुआ क्योंकि मुझे लगा कि front और rear trunk दोनों खुले हुए हैं
    • 100% सहमत। Tesla trunk UX में यह दूसरी सबसे frustrating बात है। पहली है park mode में जाने के बाद trunk खोलने के लिए इंतज़ार कराना — वह बेहद लंबा animation
      कुल मिलाकर Tesla UX दूसरी कारों से बहुत आगे है, लेकिन ऐसी छोटी चीज़ें बेहद परेशान करती हैं
    • मुझे तो यह बिल्कुल confusing नहीं लगता। rendered car trunk की current state साफ़ दिखाती है, और open button दबाने पर trunk खुलने का animation भी आता है
      लगता है हर व्यक्ति इसे अलग तरह से महसूस करता है
    • दिलचस्प बात यह है कि यह English की समस्या है। English में verb और adjective कई बार एक ही होते हैं। Spanish में “Abrir” (क्रिया का मूल रूप) और “Abierto” (विशेषण) अलग हैं, इसलिए ऐसी स्थिति नहीं बनती
      “Do open” या “Is open” जैसा लिखें तो शायद इससे बचा जा सके, लेकिन क्या यह native speakers को अटपटा लगेगा?
    • क्या यह सिर्फ English की विशेषता है? उदाहरण के लिए, Spanish में verb और adjective अलग-अलग शब्द होते हैं

  • टॉगल बटन की मूल समस्या यह है कि एक ही ऑब्जेक्ट में सिस्टम की स्थिति और उसे बदलने वाली क्रिया दोनों समा जाती हैं
    इसलिए बटन पर दिखने वाला “ON” वर्तमान स्थिति है या दबाने पर होने वाली क्रिया, यह स्पष्ट नहीं होता
    इसका समाधान स्थिति और क्रिया को कुछ हद तक अलग करना है। इसके कई तरीके हैं; लिंक किए गए जवाबों में से एक की तरह, लेबल को बटन के बाहर लिखना एक तरीका है
    अगर वह स्विच नहीं बल्कि Teams वाले उदाहरण जैसा टॉगल बटन है, तो आइकन को वैसा ही रहने दें और बटन की दूसरी विशेषताएँ बदलें। उदाहरण के लिए, जैसा दशकों से बिना समस्या किया जाता रहा है, उसे दबी हुई अवस्था में रहने दें ताकि “ON” स्थिति दिखाई दे

    • Windows 11 की system sound properties में “Allow apps and Windows to use this device for audio” विकल्प है, और उसके बगल में “Don't allow” बटन है। इसलिए वर्तमान स्थिति क्या है, यह बिल्कुल समझ नहीं आता

  • मैं निष्कर्ष से सहमत हूँ, लेकिन वर्तमान स्थिति क्या है और टॉगल बदलने पर कौन-सी स्थिति बनेगी, दोनों ही स्पष्ट होने चाहिए। बहुत बार ऐसा हुआ है कि टॉगल बदलकर ही पता चला कि बदलने की ज़रूरत ही नहीं थी
    play/pause वाला बिंदु दिलचस्प है, क्योंकि वह निष्कर्ष के उलट दिखता है। लेकिन वह एक अच्छी तरह समझे गए भौतिक precedent का पालन करता है, और आम तौर पर यह भी स्पष्ट होता है कि संगीत या वीडियो चल रहा है या नहीं। इसलिए भले ही बटन आइकन न बदले, उपयोगकर्ता समझ सकता है कि दबाने पर क्या होगा
    टॉगल और UI पर लौटें, तो टॉगल का रंग हल्के ग्रे से थोड़ा और हल्के ग्रे में बदलना बिल्कुल भी मददगार नहीं है। कृपया लेबल लगाइए। अगर लेबल आपके design motif से मेल नहीं खाता, तो बेहतर designer ढूँढिए

    • अगर भौतिक precedent का पालन करना है, तो बटन की छवि को क्रिया, यानी play, दिखानी चाहिए थी, और उसके दबे/न दबे visual state से यह दिखाना चाहिए था कि वह क्रिया सक्रिय है या नहीं
      software designers ने इसका पालन नहीं किया और play/pause आइकनों को एक-दूसरे में बदलने का तरीका बना दिया, जिससे नई उलझन पैदा हुई। यह user-friendly कारणों से कम, और skeuomorphic 3D बटन के फ़ैशन से बाहर हो जाने की वजह से ज़्यादा हुआ
      स्थिति-सूचक तरीके का एकमात्र लाभ तब होता है जब कोई समस्या हो। खासकर audio में यह बहुत आम है। mute, headphone disconnect, Linux audio driver का फिर से टूट जाना जैसी स्थितियाँ
      आज भी play/pause बटन देखकर मुझे हल्का cognitive dissonance होता है, और pause बटन का सही मतलब क्या है, इसे लेकर 100% भरोसा नहीं होता, इसलिए समस्या होने पर मैं बस दो बार दबाकर देख लेता हूँ
    • मैं इस बात से सहमत हूँ कि वर्तमान स्थिति स्पष्ट होनी चाहिए। light switch में यह जानने की ज़रूरत नहीं होती कि कौन-सी दिशा “on” है, और वास्तव में लोग यह नहीं जानते। क्योंकि बस यह देखना काफ़ी है कि बत्ती जल रही है या नहीं
    • “लेबल लगाइए, और अगर लेबल design motif से मेल नहीं खाता तो बेहतर designer ढूँढिए” वाली बात खासकर mobile पर मददगार नहीं और अवास्तविक है
      उदाहरण के लिए Spotify में हर बटन के पीछे लेबल लगाने की जगह नहीं है। album art दिखाने की जगह भी चाहिए, और मैं वह चाहता हूँ
      यह बेहतर designer का सवाल नहीं है; जगह की सीमाएँ सचमुच होती हैं। कुछ फ़ीचर एक टैप में तुरंत उपलब्ध होने चाहिए। मैं shuffle को popup menu के पीछे छिपाना नहीं चाहता

  • टॉगल बटन को वर्तमान स्थिति दिखानी चाहिए। checkbox इसका अच्छा उदाहरण है
    Muted [] और Muted [x] काफ़ी स्पष्ट हैं
    मुश्किल तब होती है जब designer ऐसा UI बनाता है जिसमें शब्दों और visual design का रिश्ता स्पष्ट नहीं होता। जैसे Mute Off [---( )], Mute On [( )---] जैसी चीज़ें स्थिति के वर्णन में क्रिया मिला देती हैं, इसलिए समझ नहीं आता कि मतलब क्या है

    • अगर पर्याप्त जगह हो तो दोनों तरफ़ लेबल वाले टॉगल की नकल अच्छी तरह काम करती है
      Loudspeaker [()---] Crossed-out loudspeaker
    • check mark एक tick है[1]। status page[2] पर tick का मतलब “काम कर रहा है” होता है और cross विफलता को दर्शाता है। “स्पष्ट” होने के नज़रिए से देखें तो Muted [x] का अर्थ यह निकाला जा सकता है कि कुछ विफल हो गया
      इसे अलग तरह से समझने के लिए computer UX की सीखी हुई समझ चाहिए, और यह स्पष्टता के उलट है। या फिर इसका मतलब यह भी लिया जा सकता है कि “X marks the spot” की तरह यह वही चीज़ है जिस पर mute करने के लिए क्लिक करना है
      [1] Unicode U+2714 https://www.compart.com/en/unicode/U+2714
      [2] e.g. https://www.githubstatus.com/
    • checkbox वर्तमान स्थिति और उपलब्ध विकल्पों को एक साधारण yes/no रूप में साथ दिखाता है
      टॉगल बटन उलझन पैदा करते हैं क्योंकि designer की मंशा पता नहीं चलती। जब तक दोनों विकल्प साथ न दिखें, समझना मुश्किल है
      Mute On[---()]Off
    • बटन को यह बताना चाहिए कि क्लिक करने पर वह क्या करेगा। अगर आप वर्तमान स्थिति दिखाना चाहते हैं, तो वह अलग indicator है, बटन नहीं
      बटन का अस्तित्व क्लिक किए जाने के लिए है, इसलिए उसे यह बताना चाहिए कि क्लिक करने पर क्या होगा
    • दाएँ से बाएँ लिखी जाने वाली लिपियों में क्या दोनों तरफ़ भी उलट जानी चाहिए?

  • analog switch की तरह, दोनों चीज़ें दिखानी चाहिए। वर्तमान स्थिति भी साफ़ और बिना भ्रम के दिखे, और साथ ही यह भी दिखे कि बदलने पर कौन-सी स्थिति बनेगी
    Apple का left-right slider toggle यह काम बहुत अच्छी तरह करता है। टॉगल इस समय कहाँ है, कहाँ जाएगा, और वर्तमान setting ने फ़ीचर को enabled किया है या नहीं, यह नीले background से, और disabled है या नहीं, यह ग्रे background से साफ़ दिखाई देता है

  • मुझे पसंद आए डिज़ाइनों में से एक वह था जिसमें switch के बगल में status light होती थी, और स्थिति on होने पर वह light जलती थी, लेकिन अब वह नहीं मिल रहा
    इसकी सबसे अच्छी बात यह थी कि इसने asynchronous काम में होने वाली देरी की समस्या भी हल कर दी थी। स्विच दबाते ही स्विच टॉगल हो जाता था, और थोड़ी देर बाद light जलती थी। यह बहुत संतोषजनक था क्योंकि interaction से भरोसा मिलता था कि सचमुच कुछ हुआ है

    • असली design देखे बिना, यह भी लेख में चर्चा की गई ambiguity का उदाहरण लगता है। यह स्पष्ट नहीं है कि आइकन आगे होने वाली चीज़ दिखा रहा है या इस समय हो रही चीज़
      समस्या यही है कि वह स्थिति है या क्रिया। कोई खास design शायद अस्पष्ट न रहा हो, लेकिन सिर्फ़ विवरण से तो यह अस्पष्ट है
    • अगर आप बहुत समय बाद उस page पर लौटें और light जलती हुई दिखे, तो आप कैसे जानेंगे कि इसका मतलब वर्तमान स्थिति ON है, या क्लिक करने पर ON हो जाएगी? क्या सिर्फ़ जली हुई light देखकर तुरंत फ़र्क़ समझने का कोई तरीका है?
    • यह कुछ वैसा लगता है जैसा “smart” devices के interface feature में दिखता है। मैं केवल TP-Link Kasa switch से परिचित हूँ, लेकिन उसके app UI में भी कुछ ऐसा ही है, जहाँ रंगीन आइकन कई स्थितियाँ दिखाते हैं, और जो स्थिति “on” के सबसे करीब लगती थी, वह switch से मिलान करके यही बताती थी कि वह चालू है
    • HDR screens के लिए यह अच्छा उपयोग-मामला लगता है। “indicator light” को स्क्रीन के बाकी हिस्से से कहीं ज़्यादा चमकीला बनाया जा सकता है, जिससे अब यह बहुत स्पष्ट हो जाता है कि light जल रही है
      हालाँकि यह तभी काम करेगा जब उपयोगकर्ता ने पहले से स्क्रीन की brightness बहुत ज़्यादा न कर रखी हो