क्या प्रगतिशील सुधार महंगा है?

पिछले लेख ने प्रगतिशील वृद्धि के सिद्धांत और व्यवहार की जांच की। इस लेख में, हम विचारधारा से स्वयंसिद्धता की ओर बढ़ेंगे और प्रगतिशील सुधार लागू करने की वित्तीय और आर्थिक व्यवहार्यता पर विचार करेंगे।

पिछले लेख पर कुछ टिप्पणियों ने राय व्यक्त की कि यह वास्तविक विकास में प्रगतिशील सुधार का उपयोग करने के लायक नहीं है। अत्यधिक लागत से उबले हुए कारण: "इस दृष्टिकोण के अनुसार एक साइट बनाने के लिए, आपको बहुत अधिक समय बिताने की आवश्यकता है, और यह बहुत महंगा है और न तो ग्राहक (पैसे के लिए) और न ही ठेकेदार को इसकी आवश्यकता है।"

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

अच्छा-पुराने-HTML चरण

इस बिंदु पर, टाइपसेट्टर CSS का उपयोग किए बिना तार्किक और शब्दार्थ रूप से सही HTML मार्कअप बनाता है। इस स्तर पर कोई अतिरिक्त समय नहीं लगता है। स्वाभाविक रूप से, कुछ टाइपसेटर्स के लिए HTML कोड बनाना और एक ही समय में आउटलाइन शैलियों के लिए यह अधिक सुविधाजनक है। प्रगतिशील सुधार इस पर प्रतिबंध नहीं लगाता है: कृपया लिखें और शैलियों पर ध्यान दें, लेकिन पहले मार्कअप पर ध्यान दें।

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

सीएसएस स्टेज

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

उन लोगों के लिए जो IE6 का समर्थन करने पर जोर देते हैं, मैं एनकोडिंग के साथ एक एनालॉग दूंगा। इससे पहले, साइट के कई संस्करण बनाए गए थे, जो कि अलग-अलग एन्कोडिंग्स के लिए बनाए गए थे, उदाहरण के लिए, KOI8-R और Win-1251। अब वे ऐसा नहीं करते हैं, हालाँकि, यदि आप चाहें, तो आप बहुत पुराने विंडोज के साथ एक बहुत पुराना कंप्यूटर खोद सकते हैं और चला सकते हैं। तो शायद यह एक बुरे सपने के रूप में IE6 को भूलने का समय है?

अन्य पुराने ब्राउज़रों के लिए जो CSS2 का सही समर्थन करते हैं, साइट उनमें अच्छी दिखेगी। 2008 में पुराने फ़ायरफ़ॉक्स 3 के तहत, लेआउट आसान और सुखद था।

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

CSS3 स्टेज

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

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

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

संक्षेप में: तीसरे चरण में, प्रगतिशील सुधार डेवलपर समय में महत्वपूर्ण बचत देता है।

जावास्क्रिप्ट स्टेज

यह चरण सबसे विवादास्पद और सबसे दिलचस्प है, इसलिए हम इस पर अधिक विस्तार से ध्यान देंगे और कुछ व्यावहारिक उदाहरणों का विश्लेषण करेंगे।

सबसे पहले, एक छोटा अस्वीकरण: हम उन साइटों पर विचार नहीं करेंगे जिनके जावास्क्रिप्ट (जेएस) के बिना संचालन मूल रूप से असंभव है या सभी अर्थ खो देता है, उदाहरण के लिए: Yandex.Maps, Htmlacademy, विभिन्न ऑनलाइन आईडीई और इतने पर।

सामान्य तौर पर, हम कह सकते हैं कि एक सक्षम दृष्टिकोण के साथ, इस स्तर पर समय का एक अतिरिक्त निवेश है, लेकिन वे छोटे हैं। मूल रूप से, वे स्क्रिप्ट के आरंभ को जटिल बनाने के लिए आते हैं। कभी-कभी अतिरिक्त लागत महत्वपूर्ण हो सकती है, क्योंकि जटिलता न केवल क्लाइंट पर होती है, बल्कि सर्वर पर भी होती है।

इस स्तर पर उत्पन्न होने वाली विभिन्न स्थितियों को व्यावहारिक उदाहरणों के साथ सबसे अच्छा समझा जाता है।

उदाहरण 1. कॉल फ़ॉर्म का आदेश दें

उद्देश्य: "साइट के प्रत्येक पृष्ठ पर एक लिंक है" ऑर्डर कॉल करें ", जब क्लिक किया जाता है, तो एक कॉलबैक फॉर्म ओवरले पॉप के साथ आता है।"

समस्या को प्रगतिशील सुधार के अनुसार हल किया गया था:

1. फॉर्म के लिए HTML कोड पेज कोड के अंदर होता है।
2. CSS का उपयोग करते हुए, फ़ॉर्म की उपस्थिति का सबसे सरल प्रभाव बनाया जाता है: शुरू में फ़ॉर्म छिपा हुआ है, केवल "कॉलबैक" लिंक दिखाई देता है। जब आप किसी लिंक पर होवर करते हैं, तो एक पूरी तरह से स्थित रूप दिखाई देता है:
   
   
   
