14 पॉइंट द्वारा GN⁺ 2025-10-31 | 9 टिप्पणियां | WhatsApp पर शेयर करें
  • free software का जटिल user interface (UI) आम उपयोगकर्ताओं के लिए प्रवेश बाधा बनता है
  • वीडियो conversion जैसे सरल काम भी Handbrake जैसे टूल के विशेषज्ञ-केंद्रित UI की वजह से आम लोग छोड़ देते हैं
  • लेखक ने इसका समाधान करने के लिए Magicbrake नाम का single-button interface वाला एक सरल frontend बनाया, जो केवल ‘अजीब वीडियो फ़ाइल को सामान्य MP4 में बदलने’ का काम करता है
  • जटिल फीचर्स को छिपाकर ज़्यादातर उपयोगकर्ताओं को वास्तव में चाहिए सिर्फ 20% फीचर्स ही दिखाए जाएँ तो productivity और संतुष्टि बढ़ती है
  • free software ecosystem को आम उपयोगकर्ता-अनुकूल डिज़ाइन अपनाना होगा, तभी टूल्स का उपयोग दायरा बढ़ सकता है

free software और आम उपयोगकर्ताओं के बीच की खाई

  • आम उपयोगकर्ता वीडियो convert करने, upload करने, चलाने जैसे बुनियादी कामों में भी format समस्याओं से जूझते हैं
    • जो format QuickTime या Facebook में नहीं चलता, उसे वे ‘अजीब’ मानते हैं
  • Handbrake शक्तिशाली है, लेकिन उसके विशेषज्ञ उपयोगकर्ता-केंद्रित UI की वजह से आम उपयोगकर्ताओं को असहजता और भ्रम महसूस होता है
  • यह समस्या FOSS(Free and Open Source Software) में व्यापक है, और नतीजतन आम उपयोगकर्ता या तो इस्तेमाल छोड़ देते हैं या विशेषज्ञों से मदद माँगते हैं

Magicbrake का उदाहरण

  • Magicbrake Handbrake की जटिल क्षमताओं को छिपाकर सिर्फ ‘अजीब वीडियो को सामान्य MP4 में बदलने’ वाला एक ही काम करता है
    • conversion का परिणाम ज़्यादातर environments में चलने वाली छोटी MP4 फ़ाइल होता है
    • interface में सिर्फ एक बटन है
  • यह तरीका तेज़ और सरल समाधान है, और उन उपयोगकर्ताओं के लिए उपयुक्त है जिन्हें जटिल फीचर्स की ज़रूरत नहीं है

सरलीकरण पर आपत्तियाँ और उनके जवाब

  • कुछ लोग पूछते हैं, “Handbrake को कम शक्तिशाली क्यों बनाया?”, “अगर कोई दूसरा format चाहिए तो?”, “विशेष फीचर्स का क्या?”
  • इसका जवाब साफ़ है: जिसे advanced features चाहिए, वह Handbrake वैसे ही इस्तेमाल करे, और जिसे नहीं चाहिए, वह सरल टूल इस्तेमाल करे
  • यह TV remote के अनावश्यक बटनों पर tape चिपका देने जैसा है; ज़रूरत पड़ने पर फीचर्स अब भी मौजूद हैं, लेकिन बुनियादी उपयोग में बाधा नहीं बनते

सरल UI का महत्व

  • दुनिया में ऐसे media server बहुत हैं जिन्हें आम लोग configure नहीं कर सकते, ऐसे audio editor हैं जिनमें बुनियादी काम के लिए भी सीखना पड़ता है, और ऐसे network monitoring tools हैं जो beginners को लगभग बाहर कर देते हैं
  • इन टूल्स की क्षमताएँ बेहतरीन हैं, लेकिन ‘सभी फीचर्स को एक ही UI में ठूँस देने वाली डिज़ाइन’ की वजह से आम उपयोगकर्ता उन तक पहुँच नहीं पाते
  • 80% उपयोगकर्ताओं को सिर्फ 20% फीचर्स चाहिए, इसलिए बाकी को छिपाने से ज़्यादा productive और संतोषजनक अनुभव दिया जा सकता है

