मल्टी-डिवाइस डेवलपमेंट के लिए सिलसिलेवार तरीके से निर्देश
Chrome Experiments A Journey Through Medium-earth के डेवलपमेंट के बारे में हमारे पहले लेख में, हमने मोबाइल डिवाइसों के लिए WebGL के डेवलपमेंट पर फ़ोकस किया है. इस लेख में, हमने HTML5 फ़्रंट-एंड बनाते समय आने वाली चुनौतियों, समस्याओं, और समाधानों पर चर्चा की है.
एक ही साइट के तीन वर्शन
चलिए, स्क्रीन-साइज़ और डिवाइस की क्षमता के लिहाज़ से इस एक्सपेरिमेंट को डेस्कटॉप कंप्यूटर और मोबाइल डिवाइस, दोनों पर काम करने के हिसाब से अपनाने के बारे में बात करते हैं.
यह पूरा प्रोजेक्ट काफ़ी “सिनेमैटिक” स्टाइल पर आधारित है. हम चाहते थे कि फ़िल्म के अनुभव को, लैंडस्केप के हिसाब से तय फ़्रेम में रखा जाए, ताकि वीडियो का जादू बना रहे. इस प्रोजेक्ट का एक बड़ा हिस्सा इंटरैक्टिव मिनी “गेम” से जुड़ा है, इसलिए उन्हें फ़्रेम से बाहर निकलने देने का कोई मतलब नहीं होगा.
हम लैंडिंग पेज को उदाहरण के तौर पर देख सकते हैं कि हम डिज़ाइन को अलग-अलग साइज़ के हिसाब से कैसे तैयार करते हैं.
इस साइट में तीन अलग-अलग मोड हैं: डेस्कटॉप, टैबलेट, और मोबाइल. हमें सिर्फ़ लेआउट को हैंडल करने के लिए नहीं, बल्कि रनटाइम के साथ लोड होने वाली ऐसेट को मैनेज करने और कई तरह की परफ़ॉर्मेंस को ऑप्टिमाइज़ करने की ज़रूरत होती है. ऐसे डिवाइस जिनका रिज़ॉल्यूशन डेस्कटॉप कंप्यूटर और लैपटॉप से ज़्यादा होता है, लेकिन उनका परफ़ॉर्मेंस फ़ोन से खराब होता है, ऐसे में नियमों का अंतिम सेट तय करना आसान काम नहीं है.
हम मोबाइल डिवाइसों का पता लगाने के लिए, उपयोगकर्ता-एजेंट डेटा का इस्तेमाल कर रहे हैं. साथ ही, उन डिवाइसों (645 पिक्सल और उससे ज़्यादा) में से टैबलेट को टारगेट करने के लिए, व्यूपोर्ट साइज़ टेस्ट का इस्तेमाल कर रहे हैं. असल में, हर अलग मोड सभी रिज़ॉल्यूशन को रेंडर कर सकता है, क्योंकि लेआउट मीडिया क्वेरी या JavaScript के साथ मिलते-जुलते/प्रतिशत की पोज़िशनिंग पर आधारित होता है.
इस मामले में डिज़ाइन, ग्रिड या नियमों पर आधारित नहीं होते और अलग-अलग सेक्शन के बीच काफ़ी यूनीक होते हैं. इसलिए, यह असल में किसी खास एलिमेंट और स्थिति पर निर्भर करता है कि किस ब्रेकपॉइंट या स्टाइल का इस्तेमाल करना है. ऐसा कई बार हुआ कि हमने अच्छे सैस-मिक्स और मीडिया-क्वेरी के साथ सबसे सही लेआउट को सेट अप कर लिया. इसके बाद, हमें माउस की स्थिति या डाइनैमिक ऑब्जेक्ट के आधार पर एक इफ़ेक्ट जोड़ना पड़ा और JavaScript में सबकुछ फिर से लिखना पड़ा.
हम हेड टैग में मौजूदा मोड के साथ एक क्लास भी जोड़ते हैं, ताकि हम उस जानकारी का इस्तेमाल अपनी स्टाइल में कर सकें, जैसे कि इस उदाहरण (एससीएसएस में):
.loc-hobbit-logo {
// Default values here.
.desktop & {
// Applies only in desktop mode.
}
.tablet &, .mobile & {
// Different asset for mobile and tablets perhaps.
@media screen and (max-height: 760px), (max-width: 760px) {
// Breakpoint-specific styles.
}
@media screen and (max-height: 570px), (max-width: 400px) {
// Breakpoint-specific styles.
}
}
}
हम 360x320 तक के सभी साइज़ के डिवाइस इस्तेमाल करने की सुविधा देते हैं. यह एक शानदार वेब अनुभव बनाते समय काफ़ी चुनौती भरा काम है. डेस्कटॉप पर स्क्रोलबार दिखाने से पहले, हमारे पास एक कम से कम साइज़ होता है, क्योंकि हम चाहते हैं कि अगर हो सके, तो आप साइट को बड़े व्यूपोर्ट पर अनुभव करें. हमने मोबाइल डिवाइसों पर लैंडस्केप और पोर्ट्रेट मोड, दोनों को इंटरैक्टिव अनुभव देने का फ़ैसला लिया है, जहां हम आपसे डिवाइस को लैंडस्केप में बदलने के लिए कहते हैं. इसके ख़िलाफ़ तर्क यह था कि यह पोर्ट्रेट में इतना इमर्सिव नहीं है जितना कि लैंडस्केप में. हालांकि, साइट की पहुंच बहुत अच्छी थी, इसलिए हमने इसे बनाए रखा.
इस बात पर ध्यान दें कि इनपुट टाइप, डिवाइस ओरिएंटेशन, सेंसर वगैरह जैसी सुविधा का पता लगाने की सुविधा के साथ लेआउट को नहीं मिलाया जाना चाहिए. ये सुविधाएं इन सभी मोड में मौजूद हो सकती हैं और सभी के बीच होनी चाहिए. माउस और टच को एक साथ दिखाना इसका एक उदाहरण है. क्वालिटी के मामले में रेटिना का मुआवज़ा मिलता है, लेकिन ज़्यादातर परफ़ॉर्मेंस दूसरी तरह की होती है, लेकिन कभी-कभी कम क्वालिटी बेहतर होती है. उदाहरण के तौर पर, रेटिना डिस्प्ले पर WebGL के अनुभवों में कैनवस आधा रिज़ॉल्यूशन है, जिसके लिए हमें पिक्सल की संख्या का चार गुना रेंडर करना पड़ता
हमने डेवलपमेंट के दौरान DevTools में अक्सर एम्युलेटर टूल का इस्तेमाल किया. खास तौर पर, Chrome कैनरी में इसका इस्तेमाल किया गया. इसमें नई और बेहतर सुविधाएं और कई प्रीसेट हैं. यह डिज़ाइन की जल्दी से पुष्टि करने का एक अच्छा तरीका है. हमें अब भी समय-समय पर असली डिवाइसों पर टेस्ट करना पड़ता था. इसकी एक वजह यह थी कि साइट, फ़ुलस्क्रीन पर काम कर रही थी. ज़्यादातर मामलों में स्क्रोल करते समय वर्टिकल स्क्रोल वाले पेज में ब्राउज़र यूज़र इंटरफ़ेस (यूआई) छिप जाता है (iOS7 पर Safari में फ़िलहाल इस समस्या में समस्याएं हैं) लेकिन हमें हर चीज़ को उसके हिसाब से फ़िट करना पड़ता था. हमने एम्युलेटर में प्रीसेट का भी इस्तेमाल किया है और स्क्रीन साइज़ की सेटिंग में बदलाव किया है, ताकि उपलब्ध जगह के खोने का अनुमान लगाया जा सके. मेमोरी के इस्तेमाल और परफ़ॉर्मेंस को मॉनिटर करने के लिए, असली डिवाइसों पर टेस्ट करना भी ज़रूरी है
राज्य का कंट्रोल
लैंडिंग पेज के बाद, हम मिडिल अर्थ के मैप पर पहुंचते हैं. क्या आपने यूआरएल में बदलाव देखा है? यह साइट एक पेज का ऐप्लिकेशन है, जो रूटिंग को मैनेज करने के लिए, इतिहास एपीआई का इस्तेमाल करता है.
साइट का हर सेक्शन उसका अपना ऑब्जेक्ट होता है, जो फ़ंक्शन के बॉयलरप्लेट को इनहेरिट करता है. जैसे, डीओएम एलिमेंट, ट्रांज़िशन, एसेट लोड करना, एसेट को लोड करना वगैरह. साइट के अलग-अलग हिस्सों को एक्सप्लोर करने पर, सेक्शन शुरू हो जाते हैं. साथ ही, डीओएम में एलिमेंट जोड़े और हटाए जाते हैं. साथ ही, मौजूदा सेक्शन के एसेट लोड हो जाते हैं.
उपयोगकर्ता किसी भी समय ब्राउज़र के 'वापस जाएं' बटन पर क्लिक कर सकता है या मेन्यू से नेविगेट कर सकता है. इसलिए, जो भी चीज़ बनाई गई है उसे किसी न किसी समय नष्ट करना ज़रूरी है. टाइम आउट और ऐनिमेशन को रोकना और खारिज करना ज़रूरी है. ऐसा न करने पर, अनचाहा व्यवहार, गड़बड़ियां, और मेमोरी लीक हो सकती हैं. यह काम हमेशा आसान नहीं होता, खासकर तब, जब समयसीमा खत्म होने वाली हो और आपको सभी काम जल्द से जल्द करने की ज़रूरत हो.
जगहों की जानकारी दिखाई जा रही है
सुंदर सेटिंग और मिडिल अर्थ के किरदारों को दिखाने के लिए, हमने इमेज और टेक्स्ट के कॉम्पोनेंट का एक मॉड्यूलर सिस्टम बनाया है. इसे हॉरिज़ॉन्टल तौर पर खींचकर छोड़ा जा सकता है या स्वाइप किया जा सकता है. हमने यहां स्क्रोलबार चालू नहीं किया है, क्योंकि हम अलग-अलग रेंज पर अलग-अलग स्पीड रखना चाहते हैं. उदाहरण के लिए, इमेज का क्रम, जहां आप तिरछी गति से होने वाली गति को तब तक रोक सकते हैं, जब तक क्लिप पूरी नहीं हो जाती.
टाइमलाइन
जब विकास शुरू हुआ, तब हमें हर जगह के लिए मॉड्यूल की सामग्री के बारे में पता नहीं था. हमें यह पता था कि हम अलग-अलग तरह के मीडिया और जानकारी को हॉरिज़ॉन्टल टाइमलाइन पर दिखाने का एक टेंप्लेट तरीका चाहते हैं. इससे हमें छह अलग-अलग जगह प्रज़ेंटेशन बनाने की आज़ादी मिलेगी और इसके लिए, आपको हर छह बार में अलग-अलग प्रोजेक्ट बनाने की ज़रूरत नहीं पड़ेगी. इसे मैनेज करने के लिए, हमने एक टाइमलाइन कंट्रोलर बनाया है, जो सेटिंग और मॉड्यूल के व्यवहार के हिसाब से, इसके मॉड्यूल की पैनिंग को मैनेज करता है.
मॉड्यूल और व्यवहार से जुड़े कॉम्पोनेंट
हमने इन अलग-अलग मॉड्यूल के लिए सुविधा जोड़ी है: इमेज क्रम, स्टिल इमेज, पैरालैक्स सीन, फ़ोकस-शिफ़्ट सीन, और टेक्स्ट.
पैरालैक्स सीन मॉड्यूल में, अपनी पसंद के हिसाब से चुनी गई लेयर के साथ ओपेक बैकग्राउंड होता है. यह बैकग्राउंड की सटीक पोज़िशन के लिए, व्यूपोर्ट की प्रोग्रेस को सुनता है.
फ़ोकस-शिफ़्ट सीन, पैरलैक्स बकेट का एक वैरिएंट है. इसके अलावा, हम हर लेयर के लिए दो इमेज का इस्तेमाल करते हैं, जो फ़ोकस बदलाव को सिम्युलेट करने के लिए फ़ेड इन और आउट होती हैं. हमने ब्लर फ़िल्टर का इस्तेमाल करने की कोशिश की, लेकिन यह अब भी महंगा है. इसलिए, हम इसके लिए सीएसएस शेडर का इंतज़ार करेंगे.
टेक्स्ट मॉड्यूल के कॉन्टेंट को TweenMax प्लगिन के साथ, Draggable में खींचकर छोड़ने की सुविधा चालू होती है. वर्टिकल तौर पर स्क्रोल करने के लिए, स्क्रोलव्हील या दो उंगलियों से स्वाइप भी किया जा सकता है. उस throw-props-plugin पर ध्यान दें जो स्वाइप करने और छोड़ने पर फ़्लिंग-स्टाइल फ़िज़िक्स जोड़ता है.
मॉड्यूल में अलग-अलग ऐसे व्यवहार भी हो सकते हैं जिन्हें कॉम्पोनेंट के सेट के तौर पर जोड़ा जाता है. उन सभी के अपने-अपने टारगेट सिलेक्टर और सेटिंग होती हैं. किसी एलिमेंट को एक से दूसरी जगह ले जाने के लिए अनुवाद करें, ज़ूम करने के लिए स्केल करें, जानकारी ओवरले के लिए हॉटस्पॉट, विज़ुअल तौर पर टेस्ट करने के लिए डीबग मेट्रिक, शुरुआती टाइटल ओवरले, फ़्लेयर लेयर वगैरह. इन्हें डीओएम में जोड़ा जाएगा या मॉड्यूल के अंदर टारगेट एलिमेंट को कंट्रोल किया जाएगा.
इसे तय करके, हम सिर्फ़ एक config फ़ाइल का इस्तेमाल करके अलग-अलग जगहें बना सकते हैं. इससे यह तय होता है कि किन ऐसेट को लोड करना है और अलग-अलग तरह के मॉड्यूल और कॉम्पोनेंट को सेटअप करना है.
इमेज का क्रम
परफ़ॉर्मेंस और डाउनलोड-साइज़ के मॉड्यूल में सबसे मुश्किल इमेज क्रम है. इस विषय के बारे में पढ़ने के लिए बहुत कुछ है. मोबाइल और टैबलेट पर, हम इसे इमेज से बदल देते हैं. अगर हमें मोबाइल पर सही क्वालिटी चाहिए, तो मेमोरी में डीकोड और स्टोर करने के लिए बहुत ज़्यादा डेटा है. हमने कई अन्य समाधान आज़माए; सबसे पहले बैकग्राउंड इमेज और स्प्राइटशीट का इस्तेमाल किया, लेकिन इसकी वजह से मेमोरी से जुड़ी समस्याएं पैदा हुईं और जीपीयू को स्प्राइटशीट के बीच स्वैप करने की ज़रूरत हुई. फिर हमने img एलिमेंट को बदलने की कोशिश की, लेकिन यह प्रोसेस बहुत धीमी थी. स्प्राइटशीट से कैनवस पर फ़्रेम बनाना सबसे बेहतर परफ़ॉर्म करने वाला था. इसलिए, हमने इसे ऑप्टिमाइज़ करना शुरू किया. हर फ़्रेम का कंप्यूटेशन टाइम बचाने के लिए, कैनवस में लिखे जाने वाले इमेज डेटा को अस्थायी कैनवस से पहले से प्रोसेस किया जाता है. साथ ही, उसे डिकोड करके एक अरे में सेव किया जाता है. यह डेटा इस्तेमाल करने के लिए तैयार होता है. ऐसा करने से, मूल स्प्राइटशीट में कचरा इकट्ठा हो सकता है और हम मेमोरी में उतना ही कम डेटा स्टोर करते हैं जितना ज़रूरी है. बिना कोड वाली इमेज को सेव करना वाकई में कम काम है, लेकिन इस तरीके से क्रम को आगे-पीछे करने से हमें बेहतर परफ़ॉर्मेंस मिलती है. फ़्रेम बहुत छोटे हैं, बस 640x400 के, लेकिन वे केवल स्क्रबिंग के दौरान दिखाई देंगे. कैमरे के रुकने पर, हाई-रिज़ॉल्यूशन वाली इमेज लोड होती है और तेज़ी से फ़ेड इन हो जाती है.
var canvas = document.createElement('canvas');
canvas.width = imageWidth;
canvas.height = imageHeight;
var ctx = canvas.getContext('2d');
ctx.drawImage(sheet, 0, 0);
var tilesX = imageWidth / tileWidth;
var tilesY = imageHeight / tileHeight;
var canvasPaste = canvas.cloneNode(false);
canvasPaste.width = tileWidth;
canvasPaste.height = tileHeight;
var i, j, canvasPasteTemp, imgData,
var currentIndex = 0;
var startIndex = index * 16;
for (i = 0; i < tilesY; i++) {
for (j = 0; j < tilesX; j++) {
// Store the image data of each tile in the array.
canvasPasteTemp = canvasPaste.cloneNode(false);
imgData = ctx.getImageData(j * tileWidth, i * tileHeight, tileWidth, tileHeight);
canvasPasteTemp.getContext('2d').putImageData(imgData, 0, 0);
list[ startIndex + currentIndex ] = imgData;
currentIndex++;
}
}
स्प्राइट-शीट, Imagemagick की मदद से जनरेट की जाती हैं. यहां GitHub पर एक उदाहरण दिया गया है, जिसमें किसी फ़ोल्डर के अंदर सभी इमेज की स्प्राइटशीट बनाने का तरीका बताया गया है.
मॉड्यूल ऐनिमेट किया जा रहा है
मॉड्यूल को टाइमलाइन पर रखने के लिए, टाइमलाइन को छिपे हुए रूप में, ऑफ़स्क्रीन पर दिखाया जाता है. यह 'प्लेहेड' और टाइमलाइन की चौड़ाई को ट्रैक करता है. यह काम सिर्फ़ कोड की मदद से किया जा सकता है. हालांकि, इसे डेवलप और डीबग करते समय, विज़ुअल तौर पर दिखाना अच्छा था. इसे असल में चलते समय, डाइमेंशन सेट करने के लिए साइज़ बदलने पर अपडेट किया जाता है. कुछ मॉड्यूल व्यूपोर्ट में भरे होते हैं और कुछ का अपना अनुपात होता है, इसलिए हर चीज़ को सभी रिज़ॉल्यूशन में स्केल करना और उसकी जगह बदलना थोड़ा मुश्किल था, ताकि हर चीज़ दिखाई दे और बहुत ज़्यादा काटे न जाए. हर मॉड्यूल में दो प्रोग्रेस इंंडिकेटर होते हैं, एक स्क्रीन पर दिखने वाली स्थिति के लिए और दूसरा मॉड्यूल की अवधि के लिए. पैरालैक्स मूव करते समय, ऑब्जेक्ट के शुरू और आखिर की पोज़िशन का पता लगाना अक्सर मुश्किल होता है. ऐसा तब होता है, जब ऑब्जेक्ट को व्यू में होने पर, उसकी अनुमानित पोज़िशन के साथ सिंक किया जाता है. यह जानना ज़रूरी है कि कोई मॉड्यूल कब व्यू में आता है, इसकी इंटरनल टाइमलाइन कब चालू होती है, और कब यह व्यू के बाहर दिखने लगता है.
हर मॉड्यूल के ऊपर एक हल्के काली लेयर होती है, जो अपनी ओपैसिटी को अडजस्ट करती है, ताकि जब यह बीच में हो, तो यह पूरी तरह से पारदर्शी हो. इससे आपको एक समय में एक ही मॉड्यूल पर फ़ोकस करने में मदद मिलती है, जिससे आपको बेहतर अनुभव मिलता है.
पेज की परफ़ॉर्मेंस
काम करने वाले प्रोटोटाइप से जैंक-फ़्री रिलीज़ वर्शन पर जाने का मतलब है, सिर्फ़ यह अनुमान लगाना कि ब्राउज़र में क्या होता है. ऐसे में, Chrome DevTools आपके लिए सबसे अच्छा है.
हमने साइट को ऑप्टिमाइज़ करने में काफ़ी समय लगाया है. शानदार ऐनिमेशन पाने के लिए, ज़बरदस्ती हार्डवेयर की रफ़्तार बढ़ाने का टूल सबसे अहम टूल में से एक है. इसके अलावा, Chrome DevTools में रंग-बिरंगे कॉलम और लाल रंग के रेक्टैंगल भी खोजे जा सकते हैं. विषयों के बारे में कई अच्छे लेख हैं और आपको उन सभी को पढ़ना चाहिए. स्किप करने वाले फ़्रेम तुरंत हटाने का इनाम तुरंत मिलता है, लेकिन उनके वापस लौटने पर उन्हें निराशा होती है. और उन्हें ऐसा करना पड़ेगा. यह लगातार चलने वाली प्रोसेस है और इसमें बार-बार बदलाव करने की ज़रूरत है.
मुझे ट्वीन प्रॉपर्टी, ट्रांसफ़ॉर्म, और सीएसएस के लिए Greensock के TweenMax कैंपेन का इस्तेमाल करना पसंद है. कंटेनर में सोचें और नई लेयर जोड़ते समय अपने स्ट्रक्चर को विज़ुअलाइज़ करें. ध्यान रखें कि मौजूदा बदलावों को नए बदलावों से ओवरराइट किया जा सकता है. आपकी सीएसएस क्लास में हार्डवेयर से तेज़ी लाने को मजबूर करने वाले TranslateZ(0) को, 2D मैट्रिक्स से बदल दिया जाता है. ऐसा तब होता है, जब आपने सिर्फ़ 2D वैल्यू जोड़ी हों. ऐसे मामलों में, लेयर को ऐक्सेलरेशन मोड में रखने के लिए, 2D मैट्रिक्स के बजाय 3D मैट्रिक्स बनाने के लिए, ट्वीन में “force3D:true” प्रॉपर्टी का इस्तेमाल करें. स्टाइल सेट करने के लिए, सीएसएस और JavaScript ट्वीन को एक साथ इस्तेमाल करने पर कोई परेशानी नहीं होती.
जहां इसकी ज़रूरत न हो, वहां हार्डवेयर से तेज़ी लाने की सुविधा लागू न करें. जब आपको कई कंटेनर को हार्डवेयर से तेज़ी से बढ़ाने की ज़रूरत होती है, तो जीपीयू की मेमोरी तेज़ी से भर सकती है और अनचाहे नतीजे दे सकती है. खास तौर पर, iOS पर, जहां मेमोरी को लेकर समस्याएं कम होती हैं. छोटी एसेट को लोड करने और उन्हें सीएसएस के साथ बढ़ाने और मोबाइल मोड में कुछ इफ़ेक्ट बंद करने के लिए बड़े सुधार किए गए हैं.
मेमोरी लीक एक और फ़ील्ड था, जिसमें हमें अपने कौशल को बेहतर बनाने की ज़रूरत थी. अलग-अलग WebGL के बीच नेविगेट करते समय, कई चीज़ें, सामग्री, बनावट, और ज्यामिति बनाई जाती हैं. अगर बाहर नेविगेट करने के दौरान वे कचरा हटाने के लिए तैयार नहीं हैं और उस सेक्शन को हटा देते हैं, तो मेमोरी खत्म होने पर कुछ समय के बाद डिवाइस क्रैश हो सकता है.
डेटा लीक होने का पता लगाने के लिए, DevTools में सीधे तौर पर वर्कफ़्लो को मैनेज किया जा रहा था. इसके लिए, टाइमलाइन को रिकॉर्ड किया जा रहा था और हीप स्नैपशॉट कैप्चर किए गए थे. अगर 3D ज्यामिति या खास लाइब्रेरी जैसी कोई खास चीज़ है, जिसे आप फ़िल्टर कर सकते हैं, तो यह आसान है. ऊपर दिए गए उदाहरण में यह पता चला कि 3D दृश्य अब भी आस-पास था और ज्यामिति को संग्रहित करने वाली श्रेणी को भी साफ़ नहीं किया गया था. अगर आपको यह पता लगाने में मुश्किल होती है कि ऑब्जेक्ट कहां मौजूद है, तो एक अच्छी सुविधा की मदद से डेटा को बनाए रखने की प्रोसेस को देखा जा सकता है. बस उस ऑब्जेक्ट पर क्लिक करें जिसकी जांच आपको हीप स्नैपशॉट में करनी है. इसके बाद, आपको नीचे दिए गए पैनल में जानकारी मिलेगी. छोटे ऑब्जेक्ट के साथ अच्छे स्ट्रक्चर का इस्तेमाल करने से, आपके रेफ़रंस ढूंढने में मदद मिलती है.
आम तौर पर, DOM में हेर-फेर करने से पहले दो बार सोचना सही होता है. ऐसा करते समय, परफ़ॉर्मेंस के बारे में सोचें. अगर हो सके, तो गेम लूप के अंदर DOM में हेर-फेर न करें. फिर से इस्तेमाल करने के लिए, वैरिएबल में रेफ़रंस को स्टोर करें. अगर आपको किसी एलिमेंट को खोजना है, तो सबसे छोटे रूट का इस्तेमाल करें. इसके लिए, स्ट्रटीजिक कंटेनर के रेफ़रंस स्टोर करें और सबसे नज़दीकी एंसेस्टर एलिमेंट में खोजें.
अगर आपको लेआउट में गड़बड़ियों का सामना करना पड़ता है, तो जोड़े गए नए एलिमेंट के डाइमेंशन को पढ़ने में देरी करें. इसके अलावा, क्लास को हटाने/जोड़ने पर भी रोक लगाएं. या पक्का करें कि लेआउट ट्रिगर किया गया है. कभी-कभी ब्राउज़र बैच, स्टाइल में बदल जाता है और अगले लेआउट ट्रिगर के बाद अपडेट नहीं होगा. कभी-कभी यह वाकई एक बड़ी समस्या हो सकती है, लेकिन ऐसा किसी कारण से होता है, इसलिए यह जानने की कोशिश करें कि यह कैसे पर्दे के पीछे काम कर रही है और आपको बहुत कुछ मिलेगा.
फ़ुलस्क्रीन
उपलब्ध होने पर, आपके पास साइट को Fullscreen API के ज़रिए मेन्यू में फ़ुलस्क्रीन-मोड में रखने का विकल्प होता है. हालांकि, डिवाइसों पर ब्राउज़र का भी इस्तेमाल किया जा सकता है कि वे उसे फ़ुलस्क्रीन पर डालें. iOS पर Safari में पहले एक हैक था, जिसकी मदद से उसे कंट्रोल किया जा सकता है. हालांकि, यह अब उपलब्ध नहीं है. इसलिए, बिना स्क्रोल किए जाने वाला पेज बनाते समय, आपको अपना डिज़ाइन इस तरह तैयार करना होगा कि वह उसके बिना भी काम करे. ऐसा हो सकता है कि आने वाले समय में हम इस अपडेट में अपडेट हों, क्योंकि इसकी वजह से कई वेब-ऐप्लिकेशन काम नहीं कर रहे हैं.
एसेट
पूरी साइट पर अलग-अलग तरह की कई ऐसेट मौजूद हैं. हम इमेज (PNG और JPEG), SVG (इनलाइन और बैकग्राउंड), स्प्राइटशीट (PNG), कस्टम आइकॉन के फ़ॉन्ट, और Adobe Edge के ऐनिमेशन का इस्तेमाल करते हैं. हम एसेट और ऐनिमेशन (स्प्राइटशीट) के लिए PNG का इस्तेमाल करते हैं, जहां एलिमेंट वेक्टर पर आधारित नहीं हो सकता. ऐसा न होने पर, हम ज़्यादा से ज़्यादा SVGs इस्तेमाल करने की कोशिश करते हैं.
वेक्टर फ़ॉर्मैट का मतलब क्वालिटी में कोई नुकसान नहीं होता, भले ही हम इसे स्केल कर लें. सभी डिवाइसों के लिए 1 फ़ाइल.
- फ़ाइल का साइज़ छोटा है.
- हम हर हिस्से को अलग-अलग ऐनिमेट कर सकते हैं (बेहतर ऐनिमेशन के लिए यह बेहतरीन है). उदाहरण के तौर पर, जब Hobbit लोगो (Smaug का डीसोलेशन) को छोटा किया जाता है, तो हम उसका "सबटाइटल" छिपा देते हैं.
- इसे SVG HTML टैग के रूप में एम्बेड किया जा सकता है या बिना किसी अतिरिक्त लोडिंग के बैकग्राउंड-इमेज के रूप में इस्तेमाल किया जा सकता है (यह एचटीएमएल पेज के समय पर ही लोड होता है).
आइकॉन टाइपफ़ेस के फ़ायदे, SVG की तरह ही होते हैं, जैसे कि स्केलेबिलिटी. इन आइकॉन का इस्तेमाल, SVG की जगह किया जाता है. इनका इस्तेमाल छोटे एलिमेंट के लिए किया जाता है, जैसे कि आइकॉन जिन पर हमें सिर्फ़ रंग बदलने (होवर, ऐक्टिव वगैरह) की ज़रूरत होती है. आइकॉन, फिर से इस्तेमाल करना भी बहुत आसान है. आपको बस किसी एलिमेंट की सीएसएस "content" प्रॉपर्टी सेट करनी होगी.
ऐनिमेशन
कुछ मामलों में, SVG एलिमेंट को कोड के साथ ऐनिमेट करने में बहुत समय लग सकता है, खासकर तब, जब डिज़ाइन के दौरान ऐनिमेशन में काफ़ी बदलाव करने की ज़रूरत होती है. डिज़ाइनर और डेवलपर के बीच वर्कफ़्लो को बेहतर बनाने के लिए, हम कुछ ऐनिमेशन (गेम से पहले दिए गए निर्देश) के लिए Adobe Edge का इस्तेमाल करते हैं. ऐनिमेशन वर्कफ़्लो, Flash के काफ़ी करीब है. इससे टीम को मदद मिली, लेकिन इसकी कुछ कमियां हैं, खास तौर पर हमारी एसेट लोडिंग प्रक्रिया में Edge ऐनिमेशन जोड़ने से, क्योंकि यह अपने लोडर और लागू करने के लॉजिक के साथ आता है.
मुझे अब भी लगता है कि वेब पर एसेट और हाथ से बनाए गए ऐनिमेशन को हैंडल करने के लिए बेहतरीन वर्कफ़्लो शुरू करने से पहले, अभी हमें बहुत लंबा सफ़र तय करना है. हमें यह देखने का बेसब्री से इंतज़ार है कि Edge जैसे टूल और कैसे बेहतर होंगे. टिप्पणियों में, दूसरे ऐनिमेशन टूल और वर्कफ़्लो के बारे में सुझाव देने में भी आपको कोई परेशानी न हो.
नतीजा
अब जब प्रोजेक्ट के सभी हिस्से रिलीज़ हो जाते हैं और आखिरी नतीजा देखा जाता है, तो मुझे कहना होगा कि हम आधुनिक मोबाइल ब्राउज़र की स्थिति से बहुत प्रभावित हैं. जब हमने इस प्रोजेक्ट की शुरुआत की थी, तब हमें इस बात की उम्मीद कम थी कि हम इसे बेहद आसान, इंटिग्रेटेड, और बेहतर परफ़ॉर्म कर पाएंगे. हमारे लिए यह सीखने का बहुत अच्छा अनुभव रहा है. इसे बार-बार दोहराने और टेस्ट करने में लगे समय ने मॉडर्न ब्राउज़र के काम करने के तरीके को बेहतर बनाया है. अगर हम इस तरह के प्रोजेक्ट के प्रोडक्शन में लगने वाले समय को कम करना चाहें, तो सिर्फ़ अनुमान लगाने तक सीमित नहीं करना पड़ेगा.