बस सामान्य वेब फीचर्स

• नए social media platforms और clients, apps, React Native आधारित web ports बढ़ने के साथ ऐसे मामले बढ़ रहे हैं जहाँ websites वे बुनियादी वेब व्यवहार खो देती हैं जिनकी users अपेक्षा करते हैं
• मुख्य कारणों में तेज़ release का दबाव, UI engineers की कमी, mobile touch-first design, और JavaScript से browser के default behavior को replace करने वाली implementations मानी जाती हैं
• text copy, link पर right-click और ctrl + click, browser zoom, responsive layout, :hover और :focus, URL और history updates, scrollbars, ctrl + f जैसे browser के default features वैसे ही काम करने चाहिए
• clickable cards में pointer-events हटाना या layers overlap करना, anchor की जगह div और on-click से navigation कराना सामान्य link experience को तोड़ देता है
• accessibility violations से इसका काफी overlap है, लेकिन web apps को mobile apps जैसा दिखने के बजाय users की अपेक्षित सामान्य वेब सुविधाएँ बनाए रखनी चाहिए

---

websites द्वारा खोए गए basic behaviors

• web projects में अब अक्सर ऐसा होता है कि वे users की अपेक्षित सामान्य वेब सुविधाओं को रोक देते हैं
• नए social media platforms बढ़ने के साथ कई clients और apps बनाए जा रहे हैं, और React Native जैसे tools से platforms के बीच code share करने की कोशिशें भी बढ़ रही हैं
• ये कोशिशें अपने-आप में सकारात्मक हैं, लेकिन image alt text जैसी basic accessibility requirements के साथ-साथ web के सामान्य interaction patterns भी कभी-कभी छूट जाते हैं
• इसके कारणों में ये शामिल हो सकते हैं
  • testable level तक जल्दी launch करने का दबाव
  • project में UI engineer का न होना
  • mobile touch input को प्राथमिकता देकर अन्य input methods या devices को नजरअंदाज करने वाला design
  • JavaScript से browser के default behavior को bypass या replace करने वाली implementation

वे सामान्य वेब फीचर्स जिन्हें बनाए रखना चाहिए

• text copy संभव होना चाहिए
  • clickable card component में pointer-events हटाने या click target layer overlap करने पर text selection और copying रुक सकती है
• link की तरह navigate करने वाले elements को link functionality जस की तस देनी चाहिए
  • right-click से context menu खोलकर link text या address copy किया जा सकना चाहिए
  • Windows के ctrl + click जैसे सामान्य link shortcuts, जो नए tab में खोलते हैं, काम करने चाहिए
  • div पर on-click लगाकर navigate कराने के बजाय anchor element का इस्तेमाल करना चाहिए
• browser zoom करने पर layout नहीं टूटना चाहिए, और user को पढ़ने के लिए zoom कर पाना चाहिए
• responsive web को 1200px से संकरा होते ही सीधे simple mobile layout में गिरने के बजाय, narrow viewport में भी space का उचित उपयोग करना चाहिए
  • Mastodon और Twitter को ऐसे उदाहरणों के रूप में देखा जा सकता है जहाँ browser width संकरी करने पर UI परिचित बना रहता है और space का कुल मिलाकर अच्छा उपयोग होता है
• web apps को :hover, :focus, :active जैसे interaction states सही तरह उपलब्ध कराने चाहिए
  • React Native apps को web पर port करने के मामलों में कभी-कभी :hover या :focus styles नहीं होते, या अजीब तरह से disabled जैसा दिखने वाला :active style दिखाई देता है
• click के बाद अगर UI पूरी तरह नई page जैसा बदलता है, तो browser history और URL भी साथ में बदलने चाहिए
  • अगर independent page जैसी दिखने वाली UI state को link नहीं किया जा सकता और navigation के बाद state गायब हो जाती है, तो usability घटती है
• scrollbars छिपाने नहीं चाहिए
  • users scrollbar पर click करके drag करना चाह सकते हैं
• सामान्य browser shortcuts को app के internal features के लिए hijack नहीं करना चाहिए
  • ctrl + f को custom in-app search box खोलने के लिए बना देने पर page search सामान्य रूप से काम नहीं कर सकती
• accessibility violations माने जा सकने वाले items से इसका काफी overlap है, लेकिन focus इस बात पर है कि web apps users की default browser expectations को न तोड़ें
• छूटे हुए examples पर Mastodon पर आगे बात की जा सकती है

[plastic041]

लगता है कि मुख्य लेख की सामग्री गलत है।

[xguru]

