आइए idiomatic design को फिर से ज़िंदा करें

 (essays.johnloeber.com)
1 पॉइंट द्वारा GN⁺ 19 일 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • उपयोगकर्ता को तुरंत समझ आने वाले design idioms सीखने का बोझ कम करते हैं और एकसमान interaction संभव बनाते हैं
  • अतीत के desktop software युग में operating system और guidelines की वजह से menu structure और shortcuts जैसे interfaces एकरूप थे
  • इसके विपरीत browser-based software युग में frameworks और custom implementations के फैलाव से interface की consistency टूट गई
  • Apple और Substack सीमित customization और एकीकृत design system के साथ आधुनिक idioms की सफलता के उदाहरण दिखाते हैं
  • product designers को मौजूदा idioms का पालन करना चाहिए और clarity तथा consistency को प्राथमिकता देकर पूरे web में standardized user experience की ओर बढ़ना चाहिए

डिज़ाइन idioms

  • checkbox को ऐसे प्रतिनिधि design idiom के रूप में प्रस्तुत किया गया है जिसे उपयोगकर्ता बिना अलग से सीखे तुरंत समझ सकता है
    • login बनाए रखना है या नहीं, यह पूछने के लिए कई input methods संभव हैं, लेकिन व्यवहार में लगभग हमेशा checkbox ही इस्तेमाल होता है
    • यह उपयोगकर्ता और developer दोनों के लिए परिचित standardized interaction pattern की तरह काम करता है

एकरूप interfaces

  • interface वह माध्यम है जिससे उपयोगकर्ता system के साथ interact करता है, और जितना कम सोचना पड़े, उतना बेहतर interface माना जाता है
    • उदाहरण के लिए, Command+C shortcut से copy करने की सुविधा हर जगह एक जैसी काम करनी चाहिए
  • लेकिन मौजूदा web software environment में interface consistency गायब हो गई है
    • date selection, card number input जैसी बुनियादी सुविधाएँ भी हर site पर अलग तरह से implement की जाती हैं
    • shortcuts और interaction methods हर app में अलग होने से उपयोगकर्ता को हर बार फिर से सीखना पड़ता है कि “कहाँ क्या दबाना है”

desktop software युग

  • Windows 95~7 काल का desktop software उच्च interface consistency बनाए रखता था
    • “File, Edit, View” menu structure हर program में एक जैसा मौजूद होता था
    • menu items के नीचे की रेखा keyboard shortcut को दर्शाती थी, और ALT+F, N आदि से उन्हें चलाया जा सकता था
    • नीचे का status bar मौजूदा स्थिति (page, word count, mode आदि) को स्पष्ट रूप से दिखाता था
    • text-based menus केंद्र में थे, और icons तभी इस्तेमाल होते थे जब उनका अर्थ स्पष्ट हो
  • ये idioms सिर्फ Microsoft Word तक सीमित नहीं थे, बल्कि पूरे Windows ecosystem में एकरूप थे
    • Windows XP की logout screen में भी हर button को साफ़ तौर पर button की तरह दिखाया जाता था, और shortcuts भी दिखाए जाते थे
  • ऐसी consistency operating system और GUI libraries की सीमाओं की वजह से संभव थी, और Microsoft सैकड़ों पन्नों की design guidelines बाँटता था ताकि developers उनका पालन करें

browser software युग

  • मौजूदा web application युग को heterogeneous interfaces का युग बताया गया है
    • Figma और Linear जैसे उत्कृष्ट web apps में भी common icons या shortcuts नहीं हैं
    • हर app अपने आप में अच्छी तरह design किया गया है, लेकिन interaction patterns एक-दूसरे से अलग हैं
    • एक ही company के भीतर भी Gmail, GSuite और Google Docs का अनुभव अलग-अलग है
    • नतीजतन उपयोगकर्ता productive flow में रहने के बजाय कौन-सा control कहाँ है, यह खोजने में समय बिताते हैं

  • mobile transition का प्रभाव

    • touchscreen के आगमन के साथ mouse और keyboard केंद्रित design patterns को फिर से गढ़ा गया
    • mobile और desktop दोनों को साथ support करने की स्थिति में बीच का अधूरा UI फैल गया
    • उदाहरण: mobile के hamburger menu का desktop पर भी वैसे ही इस्तेमाल होना
    • modular component reuse culture गलत patterns की नकल करके quality गिराती है
    • 10 साल से अधिक समय के संचय के परिणामस्वरूप UI/UX quality का पीढ़ीगत क्षरण हुआ

  • HTML से आगे idioms की कमी

    • शुरुआती web में नीले underline वाले links जैसे स्पष्ट idioms मौजूद थे, लेकिन अब हर site की styling अलग है
    • HTML/CSS standards सख्त हैं, लेकिन व्यवहार में अधिकतर लोग React·TypeScript आधारित build systems इस्तेमाल करते हैं
    • नतीजतन standard HTML elements की जगह custom implementations बेतहाशा बढ़ गए हैं, जिससे accessibility समस्याएँ भी पैदा होती हैं
    • उदाहरण: <a> की जगह onclick लगे <span> का इस्तेमाल, जिससे screen reader functionality टूट जाती है
    • Figma जैसे WebAssembly आधारित apps भी मौजूद हैं जो HTML से पूरी तरह बाहर निकल जाते हैं
    • browser के back button, shortcuts जैसी basic features की अनदेखी होती है, और human-computer interaction का नया paradigm फिर से बनाया जाता है
    • frontend development speed और possibility-केंद्रित ढंग से आगे बढ़ा है, इसलिए consistent idioms का जमना मुश्किल है
    • countless frameworks और interaction formats की मौजूदगी से एकल standard स्थापित करना संरचनात्मक रूप से कठिन हो गया है

