मेरे controls मत छिपाइए: छिपे हुए interface controls usability को प्रभावित करते हैं

• छिपे हुए controls के कारण user interface की usability कम हो जाती है
• अतीत में स्क्रीन पर दिखने वाले menus ने usability को बहुत बेहतर बनाने वाले turning point की भूमिका निभाई
• हाल के mobile और विभिन्न devices में फिर से memory-based operation की मांग करने वाली दिशा में वापसी देखी जा रही है
• interface design की complexity और aesthetic factors, छिपे हुए controls के बढ़ने के मुख्य कारण हैं
• designers को अब सभी मुख्य functions को सामने लाकर ऐसा ढांचा फिर से सोचना होगा जिससे users उन्हें खोज सकें

---

परिचय: ज्ञान का स्थान और interface

• 1960 के दशक में Douglas Engelbart ने ‘ज्ञान दुनिया में है, या दिमाग के भीतर’ जैसी अवधारणा पेश की
• ‘knowledge in the world’ का अर्थ है कि operation controls interface पर दिखाई देते हैं, इसलिए user उन्हें बिना याद किए सीधे खोजकर इस्तेमाल कर सकता है
  • उदाहरण: dropdown menu वाला graphical interface
• ‘knowledge in the head’ का मतलब ऐसा माहौल है जहाँ user को सभी controls और commands याद रखने पड़ते हैं
  • उदाहरण: DOS command prompt में अगर commands (DIR आदि) न पता हों, तो कोई काम ही नहीं किया जा सकता

छिपे हुए controls क्यों बढ़ रहे हैं और उनके दुष्प्रभाव

• जैसे-जैसे interface की complexity बढ़ती है, वैसे-वैसे अधिक controls को दृश्य रूप से छिपाया जा रहा है
• ऊपर से यह अधिक साफ-सुथरा दिख सकता है, लेकिन नए users के लिए इसे चलाना बहुत अधिक कठिन हो जाता है
• शुरुआती दौर में dropdown menus जैसे ‘दिखाई देने वाले controls’ के आने से computers का जन-प्रयोग और productivity में बड़ा उछाल आया
• लेकिन mobile devices और नए electronic devices में फिर से ‘memory map-based’ operation की मांग बढ़ रही है
  • उदाहरण: iPhone में flash light, notifications देखना, Apple Pay चलाना आदि के लिए अक्सर सही ‘hint’ के बिना छिपे हुए actions या विशिष्ट gestures जानना जरूरी होता है

रोजमर्रा की जिंदगी में छिपे हुए controls के उदाहरण

• car wireless key और door handle जैसी चीजों में भी hidden controls होते हैं, इसलिए इस्तेमाल का तरीका न पता हो तो बुनियादी access भी मुश्किल हो सकता है
  • उदाहरण: अंदर की key location, छिपा हुआ keyhole, या किसी खास button sequence की जरूरत
• vehicle navigation systems (जैसे CarPlay पर Apple Maps) में भी map को बड़ा दिखाने के लिए जरूरी controls छिपाने की प्रवृत्ति होती है, इसलिए किसी खास area को touch करना जानना जरूरी हो जाता है
• time-based controls भी hidden controls की तरह काम करते हैं
  • उदाहरण: computer का power button केवल लंबे press पर ही सही shutdown करता है, या electronic door lock में lock करने के लिए अलग key या लंबे press जैसी खास विधि चाहिए होती है

छिपे हुए controls से पैदा होने वाली सामान्य समस्याएँ और expert users पर असर

• volume को 0 करने पर भी app का मनमाने तरीके से sound बजाना जैसी स्थिति में ‘छिपी हुई settings’ user के सीधे command को override कर देती हैं
• advanced users भी command-based interfaces (जैसे R, DOS window आदि) में गंभीर ‘knowledge in the head’ निर्भरता का अनुभव करते हैं
• धीरे-धीरे अधिक primitive interfaces की ओर वापसी का रुझान दिख रहा है

छिपे हुए controls क्यों बढ़ते जा रहे हैं