अरे, यह दिलचस्प है। लगता है उस ब्लॉग पोस्ट की क्रॉलिंग खुद ही थोड़ी अजीब तरह से हो रही है.
लगता है crawler वाले हिस्से को एक बार देखना पड़ेगा।

[GN⁺]

Hacker News की राय

• अगर आप पहले React से वेब सीखते हैं और बाद में HTML, तो ऐसा हो सकता है कि आप लिंक के डिफ़ॉल्ट व्यवहार की परवाह ही न करें
  जब मैं टीम में शामिल हुआ, तब सभी लिंक या तो बटन थे, या मनमाने elements, या onClick से handle किए गए थे; किसी ने शिकायत नहीं की, लेकिन Ctrl+click बेकार था और right-click menu भी अपेक्षित विकल्प नहीं देता था
  लिंक के मामले में, मुझे लगता है इसमें समझौते की कोई गुंजाइश नहीं है

  • इस तरह का JS का दुरुपयोग मुझे सच में बहुत नापसंद है, और यह उन चीज़ों को लगातार और ज़्यादा खराब कर रहा है जिन्हें सही तरीके से किया जाना चाहिए
    YC-funded archbee नाम का documentation platform भी search results को नए tab में खोलने नहीं देता, इसलिए आपको current tab में एक result खोलना पड़ता है, नहीं तो back जाकर फिर search करना और अगला result खोलना पड़ता है
    उदाहरण यहां देखा जा सकता है: https://docs.sparklayer.io/
  • नए Reddit web version में सभी links buttons हैं, इसलिए उन्हें नए tab में नहीं खोला जा सकता
    इतने बड़े Internet service में ऐसी साफ़ accessibility problem होना सच में अजीब और पागल कर देने वाला है
  • Twitter की जगह nitter इस्तेमाल करने की लगभग आधी वजह यही है
    account की ज़रूरत न होना भी एक वजह है, लेकिन tweet thread पर right-click करके उसे नए tab में खोला जा सकता है
    Twitter conversations की प्रकृति के कारण, आप अक्सर original page position बनाए रखते हुए कई threads नए tabs में खोलकर देखना चाहते हैं, लेकिन वास्तविक Twitter UI इसे बहुत मुश्किल बना देता है
  • links वाला मुद्दा ऐसा है जिस पर कभी भी अंत तक डटे रहना ठीक है
    इससे ज़्यादा परेशान करने वाली चीज़ें कम ही हैं; अगर कुछ चुनना हो तो browser history को खराब करना
  • जिन sites में list screen और detail screen होती हैं, उनमें जब किसी item पर right-click करके या extension के ज़रिए detail screen को नए tab में नहीं खोला जा सकता, तो यह web usage की आपदा है
    अगर back जाना तुरंत और smooth काम करे तो फिर भी माफ़ किया जा सकता है, लेकिन असल में content reload होने का इंतज़ार करना पड़ता है और scroll position भी खो जाती है
    इससे भी बदतर, Facebook जैसी sites हैं जो कई tabs में एक ही chat popup state force करती हैं। एक tab में बंद करें तो दूसरे tab में भी बंद हो जाता है, जबकि कई tabs खुले रखने की अपनी अलग वजह होती है

• जिस पल आप built-in behavior से छेड़छाड़ करते हैं, मुझे लगता है आप उसकी ज़िम्मेदारी भी अपने ऊपर ले लेते हैं
  आपने जो “feature” बनाया है, वह designer के इरादे वाले संकरे दायरे तक सीमित नहीं रहता, बल्कि visitor को असल में मिलने वाला पूरा अनुभव बन जाता है
  अगर आप back button की logic बदलते हैं, तो आप उस site पर back जाने के अर्थ को ही बदल रहे हैं, और नतीजतन confused और नाराज़ users अगर “टूटी हुई site” कहकर कोसते हैं, तो उसकी ज़िम्मेदारी भी लेनी होगी
  scrollbar जैसी चीज़ों में भी browser और operating system के हिसाब से अलग-अलग behavior होते हैं—क्या आप वाकई उनकी ज़िम्मेदारी लेने के लिए तैयार हैं, यह सोचना चाहिए
  आखिरकार आप website को एक तरह की creole भाषा बोलने पर मजबूर कर देते हैं, इसलिए अगर visitor वह भाषा न समझे या उसे “गलत समझे”, तो हैरानी की बात नहीं
  ऐसी features सिर्फ़ visitor के प्रति दयालु होने के लिए avoid करने लायक नहीं हैं; इनसे मिलने वाला लाभ सीमित है और नुकसान लगभग असीमित लगता है

  • सही बात है। websites लंबे समय में refine हुए design idioms का फायदा उठा रही हैं
    जो sites इन idioms को ignore करती हैं, वे user की परिचित भाषा नहीं बोलतीं, इसलिए उन्हें इस्तेमाल करना कठिन हो जाता है
    design idioms के खो जाने पर विस्तार से लिखा एक लेख भी है: https://loeber.substack.com/p/4-bring-back-idiomatic-design