idiomatic design की सफलता के उदाहरण

  • Apple को आधुनिक समय में मज़बूत design idioms बनाए रखने वाले प्रतिनिधि उदाहरण के रूप में गिना जाता है
    • fonts, buttons, colors सहित पूरे design system में एकरूपता है, और पूरे iOS में consistent interaction experience मिलता है
    • यही consistency “it just works” जैसा भरोसा पैदा करती है
  • Substack भी सीमित customization और पहले से तय aesthetic defaults के जरिए स्थिर user experience देता है
    • Apple और Substack के design principles सफलता के माध्यम से industry standards में फैलते हैं और अंततः नए idioms के रूप में स्थापित हो जाते हैं

product designers के लिए पालन करने योग्य सिद्धांत

  • product developers के लिए जहाँ तक संभव हो मौजूदा design idioms का पालन करना usability और compatibility बढ़ाने का रास्ता बताया गया है
    • HTML/CSS के मूल idioms का पालन करें: links को underline, color, pointer cursor और <a> tag के साथ implement करें
    • मूल HTML elements को JavaScript से दोबारा implement न करें, उदाहरण: React Button की जगह <button> इस्तेमाल करें
    • browser idioms का पालन करें: back button काम करे, URL copy करने पर वही interface खुले, CTRL+click से नया tab खुले
    • अगर सामान्य idioms से हटना पड़े, तो कम-से-कम संगठन के भीतर consistent rules बनाए रखें
    • text को प्राथमिकता, icons को न्यूनतम, और icons तभी इस्तेमाल करें जब वे सार्वभौमिक रूप से समझे जा सकें
    • visual elements में स्पष्टता, सौंदर्य से पहले होनी चाहिए
    • निर्णय कठिन हो तो उत्कृष्ट websites के उदाहरण और पुरानी interface design books देखें
  • अंततः लक्ष्य ऐसा भविष्य है जहाँ पूरे web में date picker या card input forms एक जैसे काम करें, और कई दशकों की पुनरावृत्ति व सुधार के बाद web सर्वोत्तम idioms की ओर अभिसरित हो

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

