डिज़ाइन और अनुसंधान

जनवरी 2003

(यह लेख NEPLS के पतझड़ 2002 के सम्मेलन में एक मुख्य भाषण से प्राप्त है.)

इस देश के आगंतुक अक्सर आश्चर्यचकित होते हैं कि अमेरिकी लोग किसी से बात शुरू करने के लिए "आप क्या करते हैं?" पूछना पसंद करते हैं। मुझे यह प्रश्न कभी भी पसंद नहीं आया है। मेरे पास इसका एक साफ़ जवाब देने के लिए कभी नहीं रहा है। लेकिन मुझे लगता है कि मैंने अंततः इस समस्या का समाधान कर लिया है। अब, जब कोई मुझसे पूछता है कि मैं क्या करता हूं, तो मैं उनकी आंखों में सीधे देखकर कहता हूं कि "मैं एक नई लिस्प भाषा डिज़ाइन कर रहा हूं।" मैं इस जवाब को किसी को भी सुझाता हूं जो इस प्रश्न पूछने से परेशान होता है। बातचीत तुरंत ही अन्य विषयों पर चली जाएगी।

मैं खुद को प्रोग्रामिंग भाषाओं पर अनुसंधान करने वाला नहीं मानता। मैं बस एक भाषा डिज़ाइन कर रहा हूं, जैसे कि कोई व्यक्ति एक इमारत या कुर्सी या एक नई फ़ॉन्ट डिज़ाइन कर रहा हो। मैं कुछ नया खोजने की कोशिश नहीं कर रहा हूं। मैं बस एक ऐसी भाषा बनाना चाहता हूं जिसमें प्रोग्रामिंग करना अच्छा हो। कुछ मामलों में, यह मान लेना मेरे लिए काफी आसान बना देता है।

डिज़ाइन और अनुसंधान के बीच का अंतर नया बनाम अच्छा लगता है। डिज़ाइन को नया होने की ज़रूरत नहीं है, लेकिन अच्छा होना ज़रूरी है। अनुसंधान को अच्छा होने की ज़रूरत नहीं है, लेकिन नया होना ज़रूरी है। मुझे लगता है कि ये दोनों मार्ग शीर्ष पर मिल जाते हैं: सर्वश्रेष्ठ डिज़ाइन नए विचारों का उपयोग करके अपने पूर्ववर्तियों को पीछे छोड़ देता है, और सर्वश्रेष्ठ अनुसंधान वे समस्याएं हल करता है जो न केवल नई हैं, बल्कि वास्तव में हल करने योग्य भी हैं। इसलिए अंततः हम एक ही गंतव्य की ओर बढ़ रहे हैं, केवल इसे अलग-अलग दिशाओं से पहुंच रहे हैं।

जिस बारे में मैं आज बात करने जा रहा हूं, वह है कि आप इस लक्ष्य को पीछे से कैसे देखते हैं। जब आप प्रोग्रामिंग भाषाओं को एक अनुसंधान विषय के बजाय एक डिज़ाइन समस्या के रूप में देखते हैं, तो आप क्या अलग करते हैं?

सबसे बड़ा अंतर यह है कि आप उपयोगकर्ता पर अधिक ध्यान केंद्रित करते हैं। डिज़ाइन शुरू होता है यह पूछकर कि यह किसके लिए है और उन्हें इससे क्या चाहिए? एक अच्छा वास्तुकार, उदाहरण के लिए, एक ऐसा डिज़ाइन नहीं बनाता जिसे वह फिर उपयोगकर्ताओं पर थोप देता है, बल्कि वह इरादित उपयोगकर्ताओं का अध्ययन करके यह पता लगाता है कि उन्हें क्या चाहिए।

मैंने "उन्हें क्या चाहिए" कहा, न कि "वे क्या चाहते हैं"। मैं यह इंगित नहीं देना चाहता कि डिज़ाइनर के रूप में काम करना एक प्रकार का छोटा-मोटा खाना पकाने जैसा है, जहां आप ग्राहक को बताए गए कुछ भी बना देते हैं। यह कला के क्षेत्रों में अलग-अलग होता है, लेकिन मुझे लगता है कि ऐसा कोई क्षेत्र नहीं है जिसमें सर्वश्रेष्ठ काम उन लोगों द्वारा किया जाता है जो बस उपभोक्ताओं को बताए गए कुछ भी बना देते हैं।