• मैं इसे websites का app-ification मानता हूं, और अब इसे रुकना चाहिए
  websites को server-side rendering पर वापस जाना चाहिए और जितनी ज़रूरत हो उतनी ही JavaScript जोड़नी चाहिए
  इसके उलट, web apps अगर users को value देती हैं तो UX को थोड़ा ज़्यादा control कर सकती हैं, लेकिन जब तक वे browser के अंदर हैं, basic principles फिर भी लागू रहते हैं
  मैं web apps का समर्थन करता हूं क्योंकि वे app stores की दीवारों के बाहर सभी के लिए accessible development platform हैं, लेकिन हर website को app की तरह treat करना बंद होना चाहिए
  अगर कोई page search engine results में दिखना चाहता है, तो वह web app नहीं, website है

  • raw documents के लिए browser Accept: text/markdown भेज सके तो अच्छा होगा, लेकिन मुझे लगता है CSS आते ही वह जहाज़ निकल चुका था
  • आपको यह लेख पसंद आ सकता है: https://notan.app/
  • “websites को server-side rendering और थोड़े JS पर वापस जाना चाहिए” वाली बात से सहमत हूं
    अच्छी बात है कि React Server Components जैसी चीज़ों की वजह से लगता है websites में JavaScript को थोड़ा-थोड़ा जोड़ने की दिशा में वापसी हो रही है
  • अच्छी web app भी website हो सकती है
    पर्याप्त समय लगाया जाए तो यह हल हो सकने वाली समस्या है

• समझ नहीं आता कि बैंक वेबसाइटें paste क्यों रोकती हैं
  जब तक पता चलता है कि paste नहीं कर सकते, तब तक टेक्स्ट पहले ही कॉपी हो चुका होता है
  हाथ से टाइप करने पर गलती की संभावना ज़्यादा होती है, और अगर क्लिपबोर्ड संक्रमित है, तो paste पर रोक का पता चलने तक कॉपी पहले ही हो चुकी होती है

  • लगता है जैसे “फॉर्म प्रोग्रामिंग का परिचय” जैसी किसी जगह पर copy और paste रोकने वाला कोड मौजूद था, और उस विचार ने पूरे वेब में हजारों वंशज छोड़ दिए
    लोग इसे security measure समझकर खुद ही कॉपी करने लगे हैं, ऐसा लगता है
    शुरू से ही समझ नहीं आता कि यूज़र को paste करने से रोकने की वजह क्या है
  • मेरी बैंक साइट “password” paste करने से रोकती ही नहीं, keyboard input भी रोकती है
    वह “password” बस 6 अंकों की संख्या है, और उसे खुद सेट भी नहीं कर सकते। जैसे 6 अंक, password manager द्वारा बनाए गए 16-character random string से कहीं ज़्यादा सुरक्षित हों
    पेज के अंदर random जगहों पर मौजूद buttons से input करने को मजबूर करती है, लेकिन अगर device इतना संक्रमित है कि key input और clicks रिकॉर्ड हो रहे हैं, तो attacker शायद browser memory से password भी सीधे पढ़ सकता है
  • कुछ दिन पहले नए ISP के लिए signup कर रहा था, password field में paste रोक दिया गया, इसलिए password manager टूट गया
    security के नज़रिए से यह सचमुच अविश्वसनीय रूप से खराब फैसला है
  • आम तौर पर शुरुआत तब होती है जब किसी कंपनी को bot traffic की समस्या होती है
    bots को रोकने के लिए वे तरह-तरह की चीज़ें आज़माते हैं, और एक दिन middle manager के दबाव में developers login page पर copy-paste रोक देते हैं, तो bots थोड़ी देर के लिए रुक जाते हैं
    कुछ दिनों बाद bots workaround कर लेते हैं, लेकिन पिछला “fix” इस सोच के साथ बचा रहता है कि “शायद कुछ bots को रोक दे”
    इस तरह करीब 10 lines की JavaScript rewrite v6 तक ज़िंदा रहती है, और नए सिरे से शुरू करने के कुछ महीनों या वर्षों बाद वही रोक फिर वापस आ जाती है
    बिल्कुल भी अपने अनुभव से नहीं कह रहा
  • यह नहीं कह रहा कि यही मामला है, लेकिन ऐसे clipboard malware रहे हैं जो कॉपी की गई चीज़ bitcoin address जैसी दिखे तो उसे अपने address से बदल देते हैं
    https://techcrunch.com/2018/07/03/new-malware-highjacks-your...
    शायद उन्होंने ऐसी चीज़ों को ध्यान में रखा हो