डेवलपर्स के लिए सुझाव

  • आम उपयोगकर्ताओं के लिए सरल interface डिज़ाइन करना एक शाम में भी संभव है, और इसका वास्तविक मूल्य बड़ा है
  • सभी जटिल फीचर्स को सामने रखने के बजाय, सिर्फ ज़रूरी फीचर्स दिखाने की डिज़ाइन philosophy free software की accessibility बढ़ाती है
  • लेखक डेवलपर्स से ऐसे सरल किए गए टूल्स ज़्यादा बनाने की सिफारिश करते हैं

9 टिप्पणियां

 
bumjins 2025-11-01

इसे UI/UX की जटिलता भी कहा जा सकता है,
लेकिन मुझे लगता है कि समस्या यह है कि आजकल बनाए जाने वाले सॉफ्टवेयर, चाहे वे free हों या commercial, इस तरह बनाए जाते हैं कि केवल वही एक मामला काम करे जो पहले से मान लिया गया है, और बाकी अनुभवों का क्या होगा इसकी ज़्यादा परवाह नहीं की जाती।
उदाहरण के लिए, toml या yaml configuration संपादित करते समय भी कभी-कभी ऐसी चीज़ें काम नहीं करतीं जो ज़रूर काम करनी चाहिए। यह encoding की समस्या है, indentation की, या फिर किसी खास flag के होने पर इस्तेमाल न की जा सकने वाली कोई सुविधा है—ऐसी बातें आम तौर पर ठीक से documented नहीं होतीं। उपयोगकर्ता हर तरह के case एक-एक करके आज़माता रहता है और बड़ी मुश्किल से सही जवाब तक पहुँचता है।

UI में तो यह और भी गंभीर है। जैसे password reset करते समय होने वाले अनुभव memes की तरह फैल चुके हैं, वैसे ही अगर स्क्रीन पर 100 तरह के field हों, तो उनके बीच संबंध क्या है और किस तरह बदलना सबसे अच्छा होगा, यह "खुद करके देखे बिना पता नहीं चलता"।

यह UI/UX की समस्या तो है ही, लेकिन छिपी हुई "विशेषज्ञता" की समस्या भी है। जब step-by-step learning curve जैसी कोई तैयारी नहीं होती, तब जो काम किसी विशेषज्ञ व्यक्ति के लिए तुरंत सही उत्तर भर देने का होता है, वही किसी शुरुआती व्यक्ति के लिए परीक्षा या चौखट की तरह बार-बार अस्वीकृति झेलने वाला अनुभव बन जाता है।

 
lunamoth 2025-10-31

मिलते-जुलते संदर्भ में लगता है कि CLI से GUI ज़्यादा सुविधाजनक है, इसलिए मैं yt-dlp भी yt-dlg के साथ GUI में इस्तेमाल कर रहा हूँ। ffmpeg भी अक्सर इस्तेमाल होने वाले कमांड्स नोट करके उपयोग कर रहा हूँ, लेकिन शायद उसका भी GUI बनाया जा सकता है।

 
shakespeares 2025-10-31

आख़िरकार, UI/UX ही!!

 
euphcat 2025-10-31

मैंने व्यक्तिगत रूप से भी इस तरह की बातें बहुत सोची हैं, इसलिए इस पर काफ़ी सहमति महसूस होती है। WinXP~7 दौर के Paint, Notepad, Media Player जैसे ऐसे applications, जिन्हें “बस झट से खोलो और लगभग जैसे-तैसे इस्तेमाल कर लो”, Linux में ढूँढने की कोशिश करता था, तो 5~6 चीज़ें install करके देखने के बाद ही अगर कोई पसंद की मिल जाए तो वही गनीमत होती थी।