ग्राहक हमेशा सही होता है इस मायने में कि अच्छे डिज़ाइन का मापदंड यह है कि वह उपयोगकर्ता के लिए कितना अच्छा काम करता है। यदि आप एक उपन्यास बनाते हैं जो सभी को बोर करता है, या एक कुर्सी बनाते हैं जिसमें बैठना बहुत असहज होता है, तो आपने एक बुरा काम किया है, बस। यह कोई बचाव नहीं है कि उपन्यास या कुर्सी सबसे उन्नत सैद्धांतिक सिद्धांतों के अनुसार डिज़ाइन किया गया है।

और फिर भी, उपयोगकर्ता के लिए काम करना यह नहीं मतलब है कि आप बस वही बनाते हैं जो उपयोगकर्ता कहता है। उपयोगकर्ता नहीं जानते कि सभी विकल्प क्या हैं, और अक्सर वे वास्तव में क्या चाहते हैं, इसके बारे में गलत होते हैं।

इस पैरडॉक्स का जवाब, मुझे लगता है, यह है कि आपको उपयोगकर्ता के लिए डिज़ाइन करना होगा, लेकिन आपको उपयोगकर्ता को चाहिए, न कि वह जो कहता है कि वह चाहता है। यह एक डॉक्टर की तरह है। आप केवल एक रोगी के लक्षणों का इलाज नहीं कर सकते। जब एक रोगी आपको अपने लक्षण बताता है, तो आपको उसमें क्या गलत है, यह पता लगाना होता है और उसका इलाज करना होता है।

उपयोगकर्ता पर इस ध्यान केंद्रित करना एक प्रकार का मूलभूत सिद्धांत है जिससे अच्छे डिज़ाइन के अभ्यास का अधिकांश कुछ व्युत्पन्न किया जा सकता है, और जिसके आसपास अधिकांश डिज़ाइन मुद्दे केंद्रित होते हैं।

यदि अच्छा डिज़ाइन उपयोगकर्ता की जरूरतों को पूरा करना चाहिए, तो उपयोगकर्ता कौन है? जब मैं कहता हूं कि डिज़ाइन उपयोगकर्ताओं के लिए होना चाहिए, तो मैं यह नहीं कह रहा हूं कि अच्छा डिज़ाइन किसी प्रकार के सबसे कम साधारण उपयोगकर्ताओं को लक्षित करता है। आप जिस भी समूह के उपयोगकर्ताओं को चुनना चाहते हैं, उन्हें चुन सकते हैं। उदाहरण के लिए, यदि आप एक उपकरण डिज़ाइन कर रहे हैं, तो आप इसे प्रारंभिक से लेकर विशेषज्ञ तक किसी भी समूह के लिए डिज़ाइन कर सकते हैं, और एक समूह के लिए अच्छा डिज़ाइन दूसरे के लिए बुरा हो सकता है। मुख्य बात यह है कि आपको किसी उपयोगकर्ता समूह को चुनना होगा। मुझे लगता है कि आप अच्छे या बुरे डिज़ाइन के बारे में बात ही नहीं कर सकते, जब तक कि आप किसी इरादित उपयोगकर्ता के संदर्भ में न हों।

आप सबसे अच्छा डिज़ाइन तब प्राप्त करेंगे जब इरादित उपयोगकर्ताओं में डिज़ाइनर खुद भी शामिल हों। जब आप किसी ऐसे समूह के लिए कुछ डिज़ाइन करते हैं जो आपको शामिल नहीं करता, तो यह आमतौर पर उन लोगों के लिए होता है जिन्हें आप अपने से कम विकसित मानते हैं, न कि अधिक विकसित।

