स्मार्टफ़ोन के कैमरे में स्क्रीन पर बस एक बार छूने से फ़ोकस और चमक अपने आप ठीक हो जाते हैं। पहले तस्वीर लेने वाले को अपर्चर और शटर की गति की गणना खुद करनी पड़ती थी, लेकिन अब मशीन उसकी जगह यह गणना करती है। तो क्या तस्वीर लेने के काम में मौजूद जटिलता सचमुच गायब हो गई है? इस प्रश्न का उत्तर ‘जटिलता समाप्त नहीं होती, केवल अपनी जगह बदलती है’ के रूप में देने वाला सिद्धांत ही ‘टेस्लर का जटिलता संरक्षण नियम (Tesler's Law of Conservation of Complexity)’ है।
सरल शब्दों में, टेस्लर के नियम का अर्थ है कि ‘हर प्रणाली में कुछ ऐसी जटिलता होती है जिसे और कम नहीं किया जा सकता; फिर प्रश्न सिर्फ़ यह बचता है कि उसका बोझ कौन उठाएगा।’ यह सिद्धांत कंप्यूटर वैज्ञानिक लैरी टेस्लर (Larry Tesler) ने प्रतिपादित किया था, जिन्होंने ज़ेरॉक्स पालो आल्टो अनुसंधान केंद्र (Xerox PARC) और ऐपल (Apple) में यूज़र इंटरफ़ेस को बेहतर बनाया। इसे ‘जटिलता संरक्षण का नियम’ भी कहते हैं।
इस लेख में हम क्रम से टेस्लर के नियम की पृष्ठभूमि, जटिलता का बोझ बाँटने वाले तीन पक्षों, रोज़मर्रा के उदाहरणों और डिज़ाइन में इसके उपयोग के सिद्धांतों तथा सीमाओं पर विचार करेंगे।
टेस्लर का नियम: जटिलता की जगह तय करने वाला डिज़ाइन
टेस्लर का नियम क्या है?
लैरी टेस्लर ने ज़ेरॉक्स पालो आल्टो अनुसंधान केंद्र में ‘मोड रहित (modeless)’ संपादन पद्धति पर शोध किया, जिसमें उपयोगकर्ता किसी विशेष मोड में बँधा नहीं रहता। 1980 में वे ऐपल चले गए और लिसा (Lisa) कंप्यूटर के यूज़र इंटरफ़ेस के काम में शामिल हुए। आज हर किसी के इस्तेमाल में आने वाली कट, कॉपी और पेस्ट की पद्धति को व्यापक रूप से प्रचलित करने वाले व्यक्ति के रूप में भी वे जाने जाते हैं।
टेस्लर ने अपने एक संस्मरणात्मक लेख में बताया कि कट की गई सामग्री को कुछ समय के लिए सहेजने की सुविधा से विकास का बोझ बढ़ने की आपत्ति के जवाब में उन्होंने तर्क दिया था कि ‘उपयोगकर्ता के बजाय डेवलपर पर बोझ डालना बेहतर है।’ फिर उन्होंने इस तर्क को परिष्कृत करके लगभग 1984 में इस तरह प्रस्तुत किया।
“हर एप्लिकेशन में उसकी अपनी ऐसी जटिलता होती है जिसे और कम नहीं किया जा सकता। केवल एक प्रश्न बचता है: उपयोगकर्ता, एप्लिकेशन डेवलपर और प्लेटफ़ॉर्म डेवलपर में से उसे कौन सँभालेगा?”
नियम के नाम में ‘संरक्षण (Conservation)’ शब्द होने का कारण भी यही है। जिस तरह ऊर्जा केवल अपना रूप बदलती है और समाप्त नहीं होती, उसी तरह जटिलता को भी स्क्रीन पर छिपाया तो जा सकता है, लेकिन समाप्त नहीं किया जा सकता। पानी से भरे गद्दे को एक ओर दबाने पर दूसरी ओर उभार आ जाता है; इसी उपमा के आधार पर इसे ‘वॉटरबेड सिद्धांत (Waterbed Theory)’ भी कहते हैं।
जटिलता का बोझ बाँटने वाले तीन पक्ष
टेस्लर के प्रतिपादन के अनुसार, जिस जटिलता को कम नहीं किया जा सकता, उसे अंततः निम्नलिखित तीन पक्षों में से किसी को सँभालना पड़ता है।
- उपयोगकर्ता (User): सेटिंग चुनने, क्रम याद रखने और गलतियाँ सुधारने का काम उपयोगकर्ता को खुद करना पड़ता है।
- एप्लिकेशन डेवलपर (Application Developer): उत्पाद बनाने वाला व्यक्ति अधिक विचार करके और अधिक कोड लिखकर उपयोगकर्ता की मेहनत कम करता है।
- प्लेटफ़ॉर्म डेवलपर (Platform Developer): ऑपरेटिंग सिस्टम या विकास के उपकरण साझा सुविधाएँ पहले से उपलब्ध कराते हैं, जिससे कई उत्पाद एक ही बोझ को बाँट लेते हैं।
इन विकल्पों में टेस्लर सबसे अधिक सावधान उपयोगकर्ता पर बोझ डालने के विकल्प को लेकर थे। डिज़ाइनर डैन सैफ़र (Dan Saffer) की पुस्तक में प्रकाशित एक साक्षात्कार में उन्होंने कहा कि यदि ऐसी जटिलता के कारण दस लाख उपयोगकर्ता हर दिन 1 मिनट गँवाते हैं, जिसे कोई इंजीनियर केवल एक सप्ताह और मेहनत करके दूर कर सकता है, तो यह इंजीनियर का काम कम करने के लिए उपयोगकर्ताओं को दंड देने जैसा है।
इस नियम का केंद्र हिक के नियम (Hick's Law) से अलग है, जिसके अनुसार विकल्प बढ़ने पर निर्णय लेने में अधिक समय लगता है; यह फ़िट्स के नियम (Fitts's Law) से भी अलग है, जिसके अनुसार लक्ष्य जितना दूर और छोटा हो, उसे दबाना उतना कठिन होता है। जहाँ ये दोनों नियम उपयोगकर्ता को लगने वाले समय को मापने के ढाँचे हैं, वहीं टेस्लर का नियम इस ज़िम्मेदारी के प्रश्न पर विचार करता है कि जटिलता किसे सौंपी जाए।
सरल उदाहरणों से समझें कि जटिलता कैसे जगह बदलती है
जटिलता के जगह बदलने के उदाहरण हमें रोज़ इस्तेमाल होने वाली सेवाओं में आसानी से मिल जाते हैं।
(1) खोज बॉक्स
उपयोगकर्ता केवल कुछ अक्षर दर्ज करता है, लेकिन पर्दे के पीछे वर्तनी की गलतियाँ सुधारने, खोज शब्द सुझाने और परिणामों का क्रम तय करने की गणनाएँ चलती रहती हैं। सही खोज शब्द सोचने की मेहनत प्रणाली ने अपने ऊपर ले ली है।
(2) पता दर्ज करना
जिस स्क्रीन पर डाक कोड या सड़क के नाम के कुछ अक्षर दर्ज करते ही बाकी पता भर जाता है, वह लंबा पता सही-सही लिखने का बोझ डेटा और विकास के पक्ष पर स्थानांतरित करने का परिणाम है।
(3) कार और मार्गदर्शन
डोनाल्ड नॉर्मन (Donald Norman) ने अपनी 2010 की पुस्तक ‘Living with Complexity’ में समझाया कि कारों के भीतर की कंप्यूटर प्रणालियाँ हर साल अधिक जटिल होती जाती हैं, लेकिन इसी छिपी हुई जटिलता की बदौलत कार चलाना अधिक सरल और सुरक्षित होता है। अब सबसे अच्छे मार्ग की गणना का काम भी चालक के बजाय नेविगेशन प्रणाली करती है।
तीनों उदाहरणों में उपयोगकर्ता का काम हल्का हुआ है, लेकिन उसी अनुपात में बनाने वालों के लिए डिज़ाइन और गणना का बोझ बढ़ा है। जटिलता की कुल मात्रा वही है; केवल उसका बोझ उठाने वाला बदल गया है।
डिज़ाइन में उपयोग और सीमाएँ
टेस्लर के नियम को डिज़ाइन में अपनाने के लिए पहले यह पता लगाना चाहिए कि उस काम में अंततः कम न की जा सकने वाली जटिलता कहाँ है। इसके बाद केवल वे हिस्से उपयोगकर्ता के पास रखना बेहतर है जिन पर उसका निर्णय लेना ज़रूरी है, और बाकी काम डिफ़ॉल्ट मानों, स्वतः जानकारी भरने तथा चरणबद्ध मार्गदर्शन के माध्यम से प्रणाली को सौंप देना चाहिए। इस दौरान हमेशा तर्कसंगत ढंग से काम करने वाले आदर्श उपयोगकर्ता की कल्पना करने के बजाय, वास्तविक उपयोगकर्ता जहाँ अटकता है, उसी समय और उसी स्थान पर संक्षिप्त सहायता दिखाना अधिक प्रभावी होता है।
हालाँकि, सारी जटिलता छिपा देना समाधान नहीं है। बहुत अधिक छिपाने से उपयोगकर्ता के लिए अपनी इच्छा के अनुसार बदलाव करने का रास्ता समाप्त हो जाता है। इसलिए नए उपयोगकर्ताओं के लिए चरणबद्ध मार्गदर्शन और अनुभवी उपयोगकर्ताओं के लिए अलग उन्नत सेटिंग जैसी व्यवस्था करना ज़रूरी है। इंटरफ़ेस डिज़ाइनर ब्रूस टोग्नाज़िनी (Bruce Tognazzini) का यह भी मानना था कि लोग अपने जीवन की जटिलता घटने को चुपचाप स्वीकार नहीं करते। उनका आशय था कि प्रोग्राम आसान होने पर उपयोगकर्ता उसी अनुपात में अधिक जटिल काम करने की चुनौती स्वीकार करते हैं।
टेस्लर का नियम हमें बताता है कि सरल दिखने वाली स्क्रीन जटिलता समाप्त करने का परिणाम नहीं, बल्कि किसी और के उस जटिलता का बोझ उठाने का परिणाम है। इसलिए अच्छे डिज़ाइन का मूल्यांकन इससे किया जा सकता है कि उसने जटिलता कहाँ रखी है, बजाय इसके कि उसने उसे कितना कम किया है।
उपयोगकर्ता को उठाना पड़ने वाला बोझ उत्पाद बनाने वाला पहले खुद उठाए—यही उपयोगकर्ता के लिए डिज़ाइन करने का पहला कदम है।