स्क्रीनशॉट लेकर बस थोड़ा crop करना हो, तो Gimp का इस्तेमाल तो नहीं कर सकते, और क्या-क्या आज़माया था यह याद नहीं, लेकिन gtk apps में कुछ मिला नहीं, इसलिए आख़िर में Kolourpaint पर जाकर बात खत्म हुई। Notepad के लिए Gedit, Kate, Mousepad, Leafpad, Xed वगैरह हैं, और इससे भी हल्की चीज़ ढूँढनी हो तो फिर xedit, nano, vim जैसी चीज़ों तक जाना पड़ता है, जिन्होंने मानो यूज़र-फ्रेंडली होने की कोशिश ही छोड़ दी हो। Media player के लिए mpv, VLC, mplayer जैसी चीज़ों के बारे में सोचकर ही घुटन होने लगती है।

 
skageektp 2025-10-31

ऐसी लिखाइयों में बिना किसी आँकड़े वगैरह के उसे सही बताने का दावा करना थोड़ा अटपटा लगता है।

 
xguru 2025-10-31

उपयोगकर्ता एप्लिकेशन के सिर्फ 20% हिस्से की ही परवाह करते हैं
किसी तरह देखें तो यह ऊपर वाले लेख से भी जुड़ा हुआ लगता है।

 
kayws426 2025-10-31

"ज़्यादातर उपयोगकर्ता किसी application की सुविधाओं में से अपने लिए ज़रूरी लगभग 20% ही इस्तेमाल करते हैं, और वह 20% हर उपयोगकर्ता के लिए अलग होता है"
क्या यही असली बात नहीं है?

 
ndrgrd 2025-11-01

कुछ भी पूछो तो जवाब आता है, "man/readme/docs से शुरू करके पढ़ो"
असल में UX में अहम बात यह है कि उसे बस इस्तेमाल करना शुरू करो और तुरंत समझ आ जाए कि कैसे इस्तेमाल करना है।