यह एक समस्या है, क्योंकि उपयोगकर्ता पर नज़र रखना, भले ही वह दयालु हो, लगभग अवश्य ही डिज़ाइनर को भ्रष्ट कर देता है। मुझे लगता है कि अमेरिका में बहुत कम आवास परियोजनाएं ऐसे वास्तुकारों द्वारा डिज़ाइन की गई हैं जो उनमें रहने की उम्मीद करते थे। आप इसी चीज को प्रोग्रामिंग भाषाओं में भी देख सकते हैं। सी, लिस्प और स्मॉलटॉक उनके स्वयं के डिज़ाइनरों द्वारा उपयोग करने के लिए बनाए गए थे। कोबोल, एडा और जावा अन्य लोगों के लिए बनाए गए थे।

यदि आप सोचते हैं कि आप मूर्खों के लिए कुछ डिज़ाइन कर रहे हैं, तो संभावना है कि आप कुछ अच्छा नहीं बना रहे हैं, यहां तक कि मूर्खों के लिए भी नहीं।

यहां तक कि यदि आप सबसे विशिष्ट उपयोगकर्ताओं के लिए कुछ डिज़ाइन कर रहे हैं, तो भी आप मानव के लिए डिज़ाइन कर रहे हैं। अनुसंधान में यह अलग है। गणित में आप मानव को समझने में आसान अवधारणाओं का चयन नहीं करते; आप उन्हीं का चयन करते हैं जो प्रमाण को छोटा बना देते हैं। मुझे लगता है कि यह विज्ञानों के लिए सामान्य है। वैज्ञानिक विचार मानव के लिए अनुकूल होने के लिए नहीं बनाए जाते हैं।

कलाओं में, चीजें बहुत अलग हैं। डिज़ाइन लोगों के बारे में होता है। मानव शरीर एक अजीब चीज है, लेकिन जब आप एक कुर्सी डिज़ाइन कर रहे हैं, तो यही वह है जिसके लिए आप डिज़ाइन कर रहे हैं, और इससे बचने का कोई तरीका नहीं है। सभी कलाओं को मानव की रुचियों और सीमाओं के अनुकूल होना पड़ता है। चित्

याद रखें कि भाषाएं मुख्य रूप से पूर्ण कार्यक्रमों के लिए नहीं, बल्कि कार्यक्रमों को विकसित करने के लिए कुछ है। कला में कोई भी आपको बता सकता है कि आप दो स्थितियों के लिए अलग माध्यम चाहते हो सकते हैं। उदाहरण के लिए, पूर्ण विचारों के लिए संगमरमर एक अच्छा, दुर्ग माध्यम है, लेकिन नए विचारों को विकसित करने के लिए एक बेहद अलंकृत है।

एक कार्यक्रम, एक प्रमाण की तरह, एक पौधे का एक छंटित संस्करण है जिसमें पहले गलत शुरुआत सभी ओर से शाखाएं निकली हैं। इसलिए एक भाषा का परीक्षण न केवल यह है कि पूर्ण कार्यक्रम में कितना स्वच्छ दिखता है, बल्कि पूर्ण कार्यक्रम तक पहुंचने का मार्ग कितना स्वच्छ था। एक डिजाइन चयन जो आपको सुंदर पूर्ण कार्यक्रम देता है, आपको एक सुंदर डिजाइन प्रक्रिया नहीं दे सकता है। उदाहरण के लिए, मैंने कुछ मैक्रो-परिभाषित मैक्रो लिखे हैं जो अब छोटे रत्न की तरह दिखते हैं, लेकिन उन्हें लिखने में मुझे घंटों का सबसे बुरा परीक्षण और त्रुटि लगी, और सच कहूं तो, मैं अभी भी पूरी तरह से सुनिश्चित नहीं हूं कि वे सही हैं।

हम अक्सर ऐसा व्यवहार करते हैं जैसे कि भाषा का परीक्षण यह है कि इसमें पूर्ण कार्यक्रम कैसे दिखते हैं। जब आप दो भाषाओं में एक ही कार्यक्रम लिखते हैं और एक संस्करण बहुत छोटा होता है, तो यह बहुत आश्वासक लगता है। जब आप कला की दिशा से समस्या का アプローチ करते हैं, तो आप इस तरह के परीक्षण पर कम निर्भर होते हैं। आप एक ऐसी प्रोग्रामिंग भाषा नहीं चाहते जो संगमरमर की तरह हो।

