फ़ाइनमैन का उस्तरा
(defenderofthebasic.substack.com)- तकनीकी व्याख्या भले ही शुरुआती लोगों को ध्यान में रखकर की जाए, फिर भी उसमें ऐसे सटीक संकेत होने चाहिए जिनसे समझने की क्षमता रखने वाला व्यक्ति वास्तविक स्थिति को समझ सके
- Outlook का error message यह कहता है कि “जो message अब मौजूद नहीं है” उसका contents copy किया जा सकता है, और इस तरह उपयोगकर्ता को एक विरोधाभासी मॉडल देता है
- अगर
serverऔरcacheजैसे शब्द छिपाए न जाएँ, तो रुचि रखने वाले उपयोगकर्ता उन्हें खोजकर सीख सकते हैं, और जो पहले से जानते हैं वे समस्या को जल्दी समझ लेते हैं loading…जैसी परिचित लेकिन गलत state indication सिस्टम वास्तव में क्या कर रहा है इसे छिपाती है; इसकी जगह सीधे “इनपुट पूरा होने का इंतज़ार किया जा रहा है” कहना बेहतर है- अत्यधिक सरलीकरण उपयोगकर्ता की reasoning को रोक देता है, इसलिए कम-से-कम error code और संभव actions जैसे सच तक ले जाने वाले सुराग छोड़े जाने चाहिए
आसान व्याख्या भी गलत नहीं होनी चाहिए
- “फ़ाइनमैन का उस्तरा” तकनीकी बातों को आम उपयोगकर्ताओं को समझाते समय यह कसौटी है कि अगर समझने की क्षमता रखने वाला व्यक्ति भी उसे समझ न पाए, तो वह अच्छी व्याख्या नहीं है
- Richard Feynman ने एक अख़बार के लेख के बारे में कहा था कि केवल “7 ton की machine” जैसी जानकारी से यह पता नहीं चलता कि वह कौन-सी machine है, और “atomic bullet” किस चीज़ की ओर इशारा करता है यह भी समझ नहीं आता
- मूल बात यह नहीं है कि व्याख्या कितनी आसान दिखती है, बल्कि यह है कि अगर पाठक में उस विषय को समझने की क्षमता है तो क्या वह उसे वास्तव में समझ सकता है
Outlook के error message ने जो भ्रम पैदा किया
- Hacker News की चर्चा में नीचे दिए गए error message का मज़ाक उड़ाया गया
- “This message can't be saved because it no longer exists. It can only be discarded. Make sure you copy the contents of the message before you discard if you want to use them later.”
- उपयोगकर्ता से कहा जाता है कि वह जो message मौजूद ही नहीं है उसका contents copy कर सकता है, लेकिन save नहीं कर सकता
- समस्या यह नहीं है कि आम उपयोगकर्ता technical terms नहीं जानते, बल्कि यह है कि जो उपयोगकर्ता समझ सकते हैं उन्हें भी वास्तविक स्थिति नहीं बताई जाती
server और cache को न छिपाने का तरीका
- एक वैकल्पिक वाक्य यह समझाता है कि message mail server से delete हो चुका है, लेकिन Outlook उसे इस device की अस्थायी cache में रखा हुआ है
- उपयोगकर्ता message का contents copy कर सकता है या उसे cache से हटा सकता है
- cache से हटाने पर वह स्थायी रूप से delete हो जाएगा
- कुछ लोगों ने कहा कि आम उपयोगकर्ता
cacheयाserverजैसे शब्द नहीं समझेंगे - लेकिन ऐसे शब्द रुचि रखने वाले उपयोगकर्ताओं के लिए सीखने योग्य संकेत बनते हैं जिन्हें वे खोज सकते हैं, और जो पहले से समझते हैं उनके लिए वे वास्तविक स्थिति को अधिक स्पष्ट करते हैं
- जिन्हें रुचि नहीं है उन्हें किसी भी व्याख्या से बहुत मदद नहीं मिलेगी, लेकिन रुचि रखने वालों के लिए संकेत बचे रहने चाहिए
software की state को जैसी है वैसी बताना
substack-proxyटूल उपयोगकर्ता द्वारा copy-paste किए गए Substack post URL के आधार पर Twitter censorship को bypass करने वाला URL बनाता है- उपयोगकर्ता जब URL दर्ज या संशोधित कर रहा होता है, तब बहुत अधिक server requests जाने लगती थीं, इसलिए लगभग 1 second की देरी जोड़ी गई
- शुरुआती state text
loading…था, लेकिन वास्तव में वह loading नहीं बल्कि उपयोगकर्ता के input पूरा करने का इंतज़ार करने की स्थिति थी - “इनपुट पूरा होने का इंतज़ार किया जा रहा है” मशीन की वास्तविक state को अधिक सटीक रूप से दिखाता है
- अगर error की वजह से प्रक्रिया रुक जाए, तब भी
loading…पर अटके रहने की तुलना में “इनपुट पूरा होने का इंतज़ार किया जा रहा है” पर रुका होना समस्या की स्थिति को बेहतर ढंग से उजागर करता है
सब कुछ सिखाना ज़रूरी नहीं, लेकिन निष्ठा ज़रूरी है
- software को हर उपयोगकर्ता को हर चीज़ सिखाने की ज़रूरत नहीं है
- उपयोगकर्ता अक्सर कारण जानना नहीं चाहते; वे बस चाहते हैं कि चीज़ें ठीक से काम करें
- फिर भी अगर कोई व्याख्या दी जाए, तो उसमें कंप्यूटर कैसे काम करता है इस बारे में अजीब या गलत मॉडल नहीं देना चाहिए
- केवल सरल error code और action देने का तरीका भी संभव है
Error code 1027: file cannot be saved.[Copy contents][Delete file]
- रुचि रखने वाले उपयोगकर्ता error code खोज सकते हैं, और जिनकी रुचि नहीं है वे सीधे उपलब्ध विकल्प देख सकते हैं
सरलीकरण का मानदंड
- अच्छा सरलीकरण उस सच तक पहुँचने वाले धागों को नहीं काटता जिसे समझाया जा रहा है
- “औसत उपयोगकर्ता समझ नहीं पाएगा” यह मानकर सभी उपयोगकर्ताओं को एक ही स्तर पर नीचे लाकर देखना खतरनाक है
- “bits and bytes” इसका उदाहरण है: यह कंप्यूटर पहली बार इस्तेमाल करने वाले व्यक्ति को power on करना और
enterदबाना समझाता है, और उसी episode में binary code तक भी ले जाता है
1 टिप्पणियां
Hacker News की राय
message-doesn't-exist वाला उदाहरण अत्यधिक सरलीकरण की वजह से कम, और लेखक के context भूल जाने पर अक्सर होने वाली गलती जैसा ज़्यादा लगता है
programmer के नज़रिए से, उसने server से कुछ लाने की कोशिश की और server ने कहा कि वह नहीं है, इसलिए “मौजूद नहीं है” सही हो सकता है
लेकिन जिस context में user उस message को अपनी आँखों के सामने देख रहा है, वहाँ “मौजूद नहीं है” साफ़ तौर पर झूठ है
context को फिर से ऐसे तय करना चाहिए: “वह message server पर नहीं है, और अभी थोड़ी देर के लिए सिर्फ़ आपके computer पर है, इसलिए उसे copy कर लें”
user को “server” क्या है यह न भी पता हो, तो भी “कहीं पर नहीं है” वाली जानकारी भर से वाक्य कहीं ज़्यादा समझ में आता है
अगर car mechanic पूरी car की ओर इशारा करके कहे, “यह replace किया जाएगा”, तो भ्रम होगा, लेकिन “xxx replace किया जाएगा” कहे, तो xxx क्या है यह न जानने पर भी बात समझी जा सकती है
आजकल online design ऐसा लगता है कि इस धारणा के तहत सब कुछ लोगों को और बेवकूफ़ बनाने की दिशा में जा रहा है कि user जितना कम सोचेगा, उतनी आसानी से follow करेगा
उदाहरण के लिए, Google search results हर महीने और ज़्यादा lowest common denominator के हिसाब से ढलते लगते हैं, और subtle चीज़ें search करने पर भी algorithm बेकार जवाबों की ओर धकेलता है
हो सकता है बहुत से लोग सचमुच ऐसे तरीके पर बेहतर प्रतिक्रिया देते हों और data में यह अच्छा दिखता हो, लेकिन मुझे व्यक्तिगत रूप से यह पसंद नहीं
system के साथ interact करते हुए मैं थोड़ा-थोड़ा और सीखना और complexity से रूबरू होना चाहता हूँ; उस complexity को छिपा देना मुझे नहीं चाहिए
इसलिए equipment को adjustable बनाया गया, और performance बहुत बेहतर हुई तथा गलतियाँ भी कम हुईं
लेकिन tech industry में इसका ठीक उल्टा क्यों कहा जाता है—कि किसी काल्पनिक average user के हिसाब से ढालना बेहतर है या ज़्यादा पैसा बनाता है—यह समझ नहीं आता
सवाल है कि व्यक्ति की विविधता को ऐसे क्यों नज़रअंदाज़ किया जा सकता है
Norton Disk Doctor की याद इसलिए नहीं आती कि मैं drive recovery का काम करता था, बल्कि इसलिए कि उसमें user की बुद्धिमत्ता का सम्मान करने वाला interface था
storage device से जुड़े दूसरे systems “Mode 5/7? [Y]” जैसे समझ से बाहर वाक्य फेंकते थे, या “Are you sure? [N]” जैसे बेहद मूर्खतापूर्ण सवाल पूछते थे
किस बात को लेकर sure होना है, mode 5 क्या है, 7 है, या दोनों हैं—कुछ पता नहीं चलता
इसके उलट Norton हर choice का मतलब कई paragraphs में समझाता था, concepts को context में खोलकर बताता था, और फायदे व जोखिम बताता था
लगातार Y दबाकर किस्मत पर छोड़ देने के बजाय, वह जानकारी लेकर choice करने देता था
readers और users के प्रति ऐसा सम्मान manuals, user interfaces, blog posts, API docs जैसी हर technical writing पर लागू होता है
“आम लोगों” के लिए लेखन को dumb down करने के बजाय, मुझे लगता है कि बेहतर है लेखन को पढ़ने और समझने वाला हर reader थोड़ा और technical रूप से आगे बढ़े, इस तरह educate किया जाए
संदर्भ के लिए, “Mode 5/7?” सचमुच एक सरकारी विभाग का सारा data रखने वाली Hitachi SAN array में दिखा था, और manual ने बड़ी कृपा से सिर्फ़ इतना बताया था कि यह option mode 5/7 को on या off करता है
गलत चुनाव करने पर array खुद को wipe कर सकती थी और बिल्ली मर सकती थी, या फिर कुछ भी न हो सकता था। कौन जाने
settings बनाने वालों को हर item में छोटा-सा tooltip description डालने में लगभग कोई मेहनत नहीं लगती, फिर भी असल में वे ऐसा लगभग कभी नहीं करते
अगर लक्ष्य information पहुंचाना है, तो यह बात सही है
लेकिन अगर लक्ष्य clicks बढ़ाना, support queries घटाना और engagement बढ़ाना है, तो technically specific और accurate explanation को, गलत हद तक simplified explanation से बेहतर मानना मुश्किल है
इसका मतलब यह नहीं कि मैं information delivery से ज़्यादा engagement को प्राथमिकता देने वाले लक्ष्य से सहमत हूँ
https://www.goodreads.com/quotes/65213-briefly-stated-the-ge...
जिन लोगों ने ऐसे goals pursue करने का फैसला किया है, उनके लिए इसे सचमुच जोखिम भरा चुनाव बनाना चाहिए
काम में मैं इस समस्या से बहुत जूझता हूँ
यह मानकर नहीं चल सकते कि reader अंग्रेज़ी में proficient है, topic समझता है, या यहाँ तक कि उसे समझने में रुचि भी है
इसलिए हमने सरल और अस्पष्टता-रहित writing अपनाई है, और अब ऐसे formatting के साथ भी experiment कर रहे हैं जिससे skim करने पर ही मुख्य बात पकड़ में आ जाए
व्यक्तिगत रूप से, मुझे nhs.uk सीखने लायक सबसे अच्छा example लगता है
लोग बेवकूफ़ नहीं हैं; वे busy, थके हुए, आलसी, या details में बहुत ज़्यादा interested नहीं होते
reader की intelligence का सम्मान करने और उसके समय का सम्मान करने के बीच balance होता है
https://www.gov.uk/guidance/content-design/writing-for-gov-u...
मुझे लगा था कि Feynman का razor भी मूल रूप से इसी दिशा में था। 1979 में New Zealand में QED lecture के दौरान audience के एक सवाल का उनका जवाब याद आता है।
सवाल था, “क्या आपको यह विचार पसंद है कि दुनिया की हमारी तस्वीर probability को शामिल करने वाली calculations पर आधारित होनी चाहिए?” इस पर Feynman ने जवाब दिया कि वे यह नहीं कहते कि उन्हें यह पसंद है या नहीं।
लंबे समय तक वैज्ञानिक के रूप में train होने से चीज़ों को देखने का एक खास तरीका बन गया है, और lecture में वे इसे थोड़ा simplify कर सकते हैं और थोड़ा धोखा देकर ऐसा दिखा सकते हैं मानो उन्हें यह पसंद नहीं है, लेकिन असल मतलब यह है कि यह “अजीब” है।
उन्होंने कहा कि उनके लिए मुद्दा यह नहीं है कि उन्हें यह पसंद है या नहीं, बल्कि यह है कि यह क्या है और क्या नहीं है; पसंद होना पूरी तरह irrelevant है, इसलिए उन्होंने इसे अपने दिमाग से हटा दिया है।
complexity और non-experts को समझाने के मामले में rabbit hole हमेशा और गहरा होता जाता है।
Caltech lectures के space rotation वाले हिस्से में भी एक अच्छा quote है। “हम इन equations को पूरी generality में इस्तेमाल करके सभी results का अध्ययन नहीं करेंगे। ऐसा करने में कई साल लगेंगे, और हमें जल्द ही दूसरे topic पर जाना होगा। introductory course में हम केवल basic laws पेश कर सकते हैं और उन्हें कुछ खास दिलचस्प situations पर ही लागू कर सकते हैं।”
अच्छे अर्थ में देखें तो यह expertise वाली position से गलत बात कहने या कोई असत्य imply करने से बचने का रवैया है, लेकिन साथ ही यह सवाल का ठीक से जवाब दिए बिना निकल जाने जैसा भी दिख सकता है।
जिस video में interviewer पूछता है कि magnet कैसे काम करता है, उसमें भी वे बिल्कुल इसी तरह जवाब देते हैं।
“मेरा सबसे पसंदीदा comment lisper का…” यह तो बढ़िया है। किसी ने मुझे पहचान लिया।
मैं scientific method पर blog posts की series मेहनत से लिख रहा हूँ, लेकिन feedback लगभग नहीं मिला; अजीब है कि ऐसा हल्का-फुल्का comment attention पा रहा है।
जिंदगी कभी-कभी मज़ेदार होती है।
लेखक ने खुद भी Feynman quote को सही तरह reproduce नहीं किया।
“And there are not sixty two kinds of particles” नहीं, बल्कि “And there are now sixty two kinds of particles” होना चाहिए।
अगर technical terms के बिना भी ऐसा समझाया जा सकता है कि beginners और experts दोनों संतुष्ट हों, तो jargon का फायदा ही क्या है?
लेख का example किसी भी पक्ष के लिए उपयोगी नहीं है, और jargon हो या न हो, वह बेहतर नहीं होता।
यह बस खराब explanation है, इसलिए argument खुद कमजोर हो जाता है।
या तो वह सब convey करना पड़ता है, या फिर jargon के जरिए shortcut लेना पड़ता है।
कुछ cases में दोनों पक्षों को संतुष्ट करने वाली explanation संभव होती है, लेकिन वह कठिन होती है और ज्यादा शब्द मांगती है। कम-से-कम media context में यह महत्वपूर्ण है।
फिर भी यहाँ एक spectrum है, और आम तौर पर कोई उचित middle ground मिल सकता है।
अगर “message मौजूद नहीं है लेकिन content copy किया जा सकता है? copy कर सकते हैं तो save क्यों नहीं कर सकते? अगर मौजूद नहीं है तो discard क्यों करना है?” जैसी उलझन पैदा हो, तो शायद कम explanatory लिखना बेहतर हो सकता है।
“यह message जल्द ही उपलब्ध नहीं रहेगा। बाद में इस्तेमाल करना हो तो discard करने से पहले message का content copy कर लें” इतना काफी होगा।
cache की बात छेड़ने से user को मदद नहीं मिलती।
असली solution है message के अंत में “message content को device पर save करें” button जोड़ना।
तब copy साफ हो जाएगी और सीधे action तक ले जाएगी।
ज्यादा detailed explanation पर label लगा दें, या उसे “advanced explanation” button से खुलने वाली दूसरी screen में रख दें।