• functions इतने अधिक हो गए हैं कि सब कुछ स्क्रीन पर दिखाना संभव नहीं, इसलिए visibility घटती है
• system modes के बीच interaction, बढ़ती complexity, और designers की aesthetic preference या implementation convenience के कारण controls को छिपाना आम होता जा रहा है
• वास्तव में यह अक्सर user consideration से अधिक design goals (जैसे visual polish) को प्राथमिकता देने का परिणाम है

सफल उदाहरण और mission-critical systems का अंतर

• General Motors navigation जैसे कुछ systems सभी जरूरी controls को हमेशा स्क्रीन पर स्पष्ट रखते हैं, जिससे beginners भी आसानी से खोज सकते हैं
  • उदाहरण: Buick LaCrosse में physical dial के जरिए zoom function
• mission-critical systems (aircraft, factories आदि) में लगभग हमेशा स्थायी रूप से दिखाई देने वाले controls के आधार पर design किया जाता है
  • कोई भी hidden controls के कारण तेज operation में बाधा आने का जोखिम नहीं उठाता

hidden interface के पक्ष में तर्क और उनकी सीमाएँ

• hidden controls केवल पीढ़ियों के बीच शिकायत का मामला नहीं, बल्कि एक वास्तविक usability समस्या हैं
• कुछ लोग ‘hidden features’ की खोज को ही advantage बताकर प्रचार करते हैं, लेकिन वास्तव में accessibility में गिरावट साफ दिखाई देती है
• user के नज़रिए से जो control खोजा ही न जा सके, वह लगभग अस्तित्वहीन है

ubiquitous computing और controls का automatic/transparent होना

• Mark Weiser और Donald Norman ने ऐसे भविष्य की कल्पना की थी जहाँ technology ‘transparent’ होकर background में चली जाए
  • उदाहरण: car engine control पूरी तरह background में अपने-आप adjust हो, ताकि user को उसे चलाना न पड़े
• automation के कारण controls का पूरी तरह छिप जाना कुछ मामलों में जरूरत और context के लिहाज से उचित है
  • लेकिन जहाँ user interaction जरूरी है, वहाँ explicit controls भी जरूरी हैं

निष्कर्ष और interface designers के लिए दिशा

• interface designers को hidden controls के उपयोग से बचना चाहिए और सभी functions को ‘knowledge in the world’ आधारित रूप में बदलना चाहिए
• control discoverability अब भी एक मुख्य design principle है
• आधुनिक interfaces में discoverability का कम होना, दरअसल शुरुआती computer युग की ओर पीछे लौटना है

संदर्भ

• Engelbart, D.C. (1962) आदि प्रमुख साहित्य का संकलन
• Apple Macintosh, The Psychology of Everyday Things, The Invisible Computer जैसी संबंधित पुस्तकों और शोध-पत्रों का उल्लेख

लेखक जानकारी

• Philip Kortum: Rice University में psychological sciences के professor, जो usability और trust evaluation, global health, mobile systems आदि विविध क्षेत्रों में usability-centered system development पर शोध करते हैं

[GN⁺]

Hacker News राय

• हाल के hidden scrollbar डिज़ाइन में असुविधा महसूस करने वाले user experience साझा किए गए, और लेख में दिए कुछ intuitive physical knob उदाहरणों के बारे में कहा गया कि उनमें cost और practicality की सीमाएँ हैं; साथ ही toggle switch के label का मतलब current state नहीं बल्कि वह state होना जिससे वह बदलेगा, इस वजह से भ्रम महसूस हुआ
  • वास्तविक toggle switch भी अस्पष्ट होते हैं इसलिए पसंद नहीं; checkbox या pressed button कहीं अधिक स्पष्ट हैं, लेकिन modernization के दौर में उनका त्याग होना खलता है
  • ऑस्ट्रिया के train ticket vending machine में instant validation toggle switch ने भ्रम पैदा किया था; scrollbar भी इतने पतले हो गए हैं कि मानो FPS game जैसी skill चाहिए, और कभी-कभी horizontal scrollbar अधिक सुविधाजनक होता है; Firefox और CSS standards पर भी तंज
  • macOS में system settings या terminal command से scrollbar हमेशा दिखाने की संभावना की जानकारी
  • अगर toggle किसी action को दर्शाता है, तो उसमें verb ("TURN ON") ज़रूर होना चाहिए ताकि बात स्पष्ट हो; अगर वह state दिखाता है, तो "IS ON" जैसी साफ़ wording बेहतर है; संदर्भ के कुछ बहुत कम भ्रमित करने वाले मामलों को छोड़ दें तो verb का उपयोग लगभग हमेशा स्पष्टता देता है
  • PgUp और PgDn support भी चाहिए