चूंकि यह कोई पैसे लेकर किया जाने वाला काम नहीं है, इसलिए लोग इसे नज़रअंदाज़ कर देते हैं, लेकिन non-developer यूज़र के नज़रिए से सोचें तो यह सच है कि user experience अच्छा नहीं होता।

 
GN⁺ 2025-10-31
Hacker News राय
  • लेख अच्छा है, लेकिन मुझे लगता है कि इसकी तर्कशृंखला गलत है
    एक सरल, संक्षिप्त इंटरफेस बनाना कभी आसान नहीं होता
    किसी खास use case के लिए UI बनाना मुश्किल नहीं है, लेकिन उस ‘सटीक use case’ को परिभाषित करना, और फिर “बस इसमें यह थोड़ा और जोड़ दीजिए” जैसी मांगों को रोकना ही असली मुश्किल है
    ऐसी सादगी वांछनीय है, लेकिन अस्थिर अवस्था में रहती है

    • डेवलपर दुनिया गैर-डेवलपर्स के लिए अच्छा इंटरफेस डिज़ाइन करने की कठिनाई को सहज रूप से नहीं समझती
      कोड की जटिलता दिखाई देती है, लेकिन UI की जटिलता दिखाई नहीं देती
      बटन और इनपुट बॉक्स सरल दिखते हैं, लेकिन उस भाषा में समस्या हल करना बेहद जटिल होता है
      असफलता साफ दिखती है, लेकिन सफलता धुंधली होती है और हर उपयोगकर्ता के लिए अलग
      अच्छा इंटरफेस बहुत कुछ ‘अप्रत्यक्ष’ रूप से संप्रेषित करता है, और वही सबसे कठिन हिस्सा है
    • आम उपयोगकर्ता अक्सर “क्या यह बटन X कर सकता है?” जैसी अटपटी मांगें करते हैं
      भले ही उस बटन का मूल काम Y से लगभग कोई संबंध न हो, वे ज़ोर देते हैं कि वही बटन वह काम करे
      इस तरह के “बस थोड़ा बदल दीजिए” अनुरोध जमा होते-जाते हैं, UI को और जटिल बनाते हैं, और अंततः वह टूट जाता है
    • ओपन सोर्स contributors ज़्यादातर power users होते हैं, इसलिए वे बस इस बात पर ध्यान देते हैं कि उनका अपना workflow ठीक चले
      वे आम 80% उपयोगकर्ताओं की usability के लिए अपनी सुविधा छोड़ना नहीं चाहते
    • इस UI/UX विघटन को रोकने के लिए ‘feature freezing’ का सुझाव दिया गया है
      फीचर सेट पहले से तय किया जाए और उसके बाद bug fixes और efficiency improvements पर ध्यान दिया जाए
      नए features सिर्फ सख्त समीक्षा के बाद ही जोड़े जाएँ
      तेज़ी से बदलने वाले software में यह कठिन है, लेकिन अधिकांश स्थिर क्षेत्रों में यह प्रभावी हो सकता है
    • अल्पकाल में शायद उपयोगकर्ता ChatGPT जैसे AI से “मेरी वीडियो को फोन पर चलने लायक बना दो” कहकर चरण-दर-चरण निर्देश लेंगे
      दीर्घकाल में ऐप्स खुद AI को integrate करके, उपयोगकर्ता की इच्छा के मुताबिक UI अपने-आप बना सकती हैं
  • मुझे लगता है कि यह समस्या आखिरकार परिचितता की समस्या है
    मेरी पत्नी टेक्नोलॉजी में सहज नहीं है, लेकिन Linux user है
    नया कारोबार शुरू करते समय उसे Windows इस्तेमाल करना पड़ा, लेकिन उसे वह इतना असुविधाजनक लगा कि वह फिर Linux पर लौटना चाहती थी
    मुझे भी Mac vs PC में ऐसा ही अनुभव हुआ
    जब मुझे मजबूरी में Mac इस्तेमाल करना पड़ा, तो मेरी productivity लगभग 10% रह गई और वह बेहद कठिन था
    आखिरकार लोग उसी माहौल में सबसे अच्छा काम करते हैं जिससे वे परिचित हों

    • मिडिल स्कूल के समय परिवार का कंप्यूटर खराब हो गया था, तो मैंने Ubuntu इंस्टॉल किया, और मेरी माँ ने जल्दी ही खुद को उसके मुताबिक ढाल लिया
      आखिरकार वह ‘बस एक कंप्यूटर’ ही था
    • मुझे भी कंपनी से Mac मिला था, लेकिन मैं लगभग उसका उपयोग नहीं करता
      अच्छी बात यह है कि VPN और ज़रूरी ऐप्स सब Linux + web interface से चल जाते हैं
    • Linux desktop adoption की चर्चा में परिचितता के महत्व को कम करके आँका जाता है
      ऐसा स्थिर distribution चाहिए जो commercial OS जैसा लगभग वही UI दे और जिसमें terminal खोलने की ज़रूरत न पड़े
      सिर्फ “काफ़ी मिलता-जुलता” होना काफी नहीं, बारीक स्तर की पूर्णता मायने रखती है
  • ओपन सोर्स UI शुरू में अपरिचित और जटिल लगता है
    यह डेवलपर-केंद्रित तरीके से बनाया जाता है, इसलिए आम उपयोगकर्ता का ‘मुझे चौंकाओ मत’ सिद्धांत निभाया नहीं जाता
    लेकिन लगातार इस्तेमाल करने पर लोग नई philosophy के अभ्यस्त हो जाते हैं और उसे सफलतापूर्वक इस्तेमाल कर सकते हैं
    मैं भी Firefox, LibreOffice, Avidemux, Virt-manager का अच्छी तरह उपयोग करता हूँ

    • आजकल मुझे Firefox और Chrome में बहुत कम अंतर महसूस होता है
      असली समस्या designer resources की कमी है
      FOSS में आम तौर पर खाली समय वाले डेवलपर्स भाग लेते हैं, लेकिन कलाकार या डिज़ाइनर अपेक्षाकृत कम होते हैं
      इसलिए कई बार सिर्फ बुनियादी स्तर का UI ही मिलता है
  • मुफ्त audio editor Audacity की UX समस्याओं को डिज़ाइनर पहले से पहचानते हैं
    उन्होंने “modes” और “Audacity says no” समस्या को सुलझाने की कोशिश वाला UX redesign वीडियो डाला है
    आगे इसमें सुधार होगा, और ओपन सोर्स में अच्छा UX अभी भी कम है, लेकिन बदलाव जारी है

    • UX सबसे बड़ा debt है
      शुरुआत में ऐप खुद के इस्तेमाल के लिए बनाया जाता है, लेकिन बाद में लोग कहते हैं, “features अच्छे हैं, पर UX अच्छा नहीं”
      और अगर UX सुधारा जाए, तो लोग कहते हैं “features कम हैं”
      आखिरकार सबको खुश करने की कोशिश में आप अंतहीन redesign hell में फँस जाते हैं
      कई बार theme engine जैसी चीज़ें बनाते-बनाते project ही बिखर जाता है
    • नई Audacity की समस्या नई version खुद नहीं है, बल्कि यह है कि वह पुराने version की जगह लेती है
      अगर उसे बस नया नाम देकर अलग जारी किया जाता, तो शायद कोई शिकायत नहीं करता
  • मुझे लगता है कि इस समस्या का समाधान OS-स्तरीय standardization में है
    OS को UI और workflow एकसमान तरीके से देना चाहिए
    उदाहरण के लिए “Handbrake” की जगह “Video Converter” नाम का default app हो,
    जो “इसे Facebook पर चलने लायक convert कर दो” जैसे निर्देश समझकर अपने-आप सही settings लागू कर दे
    app branding न्यूनतम हो, और उपयोगकर्ता को theme और font पर पूरा नियंत्रण मिलना चाहिए
    GUI features से जुड़ी हुई एक standard shell language भी चाहिए

  • लोग आखिरकार functionality चाहते हैं
    अगर जटिल UI सीखने के बाद वे अपनी मनचाही चीज़ कर सकते हैं, तो वे उसे स्वीकार कर लेते हैं
    सिर्फ सरल options वाला software छोटा बाजार रखता है
    जो उपयोगकर्ता video formats नहीं समझता, वह अंततः वेबसाइट पर “convert x to y” खोजकर काम चला लेता है
    और अगर कोई professional tools तक पहुँच गया है, तो वह पहले ही विशेषज्ञ उपयोगकर्ता के दायरे में है

    • लेकिन यह ज़रूरी नहीं कि “जटिल software” ही चाहिए
      “फ़ाइल यहाँ drop करो और Fix It दबाओ” जैसा सरल UI भी संभव है
      मुझे लगता है कि मूल लेख का यही असली बिंदु था
  • ओपन सोर्स के जटिल होने के कई कारण हैं

    1. डेवलपर्स इसे अपनी ज़रूरत के हिसाब से बनाते हैं
    2. options जोड़ने की लागत कम होती है
    3. user research नहीं की जाती
    4. जो लोग इसे इंस्टॉल कर सकते हैं, वे खुद पहले से power users होते हैं
    • उदाहरण के लिए Sonobus को आम उपयोगकर्ताओं से भी अच्छी प्रतिक्रिया मिलती है
      लेकिन अधिकांश FOSS की संरचना technical literacy मांगती है
      जटिल software सीखना ही लंबे समय में अधिक प्रभावी हो सकता है
    • minimal interface बनाए रखने में बहुत समय और ऊर्जा लगती है
      ओपन सोर्स डेवलपर्स के लिए सीमित समय में इसे प्राथमिकता देना मुश्किल होता है
  • एक मज़ाक है कि अगर Handbrake मुश्किल लगता है, तो ffmpeg दिखाना ही मत
    जब मैंने पहली बार Handbrake इस्तेमाल किया, तो वह ffmpeg की तुलना में बहुत आसान लगा

    • ffmpeg के लिए ज़्यादातर मामलों में Google पर “ffmpeg से X कैसे करें” खोजते ही copy-paste command मिल जाती है
      जबकि GUI tools सीखने के लिए वीडियो देखनी पड़ती है
    • अगर आपको सिर्फ simple conversion चाहिए, तो ffmpeg ही सबसे सरल UI है
      ffmpeg -i input.avi output.mp4 एक लाइन काफी है
    • जो लोग command line के अभ्यस्त हैं, उनके लिए ffmpeg, Handbrake से भी सरल है
      Handbrake सारे options दिखाता है, जबकि ffmpeg में आप सिर्फ वही लिखते हैं जिसकी ज़रूरत है
      एक बार आदत पड़ जाए, तो यह बहुत precise control देता है
      “सिर्फ input और output लिखो, काम खत्म” वाली सादगी ही इसकी खासियत है
    • मैं भी आज तक ffmpeg conversion commands ढूँढने के लिए अक्सर LLM search का उपयोग करता हूँ
      यह परफेक्ट नहीं है, लेकिन मुझे लगता है कि यह मुझसे बेहतर है
    • मुझे तो Handbrake, preset-based workflow की वजह से, उल्टे काफ़ी सरल लगता है
      इसलिए मूल लेख में उसका उदाहरण थोड़ा अजीब लगा
  • मेरे जैसे लोग जटिल इंटरफेस पसंद करते हैं
    मैं चाहता हूँ कि सिस्टम मुझे समझदार माने
    जिन tools का मैं अक्सर उपयोग करता हूँ, उनमें जटिलता होने पर भी तेज़ी से काम कर पाना बेहतर है

  • समस्या यह है कि हर कोई अलग-अलग 20% features चाहता है
    अच्छा UI/UX बनाने के लिए tester–designer–developer–user के बीच घनिष्ठ feedback loop चाहिए
    FOSS के पास इसके लिए पर्याप्त resources नहीं होते

    • वास्तव में आम 80% उपयोगकर्ताओं को लगभग वही 20% features चाहिए होते हैं
      लेकिन FOSS का औसत उपयोगकर्ता शीर्ष 1% power user होता है, इसलिए वह इसे समझ नहीं पाता
      इसीलिए जब चीज़ों को आम उपयोगकर्ता-केंद्रित बनाने की कोशिश होती है, तो community से विरोध मिलता है
    • FOSS अक्सर शुरू से ही “customers” के लिए नहीं होता
      डेवलपर इसे अपनी ज़रूरत से बनाते हैं, इसलिए user satisfaction उसका लक्ष्य हो भी नहीं सकता
      यह असफलता नहीं, बस अलग उद्देश्य है
    • Handbrake जैसे मामले में ज़्यादातर लोगों को बस वीडियो का आकार कम करना होता है
      advanced features का उपयोग बहुत कम लोग करते हैं
      इसलिए default UI + advanced mode में बाँटना व्यावहारिक है
    • FOSS का feedback loop self-reinforcing होता है
      क्योंकि टेस्ट वही लोग करते हैं जो पहले से उस UI के अभ्यस्त हैं, इसलिए “कुछ मत बदलो” वाली राय अधिक आती है
      वहीं बड़ी कंपनियाँ नए उपयोगकर्ताओं के साथ paid user testing करा सकती हैं
      इसलिए UX सुधार तेज़ी से होता है
    • FOSS community का 99% हिस्सा डेवलपर्स का है
      UI/UX experts से योगदान माँगा भी जाए, तो अक्सर उन्हें समझा नहीं जाता