1 टिप्पणियां

 
GN⁺ 19 일 전
Hacker News की राय

  • कुछ apps में Enter का मतलब message भेजना होता है और Ctrl+Enter का मतलब line break (जैसे Slack), जबकि कुछ जगह इसका उल्टा होता है (जैसे GitHub)
    ऐसी consistency की कमी user के लिए काफ़ी confusing होती है। लोग कहते हैं “idiomatic design को वापस लाओ”, लेकिन असली समस्या यह है कि साझा idiom ही कम हैं

    • पहले Return और Enter अलग keys हुआ करते थे। Return का मतलब line break था, Enter input submit करने के लिए था।
      अब दोनों एक ही key में मिल गए हैं, इसलिए आम तौर पर multiline input box में Enter line break देता है और Ctrl+Enter submit करता है।
      दूसरी तरफ chat apps में छोटे messages ज़्यादा होते हैं, इसलिए वहाँ इसका उल्टा behavior होता है। अच्छे apps इसे setting से बदलने देते हैं
    • Teams में दो modes हैं। default में Enter से send होता है और Shift+Enter से line break, लेकिन formatting toolbar खोलते ही यह उल्टा हो जाता है।
      कौन-सा combination line break है, यह दिखाया तो जाता है, फिर भी confusion बना रहता है
    • Slack और भी जटिल है। Markdown on हो तो Shift+Enter line break देता है, लेकिन code block(```) के अंदर Enter line break और Shift+Enter send करता है।
      इरादा समझ में आता है, लेकिन usability बुरी तरह बिगड़ जाती है
    • आदर्श समाधान शायद यह होगा कि Ctrl+Enter हमेशा send करे, Shift+Enter हमेशा line break दे, और Enter context के हिसाब से default behavior अपनाए
    • मुझे भी लगता था कि Shift+Enter line break होता है, और यही दिखाता है कि fragmented UX असली समस्या है

  • आजकल software पहले की तरह सोच-समझकर design करने वाले लोग नहीं बना रहे।
    अब अक्सर जल्दबाज़ी में promote हुए PM या product owners नेतृत्व करते हैं, और revenue के लिए dark patterns तक को बढ़ावा दिया जाता है

    • mobile engineer के तौर पर, जब stakeholders से कहता हूँ कि “सिर्फ idea के हिसाब से इसे बना नहीं सकते”, तो अक्सर blank stare मिलता है।
      UX consistency और information architecture (IA) की अहमियत बार-बार समझानी पड़ती है। यह नहीं भूलना चाहिए कि designers भी problem solvers होते हैं
    • यह आलोचना बहुत surface-level है। असल में एक साधारण online form बनाना भी नर्क जैसा हो सकता है।
      जैसे credit card form बनाते समय copy/paste allow करना है या नहीं, पुराने browsers को support करना है, accessibility और security के बीच संतुलन कैसे रखना है—ऐसे अनगिनत factors होते हैं।
      वैसे Steve Yegge का platform वाला लेख इस complexity को अच्छी तरह समझाता है
    • 2010s में experienced UX designers कम होते गए, और print या graphic background वाले non-specialist designers बड़ी संख्या में आए, जिससे quality गिरी
    • बेशक खराब incentives और तंग deadlines भी कारण हैं, लेकिन इसे सिर्फ incompetence या malice कह देना ठीक नहीं। पूरा system ही बदल गया है
    • आज भी जब PM खुद पूरी architecture और release roadmap तक design करने लगते हैं, तो लगता है यह बात ग़लत नहीं है

  • system frameworks ही idiomatic UI की नींव हुआ करते थे।
    Win32, AppKit, UIKit जैसी चीज़ें इतने details संभालती थीं कि developers स्वाभाविक रूप से consistent UX follow करते थे।
    वहीं web में ऐसा आधार नहीं है, इसलिए सब कुछ खुद implement करना पड़ता है, और नतीजा अक्सर आधा-अधूरा UI होता है

    • लेकिन लेखक ने web की inconsistency को थोड़ा ग़लत पकड़ा है। “desktop era” असल में लगभग Windows era था, और Win32 default होने के कारण सब उसी को follow करते थे।
      web शुरुआत से document-centric था, इसलिए कोई standard approach थी ही नहीं; बाद में Bootstrap जैसी चीज़ों ने थोड़े समय के लिए एक तरह का standard बनाया
    • HTML और CSS तो थे, लेकिन आजकल लोग WebAssembly वगैरह से उन्हें bypass कर देते हैं।
      असल में date picker और card input जैसी चीज़ों के लिए native HTML controls इस्तेमाल करने चाहिए।
      तब browser OS-level security और convenience दे सकता है (जैसे Safari में Apple Wallet, Android में Google Pay integration)
    • जो developers OS के consistent behavior के आदी हैं, वे स्वाभाविक रूप से उसी environment की नकल करना चाहते हैं।
      लेकिन web और mobile पूरी तरह अलग boxed environments हैं, इसलिए यह consistency टूट गई।
      उदाहरण के लिए desktop के right-click को mobile के long press से एकरूप बनाने का मौका था, लेकिन इसे consistently आगे नहीं बढ़ाया गया
    • web की बुनियादी समस्या यह है कि वह अब भी document-centric paradigm में अटका हुआ है।
      app UI बनाने के लिए document UI के ऊपर layers चढ़ानी पड़ती हैं, जिससे टकराव पैदा होता है।
      browsers ने इसे थोड़ा कम किया है, लेकिन यह मूल सुधार नहीं है
    • जानकारी के लिए, AppKit में button height बदलना संभव है। बस यह बहुत स्पष्ट नहीं है

  • date picker सच में UX nightmare है।
    अक्सर users को date सीधे type करने से रोका जाता है और ज़बरदस्ती click करवाया जाता है।
    सिर्फ invalid input पकड़ना काफ़ी होना चाहिए, लेकिन लोग इसे बेवजह असुविधाजनक बना देते हैं

    • birthday डालने के लिए जब दशकों पीछे calendar scroll करना पड़ता है, तो जीवन की क्षणभंगुरता महसूस होने लगती है
    • mobile के time pickers भी सब जगह अलग-अलग हैं। कभी एक scroll में 12:00 से 11:50 पहुँच जाते हैं, कभी नहीं।
      analog clock-style picker ज़्यादा intuitive लगता है, अच्छा हो अगर वही standard बन जाए
    • date format भी समस्या है। 03/04/2026 का मतलब 3 March है या 4 March, यह confusing है।
      international users के लिए YYYY-MM-DD format ज़्यादा सुरक्षित है
    • birthday input के लिए future schedule वाले जैसे ही date picker इस्तेमाल करने वाली sites सबसे खराब हैं।
      वे आपको 50 साल पीछे scroll करवाती हैं और सिर्फ उम्र का एहसास कराती हैं
    • हर बार birthday डालते समय scroll करके अपनी उम्र महसूस करना किसी torture जैसा है

  • आजकल UX quality में गिरावट बहुत गंभीर है, खासकर banking websites में।
    hidden scrollbars, बेकार wasted whitespace, flat buttons, confusing icons—इन सबने पुराने desktop UI की तुलना में चीज़ों को कहीं ज़्यादा असुविधाजनक बना दिया है

    • scrollbars छिपाना सच में समझ से बाहर है। लगता है यह सिर्फ “सुंदर दिखाने” के aesthetic कारण से किया जाता है
    • लगता है Material UI ने कई industries पर बुरा असर डाला।
      GCP और Google tools बेवजह complex हैं, और borderless input fields जैसी चीज़ों ने UX को नुकसान पहुँचाया है।
      राहत की बात है कि अब यह style पुराना माना जाने लगा है

  • पुराने Mac से आई एक अवधारणा यह थी कि button text के अंत में ellipsis (…) हो तो उसका मतलब है कि आगे और input चाहिए।
    वहीं बिना ellipsis वाला button click करते ही तुरंत action पूरा कर देता है

  • “icons से ज़्यादा words को prefer करो” वाली बात से सहमत हूँ।
    ज़्यादातर लोग शब्दों को पहचानने में icons से तेज़ होते हैं

    • हाँ, अगर icons असली वस्तुओं को दिखाते हों तो ठीक है, लेकिन आजकल बहुत ज़्यादा abstract और linear icons हैं।
      text label न हो तो उनका मतलब समझना almost Russian roulette जैसा हो जाता है
    • HN के “unvote/undown” की तरह, जहाँ prefix एक जैसे होने से भ्रम होता है, वहाँ हर click पर फिर से देखना पड़ता है
    • अगर icons छोटे हों या उनकी position बार-बार बदलती हो, तो words बेहतर हैं; लेकिन fixed environment में icons तेज़ भी हो सकते हैं

  • हाल ही में मैंने CSS नाम की एक नई technology खोजी, जिसमें declaratively layout define किया जा सकता है और DOM-based hierarchical styling apply की जा सकती है।
    इससे client और server load कम हो सकता है, stylesheets share की जा सकती हैं, और user-specific themes भी आसानी से बनाई जा सकती हैं।
    मैं इसे “no-framework” UI paradigm कहना चाहूँगा
    उदाहरण image

    • इस्तेमाल किया है, और यह पूरा nightmare था। कौन-सा style कहाँ apply हो रहा है, पता नहीं चलता, और DOM structure बदलते ही styles बुरी तरह टूट जाते हैं।
      ऊपर से “client load कम” होना सिर्फ एक myth है। व्यवहार में यह और धीमा है
    • यह idea vanilla-js framework team को suggest करना चाहिए

  • वे common features जिन्हें हमने खो दिया:
    Undo/Redo, help (F1), mouse-over hints, shortcut customization, main menu, file/directory, ESC से close करना, drag-and-drop वगैरह
    जो कभी innovative features थे, वे अब mobile और web में लगभग गायब हो चुके हैं

  • कई समस्याएँ इसलिए हैं क्योंकि visual designers product design में आ गए।
    design roles का घालमेल अब तक सुलझा नहीं है, और हक़ीक़त यह है कि कई projects में जहाँ “designer” की ज़रूरत ही नहीं होती, वहाँ भी बहुत ज़्यादा designers लगा दिए जाते हैं