• एक पुरानी Toyota चलाने का अनुभव साझा किया गया, जिसमें हर control हमेशा दिखता है, स्पष्ट label के साथ है, और उँगलियों से अलग पहचाना जा सकता है; इसे आसानी से दोहराया जा सकने वाला और न्यूनतम engineering वाला डिज़ाइन बताया गया, जबकि आज के अधिकांश car makers यह भी नहीं कर पाते—इसे उनकी skill की कमी माना गया
  • कुछ हद तक सहमति है, लेकिन "सभी controls दिखने चाहिए" कहना designers को कम करके आँकना है; व्यवहार में driving के दौरान ज़रूरी controls ही सामने होते हैं, बाकी छोटे, जटिल, या hidden होते हैं; seat height adjustment lever, bonnet open lever आदि hidden होते हुए भी accessible हैं; इस तरह के details को ध्यान में रखकर design करना न तो सरल है न trivial, और इसे हल्के में लेना ही शायद आज UX खराब होने का एक कारण है
  • इसे skill नहीं बल्कि cost का मुद्दा माना गया; आजकल कई अलग-अलग button और knob बनाकर assemble करने से touchscreen सस्ती और बनाना आसान पड़ती है
  • अमेरिकी car manufacturers से systems developer hiring offers बहुत मिलीं, लेकिन Hacker News community में राय थी कि “mental health बचानी है तो दूर रहो”
  • व्यक्तिगत रूप से भी समझाया गया कि knob जैसे mechanical parts को अलग-अलग बनाना पड़े तो custom molds जैसी manufacturing cost बढ़ती है; screen में डाल देना लागत के हिसाब से कहीं अधिक efficient है
• screen space efficiency के लिए UI elements छिपाना समझ में आता है, लेकिन जगह खाली छोड़कर छिपाना समझ से बाहर है; IntelliJ में project tree के ऊपर icons hidden रहते हैं और mouse hover करने पर ही दिखते हैं—इसे ऐसे बनाने की ज़रूरत थी या नहीं, इस पर सवाल
  • mobile, desktop, laptop screens अब पहले से कहीं बड़ी हैं, फिर भी screen elements छिपाने का तर्क संदिग्ध लगता है; 1984 Macintosh की छोटी black-and-white screen में भी clarity और visibility के लिए screen ratio की कुर्बानी देकर button रखे जाते थे, यह याद दिलाया गया
  • कुछ लोग visual “noise” से focus टूटने की शिकायत करते हैं, जबकि दूसरे लोग dashboard की तरह सभी controls और indicators हमेशा देखना चाहते हैं; IDE defaults इन दोनों अतियों के बीच संतुलन बनाने की कोशिश करने वाला समझौता हैं; कुछ tools “no distractions mode” जैसी detailed settings भी देते हैं
  • IntelliJ के Windows version में menu भी hamburger icon के अंदर छिपा है, जिससे खाली जगह ज़्यादा दिखती है; अच्छा है कि settings में इसे वापस लाया जा सकता है, लेकिन default समझ से परे है
  • कभी-कभी button के बारे में पता होने और उसके दिखने का तरीका याद होने के बावजूद, वह कहाँ था यह भूलकर बस खाली नज़र से screen देखते रहने की स्थिति बनती है
  • कुछ apps तो अतिरिक्त buttons छिपाते भी नहीं; उल्टा मन करता है कि उनमें hide करने का option होना चाहिए—Google Maps का ज़िक्र
