- जब Microsoft और IBM मिलकर OS/2 विकसित कर रहे थे, तब डायलॉग बॉक्स में फ़ील्ड्स के बीच जाने के लिए कौन-सी key इस्तेमाल होगी, यह संगठनात्मक संरचना के अंतर को उजागर करने वाला मुद्दा बन गया
- Boca Raton में IBM दफ़्तर में तैनात Microsoft के एक सहयोगी ने फ़ील्ड navigation key के रूप में TAB key इस्तेमाल करने का फ़ैसला किया, और IBM ने कहा कि यह बात Redmond के manager तक escalate की जाए
- Microsoft manager ने जवाब दिया कि वह Boca में इसी लिए है ताकि वह ऐसे फ़ैसले खुद ले सके, और IBM को यह बात “Microsoft इस उद्देश्य के लिए TAB key के उपयोग का समर्थन करता है” के रूप में बताई गई
- IBM इससे संतुष्ट नहीं हुआ और अपनी संगठनात्मक प्रक्रिया के अनुसार मुद्दे को कई स्तर ऊपर तक ले गया; उसने कहा कि programmer से लगभग 7 स्तर ऊपर का VP इसका विरोध करता है, और Microsoft में भी समान स्तर के manager से पुष्टि मांगी
- Microsoft के उस सहयोगी ने जवाब दिया, “Bill Gates की mother को TAB key में कोई दिलचस्पी नहीं है,” और इसके बाद चर्चा समाप्त हो गई लगती है, तथा TAB key वैसी ही बनी रही
OS/2 सहयोग में सामने आया संगठनात्मक संरचना का अंतर
- जब Microsoft और IBM मिलकर OS/2 विकसित कर रहे थे, तब सांस्कृतिक टकराव भी थे। Microsoft पक्ष को लगता था कि IBM के सहयोगी अनावश्यक bureaucracy में बंधे हुए हैं, जबकि IBM पक्ष Microsoft के लोगों को बिना अनुशासन वाले hackers के रूप में देखता था
- टकराव के बिंदुओं में से एक संगठनात्मक संरचना थी, और डायलॉग बॉक्स (dialog box) में एक फ़ील्ड से दूसरी फ़ील्ड में जाने के लिए कौन-सी key उपयोग होगी, यही विवाद का विषय बन गया
- Microsoft का एक सहयोगी फ़्लोरिडा के Boca Raton स्थित IBM दफ़्तर में तैनात था, और उसने फ़ील्ड navigation key के रूप में TAB key इस्तेमाल करने का निर्णय लिया
- IBM पक्ष इस निर्णय से संतुष्ट नहीं था और उसने कहा कि मामला Redmond में उसके manager तक ले जाया जाए
Microsoft की delegation और IBM की ऊपर ले जाने वाली प्रक्रिया
- Microsoft manager ने जवाब दिया, “तुम Boca में इसलिए हो ताकि मैं Boca में हुए बिना भी तुम ऐसे फ़ैसले ले सको”
- IBM को भेजे जाने से पहले इस जवाब को थोड़ा अधिक corporate अंदाज़ में बदलकर “Microsoft इस उद्देश्य के लिए TAB key के उपयोग का समर्थन करता है” कर दिया गया
- IBM पक्ष इससे संतुष्ट नहीं हुआ और उसने अपनी संगठनात्मक व्यवस्था के अनुसार इस मुद्दे को कई स्तर ऊपर तक escalate किया
- IBM ने कहा कि programmer से लगभग 7 स्तर ऊपर का VP इस उद्देश्य के लिए TAB के उपयोग का कड़ा विरोध करता है, और Microsoft से भी समान स्तर के manager की पुष्टि मांगी
बहस का अंत
- Microsoft के सहयोगी ने जवाब दिया, “Bill Gates की mother को TAB key में कोई दिलचस्पी नहीं है”
- इस जवाब के बाद चर्चा समाप्त हो गई लगती है, और TAB key वैसी ही बनी रही
- अंत में यह मज़ाक किया गया कि अमेरिका में आने वाला रविवार Mother’s Day है, लेकिन अपनी mother से TAB key पर उनकी राय पूछना सलाहयोग्य नहीं है
- Microsoft और IBM, दोनों की एक-दूसरे के बारे में राय शायद कुछ हद तक सही रही हो
1 टिप्पणियां
Hacker News टिप्पणियाँ
IBM कुख्यात रूप से अत्यधिक प्रबंधन-प्रधान था
पहले मेरे साथ काम करने वाले एक व्यक्ति ने बताया कि 90 के दशक के मध्य में वह लंदन IBM में समर इंटर्न था और आज के QA engineering जैसे काम करता था। उस समय सभी लोग सूट पहनकर दफ़्तर आते थे, लेकिन वह संस्कृति बदल रही थी, इसलिए इंटर्न्स ने अनुरोध किया कि कम से कम शुक्रवार को casual कपड़े पहनने की अनुमति दी जाए।
उन्हें लगा कि यह कोई बड़ी बात नहीं है, क्योंकि उनका ग्राहकों से कोई वास्ता नहीं था और वे पीछे के कमरों में बंद होकर काम करते थे, लेकिन कुछ महीनों बाद, इंटर्नशिप खत्म होने से ठीक पहले जवाब आया। अनुरोध लंदन ऑफिस की 4-स्तरीय approval chain से होता हुआ अमेरिका मुख्यालय तक गया और एक vice president की मेज़ तक पहुँचा।
लगता है हर स्तर ने यह सोचने में कई हफ्ते लगाए कि क्या उन्हें इतने गंभीर मामले पर निर्णय लेने का अधिकार है, और जवाब वही रास्ता तय करते हुए एक-एक स्तर नीचे आया, अटलांटिक पार करके लंदन के सूट पहने इंटर्न्स तक पहुँचा, तब तक इंटर्नशिप में बस कुछ दिन बचे थे।
जवाब था अस्वीकृत
लेकिन 8 महीने बाद IBM HR ने फोन करके पूछा कि क्या मैं अगले गुरुवार interview के लिए आना चाहूँगा। जब मैंने कहा कि अब मेरी रुचि नहीं है, तो वे पूरी तरह हैरान रह गए।
वे क्या सोच रहे थे, पता नहीं, लेकिन अच्छी salary offer किए बिना भी उनमें ग़ज़ब का आत्म-महत्व था
माहौल काफ़ी informal था। मैं ऊपर की कहानी को झुठलाने की कोशिश नहीं कर रहा, बस एक और नज़रिया जोड़ रहा हूँ
मैंने contract clause में exception माँगा था जिसमें IBM को काम के बाहर बनाए गए intellectual property पर first right मिलता था।
मैं केवल tech support call center में काम करता था, IBM की कोई proprietary जानकारी मेरी पहुँच में नहीं थी और मेरी भूमिका development की भी नहीं थी, इसलिए इस मामले में शून्य जोखिम था।
जिन लोगों से मैं वास्तव में मिल सकता था, सबको यह बिल्कुल उचित अनुरोध लगा, लेकिन पहला rejection आने में 6 हफ्ते लगे, फिर मेरे direct manager ने mediation की कोशिश की और review में 2 हफ्ते और जुड़ गए, पर जवाब फिर भी rejection ही रहा।
लगता है मामला reporting line से ऊपर अमेरिका तक गया, वहाँ legal में मुड़ा, फिर वापस नीचे आया। अंत में मैं कंपनी छोड़कर चला गया ताकि किसी दोस्त के साथ छोटे software project पर काम करने पर भी IBM अधिकार जताने का जोखिम न रहे।
और HR forms 80 के दशक की शुरुआत में बनाए गए थे, जिन्हें 2000 के दशक में digitize किया गया था, जबकि हमारी non-customer-facing टीम काफ़ी diverse थी।
forms को अलग gender/pronoun combinations को मान्यता देने लायक update करने की कोशिश हुई, review में लगभग 12 हफ्ते लगे, और अंततः लगता है यह इसलिए reject हो गया क्योंकि कोई यह पता नहीं लगाना चाहता था कि form बदलने की ज़िम्मेदारी किसकी है।
टीम में LGBT सदस्य बहुत थे और उन्हें बनाए रखना महत्वपूर्ण लगता था, फिर भी इसे सख्ती से ठुकरा दिया गया।
sexual harassment prevention training 2010 में tape पर दी जाती थी, और उस पर “updated version” लिखा था, तो शायद उससे पहले वह vinyl record पर रही होगी
यह कहानी अजीब लगती है क्योंकि IBM कई products में keyboard nomenclature का उपयोग लगातार एकसमान करता था, और 3270-family mainframe terminals में आधुनिक keyboard पर Tab की जो position होती है, उसी जगह वाला Tab key cursor को अगले field में ले जाता था।
https://www.bitsavers.org/pdf/ibm/3278/GA27-2890-4_3278_Disp... PDF पेज 73
वैसे IBM terminals में fields के बीच navigation महत्वपूर्ण था, इसलिए Tab key के opposite side पर dedicated Back Tab key भी होती थी।
मूल IBM PC में दोनों functions को एक key में मिला दिया गया, और इसी वजह से classic PC keyboard की Tab key पर forward Tab और backward Tab दोनों के symbols होते हैं; backward Tab symbol ऊपर होने का मतलब है कि उसके लिए Shift दबाना होता है।
इसके अलावा, 5250-family terminals ने Tab/Back Tab की जगह “Field Advance” और “Field Backspace” शब्दावली इस्तेमाल की, लेकिन keys के symbols और positions लगभग 3270-family जैसे ही थे।
संदर्भ: https://www.bitsavers.org/pdf/ibm/5291/GA21-9409-0_5291_Disp...
बाएँ तरफ़ की “Next field” key और दाएँ तरफ़ की matching “Previous field” key पर ध्यान दें।
IBM 3270 एक form-entry device था, जिसमें mainframe खाली स्थानों वाला form terminal को भेजता था और user उन blanks को भरता था।
terminal hardware form के fixed हिस्सों को overwrite होने से रोकता था और numeric fields जैसी restrictions भी लागू करता था; यह सब processing terminal पर ही होती थी।
form पूरा होने पर user ENTER दबाता था और पूरा भरा हुआ form एक single transaction के रूप में mainframe को भेजा जाता था।
इस तरीके से एक mainframe बहुत बड़ी संख्या में terminals संभाल सकता था, और users input के दौरान lag महसूस किए बिना, स्क्रीन देखे बिना भी तेज़ी से type कर सकते थे।
PCs में ऐसा usage model नहीं था, और PC पक्ष के लोग “typewriter” की सोच में थे।
शुरुआती home computer terminals में से एक को “TV Typewriter” भी कहा जाता था।
web forms में यह मॉडल कुछ हद तक है, लेकिन consistency बहुत कम है।
[1] https://sharktastica.co.uk/resources/images/model_bs/themk_1...
लेकिन यह सिर्फ़ अनुमान है।
80 के दशक में IBM में “Systems Engineers” नाम का एक senior technical cadre था, जिनका पूरा काम किसी विशेष system की खूबियों और कमियों पर टिप्पणी करना था।
वे systems को लिखते, debug करते या समझाते नहीं थे, बस यह तय करते थे कि “आप ग़लत कर रहे हैं”
Microsoft टीम को वह बेहद corporate organization जैसी लगती थी, लेकिन IBM के भीतर Boca वाले “rebels” माने जाते थे, और सच कहें तो ज़्यादातर IBM लोगों को उनके अस्तित्व का पता भी नहीं था।
IBM के समय-बोध से देखें तो यह लगभग रातोंरात शुरू हुई, बहुत तेज़ी से चली, और यह इसलिए संभव हुआ क्योंकि Thomas Watson Jr. ने अपने अधीनस्थों के विरोध को दबाकर इस तरह के skunkworks को मंज़ूरी दी।
इसलिए Boca में उस आकार के project में आम तौर पर होने वाली oversight, coordination और control लगभग नहीं के बराबर थी।
शुरुआती Boca सामान्य reporting structure के बाहर काम करता था, और IBM के दूसरे हिस्सों से technology या components लेने की कोशिश में उन्हें कभी-कभी समझाना पड़ता था कि वे सचमुच IBM का हिस्सा हैं
एक आज की सामान्य Return key जैसी थी, जो सिर्फ़ अगले field में जाती थी, form submit नहीं करती थी।
दूसरी Enter key आज के right Ctrl की position पर होती थी, और वही form submit करती थी।
इसलिए हो सकता है IBM को Tab key से नहीं, बल्कि उस Return key को form-submit key की तरह इस्तेमाल करने से आपत्ति रही हो, जिसे 3270 users अगले field में जाने के लिए अपेक्षित मानते थे।
बहुत से DOS programs में भी ऐसा ही होता था, जहाँ Return दबाने पर form submit नहीं होता था बल्कि अगला field चुना जाता था; Windows में यह उन चीज़ों में से एक था जिसकी आदत डालनी पड़ती थी
CUA स्पष्ट रूप से कहता है कि Tab और Backtab fields के बीच move करते हैं।
तो IBM दरअसल अपने ही standard के खिलाफ़ 7-स्तरीय management chain चढ़ाकर आपत्ति कर रहा था: https://archive.org/details/ibmsj2703E/page/n13/mode/2up
मैं Tab पसंद करने वालों से बहस छेड़ना नहीं चाहता, लेकिन मैंने कभी Twitter पर Brendan Eich से पूछा था कि वे spaces क्यों पसंद करते हैं।
उनका जवाब मेरी अपेक्षा से ज़्यादा विचारपूर्ण था।
आधुनिक operating systems और user interface behavior Tab key को ही intercept कर लेते हैं, इसलिए खासकर browser जैसे context में actual tab character डालना जटिल हो जाता है।
फिर भी मैं अब भी Tab को पसंद करता हूँ और Go developer हूँ, लेकिन यह सचमुच परेशान करने वाली समस्या है, इस मामले में वे पूरी तरह सही थे।
उदाहरण के लिए Hacker News के text area में tab character डालने की कोशिश करके देखिए, तुरंत समझ आ जाएगा
मैं तर्क कुछ हद तक समझता हूँ, लेकिन अगर आप HN text area में tab/space-sensitive code लिख रहे हैं, तो अपने-आप में कुछ गड़बड़ है।
code editor तो Tab key को ठीक तरह handle करता है।
लेकिन Enter के मामले में Shift+Enter, Alt+Enter, Cmd+Enter जैसी कुछ conventions हैं, जबकि पूरे operating system में इस्तेमाल करने लायक tab character input method लगभग नहीं के बराबर है, और यह बात अब भी परेशान करती है।
Shift/Alt/Ctrl+Tab भी आम तौर पर पहले से किसी और action के लिए intercept हो चुके होते हैं
हालाँकि tab और newline हर context पर लागू नहीं होते।
साथ ही, कुछ programs में ^V की तरह, control characters को command की बजाय data के रूप में input करने के लिए कोई key या key combination रखना भी तर्कसंगत हो सकता है।
अगर आप ऐसा नया computer design कर रहे हों जिसे मौजूदा computers जैसा होना ज़रूरी न हो, तो यह विचार करने लायक चीज़ है; मैंने भी इस पर सोचा है और शायद वास्तव में इस पर विचार करूँ
Tab key का एक मूल उद्देश्य था, जिसे hijack कर लिया गया और उसके वास्तविक उद्देश्य का उपयोग करना और कठिन बना दिया गया।
यह बहुत अलग नहीं है उस समय से जब Apple ने पहली बार Touch Bar लाकर Escape key हटा दी थी।
औसत user उस key का शायद कम उपयोग करता हो, लेकिन औसत developer के लिए उसके मूल उद्देश्य के बिना लंबे समय तक काम करना मुश्किल है
मैंने पहले सुना है कि tab key को अलग-अलग systems अलग तरह से render कर सकते हैं, इसलिए spaces ज़्यादा सुरक्षित होती हैं क्योंकि वे हमेशा एक जैसी दिखती हैं।
क्या Brendan का मतलब वही था?
शानदार लेख है, लेकिन मैं अब भी जानना चाहता हूँ कि IBM को Tab key के इस उपयोग से आपत्ति क्यों थी।
क्या वे नहीं चाहते थे कि Tab एक input character भी हो और साथ ही control character भी?
यानी कुछ input fields में Tab डाला जा सके और कुछ में न डाला जा सके, और तुरंत यह समझना मुश्किल हो कि कौन-सी स्थिति है?
2026 में भी मैं इस दृष्टिकोण से सहमत हो सकता हूँ
पहली वजह DOS में compatibility breakage थी।
DOS programs Enter का इस्तेमाल करते थे, और numeric keypad पर भी Enter key होती थी, इसलिए एक हाथ से numeric data entry संभव होती थी।
बायाँ हाथ paper original पर रखा जा सकता था और दाएँ हाथ से input किया जा सकता था, और लोग इसमें बहुत तेज़ हो जाते थे।
यह pattern आज भी Excel जैसे कुछ programs में बचा हुआ है।
कई customers को यह पसंद नहीं था कि keyboard पर दोनों हाथ रखने पड़ें, इसलिए हमारे बहुत से programs Enter=Tab mapping की अनुमति देते थे।
असल बात key का “नाम” नहीं, उसकी position है।
key का dual-use बस वह झुंझलाहट है जिसे हम झेलते हैं; कभी वह navigation key की तरह काम करती है, कभी whitespace input key की तरह।
Enter में भी यही समस्या रही होगी।
जबरदस्त बेहतर समाधान keyboard में एक नई key जोड़ना होता, और संभव हो तो उसे numeric keypad पर रखना बेहतर होता।
उस दौर में काफ़ी नई keys जुड़ी थीं; पीछे मुड़कर देखें तो उसी समय “move next” key जोड़ देनी चाहिए थी
क्योंकि उस environment में Tab key के दो ऐसे roles हैं जो पूरी तरह logical और intuitive हैं, लेकिन आपस में टकराते हैं।
यही समस्या Enter key के साथ भी बहुत ज़्यादा बार आती है, और आज भी हम ctrl+crlf newline है या message send, अकेला crlf क्या करता है और shift+crlf क्या करता है—इन सबके जटिल नियम याद रखते हैं।
HN editor में shift+crlf और अकेला crlf newline बनाते हैं, जबकि ctrl+crlf कुछ नहीं करता।
लेकिन दूसरी जगह ctrl+crlf form या message submission trigger कर सकता है, shift+crlf raw newline डालता है, और अकेला crlf इन दोनों में से कुछ भी हो सकता है या कुछ भी नहीं।
ये bindings आम हैं, लेकिन मैंने इनके exceptions और उलटे versions भी देखे हैं, जहाँ shift+crlf form submit करता है और ctrl+crlf raw newline डालता है।
ये सब सचमुच परेशान करने वाली चीज़ें हैं और user friction बहुत बढ़ाती हैं, और कुछ समय तक Microsoft style guide—जो आज के लोगों को ironical लगे—best practices के मुख्य reference के रूप में देखी जाती थी
अनगिनत चलती हुई इकाइयों वाले संगठन को manage करना और users के लिए जल्दी कुछ बनाना, दोनों की प्राथमिकताएँ स्पष्ट रूप से बहुत अलग होती हैं
ऐसा लगा कि IBM bureaucracy का कोई व्यक्ति बीच में आया और काम रोक दिया, और यह बात cultural difference को दिखाने के लिए कही गई।
आखिर वह लेख मूल रूप से इसी cultural difference के बारे में है
IBM ही वह कारण है कि MS-DOS में options के लिए “-” नहीं चला, और devices हर drive के “\DEV” directory में नहीं गए।
path separator के रूप में “/” का समर्थन बचा रहा।
Microsoft के कई लोग Xenix इस्तेमाल करते थे और Unix fans थे, और बहुत शुरुआती DOS में SWITCHCHAR और AVAILDEV नाम के config.sys options इसी काम के लिए थे।
लेकिन मेरी जानकारी के अनुसार IBM ने इसका कड़ा विरोध किया और इन्हें हटवाया।
खास तौर पर DEV issue परेशान करता है क्योंकि DOS 1 में directories थीं ही नहीं, इसलिए compatibility problem गंभीर हो ही नहीं सकती थी।
लेकिन नतीजा यह हुआ कि DOS/Windows इस मान्यता में बँध गए कि device files हर directory में मौजूद हैं, इसलिए “CON” या “COM1” नाम की files बनाना आज भी संभव नहीं है
बस सालों तक उसके लिए ज़रूरी call को document नहीं किया
यह अजीब है, क्योंकि मुझे याद है कि mainframe 3270 में Tab key fields के बीच जाने के लिए इस्तेमाल होती थी
मुझे Operator's Guide PDF मिल गई।
https://news.ycombinator.com/item?id=48028227 देखिए
Tab का उपयोग लगभग दूसरी प्रकृति जैसा था, और जब GUI apps में गया, खासकर Visual Basic apps में tab order गड़बड़ होता था तो बहुत चिढ़ होती थी
हालाँकि शायद उस उद्देश्य के लिए reserved function keys भी थीं
मैंने AS/400 इस्तेमाल नहीं किया, लेकिन मुझे लगता है कि वहाँ अलग Field Exit key की अवधारणा थी
“Microsoft वाले IBM सहयोगियों को बेवजह की bureaucracy में फँसे लोग समझते थे, और IBM वाले Microsoft वालों को अनुशासनहीन hackers मानते थे” — इस पंक्ति पर मैं ज़ोर से हँसा।
मैं MSFT में काम करता हूँ, और लगता है उस दौर का Microsoft आज की कंपनी से बहुत अलग था।
अब तो endless meetings, AI निर्देश, और promotion drama के कारण मैं और मेरे सहकर्मी ख़ुद को बेकार की bureaucracy में फँसा हुआ महसूस करते हैं।
compensation ठीक है, लेकिन bureaucracy आत्मा को खा जाती है
हर machine में game controller जोड़ देना चाहिए, और direction buttons से fields के बीच move करना चाहिए, ‘A’ key से hierarchy menu में एक level ऊपर जाना चाहिए, और ‘B’ key से submenu में जाना चाहिए
तब fields के बीच जाने के लिए आपको data enter करने के बाद keyboard से हाथ हटाकर game controller उठाना होगा, फिर right या left दबाना होगा, और फिर वापस keyboard पर हाथ रखना होगा
productivity वाकई आसमान छू लेगी
इसका मकसद standard OS controls वाले video games को gamepad से स्वाभाविक रूप से control करने देना है
इसका patent ज़रूर करा लेना चाहिए
तब तक हमें दूसरे दर्जे के विकल्प mouse से काम चलाना पड़ेगा
मैं 30+ साल से Mac user हूँ, लेकिन Raymond Chen की historical writing मुझे बहुत पसंद है।
folklore.org के बारे में जानता हूँ, लेकिन काश Apple के अंदर से भी वैसा कुछ होता।
अफ़सोस कि यह Apple culture का हिस्सा नहीं है
1992 में मैं System Software team में समर इंटर्न था, और मेरे projects में से एक Disk Initialization Package की उस feature को बेहतर बनाना था जो disk initialization के दौरान मिले bad blocks को mark करती थी।
मौजूदा feature काम तो करती थी, लेकिन बहुत धीमी थी, progress नहीं दिखाती थी और cancel भी नहीं की जा सकती थी।
सबसे कठिन हिस्सा user interface था।
मैंने speed काफ़ी बढ़ा दी थी, लेकिन मुझे पता नहीं था कि पूरा process कितना लंबा चलेगा, इसलिए remaining time दिखाने वाली हर heuristic बेकार थी।
कुछ cubicles दूर मुझे एक व्यक्ति दिखे जिनका title “User Interface” था, तो मैंने सोचा शायद वे मदद कर सकें। मैंने पूछा क्या उनके पास कुछ मिनट हैं, और फिर Apple employee #4 तथा दोनों Steves को एक-दूसरे से मिलवाने वाले Bill Fernandez के साथ बैठकर हमने समस्या सुलझाई।
उस गर्मियों में मिले लोगों में, मेरे manager को छोड़ दें तो, वे सबसे दयालु व्यक्ति थे। उन्होंने समस्या तुरंत पूरी तरह समझ ली और शानदार समाधान दिया।
उन्होंने कहा कि remaining time estimate छोड़ दो, और इसकी जगह ऐसा indeterminate progress bar रखो जो हर disk track test होने पर आगे बढ़े।
वह बहुत अच्छी तरह काम किया, लोगों को पसंद आया, और 7.1 के बाद की point release में शामिल हुआ।
Raymond की कहानियों जितना चौंकाने वाला नहीं, लेकिन शुरुआत के लिए काफ़ी है
यह बात मुझे प्रभावित करती है कि हर दौर लगभग हर detail को लेकर संघर्षों से भरा था
keys, layout, shape, meaning—सब पर लड़ाई थी
और अब यह बहुत अजीब, लेकिन मज़ेदार भी लगता है कि आज शायद ही कोई इन चीज़ों की परवाह करता हो