'Usability' में गिरावट की घटना (2020)
(datagubbe.se)- 1994~2012 के आसपास के desktop GUI में, operating system अलग होने पर भी कॉमन नियम बहुत थे, इसलिए अनुभवी users नए environment में जल्दी adapt कर पाते थे; लेकिन हाल के समय में यह आधार कमजोर हुआ है
- smartphone की छोटी screen और touch input के हिसाब से बने single-app paradigm के desktop पर आने से, keyboard और precise mouse को आधार मानने वाले multi-window उपयोग तरीके से टकराव होता है
- Windows 10 apps, Slack, Chrome, Firefox 75, QT5, Gnome apps के उदाहरणों में titlebar widgets, megabar, auto-hide scrollbars, गायब menu bar जैसे बदलाव बार-बार दिखते हैं, जो पुराने UI concepts को धुंधला करते हैं
- dropdown menus, स्पष्ट titlebar, window focus indication, पहचाने जा सकने वाले buttons और input fields platforms के पार सीखी जा सकने वाली कॉमन भाषा थे, लेकिन हर app का अलग व्यवहार अलग से learning मांगता है
- screen space बचाना, बदलाव की अनिवार्यता, Electron की multi-platform सीमाएं, या free software होना—इन कारणों से validated UI concepts को तोड़ना उचित ठहराना मुश्किल है; प्रभावशाली projects और companies के लिए consistency standards जरूरी हैं
Desktop GUI में कमजोर हुए कॉमन नियम
- 1994~2012 के आसपास, reasonable computer literacy वाले users लगभग किसी भी operating system GUI के सामने बैठकर जल्दी adapt कर सकते थे
- Windows, MacOS, CDE, OpenStep, OS/2 ही नहीं, Amiga, Atari, BeOS जैसे environments में भी फर्क से ज्यादा commonalities थीं
- उस समय windows आम तौर पर titlebar के जरिए drag, पहचान और current input focus indication देते थे
- File, Edit, View, Help जैसे standardized dropdown menus नए app के features explore करने और shortcuts सीखने को आसान बनाते थे
- buttons, input fields और अन्य widgets 3D bevel जैसे visual cues की वजह से interactive elements के रूप में पहचानने में आसान थे
- कुछ exceptional apps नियमों का पालन नहीं करते थे, लेकिन अहम basic areas में ज्यादातर software समान conventions share करते थे
Smartphone paradigm के desktop पर आने की समस्या
- smartphone जैसे अपेक्षाकृत नए platforms में input method और screen interaction desktop से अलग होते हैं, इसलिए नया paradigm जरूरी हो सकता है
- समस्या यह है कि यह paradigm keyboard और pixel-level mouse operation वाले desktop तक फैल रहा है
- flat design के साथ मिलकर UI elements बड़े होते जा रहे हैं, साथ ही decoration या content से अलग पहचानना मुश्किल होता जा रहा है
- desktop application design कई apps और windows को साथ-साथ दिखा सकने की premise को कमजोर करता है, और smartphone-style single-app usage को अपनाने की दिशा में बढ़ रहा है
- desktop UI conventions, जो पहले ही कई users की muscle memory बन चुके हैं, उन्हें bypass करना और ज्यादा असुविधा पैदा करता है
Window management: titlebar अब सिर्फ window के लिए area नहीं रहा
- Windows 10 के कई लोकप्रिय apps के titlebars में, एक ही computer पर कुछ मिनटों के भीतर capture किए गए screenshots में भी consistency की कमी साफ दिखती है
- छहों windows active window दिखाती हैं, लेकिन Outlook और Slack लगभग inactive state जैसी दिखती हैं, और बाकी windows में भी cmd.exe को छोड़कर active/inactive फर्क बहुत subtle है
- ज्यादातर titlebars में tool icons, tabs, dropdown menus या उनका combination शामिल है
- window move, focus, bring to front जैसे traditional operations के लिए clickable area की चौड़ाई हर app में अलग हो जाती है
- जिन users ने titlebar को window manipulation area के रूप में सीखा है, वे अनजाने में app functions चला सकते हैं
- Visual Studio Code के छोटे logo जैसे elements भी हैं, जो icon जैसे दिखते हैं लेकिन वास्तव में decorative हैं
- छह apps में से चार Microsoft apps हैं, इसलिए ऐसा irregular design standard की तरह फैल सकता है
- Slack के latest version में, Windows 2 के समय से संभव top border और corner drag resize areas काफी घट गए हैं
- लाल area बचे हुए resize hotspots दिखाता है, नीला area window move hotspots दिखाता है
- बाकी space non-standard widget combinations ने घेर लिया है
- 22 अप्रैल 2020 के update से Slack desktop version inactive window में titlebar को थोड़ा dark दिखाने लगा
Browser UI: tooltips और address bar पुराने concepts को हिलाते हैं
- Chrome tabs पर mouse hover करने पर तुरंत दिखने वाला बड़ा tab tooltip देता है
- सामान्य browser tab tooltip थोड़ी देरी के बाद छोटे floating tooltip के रूप में दिखता है
- Chrome का नया tooltip बिना delay आता है और नीचे के UI के बड़े area को ढक देता है
- tab tooltip की उपयोगिता खुद भी चर्चा का विषय है, लेकिन इस रूप को distracting और unnecessary element माना गया है
- Firefox 75 के URL bar बदलाव को megabar कहा जाता है
- यह अप्रत्याशित क्षणों में pop out होता है
- इसे हटाना मुश्किल है, और यह नीचे की bookmarks toolbar को ढक देता है
- text input field एक पुराना UI element है जिसकी मूल अवधारणा कम से कम 1980s की शुरुआत से बनी हुई है, लेकिन megabar उसका behavior काफी बदल देता है
Scrollbar: hide होना और low contrast position awareness को मुश्किल बनाते हैं
- auto-hide scrollbar smartphone पर छोटी screen space बचाने और अंगूठे से सीधे scroll करने के कारण उपयोगी हो सकता है
- desktop पर scrollbar current content position दिखाने वाला status indicator भी होता है
- user अपना काम रोके या mouse पकड़े बिना current position जान सकता है
- बिना focus वाली window में भी position check हो सकता है
- tailing log file reader या debug stream वाले command prompt में scrollbar यह confirm करने में मदद करता है कि आप latest output position देख रहे हैं या नहीं
- auto-hide scrollbar में यह check मुश्किल हो जाता है, और कम clear या ज्यादा cumbersome दूसरे तरीकों का इस्तेमाल करना पड़ता है
- QT5 की default scrollbar rendering में bar और tray अलग करना मुश्किल है और contrast बहुत low है
- यह जानने के बाद भी कि थोड़ा ज्यादा bright हिस्सा bar है, misclicks अक्सर होते हैं
- पुराने और सस्ते laptop screens पर bar और tray का फर्क पहचानना मुश्किल हो सकता है
- QT5 tools के जरिए अधिक traditional appearance set कर सकता है, लेकिन नए users के लिए यह जानना मुश्किल है, इसलिए default appearance महत्वपूर्ण है
Menu bar और Gnome apps की inconsistency
- menu bar Windows, Mac और Unix-like systems में मोटे तौर पर समान तरीके से काम करने वाला lowest common denominator था
- traditional File, Edit, View तरीका app functions explore करने का standard path था, लेकिन Gnome design इसे दूसरे तरीके से replace करता है
- hamburger menu smartphone पर उपयोगी है, लेकिन wide-screen desktop पर horizontal space की कमी हल करने की जरूरत कमजोर है
- Gnome में hamburger menu उन UI operations को रखने के लिए इस्तेमाल होता दिखता है जो कहीं और नहीं रखे गए
- Evince के hamburger menu में Open, Save, Print, Close हैं
- Gnome-MPV के hamburger menu में Open या Close नहीं है, और file खोलने के लिए बाईं ओर के plus icon button को दबाना पड़ता है
- Gnome-MPV के app icon button में preferences और quit options हैं, लेकिन Evince का app icon button अलग menu देता है
- apps के बीच consistency कम है, इसलिए users को वही function ढूंढने के लिए अलग-अलग locations सीखनी पड़ती हैं
- सामान्य dropdown menu या कुछ hamburger menus के विपरीत, इन menus के खुलने के बाद keyboard से navigate करने का तरीका ढूंढना मुश्किल है
Gnome का titlebar integration और extra toolbar
- Gnome apps toolbar को window titlebar में integrate करने वाला नया paradigm अपनाते हैं, जिससे Windows app examples में आलोचना किए गए titlebar occupation को institutionalize कर देते हैं
- दूसरे window manager का उपयोग करने पर titlebar और app का अपना close button duplicate दिख सकते हैं
- window move के लिए कुछ area बचाने की कोशिश में, वे widgets जो पहले titlebar के नीचे toolbar में रखे जा सकते थे, अलग से खुलने वाली structure बन जाते हैं
- Evince का search box अलग से expand होने वाले रूप में दिया जाता है
- annotation toolbar में केवल दो icons हैं, लेकिन इसे खोलने के लिए एक अलग icon इस्तेमाल होता है
अक्सर आने वाली आपत्तियों के जवाब
- “technology आगे बढ़ती है और change रोका नहीं जा सकता” जैसी बात असल argument के बिना इस्तेमाल होने वाला cliché ज्यादा लगती है
- UI design बदलना nature की force नहीं, लोगों का decision है
- change का मतलब improvement नहीं होता; goal change itself नहीं, improvement होना चाहिए
- “past में अटके रहना” वाली आपत्ति traditional UI elements पसंद करने के अर्थ में सही हो सकती है, लेकिन इसका मतलब यह नहीं कि सभी modern desktops Windows 95 या CDE जैसे दिखने चाहिए
- basic concepts तोड़े बिना भी UI के look and feel को improve करने के और रास्ते हैं
- “Electron apps किसी single platform standard का पालन नहीं कर सकते” वाली आपत्ति पर, multi-platform apps को ही common platforms में translate होने वाले paradigms का पालन करना चाहिए
- dropdown menus, clean titlebars, clear window focus indication लागू करने में मुश्किल concepts नहीं हैं
- multi-platform frameworks को ऐसे concepts implement करना आसान और bypass करना मुश्किल बनाना चाहिए
- “free software पर शिकायत नहीं करनी चाहिए” वाली आपत्ति के बावजूद, Gnome और KDE जैसे बड़े FOSS projects Microsoft या Google की तरह users, designers और programmers पर बड़ा प्रभाव डालते हैं
- जो projects example set करते हैं, उन पर उसी के अनुरूप standards लागू होने चाहिए
Screen space बचत और UI complexity
- titlebar में elements डालने से कुछ हद तक screen space बच सकती है
- लेकिन सामान्य screen space अब कोई बड़ी समस्या नहीं मानी जाती
- computer बहुत इस्तेमाल करने वाला user करीब US$200 में 2560x1440 resolution वाला बड़ा monitor खरीद सकता है
- सबसे सस्ते laptops भी आम तौर पर कम से कम 1366x768 resolution देते हैं
- screen space की समस्या बल्कि मौजूदा UI design के बड़े whitespace की वजह से बढ़ती है
- पुराने सरल request window के full-screen application जैसा दिखने के उदाहरण हैं
- 13-inch laptop पर पूरा दिन coding करने वाले user को कुछ pixels से ज्यादा अपनी back, neck, hands और shoulders की health की चिंता करनी चाहिए
- यह सही है कि UI design कठिन है और हर user को हमेशा satisfy नहीं किया जा सकता, लेकिन यह दशकों से validated basic UI concepts को जानबूझकर तोड़ने की वजह नहीं बनता
- अगर हर app में window decoration और operation methods के detailed differences अलग से सीखने पड़ें, तो users बार-बार differences interpret करने में समय और energy लगाते हैं
1 टिप्पणियां
Hacker News राय
पिछले करीब 10 साल से ऐसा लग रहा है जैसे UI/UX टीम से लगातार लड़ाई चल रही हो, और मूल बात यह दिखती है कि डिजाइन के मानदंड professional tools से हटकर consumer content consumption paradigm की तरफ चले गए हैं
20 साल पहले software अक्सर professional tools होता था, लेकिन अब usage के हिसाब से video और social media जैसे consumer software केंद्र में हैं। Designers “काम पूरा करने” वाले products पर भी content consumption के नियम लागू करना चाहते हैं
आम उदाहरण यह है कि “ज्यादा साफ़-सुथरा और intuitive” बताकर दिखने वाले tools को तीन डॉट वाले menu के पीछे छिपा दिया जाता है, जिससे एक click वाला काम दो clicks का हो जाता है, और tool users को इसे दिन में सैकड़ों बार दोहराना पड़ता है। Tables में जहाँ पहले 20 items और 6–8 details दिखती थीं, उसी जगह अब सिर्फ़ 10 items और 4 details दिखती हैं; dashboards में 10 graphs की जगह सिर्फ़ 4 दिखते हैं; menu app के ऊपर के 10–20% हिस्से पर कब्ज़ा कर लेता है; और H1 title बहुत बड़ा हो जाता है
मेरी एक मौसी हैं जो इसलिए furniture लगातार बदलती रहती हैं क्योंकि कोई बेहतर arrangement मिला है ऐसा नहीं, बल्कि मौजूदा arrangement से ऊब गई हैं; PM या UX side में यह प्रवृत्ति आम लगती है। Product में चौथा table view जोड़ते समय “बिल्कुल अलग style इस्तेमाल करना चाहिए” कहना भी इसलिए नहीं होता कि वह बेहतर है। COVID के बाद से मैं हर हफ्ते दोस्तों के साथ Google Meet करता आया हूँ, और लगभग हर बार कुछ न कुछ बदल जाता है; हाल में join request flow फिर बदल गया, लेकिन वह बेहतर नहीं हुआ
किसी point के बाद आप बस इसे स्वीकार कर लेते हैं और इंतज़ार करते हैं कि बेहतर तरीका नया best practice बन जाए
लेकिन जो धारा मूल समस्या ठीक करने के लिए शुरू हुई थी, वह बढ़ती ही गई, और शायद किसी ने ध्यान ही नहीं दिया कि बात हद से आगे निकल चुकी है। या शायद नए designers, जिन्हें पुराने UI context का पता नहीं, पहले से सुधरे हुए UI पर वही prescription दोबारा लागू कर रहे हैं
ऐसा लगता है pendulum वापस लौटने के बजाय escape velocity तक पहुँच गया है
Screen पर हर button और scrollbar लगातार “यह किया जा सकता है, पर अभी किया नहीं गया” बताता रहता है; designer के लिए निजी तौर पर यह इतना परेशान करने वाला और खुला-खुला लगता है कि अंततः वे सब कुछ हटाना चाहते हैं
उत्सुक हूँ कि UI flow average user को जितनी skeuomorphism चाहिए, उस तरफ कब लौटेगा। Web link paradigm तक elderly या कम experienced users के लिए बहुत कठिन लगता है, और कभी न कभी यह unavoidable data के रूप में सामने आएगा
PM और UX लोगों को भी काम करने के पैसे मिलते हैं, और उनका काम UI/UX बदलना है। अगर उन्हें लगभग complete software maintain करने के पैसे मिलें, तो वे refactoring या मामूली fixes पर समय लगाएंगे; फर्क यह है कि हम जो कुछ करते हैं, वह सब users को दिखाई नहीं देता
UX side जो भी करे, बस इतना हो कि मैं Ctrl-K दबाकर इच्छित command के शुरुआती letters type कर सकूँ
लगभग 2000 से web, mobile और related UI ही design कर रहे UX designer के रूप में, मैं सहमत हूँ कि change for the sake of change बहुत-सी usability problems पैदा करता है
लेकिन बड़ा मुद्दा यह है कि actual design करने वाले लोगों के बीच professional discussion या ठीक-ठाक design analysis लगभग गायब हो गया है
जिन designers के साथ मैं काम करता हूँ, उनमें से कई के पास broadly यह समझाने की vocabulary या knowledge नहीं है कि कोई चीज़ “usable” कैसे बनती है, और subtle interaction design या information display problems हल करने की क्षमता भी कम है। Basic heuristics के बारे में knowledge या interest नहीं है, इसलिए उन्हें यह भी नहीं पता कि शुरू कहाँ से करें
इसलिए वे Figma में colors, shapes और effects के साथ काम करते हुए रहते हैं, और उसी UI के कुछ variants को “user test” के लिए दिखाने तक सीमित रह जाते हैं। यह एक जानबूझकर अज्ञानी “non-technical” innovation cult बन गया है, जिसने अपना मूल उद्देश्य पूरी तरह खो दिया है
यह कहना अतिशयोक्ति नहीं कि मुझे अपने profession पर शर्म आती है। यह बहुत बड़े स्तर पर fail हुआ है
उस समय लगा था कि हम उस दुनिया की बस थोड़ी झलक देख रहे हैं जिससे UI/UX designers कहीं ज्यादा परिचित हैं, लेकिन शायद ऐसा नहीं है
बहुत से लोग context, ecosystem और design decisions के systemic effects पर सोचने के बजाय कमजोर research के साथ संकरे questions पूछते हैं और फिर चीज़ों को “सुंदर” बनाने पर लौट जाते हैं
HCI intro और अच्छे designers से मिली बहुत basic knowledge तो है, लेकिन अभी वह technical या formal level की नहीं है
यानी pay पाने के लिए न्यूनतम mental labor ही लगाई जाती है
मैं दोष देने की कोशिश नहीं कर रहा। ये लोग saturated field में काम कर रहे हैं, और usability से ज्यादा visual appeal या feel को महत्व देने वाले executives की whims और tastes के अधीन हैं
आखिरकार यह marketing है। अगर लोग use करना ही न चाहें, तो product कितना easy to use है, इसका बहुत अर्थ नहीं। Military जैसी कई industries हैं जो highly usable चीज़ें बनाती हैं, लेकिन वे आम तौर पर बस ugly होती हैं
लेखक ने कहा था कि macOS का उनका अनुभव कम है इसलिए वे फैसला रोक रहे हैं, लेकिन यहाँ भी वही गिरावट हो रही है। खासकर Apple धीमे hover effects और जरूरत से ज्यादा सूक्ष्म gray shades के पीछे features छिपाने में उलझा दिखता है
शायद यह polished दिखने के लिए हो, लेकिन इससे interface की discoverability खराब हो रही है। अगर आप यह सीख भी लें कि किसी hover animation के पीछे कुछ है, तब भी असली target area माउस को ठीक उसी जगह ले जाने के बाद ही दिखता और सक्रिय होता है, इसलिए उसे आसानी से निशाना नहीं बनाया जा सकता। Music app और notifications के actions खास तौर पर खराब हैं
window title bar में कौन-सा हिस्सा drag किया जा सकता है, यह भी साफ नहीं है। मैं कभी समझ नहीं पाया कि एक pixel से window खींची जा सकती है, लेकिन उसके ठीक नीचे वैसा ही दिखने वाला pixel ऐसा क्यों नहीं कर सकता
मेरी राय में Apple की UI usability काफी समय से उसकी ताकत नहीं रही है। Mac और PC दोनों इस्तेमाल करने की मजबूरी में, macOS भी कई मामलों में PC जितना, या उससे भी ज्यादा, भयानक है
Apple जिस चीज में अच्छा है, वह अपने ecosystem में device integration usability है
लेकिन macOS screen switching के समय सुस्त animation चलाता है। इसे बंद नहीं किया जा सकता, और लगभग उतने ही धीमे दो विकल्पों में से बस एक चुन सकते हैं
इसे सही ठहराने की कोई अच्छी वजह मुझे नहीं सूझती। पता नहीं किस user model से यह निष्कर्ष निकला कि “window बदलते समय slow animation अच्छा है”
duplex printing supported नहीं है, इसलिए हाथ से करना पड़ता है, और कुछ apps pages को उलटे क्रम में print करते हैं, इसलिए फिर से sort करना पड़ता है
numpad के
.को,नहीं बल्कि.की तरह इस्तेमाल करने के लिए, normal default पाने हेतु app डाउनलोड करनी पड़ती हैEnglish keyboard इस्तेमाल न करें तो terminal में Alt+. भी काम नहीं करता
डाउनलोड की गई app चलाने के लिए उसे run करना, failure स्वीकार करना, settings और security में जाकर blocked app ढूँढना और allow करना पड़ता है। Windows Vista से भी बदतर
किसी app को permission देनी हो तो permission का type पता होना चाहिए, और app के आधार पर search नहीं कर सकते। ऐसी चीजें लगातार चलती रहती हैं
आज भी Finder sidebar के नीलेपन लिए gray icon shapes को समझने में बहुत ज्यादा समय लगाता हूँ
file structure, यहाँ तक कि file नाम की अवधारणा तक छिपाने की दिशा में और आगे बढ़ गए हैं। किसी non-technical Windows या Mac user से पूछें कि files कहाँ save होती हैं, तो उन्हें नहीं पता। पूछें कि cloud में हैं क्या, तो भी नहीं पता
इससे भी बुरी बात यह है कि UI की तरह, apps के बीच data save करने की location consistent नहीं है। file extensions छिपाने वाली मूर्खता को भी नहीं भूलना चाहिए
Windows non-English users से तो झूठ भी बोलता है। उदाहरण के लिए German में यह कहता है कि home directory “Benutzer” में है, जबकि असल में ऐसी कोई directory नहीं है, सिर्फ “Users” है। complexity छिपाने की कोशिश आखिर में भ्रम और ज्यादा complexity पैदा करती है
पहली full-time iOS job में आई एक और समस्या याद आती है। app description में “button” लिखा था और German translation “Knopf” थी, जो Apple के forbidden-words filter में फँस गई। शायद इसलिए कि “Knopf” “knob” का translation भी है, लेकिन German के “Knopf” में English “knob” जैसा genital hint नहीं है
Apple “files” की अवधारणा से हटकर “content” को कई apps के बीच ले जाने की दिशा में सबसे जोर से धक्का देने वाला लगता है। लेकिन हर app में sharing, import, export के paradigms भी थोड़े-थोड़े अलग हैं
अब iCloud Drive की “Files” app भी है। इसका मतलब क्या है, यह मेरे phone पर है या iCloud Drive में मौजूद चीज को सिर्फ दिखा रहा है—यह कैसे पता चले? cloud icon का मतलब downloaded है या नहीं, और थोड़ा गहरा gray बनाम थोड़ा हल्का gray फिर क्या बताता है, समझ नहीं आता
जबकि सबसे non-technical users भी जानते हैं कि file extension क्या है और कैसे काम करता है
समझ नहीं आता Microsoft आखिर कर क्या रहा है
Explorer का एक और regression यह है कि पहले जिस directory में content होता था उसके बगल में छोटा “+” sign होता था, जिसे Microsoft ने हटा दिया
left panel के ऊपर cursor ले जाने पर ही वह बिना वजह दिखाई देता है। या शायद universally understood “+” symbol से पीछे जाकर मूर्खतापूर्ण triangle तक गिर गया है
अब regressions का पीछा भी नहीं कर सकते
डेस्कटॉप usability को mobile compatibility के लिए घटा दिया गया, फिर भी कई environments में mobile की मौजूदगी अब भी नहीं है। अब तो कृपया scrollbar वापस दे दें
एक बार किसी setting को खोजने में मैंने और developer ने काफी समय लगा दिया, लेकिन इस बात का कोई संकेत ही नहीं था कि window के नीचे और content व checkboxes हैं। hidden scrollbar आने से पहले यह चीज़ स्वाभाविक रूप से दिख जाती
समस्या यह है कि pointer अगर navigation panel के ऊपर हो—जहां वह लगभग हमेशा रहता है—तो दूसरे panel की scrollbar छिप जाती है। scrollbar जैसा visual cue न होने से, दूसरे panel में और content है यह पता लगाने के लिए pointer हिलाने की कोई वजह ही नहीं थी। अब तो सभी borders भी हटा दिए गए हैं, इसलिए यह भी पता न चले कि वह अलग panel है
मैंने developer को screenshot भेजा और बताया कि मैं latest version इस्तेमाल कर रहा हूं, तो जवाब आया: “नीचे scroll करें।” जाहिर है, बेवकूफ तो मैं ही रहा होऊंगा। /s
mobile की तरह हर UI element को randomly छू-छूकर पता लगाना पड़ता है कि वह कैसे काम करता है, और इस तरह सीखी गई skill सिर्फ उसी एक app में चलती है। tap करो, long tap करो, long tap की अवधि बदलो, और तेज tap करो, अंधाधुंध दबाओ, “Google” करो, और इस बार ऐसी जगह drag करो जो UI element जैसी दिखती भी नहीं
“क्या checkbox checked है?” कभी भी “क्या slider switch on है?” जितना अस्पष्ट नहीं था। checkbox screen space भी कम लेता है। यह न space के लिए optimize है, न user-friendliness के लिए; यह बस दिखावट के लिए optimize किया गया है
इसे और flat बनाकर दो rectangles जैसा दिखा दें तो यह और भी खराब हो सकता है। dark area switch वाला हिस्सा है क्या? किसे परवाह है। बस साफ-सुथरा और distraction-free दिखना चाहिए। शायद switch की state समझ पाना ही मेरे लिए बहुत distracting था
उस किताब ने pages खर्च करके कहा कि modes से बचना चाहिए, और वजह भी समझाई। page 70 पर दिए UI do’s and don’ts दोहराने लायक हैं
do’s ये थे: object की appearance पर user को जितना हो सके control देना, action करने वाले menu commands में verbs इस्तेमाल करना, alerts को self-explanatory बनाना, और सिर्फ menu commands नहीं बल्कि controls और graphics भी इस्तेमाल करना
don’ts ये थे: modes का misuse, mouse से आसान कामों के लिए keyboard थोपना या इसका उलटा थोपना, खासकर scrolling जैसी चीज़ों से screen की shape को अनपेक्षित रूप से बदलना, objects को बेवजह redraw करना, और standard menus जैसे नामों वाले अपने custom menus बनाना। About, File, Edit और उनके अंदर क्या होना चाहिए—यह तक उस किताब ने define किया था
हम एक अजीब local minimum में आ गए हैं, जहां हर app का अलग एकमात्र सही UI होता है और सभी users पर वही एक जैसा रूप थोप दिया जाता है। इसके उलट industrial control जैसे क्षेत्रों में, जहां 50,000 डॉलर के equipment से जुड़ी app 1–3 लोग इस्तेमाल करते हैं, responsive mobile interfaces को slide deck बनाने जितनी आसानी से arrange किया जाता है, और custom dashboard भी सिर्फ एक widget से बन जाता है
अगर cloud ने जूते बनाए होते, तो घास के लिए और concrete के लिए जूते अलग होते, लेकिन सबका size एक ही होता; पैर बड़े हों तो उंगलियां काटनी पड़तीं, और छोटे हों तो fillers भरने पड़ते
scroll वाली शिकायत से जुड़ा, पुराने desktop UI को देखते हुए एक desktop-specific principle साफ दिखता है। controls कभी scroll नहीं होते, सिर्फ content scroll होता है
अगर controls window में fit नहीं होते, तो उस window को scrollable नहीं बनाया जाता; उसे tabs में बांटा जाता है या buttons से खुलने वाली अलग window में extra controls रखे जाते हैं। कम से कम Windows और macOS में यह एक सामान्य principle लगता है
checkbox कहीं बेहतर है, बस label में double negative न हो। उदाहरण के लिए, checkbox tick करने पर कोई चीज़ disable हो जाए—ऐसा बनाने वाले developer को सुबह-सुबह गोली मार देने लायक समझा जाता है
sliding circle सच में on है या off, यह भी नहीं पता चलता; और आधे मामलों में on और off में से मुझे क्या चाहिए, यह तक समझ नहीं आता। double negatives भरे पड़े हैं, phrasing अजीब है, और actual impact का कोई संकेत भी नहीं
सब कुछ पागलपन जैसा लगता है
कहा गया था कि Google जैसी जगहें हाल में A/B testing में और डूबती जा रही हैं, लेकिन user research के इतिहास में किसी भी A/B test ने कभी यह ठीक से नहीं मापा कि कोई button किसी भी वजह से move होने पर power users में कैसी भयंकर नाराज़गी फूट पड़ती है
पोर्टेबल म्यूज़िक प्लेयर—पुराने शब्दों में Walkman या MP3 प्लेयर, आजकल के शब्दों में DAP—का क्षेत्र मेरी स्थायी शिकायत है। अभी बिक रहे प्लेयरों की usability इतनी भयानक है कि समझ नहीं आता इन्हें कौन खरीदना चाहेगा
अच्छे प्रोडक्ट streaming services और Android devices के कॉम्बिनेशन के आगे गायब हो गए। अब हल्का और सरल, बड़ी क्षमता वाला, physical buttons और अच्छी battery life वाला प्लेयर नहीं मिलता। ऐसा सामान जिसे जेब में रखकर दौड़ें तो चोट न लगे
पढ़ने में आसान screen, ठीक-ठाक menu structure, file tags पढ़ने वाला और playlists को बस drag करके डालने देने वाला device। ऐसा चाहने वाले लोग पक्का हैं, लेकिन manufacturers उभरे हुए knobs और अजीब कोनों, battery खा जाने वाली बड़ी touchscreen, और घटिया Android variant OS के साथ विशाल ईंटें निकालते हैं
वे कहते हैं, “इसमें दो DAC हैं!” सच में? मैं 10,000 euro के monitors वाले soundproof listening room में नहीं, earphones लगाकर bus में हूँ
Reviews portable music devices के सबसे अहम पहलुओं को शायद ही छूते हैं, और wine critics की तरह music की खुशबू या स्वाद जैसी चीज़ों की तारीफ करते हैं। आधा मज़ाक है। जितना प्रतिष्ठित reviewer, उतनी ज़्यादा बकवास लिखता है, और अक्सर weight या size का ज़िक्र तक नहीं मिलता
ज़िक्र करें भी तो गलत। जैसे, “Shanling Q1 एक हल्का portable device है”—बिल्कुल नहीं। यह घटिया OS, खराब battery life और जरूरत से ज़्यादा sensitive buttons वाली भयानक ईंट है। आवाज़ कितनी भी अच्छी हो, अगर मैं playlist डाल नहीं सकता, यह भारी है और interface इतना खराब है कि इस्तेमाल करने का मन न करे, तो मुझे परवाह नहीं
13 साल पहले Sansa Clip+ पर Rockbox शानदार था। आज की technology से अगर वही चीज़ ज्यों की त्यों बनाई जा सके, तो मैं बेहिसाब महंगी और विशाल ईंटों के बजाय वही चुनूँगा
सच में दुख होता है कि UI, form factor, touchscreen जैसे खराब design decisions कैसे अच्छे-भले hardware को बर्बाद कर देते हैं
कई घंटे लगाने के बाद मुझे एक कामचलाऊ समाधान मिला। Amazon से Hifi Walker H2 खरीदा; इसमें typos समेत खराब UI design है, लेकिन hardware अच्छा है
उस पर RockBox install किया, और थोड़ा customize करने पर घटिया UI की समस्या हल हो गई। अफसोस की बात यह है कि RockBox Bluetooth या USB DAC support नहीं करता; अगर आपको ये features चाहिए तो यह समस्या है
“हमें screen space बचानी है, इसलिए… notes check करता हूँ… हम पूरी screen घेरने वाला button डालने वाले हैं”
“title bar में ले जाने से screen space बचती है” वाली बात में मुझे हमेशा यही बात खटकती है
आजकल एक और बात गुस्सा दिलाती है कि कई applications चलते समय focus को कई बार चुरा लेती हैं। इस बेतुकी focus stealing की वजह से team chat में गलती से password पोस्ट कर देने वाले लोग बहुत ज़्यादा हैं
जब iOS ने long press शुरू किया, तभी मुझे लगा कि खेल लगभग खत्म हो गया। किसी UI element को दबाने पर क्या होगा, यह पता नहीं चल सकता था, इसलिए सब कुछ tap करके देखना पड़ता था, और अब अलग action के लिए long press करना पड़ता है
मैं हर element को tap करने और फिर long press करने में समय नहीं लगा सकता, सिर्फ यह जानने के लिए कि app वह काम कर सकता है या नहीं जिसकी मैं सोचता या उम्मीद करता हूँ
साफ लगता था कि इसे ऐसे ही काम करना चाहिए, लेकिन अब long press मनमाने कामों के लिए इस्तेमाल होता है
इसे साबित तो नहीं किया जा सकता, लेकिन मुझे लगता है कि ऐसी UI/UX आपदाएं कई बार इस दबाव से पैदा होती हैं कि software ज़िंदा दिखने के लिए हमेशा बदलता रहना चाहिए
कल्पना करें कि 2023 में कोई app usability की चरम सीमा पर पहुंच गया। वह perfect नहीं है, लेकिन उसकी usability को और बेहतर बनाने का कोई कल्पनीय तरीका नहीं है। users काफ़ी कुशल हो चुके हैं, और app सीखने की अंतर्निहित बाधा पार करने के बाद सब कुछ कुल मिलाकर ठीक बैठता है
क्या यह स्थिति बनी रह सकती है? नहीं। अगर UI को वैसा ही छोड़ दिया जाए, तो software जगत अक्सर उस app को “पुराना” या यहां तक कि मृत मानने लगता है। इसलिए उसे बदलना पड़ता है। लेकिन usability के शिखर के बाद कुछ भी बदलने पर UX अनिवार्य रूप से खराब होता है, और कभी-कभी विनाशकारी हद तक
मुझे लगता है कि कुछ apps और desktop environments के ठीक-ठाक UI के पूरी तरह बिगड़ जाने की यह एक वजह है
तेज़, हमेशा-on internet connection के आम हो जाने ने इस समस्या को बहुत बढ़ा दिया। पहले software developers को product को CD या floppy वगैरह में डालकर दुकानों तक भेजना पड़ता था, और आसानी से update करने का मौका नहीं होता था, इसलिए कम-से-कम स्पष्ट लक्ष्य और deadline की ज़रूरत होती थी
update जारी करते समय भी वह इतना meaningful और substantial होना चाहिए था कि user नया version हासिल कर उसे install करने की मेहनत उठाए। इसके उलट, आधुनिक software पर हमारी भाषा की एक कहावत का थोड़ा खुरदुरा अनुवाद सबसे ठीक बैठता है: “समुराई का कोई लक्ष्य नहीं होता, सिर्फ़ रास्ता होता है”
मेरा आदर्श यह है कि कोई प्रिय और व्यापक रूप से इस्तेमाल होने वाला product बनाया जाए, customer support और operations से जुड़ी जितनी समस्याएं संभव हों उन्हें automate किया जाए, और फिर किसी दूसरे product पर चला जाए या beach पर आराम किया जाए
कोई बदलाव नहीं चाहता। मैंने हर बार UI बदलने पर शिकायत करने वाली भीड़ ही देखी है; दूसरी तरफ से उतने ही बड़े पैमाने पर सच्चे भक्तों की भीड़ निकलती कभी नहीं देखी
शुरुआत में हम चाहते हैं कि लोग हमारा product पसंद करें; हम ध्यान देते हैं, सुनते हैं, और usability पर resources लगाते हैं। खुश customer हमें खुश करते हैं
बीच के चरण में एहसास होता है कि usability कठिन है, ergonomics और affordance बनाना जितना सोचा था उतना आसान नहीं, और internationalization भी साथ आ जाता है। कोई भी यह क्षेत्र ठीक से नहीं सिखाता, इसलिए ज़्यादातर खुद सीखना पड़ता है, और contractors महंगे होते हैं
गिरावट के चरण में हम और features बनाना चाहते हैं, इसलिए और programmers hire करते हैं, और usability team को यह कहकर निकाल देते हैं कि “ज़रूरी सब कर लिया गया है।” documentation team को भी निकाल देते हैं। माना जाता है कि software developers engineer हैं, तो FAQ तो लिख ही सकते हैं
सबसे निचले चरण में, शानदार sprints के जरिए customers पर ढेरों features फेंकने के बावजूद customers नाखुश रहते हैं। फिर पूछना पड़ता है, “customers के साथ दिक्कत क्या है?”
Office 2007 के बाद कुछ समय तक मैं सांस रोके यही उम्मीद करता रहा कि OpenOffice/LibreOffice developers जल्दबाज़ी में Ribbon implement न करें। अब तक उनका टिके रहना एक छोटी-सी उजली बात है
लगभग perfect v1 में उपयोगी रही पूरी UX team को भी लगातार वेतन दिया जा रहा है, इसलिए उन्हें काम खिलाते रहना पड़ता है