• चिढ़ होती है जब fancy JS developers ऐसी complexity और features, जिनकी किसी ने मांग नहीं की, native HTML जैसे दिखने वाले select menu के पीछे छिपा देते हैं
  शहर और राज्य के input में यह अक्सर दिखता है, जहाँ शहर text input होता है और state dropdown/select menu
  Texas का होने के कारण मैं शहर टाइप करके Tab से state select menu पर जाता हूँ, फिर t, t दबाकर अगले form element पर चला जाता हूँ
  लेकिन आजकल यह dropdown जैसा सजाया गया text search input होता है, इसलिए t, t Tennessee के बाद Texas चुनने के बजाय सचमुच tt search बन जाता है
  यह केवल उस व्यक्ति के लिए उम्मीद के मुताबिक काम करता है जो mouse से triangle click करके states की list scroll करता है
  अगर टूटा नहीं है, तो उसे ठीक करने की ज़रूरत नहीं

  • यह समस्या ज़्यादातर web platform की कमी की वजह से थी
    ऐतिहासिक रूप से असली <select> की styling बदलना या उसका behavior extend करना बहुत मुश्किल या असंभव था, इसलिए कई apps ने इसे खुद reimplement किया और अक्सर बुरी तरह किया
    लगता है कि नए style-able built-in alternatives आ रहे हैं
    साथ ही apps, frameworks और companies के बीच code sharing मुश्किल होने के कारण, full functionality, accessibility और customization वाले built-in component replacements सिर्फ बड़ी कंपनियाँ ही बना पाती थीं
    Web Components, <select> जैसे common leaf components पर दुनिया-भर का collaboration संभव बनाकर इस समस्या को हल कर सकते हैं
    संबंधित लेख: https://blogs.windows.com/msedgedev/2022/05/05/styling-selec...

• मुझे लगता है कि broken link behavior का बड़ा हिस्सा default link behavior को override करने के लिए higher-level methods की कमी से आता है
  उदाहरण के लिए, link को modal में खोलने के लिए मैं click event listener लगाना नहीं चाहता। click event बहुत low-level है, इसलिए modifier keys खुद check करनी पड़ती हैं
  असल में मैं browser से कहना चाहता हूँ: “अगर इस anchor element की वजह से current window URL बदलने वाला हो, तो इसकी जगह यह function call करो”
  तब user link को नई window या नए tab में स्वतंत्र रूप से खोल सकेगा, और उस स्थिति में मेरा code execute नहीं होगा
  CSS में भी ऐसा ही है: मैं हर element और pseudo-class के लिए cursor image specify नहीं करना चाहता। मैं कहना चाहता हूँ, “जहाँ default hand/wait/resize cursor इस्तेमाल होना था, वहाँ यह custom image इस्तेमाल करो”
  तब नए elements या UI आने पर भी code future-safe रहेगा
  कुछ browser APIs कभी-कभी XY problem से जूझते लगते हैं

  • यह JavaScript से काफी हद तक संभव है
    tag पर onclick register करके event handler में default navigation behavior cancel कर दें
    अगर user JavaScript बंद कर दे तब भी site ठीक चलती रहती है, और right-click link menu या Ctrl+click जैसे built-in browser behaviors भी वैसे ही काम करते हैं
    बस यह काफी obscure “trick” है, इसलिए अच्छा होगा अगर DOM API इसे आसान बना दे
  • https://developer.mozilla.org/en-US/docs/Web/API/Navigation_...
    मुझे लगता है यह Navigation API का use case है
  • आखिरकार online अपनी ही सोच देखने को मिली
    click या pointer event नहीं, बल्कि higher-level visit event चाहिए