उदाहरण के लिए, सॉफ्टवेयर विकास में एक बहुत बड़ी जीत यह है कि आपके पास एक इंटरैक्टिव टॉपलेवल है, जिसे Lisp में एक पढ़ें-मूल्यांकन-प्रिंट लूप कहा जाता है। और जब आपके पास यह होता है, तो इसका भाषा के डिजाइन पर वास्तविक प्रभाव होता है। उदाहरण के लिए, एक ऐसी भाषा के लिए यह अच्छी तरह से काम नहीं करेगा जहां आपको उपयोग करने से पहले चर घोषित करने की आवश्यकता होती है। जब आप केवल टॉपलेवल में अभिव्यक्तियां टाइप कर रहे हैं, तो आप x को कुछ मान देना चाहते हैं और फिर x के साथ काम करना शुरू करना चाहते हैं। आप पहले x की प्रकार घोषित करना नहीं चाहते। आप इन प्रमिसों में से किसी एक को भी विवाद कर सकते हैं, लेकिन यदि एक भाषा को सुविधाजनक होने के लिए एक टॉपलेवल होना चाहिए, और अनिवार्य प्रकार घोषणाएं एक टॉपलेवल के साथ असंगत हैं, तो कोई भी भाषा जो अनिवार्य प्रकार घोषणाएं करती है वह सुविधाजनक नहीं हो सकती।

व्यवहार में, अच्छा डिजाइन प्राप्त करने के लिए आपको अपने उपयोगकर्ताओं के करीब आना और उनके करीब रहना होगा। विशेष रूप से शुरुआत में, आपको अपने विचारों को वास्तविक उपयोगकर्ताओं पर लगातार कैलिब्रेट करना होगा। जेन ऑस्टन की उपन्यासों की एक वजह यह है कि वह उन्हें अपने परिवार के सामने ऊंची आवाज में पढ़ती थीं। यही कारण है कि वह कभी भी परिदृश्यों का स्वयं-अनुमोदित रूप से कलात्मक वर्णन या दुर्भाषी दार्शनिकता में नहीं गिर जाती। (दर्शन वहां है, लेकिन वह कहानी में बुना हुआ है, न कि उस पर एक लेबल की तरह चिपका दिया गया है।) यदि आप एक औसत "साहित्यिक" उपन्यास खोलते हैं और अपने दोस्तों के सामने उसे ऊंची आवाज में पढ़ने की कल्पना करते हैं कि आपने लिखा है, तो आप उस तरह की चीजों पर पाठक पर लगने वाले बोझ को गहराई से महसूस करेंगे।

सॉफ्टवेयर दुनिया में, यह विचार "बदतर बेहतर है" के रूप में जाना जाता है। वास्तव में, "बदतर बेहतर है" की अवधारणा में कई विचार मिले हुए हैं, जिसके कारण लोग अभी भी यह तय करने के बारे में बहस कर रहे हैं कि क्या बदतर वास्तव में बेहतर है या नहीं। लेकिन इस मिश्रण में मुख्य विचारों में से एक यह है कि यदि आप कुछ नया बना रहे हैं, तो आपको उपयोगकर्ताओं के सामने जल्द से जल्द एक प्रोटोटाइप लाना चाहिए।

वैकल्पिक アプローチ को "हेल मैरी रणनीति" कहा जा सकता है। एक त्वरित प्रोटोटाइप बनाने और धीरे-धीरे इसे परिष्कृत करने के बजाय, आप एक लंबे टचडाउन पास में पूर्ण, समाप्त उत्पाद बनाने का प्रयास करते हैं। जहां तक मुझे पता है, यह विनाश का सूत्र है। इंटरनेट बबल के दौरान कई स्टार्टअप ने खुद को इस तरह से नष्ट कर दिया। मुझे ऐसा कोई मामला नहीं मिला है जहां यह काम किया हो।