• car smart key इस्तेमाल करते समय असली key hidden होना, और यहाँ तक कि door handle खोलकर ही keyhole मिलना—इसे महत्वपूर्ण controls को छिपाने वाली बेहद user-unfriendly engineering कहा गया
  • किसी ने rental car में ऐसा ही अनुभव साझा किया; remote key खराब हो गई थी और सारा सामान car में बंद रह गया; physical key होने का पता था, लेकिन door handle के आसपास पिछले user द्वारा खोलने की कोशिश में पड़े खरोंच के निशानों से ही keyhole की जगह समझ आई
  • इसके जवाब में कहा गया कि ऐसी बातें user को बुनियादी रूप से पता होनी चाहिए और Google आदि पर जानकारी मिल सकती है; नई car मिलते ही backup options और उनके काम करने के तरीके की जाँच करने का उदाहरण देकर, अपने product की मूल समझ का महत्व बताया गया
• iPhone से home button हटने के बाद Android पर जाने का एक कारण यह था कि परिवार के बुज़ुर्गों को समझाना और इस्तेमाल कराना अधिक कठिन हो गया; नया Pixel phone लेते ही 3-button navigation पहले चालू करते हैं, लेकिन आजकल apps bottom navigation bar मानकर चलती हैं और 3-button layout पर content ढक जाता है—यह UI की कमी बताई गई
  • दावा किया गया कि core UI elements हमेशा दिखाई देने चाहिए; Apple भी कभी-कभी इस सिद्धांत का उल्लंघन करता है, लेकिन अक्सर इसका विरोध करता दिखता है; home button हटाना UI element छिपाना कम और interaction बदलना ज़्यादा है—इसकी intuitiveness या quality पर बहस हो सकती है, लेकिन आदत पड़ने के बाद friction बहुत कम रहता है; iOS में एक accessibility feature भी है जिसमें screen पर drag किया जा सकने वाला छोटा गोल shortcut दिखाया जा सकता है, text label के साथ
  • सामान्य software में बिना किसी संकेत के गायब हो जाने वाले menu items की समस्या भी इसी तरह की है; उदाहरण के तौर पर MS Word में read-only file save करने वाला icon पूरी तरह गायब हो गया; इसके बजाय disabled state में रखना और save करते समय कारण बताकर समाधान देना बेहतर अनुभव होगा
  • लंबे समय से Android user होने के बावजूद, कभी-कभी iPhone उधार लेने पर non-intuitive या गायब interactions से झुंझलाहट होती है; Pixel और Samsung camera quality भी अब काफ़ी अच्छी है, इसलिए Apple ecosystem में जाने का कारण नहीं दिखता
• राय दी गई कि लेख में UI के गायब होने को सिर्फ़ accident या mistake नहीं, बल्कि user lock-in का हिस्सा होने की बात पर्याप्त रूप से नहीं उठाई गई; saturated point पर पहुँच चुके software में पुराने users के पलायन को रोकने के लिए UI को non-intuitive तरीके से बदला जाता है; devices को “use” करने की चीज़ नहीं बल्कि “internalized” उपस्थिति बनाकर exit barrier खड़ी की जाती है; UI सीखने की प्रक्रिया के ज़रिए नए product पर जाने का डर पैदा होता है—और यही वजह है कि अधिकतर बड़े software firms यह तरीका अपनाते हैं
  • इस hypothesis को टुकड़ों में देखें तो सही लग सकता है, लेकिन वास्तविकता में “जटिल और भीड़भाड़ वाले interface” के खिलाफ़ प्रतिक्रिया भी बहुत है; minimalism trend और /r/unixporn जैसी communities में भी users खुद controls छिपाते हैं; GNOME आदि में भी हाल में minimal interface मुख्यधारा में है; कई users ज़रूरत पड़ने पर features खोजकर इस्तेमाल करना जानते हैं, इसलिए इसे कुछ हद तक choice का मामला माना गया
  • यह तरीका दोधारी तलवार है, क्योंकि नए users को अपनाने में बाधा भी बनता है; Apple के interfaces का बहुत कुछ एक button पर केंद्रित होना पसंद नहीं, इसलिए Android अधिक परिचित लगता है; Apple के प्रति असंतोष के और भी अलग कारण बताए गए
  • non-profit OSS में भी इस trend का बिना आलोचना के पालन होता दिखता है; Firefox के बार-बार होने वाले design changes और GNOME को भी इसी संदर्भ में देखा गया