• जब मैंने पहली बार Flutter Gallery देखी, तो web browser में सब कुछ टूटा हुआ लगा और मैं हैरान रह गया: https://gallery.flutter.dev
  खासकर Reply example शायद ऐसा ही था
  link पर Ctrl+click या middle mouse button काम नहीं करते, right-click भी नहीं, text select और copy भी नहीं, technical structure के कारण inspect element भी नहीं, और page zoom करने की कोशिश करने पर भी कुछ नहीं हुआ
  उस अनुभव और ज़्यादा traditional technologies से बने कुछ SPA implementations को याद करूँ तो यह लेख सही लगता है

  • Flutter, unified development framework की राह का एक और dead end है
    web हो या mobile, किसी भी Flutter demo ने मुझे कभी यह नहीं समझाया कि इसकी UX इस्तेमाल लायक है
  • mobile browsers में भी यह text selection को अजीब तरह से handle करता लगता है
    अगर Flutter का वादा हर जगह एक जैसा होना है, तो यह demo desktop पर भी उतना ही खराब होगा

• स्क्रॉल व्यवहार को भी override न किया जाए
  स्क्रॉल को “और smooth” बनाने के नाम पर उसे सुधारने की कोशिश नहीं करनी चाहिए
  Windows पर यह ठीक लग सकता है, लेकिन Mac पर Apple input devices इस्तेमाल करने पर trackpad या mouse पर उंगली की हरकत और स्क्रॉल target की movement 1:1 match करती है
  ऐसे “improvements” आम तौर पर molasses में स्क्रॉल करने जैसा महसूस कराते हैं
  सामान्य तौर पर browser के default behavior को improve करने की कोशिश नहीं करनी चाहिए

• खराब modern web में जिन चीज़ों से नफ़रत है, उनमें से एक है History API से छेड़छाड़
  HN जैसी जगहों पर कोई दिलचस्प दिखने वाला link क्लिक करके page में जाते हैं और scroll करते हैं, तो हर header या बहुत कम महत्व वाले element तक के लिए history में entry जुड़ जाती है
  मूल site पर वापस जाने के लिए back button शायद लाखों बार दबाना पड़ता है
  ऐसा करने वाले सभी लोगों से चिढ़ है

  • इसमें infinite scroll भी जोड़ना चाहूंगा
    बस pagination इस्तेमाल कर लो
    वह linkable, searchable, navigable होता है और history के साथ भी सही काम करता है
    infinite scroll बिना खास वजह इन सबको खराब कर देता है

• यहां असल में दो समस्याएं हैं जो web जितनी ही पुरानी हैं: कम expectations और लोगों या practices को define करने वाले standards/criteria का अभाव
  आजकल job postings देखें तो सब “Senior Fullstack Engineer” लिखते हैं, लेकिन अंदर जाने पर असल में अक्सर Java या Python, R, Spring, SQL का combination चाहिए होता है
  अगर वह fullstack नहीं है और फिर भी ऐसा लिखा जाए, तो यह लोगों का समय बर्बाद करता है और public को signal देता है कि आप technology को समझते नहीं हैं या उसकी परवाह नहीं करते
  Programming में इसे “X/Y problem” कहा जाता है। आपको desired final state X solve करनी होती है, लेकिन उसकी जगह आप सिर्फ उस approach Y की बात करते हैं जिसे आप अपनाना चाहते हैं—यह एक anti-pattern है
  इसलिए employer एक posting पर 500 resumes पाकर भी महसूस करता है कि कोई fit नहीं है
  शुरुआत goal से होनी चाहिए: “हम इस तरह की client/server app बनाने के लिए hire कर रहे हैं, candidate को X, Y, Z features लिखने और support करने होंगे, और constraints A, B, C हैं” जैसे लिखना चाहिए
  Companies ऐसा इसलिए नहीं कर पातीं क्योंकि वे अक्सर जानती ही नहीं कि वे असल में क्या करती हैं, और कई गलत रास्तों से गुजरते हुए टूटी हुई technology अपने ऊपर ले चुकी होती हैं। इसलिए इसे technical debt कहा जाता है
  Goal इतना clear हो तो interview में company और candidate दोनों जानते हैं कि क्या verify करना है और एक-दूसरे को ठीक से filter कर सकते हैं। वरना यह blind date और game show के मिले-जुले भयानक process जैसा बन जाता है
  उदाहरण के लिए, साफ लिखा जा सकता है कि hiring एक highly distributed media conferencing application बनाने के लिए है, developer को TypeScript लिखना होगा, sockets के stream data को pipe करना होगा, browser और server दोनों तरफ काम करना होगा और test automation लिखना होगा
  Operational constraints में WCAG AA compliance, legal team की बनाई privacy compliance checklist, execution speed और network latency को target करने वाली performance considerations शामिल होंगी, और ideal candidate को interview में network latency, browser application logic, और streaming data state management के solutions दिखाने होंगे