सॉफ्टवेयर दुनिया के बाहर के लोगों को शायद यह नहीं पता है कि "बदतर बेहतर है" कला के सभी क्षेत्रों में पाया जाता है। उदाहरण के लिए, ड्राइंग में, यह विचार रेनेसांस के दौरान खोजा गया था। अब लगभग हर ड्राइंग शिक्षक आपको बताएगा कि एक सटीक ड्राइंग प्राप्त करने का सही तरीका यह नहीं है कि आप धीरे-धीरे किसी वस्तु के परिधि के चारों ओर काम करें, क्योंकि त्रुटियां जमा होंगी और आप पाएंगे कि अंत में रेखाएं नहीं मिलती हैं। बजाय इसके, आपको लगभग सही स्थान पर कुछ त्वरित रेखाएं खींचनी चाहिए, और फिर इस प्रारंभिक स्केच को धीरे-धीरे परिष्कृत करना चाहिए।

अधिकांश क्षेत्रों में, प्रोटोटाइप पारंपरिक रूप से अलग-अलग सामग्रियों से बनाए जाते हैं। धातु में काटने के लिए टाइपफेस को पहले कागज पर ब्रश से डिजाइन किया जाता था। कांस्य में ढलने वाली मूर्तियों को मोम में मॉडल किया जाता था। टैपेस्ट्री पर गढ़ने के लिए पैटर्न को कागज पर स्याही धुलाई से खींचा जाता था। पत्थर से बनने वाले भवनों का परीक्षण छोटे पैमाने पर लकड़ी में किया जाता था।

तेल रंग को इतना रोमांचक बनाता था, जब यह पंद्रहवीं सदी में लोकप्रिय हुआ, यह था कि आप वास्तव में प्रोटोटाइप से ही समाप्त कार्य बना सकते थे। आप यदि चाहें तो एक प्रारंभिक ड्राइंग बना सकते हैं, लेकिन आप इसके लिए बाध्य नहीं हैं; आप सभी विवरण काम कर सकते हैं, और यहां तक कि मुख्य परिवर्तन भी कर सकते हैं, जैसे कि आप पेंटिंग को समाप्त करते हैं।

आप सॉफ्टवेयर में भी ऐसा कर सकते हैं। एक प्रोटोटाइप केवल एक मॉडल नहीं होना चाहिए; आप इसे समाप्त उत्पाद में परिष्कृत कर सकते हैं। जब भी आप कर सकते हैं, तो मुझे लगता है कि आपको ऐसा ही करना चाहिए। यह आपको रास्ते में नए अंतर्दृष्टि का लाभ उठाने देता है। लेकिन शायद इससे भी महत्वपूर्ण, यह मनोबल के लिए अच्छा है।

डिजाइन में मनोबल महत्वपूर्ण है। मुझे आश्चर्य है कि लोग इसके बारे में अधिक नहीं बोलते। मेरे पहले ड्राइंग शिक्षकों में से एक ने मुझे बताया: यदि आप कुछ खींच रहे हैं तो यदि आप बोर हो जाते हैं, तो ड्राइंग बोरिंग दिखेगी। उदाहरण के लिए, मान लीजिए कि आपको एक इमारत खींचनी है, और आप प्रत्येक ईंट को अलग-अलग खींचने का फैसला करते हैं। आप ऐसा कर सकते हैं, लेकिन यदि आप आधे रास्ते में बोर हो जाते हैं और ईंटों को देखने के बजाय मशीनी रूप से बनाने लगते हैं, तो ड्राइंग उस से भी बदतर दिखेगी जैसे कि आपने केवल ईंटों का सुझाव दिया हो।

एक प्रोटोटाइप को धीरे-धीरे परिष्कृत करके कुछ बनाना मनोबल के लिए अच्छा है क्योंकि यह आपको संलग्न रखता है। सॉफ्टवेयर में, मेरा नियम है: हमेशा कार्यशील कोड होना चाहिए। यदि आप कुछ ऐसा लिख रहे हैं जिसे आप एक घंटे में परीक्षण कर सकते हैं, तो आपके पास तुरंत पुरस्कार की उम्मीद होती है जो आपको प्रेरित करती है। कला में और विशेष रूप से त