• कहा गया कि जब “artist” type designer को UI का निर्णयाधिकार मिलता है, तो वह साफ़-सुथरेपन के जुनून में intuitive usage (affordance) और सीखने के अवसरों को नज़रअंदाज़ कर देता है; airplane cockpit इसका प्रतिनिधि उदाहरण बताया गया—ग़ैर-विशेषज्ञ के लिए भारी, लेकिन विशेषज्ञ के लिए हर चीज़ labeled
  • जवाब में कहा गया कि घर के साधारण पानी के नल पर भी दिशा का label होना ज़रूरी नहीं; airplane cockpit शुरुआती user के लिए उल्टा बहुत ज़्यादा overwhelming है; interface designers अच्छी तरह जानते हैं कि क्या intuitive है और जटिल functions को सरल form factor में समेटने की क्षमता रखते हैं; यह सोचना कि design training न रखने वाला व्यक्ति बेहतर परिणाम देगा, केवल अहंकार और अवमानना है; वास्तव में बिना training के भी आधुनिक smartphone बहुत से users अच्छी तरह चला लेते हैं, यह अपने आप में बड़ी उपलब्धि है
• Hacker News से जुड़ा desktop software पर rant और मौजूदा स्थिति पर सवाल
• अपनी कंपनी के UI design principles में एक सिद्धांत यह है कि keyboard shortcuts और context menus तक पहुँच हमेशा किसी स्पष्ट button या menu से भी संभव होनी चाहिए; यह थोड़ा old-fashioned हो सकता है, लेकिन महत्वपूर्ण है; screen के चारों कोने mouse से जल्दी पहुँचे जा सकने वाले हिस्से हैं, इसलिए UI में अहम होते हैं; Windows 11 में start menu को बीच में ले जाना user inconvenience का उदाहरण बताया गया, हालांकि यह mobile नहीं बल्कि touch-first policy का असर भी हो सकता है
• accessibility और UI की घटती intuitiveness का असर disabled users और बुज़ुर्गों पर बहुत अधिक पड़ता है; touch और gestures भले मुख्यधारा बन गए हों, लेकिन शुरुआती mobile UI उल्टा अधिक accessible थे; अत्यधिक minimal और flat design इस गिरावट का मूल कारण माना गया; palm, compaq pilot, iPod और शुरुआती iPhone UI systems को सकारात्मक रूप से याद किया गया, और उसके बाद की दिशा को regression कहा गया
  • इसके विपरीत, जैसे phone पर HN comments पढ़ते समय कई UI controls छिपे होने से वास्तविक content पर ध्यान केंद्रित करना ज़्यादा सुंदर और आरामदायक लगता है; palm pilot के दौर में buttons और controls screen का आधा हिस्सा घेर लेते थे, जिससे content area कम हो जाता था; hidden controls हमेशा बुरे नहीं होते, और एक बार सीख लेने पर experts के लिए शक्तिशाली tool बन सकते हैं; users से UI सीखने की अपेक्षा कुछ हद तक अपरिहार्य है, और code editor/ git जैसे high-function tools में simplicity और power के बीच trade-off रहता है; हालांकि हाल के समय में हर app द्वारा अपने custom controls बनाने से UI learning की transferability घटती है, यह समस्या है; palm pilot platform की तरह एक बार सीखकर सभी apps में वही pattern इस्तेमाल कर पाना आदर्श माना गया