सामान्य सत्य

इंटरेक्शन के लिए डिजाइनिंग से लैरी टेस्लर के साथ साक्षात्कार।

लैरी टेस्लर जीयूआई विकास उद्योग का एक अनुभवी है।
ज़ेरॉक्स PARC, Apple Computer, Amazon.com, और Yahoo में काम किया!
कट एंड पेस्ट ऑपरेशन, संदर्भ मेनू का आविष्कारक।




?

केवल एक चीज। उपयोगकर्ताओं के लिए डिज़ाइन।

?



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

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

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

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

आपके व्यवसाय की सफलता के लिए किसका समय अधिक महत्वपूर्ण है? सॉफ्टवेयर के बड़े पैमाने पर बाजार के लिए, यदि आपके पास एक स्थिर एकाधिकार स्थिति नहीं है, तो ग्राहक का समय आपके लिए आपके लिए अधिक महत्वपूर्ण होना चाहिए।

PARC में Trygve Reenskaug द्वारा विकसित ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग का विचार, साथ ही एक "बेसिक एप्लिकेशन" का विचार जो मैंने अपनी MacApp टीम के साथ विकसित किया, सॉफ्टवेयर की सुविधा में निवेश को डेवलपर्स के लिए अधिक स्वीकार्य बनाया, साथ ही उनके काम को आसान बनाने की अनुमति दी। अधिक जटिलता सॉफ्टवेयर पदानुक्रम (विकास में) के निम्न स्तर पर संपन्न होती है, कम यह ऊपरी स्तर पर रहेगा (यानी, अंतिम उपयोगकर्ताओं के लिए - लगभग। अनुवादक)। MacApp का नारा था: "यदि आप हमारे सामान्य उपयोगकर्ताओं के लिए जीवन को आसान बनाते हैं, तो हम आपके लिए विकास को आसान बनाएंगे।"

, GUI?

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

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

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

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

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

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

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

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