मनोबल एक और कारण है कि असोफिस्टिकेटेड उपयोगकर्ता के लिए कुछ डिज़ाइन करना कठिन है। जिस चीज़ से आप खुद खुश नहीं हैं, उसमें रुचि बनाए रखना कठिन होता है। कुछ अच्छा बनाने के लिए, आपको ऐसा महसूस होना चाहिए कि "वाह, यह वाकई बहुत अच्छा है," न कि "यह कितना गंदा है; ये मूर्ख इसे पसंद करेंगे।"

डिज़ाइन का मतलब है मनुष्यों के लिए चीजें बनाना। लेकिन यह केवल उपयोगकर्ता ही नहीं है जो मनुष्य है। डिज़ाइनर भी मनुष्य है।

ध्यान दें कि मैं "डिज़ाइनर" के बारे में बात कर रहा हूं। डिज़ाइन अच्छा होने के लिए, इसे एक व्यक्ति के नियंत्रण में होना चाहिए। और फिर भी, यह संभव लगता है कि कई लोग एक शोध परियोजना पर सहयोग कर सकते हैं। यह मुझे शोध और डिज़ाइन के बीच सबसे दिलचस्प अंतर लगता है।

कलाओं में सहयोग के प्रसिद्ध उदाहरण हैं, लेकिन उनमें से अधिकांश अणु बंधन के मामले लगते हैं, न कि परमाणु संलयन के। ओपेरा में आम तौर पर एक व्यक्ति लिबरेटो लिखता है और दूसरा संगीत लिखता है। और रेनेसांस के दौरान, उत्तरी यूरोप के कारीगर अक्सर इतालवी चित्रों के पृष्ठभूमि में परिदृश्य बनाने के लिए नियुक्त किए जाते थे। लेकिन ये सच्चे सहयोग नहीं हैं। ये रॉबर्ट फ्रॉस्ट के "अच्छे बाड़े अच्छे पड़ोसी बनाते हैं" के उदाहरण हैं। आप अच्छे डिज़ाइन के टुकड़े एक साथ जोड़ सकते हैं, लेकिन प्रत्येक व्यक्तिगत परियोजना में, एक व्यक्ति को नियंत्रण में होना चाहिए।

मैं यह नहीं कह रहा हूं कि अच्छा डिज़ाइन करने के लिए एक व्यक्ति को सब कुछ सोचना चाहिए। किसी ऐसे व्यक्ति की सलाह जिसके निर्णय पर आप भरोसा करते हों, उतना ही मूल्यवान कुछ नहीं है। लेकिन बातचीत खत्म होने के बाद, क्या करना है, इस निर्णय को एक व्यक्ति के पास होना चाहिए।

शोध को सहयोगियों द्वारा किया जा सकता है लेकिन डिज़ाइन नहीं, यह क्यों है? यह एक दिलचस्प प्रश्न है। मुझे जवाब नहीं पता। शायद, यदि डिज़ाइन और शोध एक हो जाते हैं, तो सबसे अच्छा शोध भी अच्छा डिज़ाइन है, और वास्तव में सहयोगियों द्वारा नहीं किया जा सकता। प्रसिद्ध वैज्ञानिकों में से कई ने अकेले काम किया लगता है। लेकिन क्या यहां कोई पैटर्न है, इसके बारे में कहने के लिए मेरे पास पर्याप्त जानकारी नहीं है। यह भी हो सकता है कि कई प्रसिद्ध वैज्ञानिक उस समय काम कर रहे थे जब सहयोग कम आम था।

विज्ञानों में जो भी कहानी हो, कलाओं में सच्चा सहयोग बहुत कम है। कमेटी द्वारा डिज़ाइन एक खराब डिज़ाइन का पर्याय है। यह क्यों है? क्या इस सीमा को पार करने का कोई तरीका है?

मुझे लगता है कि नहीं - कि अच्छा डिज़ाइन एक तानाशाह की जरूरत है। एक कारण यह है कि अच्छा डिज़ाइन एक टुकड़े में होना चाहिए। डिज़ाइन केवल मनुष्यों के लिए नहीं है, बल्कि व्यक्तिगत मनुष्यों के लिए है। यदि एक डिज़ाइन किसी व्यक्ति के दिमाग में फिट होने वाले विचार को प्रतिनिधित्व करता है, तो यह उपयोगकर्ता के दिमाग में भी फिट होगा।