- Gnome Files को वास्तव में फ़ाइलें व्यवस्थित करने के लिए इस्तेमाल करते समय view switch, path input, help, tooltip, window move जैसी बुनियादी क्रियाएँ उपयोगकर्ता को भ्रमित करती हैं — यही इसकी आलोचना का केंद्र है
- “View Options” dropdown वास्तव में sorting options दिखाता है, जबकि view switch split button के दूसरे हिस्से में छिपा है, इसलिए नाम और function placement एक-दूसरे से मेल नहीं खाते
- path bar टेक्स्ट input जैसा दिखता है, लेकिन माउस से edit नहीं किया जा सकता और केवल Ctrl-L shortcut से सक्रिय होता है, जिससे GUI feature की discoverability कम हो जाती है
- title bar हटाकर बनाई गई ऊपरी area में button click, window drag, context menu एक-दूसरे पर overlap करते हैं, और hidden scrollbar भी pointer ले जाने पर अपनी position बदल देता है, जिससे बुनियादी क्रियाएँ अनिश्चित लगती हैं
- नया UI paradigm menu bar, title bar, और shortcuts के सुसंगत प्रदर्शन जैसे आज़माए हुए pattern से बेहतर नतीजा नहीं दे पाया, और पुराना तरीका अपने-आप बुरा नहीं होता
Gnome Files चुनने का कारण और आधार
- आलोचना का फ़ोकस flat design पर नहीं, बल्कि core program features तक पहुँचने के तरीके पर है
- यह माना गया है कि modern design शुरुआती उपयोगकर्ताओं के लिए अनुकूल हो सकता है, लेकिन रोज़ कई घंटे कंप्यूटर इस्तेमाल करने वाले power user भी design target का हिस्सा होने चाहिए
- इंटरफ़ेस जितनी अधिक सुविधाएँ छिपाता है, उपयोगकर्ता के लिए उन्हें खोजने और सीखने का अवसर उतना ही कम हो जाता है
- Gnome कई प्रमुख Linux distributions में default desktop environment होता है, और “usable by everyone”, “structurally and aesthetically elegant”, “distraction free”, “traditional desktop is dead” जैसी दिशाएँ सार्वजनिक रूप से रखता है
- Gnome Files desktop environment का केंद्रीय file manager है, इसलिए Gnome की UI philosophy को समझने के लिए यह एक महत्वपूर्ण उदाहरण है
list view switch में दिखने वाली menu structure की समस्या
- पहली नज़र में UI साफ़-सुथरा और शांत लगता है, और clickable elements भी कुछ हद तक अलग पहचाने जा सकते हैं
- बड़े icons की जगह list view में बदलने की कोशिश करते ही समस्या शुरू होती है
- toolbar में एक-दूसरे जैसे दिखने वाले icons हैं, और “View Options” tooltip वाला dropdown view options नहीं बल्कि कई sorting options दिखाता है
- असली view-related options जैसे “Icon Size” और “Show Hidden Files”, “Main Menu” में हैं, इसलिए “View Options” नाम और वास्तविक contents में मेल नहीं है
- list view switch “View Options” dropdown का हिस्सा नहीं, बल्कि split button के toggle area में है
- dropdown में toggle function साथ में सूचीबद्ध नहीं है, इसलिए इसे उसी widget में रखने का कारण स्पष्ट नहीं है
- इस संरचना की वजह से list view toggle ढूँढने में समय लगा, और इससे structural elegance की जगह निराशा मिली
help और tooltip की discoverability की समस्या
- built-in help में “list view” खोजने पर भी list view को enable करने का तरीका तुरंत मिलना मुश्किल है
- Gnome Files menu से help खोलने पर भी search results में दूसरे applications से जुड़े items साथ में दिखते हैं
- “Browse files and folders” Gnome Files से संबंधित था, लेकिन वह “Manage volumes and partitions”, “Edit contact details” जैसे items के बाद दिखाई देता है
- help को सीधे देखने पर मिला “List View” संबंधित item उन कामों के बारे में था जो list view चुने जाने के बाद किए जा सकते हैं
- tooltip उपयोगी हो सकते हैं, लेकिन Gnome Help और Gnome Files में अनावश्यक tooltip उल्टा बाधा बनते हैं
- Gnome Help में item title के समान टेक्स्ट वाला tooltip अगले item title को ढक देता है
- Gnome Files के बाएँ sidebar में “Recent”, “Starred” जैसे items पर भी स्पष्ट और अनावश्यक tooltip दिखते हैं
- ऐसा व्यवहार उपयोगकर्ता को यह सिखा सकता है कि tooltip उपयोगी जानकारी नहीं, बल्कि बाधा हैं
path navigation और shortcut-केंद्रित feature exposure
- Gnome Files में navigation सामान्यतः ठीक है, लेकिन ऊपर की directory में जाने के लिए parent directory button का न होना खटकता है
- back/forward buttons केवल navigation history में चलते हैं, वे parent folder में जाने के बराबर नहीं हैं
- location bar में directory name पर क्लिक करके जाया जा सकता है, लेकिन यह parent folder button की तुलना में misclick के लिए अधिक संवेदनशील और कम सुविधाजनक है
- location bar टेक्स्ट box जैसा दिखता है, लेकिन माउस से सामान्य edit mode सक्रिय नहीं किया जा सकता
- edit mode शायद केवल Ctrl-L shortcut से ही सक्रिय होता है
- पहले लगा कि यह feature मौजूद ही नहीं है, बाद में खोजने पर पता चला, और Keyboard Shortcuts window में यह shortcut सूचीबद्ध है
- यदि GUI elements तक माउस से पहुँचना संभव न हो, तो discoverability घट जाती है
shortcut window और menu bar replacement की सीमाएँ
- shortcut list 3 pages की है और search भी है, लेकिन क्या खोजें यह न पता हो तो इसका उपयोग कठिन है
- Gnome Help location bar को “path bar” कहता है, लेकिन shortcut window में “path” खोजने पर कोई result नहीं मिलता
- shortcut list में contents या categories को जल्दी skim करने का तरीका नहीं है, इसलिए pages एक-एक करके देखने पड़ते हैं
- Keyboard Shortcuts window खोलने का shortcut भी है, लेकिन कुछ अन्य shortcuts की तरह Main Menu के संबंधित item के बगल में वह नहीं दिखता
- पारंपरिक menu bar program features को category के अनुसार व्यवस्थित कर हमेशा visible रखता है, shortcuts को सुसंगत रूप से दिखाता है, और खोजे गए option को तुरंत चलाने देता है
- Gnome Files में features UI के अलग-अलग हिस्सों में बिखरे हुए हैं, और कुछ hidden features के बारे में केवल modal shortcut window से ही सीखा जा सकता है
- shortcut window non-interactive और modal है, इसलिए उसे खुला रखकर प्रयोग नहीं किया जा सकता
- उपयोगकर्ता को shortcut ढूँढना, याद रखना, window बंद करना और फिर feature चलाना पड़ता है
- mouse-centered environment में GUI के जरिए features ढूँढने और चलाने का तरीका न होना सीमित और भ्रमित करने वाला है
title bar के बिना ऊपरी UI की अस्पष्टता
- Gnome Files में वास्तविक title bar नहीं है, इसलिए window को ऊपर के क्षेत्र पर क्लिक करके drag करके move किया जाता है
- इस ऊपरी क्षेत्र में toolbar भी है, इसलिए पहले से function वाले UI controls पर क्लिक की हुई स्थिति में भी window move हो सकती है
- search icon पर क्लिक करके search खोला जा सकता है, या उसी icon पर क्लिक पकड़े रखते हुए drag करके window move की जा सकती है
- back/forward buttons context click या long click से location history खोल सकते हैं, लेकिन button खुद इस function का संकेत नहीं देता
- इस feature के लिए कोई shortcut भी नहीं दिखता
- दूसरे items पर long click करने पर context menu नहीं खुलता, इसलिए behavior सुसंगत नहीं है
- window को सामने लाने के लिए ऐसे non-click area को ढूँढना पड़ता है जो program function को न छुए
- search चलने, path navigation, view switch, या अन्य feature activation जैसी गलत क्रियाओं से बचना पड़ता है
- सिर्फ window activate करने के लिए भी उपयोगकर्ता को सावधान रहना पड़ता है, जिससे cognitive load बढ़ता है
- ऊपर के क्षेत्र पर right click करने पर position के अनुसार window management menu या directory operation menu खुलता है, और परिणाम current directory या click position के अनुसार बदलता है
- middle click से current directory सहित directory name को नए tab में खोला जा सकता है, और यह feature context menu में भी मौजूद है
hidden scrollbar और default theme का व्यवहार
- Gnome Files या GTK 4 hidden scrollbar का उपयोग करते हैं
- यह व्यवहार default settings और Debian द्वारा दिए गए default GTK 4 theme में देखा गया
- hidden scrollbar सिर्फ manipulability ही नहीं छिपाता, बल्कि file list या document में वर्तमान position की जानकारी भी छिपा देता है
- माउस हिलाने पर scrollbar दिखता है, लेकिन वह छोटा और कम contrast वाला लगता है, इसलिए देखना मुश्किल होता है
- pointer को scrollbar पर ले जाने पर scrollbar बड़ा होकर अधिक स्पष्ट होता है, लेकिन अपनी मूल चौड़ाई जितना बाएँ खिसक जाता है, जिससे pointer अब scrollbar के ऊपर नहीं रहता
समग्र मूल्यांकन और निष्कर्ष
- Gnome Files UI को haphazard, incoherent, और कभी-कभी ख़तरनाक महसूस होने वाला बताया गया है
- मुख्य समस्याएँ इस प्रकार हैं
- menu के नाम और contents मेल नहीं खाते, और वास्तविक view options कई जगह बिखरे हैं
- shortcuts menu में सुसंगत रूप से नहीं दिखाए जाते
- कुछ सामान्य features तक पहुँचना और उनका पता लगाना केवल shortcuts से संभव है
- widgets का बाहरी रूप उनके व्यवहार का सही अनुमान नहीं देता
- tooltip गलतफ़हमी पैदा करते हैं या जानकारी दिए बिना बाधा बनते हैं
- function icons पर क्लिक करके window move करने की व्यवस्था misclick का जोखिम बढ़ाती है
- ऊपर के क्षेत्र में context click का परिणाम अनुमान लगाना कठिन है
- default theme का scrollbar pointer ले जाने पर अपनी position बदलता है
- help और वास्तविक GUI की terminology अलग-अलग है
- ऐसी असंगतियाँ उपयोगकर्ता के लिए UI का स्थिर mental model बनाना कठिन कर देती हैं
- कार्यात्मक रूप से Gnome Files से file management किया जा सकता है, और यदि दूसरा विकल्प न हो तो UI की इन विशेषताओं की आदत भी पड़ सकती है
- लेकिन Gnome Files जैसे केंद्रीय application में भी UI design के नज़रिए से कई ऐसे तत्व हैं जिन्हें खराब कहा जा सकता है
- इसका मतलब यह नहीं कि पुराना desktop paradigm या सभी पुराने programs परिपूर्ण थे, लेकिन सवाल यह बना रहता है कि नए paradigm को बेहतर परिणाम देने चाहिए
- आलोचना की गई अधिकांश समस्याओं के समाधान दशकों से परिष्कृत रूप में मौजूद हैं
- वास्तविक window title bar
- menu में shortcuts को सुसंगत रूप से दिखाने का तरीका
- menu और options की सुसंगत categorization
- अधिक समृद्ध design language
- पुराना तरीका अपने-आप बदतर नहीं होता, और नया तरीका अपने-आप बेहतर नहीं होता
1 टिप्पणियां
Hacker News की टिप्पणियाँ
Files के list view में नया दस्तावेज़ बनाना या paste करना हो तो सिर्फ़ खाली जगह पर right-click करने की अनुमति होने वाली समस्या याद आती है
list view में अगर फ़ाइलें थोड़ी भी ज़्यादा हों और विंडो भर जाए, तो क्लिक करने के लिए खाली जगह ही नहीं बचती
पहले भी लोगों ने यही समस्या झेली है 0, और लगता है कि अब तक यह ठीक से ठीक नहीं हुई है 1
खोजने पर पता चला कि Thunar में
Ctrlदबाकर कहीं भी right-click करें तो नया फ़ोल्डर बनाना, paste करना, terminal में खोलना जैसे मेनू आ जाते हैंलेकिन अगर कोई फ़ाइल selected हो तो selected item का context menu खुलता है, इसलिए नया फ़ोल्डर वाला option नहीं दिखता; आख़िरकार selection हटाने के लिए खाली जगह क्लिक करनी पड़ती है या
Escapeपता होना चाहिए, इसलिए यह आदर्श नहीं हैपूरा article tile, link text, image, यहाँ तक कि चौड़ा whitespace भी link बन जाता है, और tiles के बीच की पतली-सी दरार ही background के रूप में clickable रहती है
अगर touch-first design हो तो समझ आता है, लेकिन GNOME जैसे desktop software में भी कई input methods को एक साथ संतुष्ट करने की कोशिश में वैसा ही लक्ष्य घुस आया हो, ऐसा लगता है
लिंक किए गए issue में right-clickable area दिखाने वाली image है
https://gitlab.gnome.org/-/project/1/uploads/50ac36ab40f9049f4a823f77aa9a8a29/gr-files-right-click-zones.jpg
इसलिए parent folder तक ऊपर जाता हूँ, फिर ऐसा फ़ोल्डर ढूँढता हूँ जो पूरा भरा न हो, वहीं Terminal खोलता हूँ, और फिर
cdसे वापस मूल फ़ोल्डर में उतरता हूँcontext menu में वही actions दिखने चाहिए जो right-click किए गए object पर लागू हो सकते हैं, और “नया दस्तावेज़” किसी फ़ाइल या फ़ोल्डर icon की function नहीं है
किसी फ़ोल्डर पर right-click करने पर नया दस्तावेज़ मौजूदा फ़ोल्डर में बनेगा या clicked folder के अंदर, यह भी अस्पष्ट है
ऐसे common tasks को खाली जगह के right-click context menu से अलग, हमेशा दिखने वाले icon bar के menu item में रखना बेहतर है
आलोचना ठीक है, लेकिन इसमें design language और बारीकियों की अधूरी polish से आने वाली UI झुंझलाहट को मिलाकर देखा गया है
अभी का macOS Finder देखें तो उसका design GNOME Files से बहुत मिलता-जुलता है: https://a.qoid.us/20240907-finder.png
इसलिए विंडो को drag करना मुश्किल होना या विंडो पर क्लिक करके activate करना कठिन होना जैसी design की बुनियादी कमियाँ Finder में भी हैं
लेकिन macOS उन अधिकतर detail समस्याओं से बच जाता है जिनकी ओर लेखक ने इशारा किया है
view options के लिए icon मिलते-जुलते हैं, लेकिन Finder में icon के दाईं ओर का छोटा arrow भी हमेशा उसी button का हिस्सा होता है, और लेखक जिस तरह के split button की शिकायत करता है, वह वहाँ नहीं है
help के मामले में macOS User Guide icon के अर्थ समझाता है, और Help में टाइप करने पर वह सभी menus के items खोजकर दिखाता है
“list” टाइप करें तो “as List” menu item आता है और चाहा गया action किया जा सकता है
tooltips बाईं ओर की location list में नहीं होते, सिर्फ़ toolbar icons पर होते हैं, और वे भी देर से दिखते हैं
navigation में Finder में path bar लगभग होता ही नहीं, path से खोलने वाला dialog भी छिपा होता है, और parent folder में जाने का action भी आसानी से नज़र नहीं आता
फिर भी ऐसा कोई element नहीं है जो editable लगे लेकिन वास्तव में editable न हो
scrollbar default रूप से छिपे रहते हैं, लेकिन विंडो के दाईं ओर ही रहते हैं; लेखक की शिकायत की तरह बाईं ओर उछलते नहीं
यक़ीन न हो तो mouse वाले device पर https://macos9.app खोलकर फ़ाइलों को व्यवस्थित और browse करके देख लें
हमेशा ऐसा लगा जैसे उसे NeXTStep से जैसे-तैसे port किया गया और फिर जल्दी ही छोड़ दिया गया
कुल मिलाकर Apple ने पिछले लगभग 10 वर्षों में UI की समझ खो दी है, और macOS को अब अच्छे desktop UI के उदाहरण के रूप में इस्तेमाल नहीं करना चाहिए
उसे चालू करने के लिए menu item मौजूद है
अगर कोई Apple की इस marketing पर यक़ीन करता है कि उसका OS सबसे ergonomic है, तो वह हास्यास्पद है
tree view जैसी किसी जगह में नया फ़ोल्डर बनाना या फ़ाइल paste करना चाहें तो वह top-level parent folder में चला जाता है; नया फ़ोल्डर बनाना भी किसी दुःस्वप्न जैसा है
recent date के हिसाब से sorting भी समझ से बाहर है
कुल मिलाकर newest से oldest क्रम है, लेकिन किसी खास date या पिछले हफ़्ते जैसे group के भीतर उल्टा oldest से newest क्रम हो जाता है
इसके अलावा ऐसी अजीब decisions सैकड़ों हैं
Enterkey से फ़ाइल खोलने के बजाय फ़ाइल नाम edit करवाना भी समझना मुश्किल हैयानी बहुत कम होने वाले काम के लिए एक मुख्य key दे दी गई है
GNOME गलती से क्लिक होने से बचाने के लिए Power off को अतिरिक्त सबमेनू में छिपा देता है, लेकिन Files में Format को “Safely remove drive” के ठीक बगल में रखता है
optदबाने पर shutdown/restart बिना पुष्टि के दो क्लिक में तुरंत हो जाता है, लेकिन GNOME में चार क्लिक और ऊपर से अटपटी animation भी हैदोनों ही title bar में controls इतने ठूँस देते हैं कि window को drag करने की जगह ही नहीं बचती
मैंने हाल ही में G4 पर OS X 10.5 एक हफ्ते इस्तेमाल किया, और लगा कि शायद वही desktop का शिखर था
उदाहरण के लिए USB mass storage device मेनू में ‘Eject’ और ‘Format’ साथ-साथ दिखते हैं
एक हानिरहित है, लेकिन दूसरा संभावित रूप से विनाशकारी
Format के बाद
...लगा है, यानी एक dialog खुलेगा, और वह dialog 2-step प्रक्रिया है जिसके अंत में सारा data स्थायी रूप से मिट जाने की लाल चेतावनी आती हैडिवाइस को गलती से format कर देने का कोई तरीका नहीं है
अगर जल्दी से power off करना हो, तो power button का व्यवहार sleep की जगह shutdown पर बदल सकते हैं
ऐसा लेख पढ़कर अच्छा लगा
मैं भी अक्सर सोचता हूँ कि GUI की छोटी-छोटी झुंझलाहटों को पूरी तरह खंगालूँ और लिखूँ कि चीजें बेहतर होनी चाहिए
Ctrl+Lबिना संदर्भ के देखें तो अजीब shortcut है, लेकिन browser में 15 साल से इस्तेमाल करते आ रहे हैं, इसलिए परिचित लगता हैWindows, GNOME और Nautilus तीनों में इसका साझा होना लंबे समय से इस्तेमाल करने वालों या power users के लिए अच्छा है
दोबारा पढ़ने पर लगता है कि शिकायत shortcut से ज़्यादा इस बात की है कि उसके अलावा कोई और तरीका नहीं है
लेख में नहीं कहा गया एक बड़ा मुद्दा यह है कि मौजूदा GNOME UI, Windows 11 जैसा बहुत लगता है, लेकिन tooltip या clickable location bar जैसी कई बारीक चीजें बिगाड़ देता है
मैंने Ubuntu 14.04 और 20.04 में GNOME इस्तेमाल किया, फिर 22.04 में stability की समस्या आई, और अब XFCE संतोष से इस्तेमाल कर रहा हूँ; लंबी अवधि की स्थिरता सबसे अच्छी चीज़ है
अब bar पर क्लिक करते ही सीधे edit mode में जा सकते हैं
GNOME के दृष्टिकोण की सबसे बुरी बात शायद अहंकार है
वे usability research करने और usability पर ध्यान देने की बात बार-बार करते हैं, इसलिए जब किसी व्यक्ति को उसे इस्तेमाल करना मुश्किल लगे तो झुंझलाहट उलटे दोगुनी हो जाती है
सुनने में ऐसा लगता है जैसे, “औसत user खुश है, तो समस्या तुम हो”
अगर वास्तव में कोई disability हो, तो political कारणों से उस UI को प्राथमिकता देने की संभावना और बढ़ जाएगी
कभी-कभी GNOME cult की गहराइयों में Mother Gnome नाम का एक ही व्यक्ति होने की कल्पना मज़ेदार लगती है
जो कानूनी रूप से दृष्टिबाधित है, शारीरिक रूप से keyboard इस्तेमाल नहीं कर सकता, और कंप्यूटर उपयोगकर्ताओं में परंपरागत रूप से कम प्रतिनिधित्व वाले हर समूह से एक साथ आता है; खुद उसने कभी कंप्यूटर इस्तेमाल नहीं किया, बस अपने Gen Alpha परनाती/परपोते से कुछ iPhone चीजें सीखी हैं
ये सब गुण मिलकर उसे UI design का utility monster बना देते हैं, और फिर किसी भी कीमत पर उसी के हिसाब से design करना एक पूर्ण नैतिक आदेश बन जाता है
अच्छा होगा अगर कोई distro यह भूमिका अपने हाथ में ले
“मैं मानता हूँ कि modern design paradigm कई मामलों में नए users के लिए अनुकूल है, लेकिन एक समय के बाद लोग नए user नहीं रहते। जो लोग हर दिन कई घंटे कंप्यूटर पर बिताते हैं और अलग-अलग programs में तरह-तरह के काम करते हैं, उन्हें भी design में ध्यान में रखा जाना चाहिए। इसलिए मेरी आलोचना अक्सर कहे जाने वाले power user नज़रिए से आती है। साथ ही, interface जितनी ज़्यादा चीजें छिपाता है, उतना ही कम वह users को आगे बढ़ने और सीखने का मौका देता है”
यह सब कहने के बाद keyboard shortcut इस्तेमाल करने की ज़रूरत पर शिकायत करना मुझे कुछ ज़्यादा लगता है
ऊपर से वह feature वैसे भी keyboard माँगने वाला feature है
ऊपर जाने वाले button के न होने की शिकायत या list view की आलोचना भी बहुत प्रभावी नहीं लगती
screenshot में list icon तुरंत पहचाना जा सकता था, और मुझे तो ऐसी window अच्छी लगती है जिसमें duplicate function buttons हर जगह ठूँसकर नहीं रखे जाते
“दबाना मुश्किल है” वाली बात भी अजीब लगती है
कोई कहे कि उसने 35 साल से कंप्यूटर इस्तेमाल किया है, लेकिन एक path को mouse से क्लिक नहीं कर सकता, यह मानना कठिन है
यह उस तरह की आम शिकायत जैसी लगती है जिसमें कोई किसी system का आदी होकर खुद को power user मान लेता है और उम्मीद करता है कि बाकी सब भी बिल्कुल वैसा ही काम करें
यही लोग terminal में
Ctrl-Cसे copy न होने पर कहते हैं कि “standard shortcut” टूट गयाजो आपको आसान लगता है, वह ज़रूरी नहीं कि दूसरों को भी आसान लगे; usability का काम इसी मान्यता से शुरू होता है
हैरानी होती है कि ऊपर जैसी tech communities मानव cognition की इतनी बुनियादी बातों का भी इतना विरोध करती हैं
उलटे वह टिप्पणी ही शिकायत लगती है, जबकि मूल लेख दशकों के शोध से निकले वास्तविक data को लागू कर रहा है
मैंने पहले यह लिखा था: https://news.ycombinator.com/item?id=41303387
यह तो सोचा भी नहीं होता कि icon खुद एक toggle है
वह toggle की तरह render भी नहीं किया गया है, और क्योंकि view options दो से ज़्यादा होने की अपेक्षा रहती है
आप path paste कर सकते हैं
dictation जैसी assistive technology भी इस्तेमाल कर सकते हैं, और phone की तरह ऐसे input methods भी हो सकते हैं जहाँ
Ctrlदबाने का तरीका ही न होबेशक, phone UI को अलग मानकों से देखना चाहिए
उससे भी बुरा यह कि अलग-अलग terminal applications में कौन से shortcuts चलते हैं, इसमें कोई consistency नहीं है
यह एक गड़बड़ है, और इसकी शिकायत जायज़ है
कुछ साल पहले मैंने मूल लेख जैसी ही एक और पोस्ट पढ़ी थी, जिसमें text box हटाने की आलोचना की गई थी; तभी पता चला
नहीं तो मुझे बिल्कुल मालूम नहीं होता कि keyboard shortcut से path text box सक्रिय किया जा सकता है
UI सिर्फ इस्तेमाल में आसान ही नहीं, discoverable भी होना चाहिए
अगर power users भी ज़रूरी features ढूँढने में कठिनाई महसूस करें, तो यह क्यों मानें कि बाकी UI सबके लिए आसान और discoverable है?
सच कहूँ तो UI का लगभग इस्तेमाल ही नहीं करता; आमतौर पर terminal इस्तेमाल करता हूँ, और सिर्फ keyboard firmware upgrade करते समय Jade का file manager इस्तेमाल करता हूँ
क्या save dialog ठीक किया गया है?
कोई
-s filenameटाइप करे तो उम्मीद होगी कि मौजूदा फ़ाइलfilenameके रूप में save हो जाएextension जुड़ सकता है
gtk-2 में behavior यह था कि जैसे ही
filenameटाइप करना शुरू करते, वह file/directory list में search करता, औरEnterदबाने पर highlighted item चुन लेता थाखैर, यह जांचने के लिए GNOME install करने का मेरा कोई इरादा नहीं है
यह भी हैरानी की बात नहीं कि file browser उतना खराब है जितना लेख में बताया गया है
jwz का cadt (cascade of attention deficit teenagers) software engineering model मूल रूप से GNOME project के व्यवहार को समझाने के लिए ही था
इसलिए यह ठीक हो चुका है
समझ नहीं आता कि “clean” UI को लेकर इतनी सनक क्यों है
हर चीज़ छिपाकर उसे बड़े whitespace और बिना किसी पहचान वाले icons में बदल देना कैसे “calm” है, यह मेरी समझ से बाहर है
यह किसी खाली घर या इस्तेमाल न होने वाली workshop की तरह निर्जीव और ठंडा लगता है
कम जटिल विकल्प मौजूद होना अच्छी बात है, और समझ नहीं आता कि हर desktop environment को एक जैसा ही क्यों काम करना चाहिए
वह बस काम करता है, उसे छेड़ने की ज़रूरत नहीं पड़ती, और वह रास्ते में नहीं आता
GNOME में, Files समेत, सबसे खराब चीज़ gtk3 और gtk4 का
gtkfilechooserwidget.cहैfile->opendialog में file path paste करने पर error आता है और popup दिखाई देता है — ऐसा bug हैGtk developers कहते हैं कि filechooser code इतना spaghetti code है कि कोई भी filename-entry location-mode को फिर से default behavior बनाना नहीं चाहता
मैं भी सहमत हूँ
gtk 3.22 और 3.24 में खुद patch करने के लिए मैंने एक साल तक रुक-रुक कर कोशिश की, लेकिन इसे सिर्फ़ किसी खास process के पहले
File->Openexecution में ही ठीक कर पाया; उसके बाद की opens में फिर error आ जाता थाGNOME UI और 2014 के बाद का Gtk, keyboard इस्तेमाल करने वालों को ध्यान में रखकर नहीं लिखा गया
यही इसकी सबसे बड़ी UI कमजोरी है
यह GNOME की कई परेशानियों में से एक है, और बहुत समय से GNOME के साथ चली आ रही समस्या है
लेकिन GNOME काफ़ी हद तक, शायद मुख्यतः, keyboard-centric है
3.0 के बाद से “इसे touch-first बनाया गया” वाला meme चलता रहा है, लेकिन ऐसा कहने वालों में शायद ही किसी ने वास्तव में touch device पर GNOME इस्तेमाल किया हो
वह एक nightmare है
GNOME के मुख्य controls keyboard shortcuts से, या फिर ऐसे बड़े mouse gestures से संचालित होते हैं जिनके keyboard alternatives और भी तेज़ होते हैं
ये शिकायतें ग़लत नहीं हैं, लेकिन सच में कितने users इन चीज़ों पर अटकते हैं, यह सोचने वाली बात है
जब list view चाहिए हो, तब list जैसा दिखने वाला icon क्लिक करना कोई अजीब व्यवहार नहीं है
मैं मानता हूँ कि dropdown का behavior थोड़ा अजीब है
इसी तरह, आजकल GNOME apps में title bars के अंदर controls होना एक accepted चीज़ है
अगर controls पर ठीक से click न हो और mouse drag शुरू हो जाए, जिससे window move हो, तो मुझे नहीं लगता कि यह इतना बड़ा issue है
लेकिन GNOME कहता है, “हमारा software इस तरह बनाया गया है कि हर कोई इसका इस्तेमाल कर सके। हम user experience को बेहद गंभीरता से लेते हैं।”
GNOME की आलोचना पहले से ही बहुत ज़्यादा है, और मैं खुद भी यहाँ कुछ लिख चुका हूँ, इसलिए और कहना समय की बर्बादी लगता है
developers के पास इस बारे में बहुत स्पष्ट vision है कि वे क्या हासिल करना चाहते हैं, इसलिए वे अपना विचार नहीं बदलेंगे
users भी उस तरीके को पसंद करते हैं और उसमें सहज हैं, इसलिए वे भी अपना विचार नहीं बदलेंगे
जो लोग इसे पसंद नहीं करते, या अब पसंद नहीं करते, वे भी अपना मन नहीं बदलेंगे क्योंकि यह उन्हें अजीब, उलझनभरा और सीमित लगता है
यह दिशा दस साल से भी ज़्यादा पुरानी है, और इसमें शायद ही कोई बदलाव होगा
जैसा लेखक ने कहा, GNOME एक ऐसा project है जो “चीज़ें कैसे होनी चाहिए, इस बारे में बहुत ऊँची आवाज़ में बोलता है — यानी काफी हद तक हठधर्मी है”
अंत में, अगर GNOME का तरीका आपको पसंद है तो उसका इस्तेमाल करें, नहीं तो कहीं और जाएँ
बस, यह “हर कोई इस्तेमाल कर सके” वाले नारे से कुछ हद तक टकराता है
वे अपनी खुद की decorations और window design लागू करते हैं, और tabs draggable title bar area का 95% घेर लेते हैं, इसलिए window हिलाने की कोशिश में अक्सर tab खिसक जाता है
इस भयानक design स्थिति में पहले कौन पीछे हटेगा, पता नहीं, लेकिन कीमत users चुका रहे हैं
सच कहूँ तो browser को बदलना चाहिए
GNOME ने दिखा दिया है कि वह ज़्यादातर लोगों का default है और काफ़ी अड़ियल भी