- UI की परिपक्वता इम्प्लीमेंटेशन के तुरंत बाद नहीं, बल्कि उसे वास्तव में बार-बार क्लिक करके देखने की दोहराव वाली प्रक्रिया में बढ़ती है, और लेख इसकी तुलना बढ़ईगीरी में sanding से करता है
- पेज ट्रांज़िशन और नेविगेशन को क्लिक, ब्राउज़र back, राइट-क्लिक “Back”, ऐप के अंदर back, और keyboard shortcuts जैसे कई एंट्री paths से जांचना चाहिए
labelऔरinput type="radio"को flexbox से align करकेgapदेने पर, radio button और label के बीच का हिस्सा एक dead zone के रूप में सामने आया जहाँ क्लिक काम नहीं करता- समाधान
gapहटाकरlabelमें padding देने का था, जिससे visual spacing बनी रही और clickable area बड़ा हो गया - छोटी interaction खामियाँ भी जमा होकर user experience को खराब कर सकती हैं, इसलिए UI को बार-बार इस्तेमाल करते हुए तब तक निखारना चाहिए जब तक “काँटे” महसूस होने बंद न हो जाएँ
बार-बार क्लिक करके UI की खुरदरी जगहें ढूँढना
- UI पर काम करना कुछ बना लेने के बाद बहुत ज़्यादा क्लिक करने, उसे सुधारने, और फिर दोबारा क्लिक करने की प्रक्रिया के ज़्यादा करीब है
- पेज ट्रांज़िशन में सिर्फ़ एक flow देखना काफ़ी नहीं है; अलग-अलग तरीकों से वापस जाते हुए भी उसे परखना चाहिए
- क्लिक के बाद ब्राउज़र का back button इस्तेमाल करना
- क्लिक के बाद राइट-क्लिक context menu का “Back” इस्तेमाल करना
- ऐप के अंदर back navigation इस्तेमाल करना
- keyboard shortcuts से back करना
- यह प्रक्रिया QA की तरह “क्लिक करके तोड़कर देखना” जैसी है, लेकिन ज़्यादा सही तुलना बढ़ईगीरी में sandpaper से खुरदरे हिस्से और काँटे ढूँढने की भावना से है
- software UI में बहुत ज़्यादा states और variables हो सकते हैं, इसलिए उसे बार-बार इस्तेमाल करके तब तक तराशा जाता है जब तक कोई “काँटा” बाकी न लगे
flexbox gap से बना क्लिक dead zone
- radio options की सूची में
<label>और उससे जुड़े<input type="radio">को एक ही पंक्ति में रखा गया - CSS एक सरल संरचना थी जिसमें container पर
display: flex,flex-direction: row,align-items: center,gap: .5remलागू था - बार-बार क्लिक करते समय पता चला कि radio button और label के बीच की जगह दबाने पर control toggle नहीं होता, यानी वहाँ एक dead spot था
- कारण flexbox का
gapथाgapvisual spacing बनाना आसान करता है- लेकिन यह label या input element के clickable area में शामिल नहीं होता, इसलिए interaction में खाली जगह बन जाती है
- समाधान
gapहटाकरlabelमें padding देने का था- spacing बनी रही
- label का clickable area बढ़ गया और dead zone गायब हो गया
- एक छोटी खामी मामूली लग सकती है, लेकिन ऐसे “छोटे काँटे” बढ़ जाएँ तो UI experience तकलीफ़देह हो सकता है
1 टिप्पणियां
Hacker News की राय
अगर डेवलपर उस प्रोडक्ट का खुद भी बहुत इस्तेमाल करने वाला यूज़र है जिसे वह बना रहा है, तो ऐसे छोटे-छोटे मुद्दे पकड़ने में उसे बड़ा फायदा मिलता है
क्योंकि यूज़र के अटकने से पहले ही डेवलपर खुद छोटी-सी खटकन महसूस कर सकता है, और वह उसे तुरंत ठीक करने की जगह पर भी होता है
इसलिए मजबूत ownership वाली छोटी टीम असरदार लगती है। अगर प्रोडक्ट के प्रति अपनापन हो, तो यूज़र की छोटी असुविधा भी अपनी समस्या जैसी लगती है, और UX को जितना हो सके smooth बनाना आत्मसम्मान का सवाल बन जाता है
अगर enterprise product जैसा कोई मामला न हो जिसे अंदर इस्तेमाल करना मुश्किल हो, तो direct ownership भले कम हो, फिर भी प्रोडक्ट की सफलता में stake बन जाता है
जानने की उत्सुकता है कि सबसे polished UI कौन-सा होगा
FAANG के पास इतना पैसा है, इसलिए लगता है कि UI/UX काफी अच्छा होगा, लेकिन Amazon.com या AWS, GCP, Azure इस्तेमाल कर चुके लोग शायद अलग महसूस करेंगे
निजी तौर पर मुझे mcmaster.com सबसे अच्छी तरह polished UI/UX लगता है। जो चाहिए वह कुछ ही मिनटों में मिल जाता है
इसके उलट Home Depot या Lowe’s जैसी बड़ी retail sites पर screw या lumber जैसी चीज़ों को सही size में ढूंढने में 10–15 मिनट लग जाते हैं, और mobile पर हालत और खराब होती है
यह अविश्वसनीय रूप से simple और practical होते हुए भी काफी powerful है। आप parts को step-by-step narrow करके ढूंढ सकते हैं या search कर सकते हैं, price comparison अपने-आप हो जाता है, और price/quality categories भी उपयोगी ढंग से grouped हैं
part number मिल जाए तो year/make/model compatibility, छोटा description, photo, और यह भी देख सकते हैं कि cart में मौजूद दूसरे parts के साथ उसी warehouse से ship होगा या नहीं। यह सब एक ही page पर, बिना friction के, किसी भी platform पर बहुत तेजी से चलता है
response बहुत तेज है और इस्तेमाल करते समय मुझे कोई bug नहीं दिखा। इसने मेरा benchmark बढ़ा दिया कि web app कितना अच्छा हो सकता है
असल में उनके पास सिर्फ usability issues ठीक करने के लिए dedicated period भी था
https://linear.app/changelog/2022-12-01-polishing-season-202...
https://web.archive.org/web/20231003205004/https://linear.ap...
खासकर temporary profile picture सबसे ज्यादा irritating है। लगभग एक साल से सही से काम नहीं कर रही, और original photo पर वापस नहीं लौटती
लगता है वहां कोई polish नहीं कर रहा
https://littlebigdetails.com बिल्कुल ऐसी ही जगह है
इस specific problem का basic solution है input element को label के अंदर रखना
मैं वजह सोच रहा था; शायद इसलिए कि label या input element की position/padding adjust करते समय theming लागू करना आसान हो जाता है
[1] https://getbootstrap.com/docs/5.3/forms/checks-radios/
for/idattributes अभी भी जरूरी हैं: https://www.tpgi.com/should-form-labels-be-wrapped-or-separa...radio या checkbox में सिर्फ box और padding ही नहीं, बल्कि पूरे text label पर click करने से भी toggle होना चाहिए
Flexbox थोड़ा overkill लगता है। non-nested syntax में भी यह inline ही layout होगा, और मुझे लगता है उसी तरह बस padding जोड़ देनी चाहिए
इसे mitigate करने के लिए
Fooको अलग element में wrap करना होगाऐसी चीजें Agile में बहुत गायब हो गई हैं
इंजीनियरों के पास प्रोडक्ट को polish करने का समय होना चाहिए, लेकिन असल में नहीं होता। अगर QA spacing issue के लिए टिकट नहीं बनाता, तो वह कभी ठीक नहीं होता
ग्राहक शायद ऐसी चीजें नोटिस कर लेते हैं, लेकिन उनका report करना भी चमत्कार है, फिर उसका टिकट बनना भी चमत्कार है, और फिर किसी का उसे priority देकर ठीक करना भी एक और चमत्कार है
सच में, ज्यादातर कंपनियों के issue boards ग्राहक के नजरिए से इतने opaque होते हैं कि अगर कोई छोटी समस्या या bug दिख जाए, तो उसे bug साबित करने और tracker में ticket डालने तक 50 घंटे की आगे-पीछे की झंझट करनी पड़ती है, जो परेशान कर देता है
क्या आपका मानना है कि waterfall model UI को test और polish करने के लिए स्पष्ट रूप से समय देता था?
यह आम तौर पर ऐसा process है जिसमें product manager priority तय करता है और सक्षम UX engineer या designer के साथ मिलकर इसे handle करता है। अगर चाहें तो किसी भी development methodology में वह priority रखी जा सकती है, इसलिए यहाँ Agile अप्रासंगिक है
पिछले 3 सालों में मैंने कई बार report किया है। क्योंकि लिखते समय text editing बेहद कठिन और चिड़चिड़ी हो जाती है
एक web developer के तौर पर मुझे हैरानी है कि शुरुआत में ही ऐसी चीज कैसे टूट गई। जो default रूप से काम करती है उसे खराब करने के लिए किस स्तर की अयोग्यता चाहिए, समझ नहीं आता। यह fix 30 मिनट से ज्यादा नहीं लेना चाहिए और सभी का user experience 1000 गुना बेहतर कर देगा, लेकिन report किए 3 साल हो गए और यह वैसा ही है
Teams में भी phone number input field में HOME/END keys इस्तेमाल न कर पाने वाला bug Microsoft Premiere Support के जरिए report किया था, और जवाब था “design के अनुसार काम कर रहा है”
यह आश्चर्य की बात नहीं कि ग्राहक ऐसे bugs अब report नहीं करते। क्योंकि कर्मचारी/developers और company, दोनों को वैसे भी परवाह नहीं है
मैं product का lead developer हूँ और इधर-उधर बहुत सारी छोटी समस्याएँ हैं। किसी चीज की जिम्मेदारी हो लेकिन उसे ठीक करने का अधिकार न हो, यह अच्छा महसूस हो ही नहीं सकता
business perspective से logic यह बनता है कि जब revenue या brand को नुकसान नहीं है तो इसे ठीक करने में time और money क्यों लगाएँ। लंबे समय में brand पर असर पड़ेगा, लेकिन ज्यादातर लोग 5 साल के अंदर role या company बदल लेते हैं, इसलिए परवाह नहीं करते
अगर जवाब मिल जाए तो वही बेहतर case है
स्पष्ट है कि कोई process customer की जरूरतें पूरी नहीं कर रहा, तो team के साथ मिलकर उसे ठीक किया जा सकता है
अगर Scrum ceremonies हैं तो retrospective में इसे उठाया जा सकता है, लेकिन असल में यह कभी भी संभव है। retrospective बस पिछले कुछ हफ्तों को जानबूझकर देखने की जगह है, और बीच में जो दिख जाए उसे बीच में ही हल करने की कोशिश करनी चाहिए
छोटे UX issues को देखकर ठीक करने की समझ रखने वाला व्यक्ति बहुत महत्वपूर्ण होता है
UX design में ऐसी चीजों की तुलना user को लगने वाले paper cuts से की जाती है। ये घातक नहीं होते, लेकिन user satisfaction घटाते हैं
लेखक की बात में जोड़ूँ तो, वह radio button selected state में check नहीं बल्कि dot इस्तेमाल करने की convention का पालन नहीं करता। user पहली नजर में समझ सकता है कि कई options select किए जा सकते हैं या कोई भी select न करना ठीक है
यह शायद उस feature का side effect है जिसमें बाहर click करने पर बंद होता है
अगर negative side पर “Papercuts” हैं, तो positive side पर हाल ही में HN पर भी चर्चा हुआ Juice है
यह लेख अच्छी तरह दिखाता है कि मुझे UI programming क्यों नापसंद है
जो चीजें unpredictable हैं और मामूली तरीकों से बिगड़ सकती हैं, वे मेरे धैर्य से बाहर हैं। कोई चीज किस तरह fail हो सकती है यह सोचकर tests लिखना मुझे कुछ हद तक अच्छा लगता है, लेकिन बस इधर-उधर click करके देखना कि क्या टूटता है, बिखराव भरा और चिड़चिड़ा है
सोचता हूँ कि UI implementation स्वभाव से ही इतना complex है, या हमने अभी तक सही programming model नहीं पाया है। कभी-कभी लगता है, क्या शुरुआत से ही यह उम्मीद करना unreasonable है कि चीजें intended तरीके से दिखें और behave करें?
UI को polish करना केवल component पहली बार बनाते समय करना पड़ता है। कभी-कभी components को अलग तरीके से combine करना या one-off implementation चाहिए हो सकता है
सच कहूँ तो, अगर आपको पता है कि आप क्या कर रहे हैं, तो इसमें इतना समय नहीं लगता। अच्छे design engineers इस भूमिका के experts होते हैं
freedom बहुत ज्यादा है, और forms जैसे basic elements को defaults से ही अच्छे से काम करना चाहिए
code के जरिए UI को अच्छे से express करने के तरीके पहले से मौजूद हैं। समस्या business side का zero-sum game है। cross-platform UI अगर सबसे बदसूरत UI stack HTML/CSS/JS से न किया जाए, तो लागत बहुत ज्यादा हो जाती है
लेकिन web platform documents के लिए तो ठीक-ठाक है, apps के लिए उसका abstraction level सही नहीं है। इसलिए web UI हर साल नए और leaky abstractions के साथ फिर से invent होता है
सिर्फ catch up करना ही बहुत बड़ा काम है
दूसरे क्षेत्रों में भी यही है। अगर request भेजने या query में parameters डालने का आसान तरीका न हो, तो लोग सावधान रहने की कोशिश करें तब भी natural pressure के कारण हर तरह के आधे-अधूरे तरीके invent कर लेते हैं
web platform graphics side में cutting-edge है, लेकिन UI के रूप में सचमुच बहुत खराब है। फिर भी कोई इसे मानकर बदलना नहीं चाहता। लोग सिर्फ पहले हिस्से पर भरोसा करते हैं, और browser की legacy और complexity बदलाव को रोकती है। library बनाओ तो वह “standard” नहीं है, इसलिए कोई ध्यान नहीं देता
वहीं कुछ UI में radio buttons के लिए square boxes भी इस्तेमाल होते हैं
highlighted button होता है लेकिन Enter key से activate नहीं होता
और अलग-अलग icons (ellipsis, hamburger, kebab) के पीछे तीन-तीन menus छिपे होते हैं
quality में बहुत variation है। UI polish करने वाले लोग सच में आभार के पात्र हैं
Apple तक ऐसा कर रहा है :(
समझ नहीं आता कि input element को label के अंदर रखने का तरीका लोकप्रिय क्यों नहीं है
ऐसा करने से समस्या पूरी तरह गायब हो जाती है, और
forमें इस्तेमाल करने के लिए uniqueidबनाने की भी जरूरत नहीं रहतीबस अब भी कुछ assistive technologies के बारे में पता है कि वे नए valid standard pattern को interpret नहीं कर पातीं, इसलिए Bronze Age standard का पालन करना best practice बन जाता है [1]
दूसरे frameworks भी शायद ऐसा ही करते होंगे। उन दोनों input fields को
labelelement से wrap कर दें तो वह अब valid HTML नहीं रहताradio button में यह समस्या नहीं है, लेकिन कुछ लोग यह झेलने के बाद “पक्का करने के लिए” ऐसा करते दिखते हैं। यह JavaScript line के अंत में semicolon लगाने जैसा है। लगभग जरूरत नहीं होती, लेकिन ठीक कब जरूरत पड़ेगी पता नहीं, इसलिए हर जगह लगा देते हैं
checkbox/radio button के आम use cases में syntax भी कहीं ज्यादा साफ होता है
input element को label से wrap करें, और text को style देना हो तो text को
spanमें डाल दें।labelकोdisplay:flexबना सकते हैं और text की position भी उसी तरह संभाल सकते हैंbug bash में हम यह तरीका इस्तेमाल करते हैं, और इससे उस व्यक्ति की तुलना में कहीं ज्यादा tickets निकलते हैं जिसने test case combinations को multidimensional Cartesian product matrix में बनाया था
शुरुआती point के तौर पर ऐसे test cases जानना अच्छा है, लेकिन छोटी समस्याएं खोजने में random testing planned testing से जल्दी आगे निकल जाती है
planned testing आमतौर पर happy path या expected errors तक ही रहती है। इस तरह की polishing edge bugs को कहीं ज्यादा तेजी से ढूंढती है
हमेशा कोई समस्या या छोटी improvement मिल जाती है। ये ऐसी चीजें हैं जो planned testing से सच में ज्यादा नहीं निकलतीं
अपनी personal website(https://dustinbrett.com) को लगभग 4 साल से polish कर रहा हूं, और लगता है यह अंतहीन चलता रह सकता है
अच्छी बात है कि मुझे इस पर काम करना पसंद है
उम्मीद है पूरा ही था :-)
“webpage पर desktop OS” देखें तो ज्यादातर आधा-अधूरा बना लगता है और सच कहूं तो बहुत common हो चुका है, लेकिन यह उल्टा बहुत solid और अच्छी तरह polished है
सच में अच्छी तरह बनाया है और प्रेरणा देता है। हर चीज कैसे implement की होगी, यह सोचना भी काफी मजेदार है
वह इच्छा phone पर window-based OS इस्तेमाल करने की थी
अगर एक कमी निकालूं तो explorer में mouse4/mouse5 इस्तेमाल न कर पाना है। “polishing” सच में हमेशा चल सकती है