3. JS का उपयोग करके, अतिरिक्त कक्षाओं को फॉर्म में जोड़ा जाता है, जिसकी मदद से डिस्प्ले लॉजिक बदलता है। इसके अलावा, प्रपत्र के व्यवहार, स्थिति तंत्र में सुधार किया जाता है, एक ओवरले जोड़ा जाता है।

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

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

उदाहरण 2. होटल खोज फ़ॉर्म

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

इस उदाहरण में, अतिरिक्त समय की लागत पहले से ही काफी अधिक है। कुल मिलाकर, उन्होंने लगभग एक कार्यदिवस की राशि ली। क्या वे उचित हैं? हम दो बिंदुओं पर ध्यान देते हैं:

1. रूप का महत्व। साइट के साथ काम लगभग हमेशा एक होटल खोज के साथ शुरू होता है।
2. स्थान के अनुसार फ़िल्टरिंग का महत्व: होटल अक्सर किसी विशिष्ट शहर या किसी विशिष्ट क्षेत्र में खोजे जाते हैं।

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

उदाहरण 3. पिज़्ज़ा डिज़ाइनर

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

समस्या को प्रगतिशील सुधार के अनुसार हल किया गया था:

1. जब आप "ऑर्डर ऑनलाइन" लिंक पर क्लिक करते हैं, तो मूल संस्करण में टोकरी में पिज्जा जोड़ा जाता है।
2. यदि जेएस काम करता है, तो जब आप लिंक पर क्लिक करते हैं, तो एक निर्माणकर्ता दिखाई देता है जिसमें आप आटा, सॉस, एडिटिव्स चुन सकते हैं, जिसके बाद पहले से ही पूरा पिज्जा टोकरी में जोड़ा जा सकता है। यहाँ इंटरफ़ेस के कुछ उदाहरण दिए गए हैं:

इस निर्णय के साथ, जैसा कि आपने देखा, कंस्ट्रक्टर का उपयोग करके पिज्जा का पूरा होना केवल जेएस के चलने के साथ ही संभव है। जेएस के बिना एक ही निर्माण कार्य करना काफी लंबा और महंगा होगा। क्या यह इसके लायक है? इस मामले में, सबसे अधिक संभावना है, यह आवश्यक नहीं है, क्योंकि:

1. ऐसी साइटों के लिए बुनियादी कार्यक्षमता टोकरी में अपने पसंदीदा पिज्जा डालने की क्षमता है। ऑर्डर देने के बाद, ऑपरेटर ग्राहक को वापस बुलाता है, जो ऑर्डर, डिलीवरी आदि का विवरण स्पष्ट करता है। यही है, ग्राहक ऑपरेटर की मदद से अपने पिज्जा को हमेशा "ट्यून" कर सकता है।
2. जेएस उपयोगकर्ताओं के एक छोटे प्रतिशत के लिए अक्षम है, और इस तरह की कार्यक्षमता काफी महंगी और समय लेने वाली होगी (और प्रगतिशील सुधार के खिलाफ अन्य विशिष्ट तर्क)।

जैसा कि आप देख सकते हैं, प्रगतिशील सुधार के ढांचे के भीतर भी, आप "शुद्ध एचटीएमएल" में अतिरिक्त कार्यक्षमता को लागू करने से इनकार कर सकते हैं, जो समय और धन दोनों को बचाएगा।

लेकिन! क्या होगा यदि ग्राहक डिजाइनर को महत्वपूर्ण पाता है और उसे जेएस के बिना काम करना चाहता है? यह हमेशा एक अतिरिक्त कीमत पर किया जा सकता है। प्रारंभिक मूल्यांकन में इस तरह के सुधार की लागत को शामिल करने के लिए महत्वपूर्ण बिंदु नहीं है।

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

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

कुल मिलाकर

प्रत्येक चरण में प्रगतिशील सुधार लागू करते समय अतिरिक्त समय खर्च होता है:

1. HTML चरण - कोई नहीं;
2. सीएसएस चरण - कोई नहीं;
3. CSS3 चरण - समय की बचत;
4. जेएस चरण - वर्तमान, लेकिन मामूली।

स्क्रिप्टिंग के चरण में महत्वहीन खर्च लेआउट के चरण में समय की बचत करके क्षतिपूर्ति से अधिक है। परिणामस्वरूप, हमें समय की बचत होती है, न कि अतिरिक्त लागतों की।

हालाँकि, प्रगतिशील सुधार के लिए प्रभावी ढंग से काम करने के लिए, आपके पास दो शर्तें होनी चाहिए:

1. डेवलपर्स की उच्च योग्यता और अनुभव। आप इसे पहली बार जल्दी और कुशलता से नहीं कर सकते। पहले आपको अभ्यास की आवश्यकता है। लेकिन आखिरकार, उन्होंने भी लंबे समय तक और दर्द से PHP में OOP का उपयोग करना सीखा।
2. ग्राहक और डेवलपर दोनों को इस तथ्य के साथ रखना चाहिए कि कुछ ब्राउज़रों में साइट, विशेष रूप से पुराने वाले, "बदतर" (और यहां तक ​​कि IE6 में अलग हो जाएंगे)।

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

दुख के बारे में निष्कर्ष में

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

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