क्रॉस-डिवाइस वेबऐप्लिकेशन बनाने का ऐसा तरीका जो रिस्पॉन्सिव नहीं है

Boris Smus

मीडिया क्वेरी बहुत अच्छी होती हैं, लेकिन…

मीडिया क्वेरी बहुत अच्छी होती हैं. यह वेबसाइट डेवलपर के लिए किसी वरदान से कम नहीं है. इसकी मदद से, डेवलपर अलग-अलग साइज़ के डिवाइसों पर उपयोगकर्ताओं को बेहतर अनुभव देने के लिए, अपनी स्टाइलशीट में छोटे-मोटे बदलाव कर सकते हैं. मीडिया क्वेरी की मदद से, स्क्रीन के साइज़ के हिसाब से अपनी साइट की सीएसएस को पसंद के मुताबिक बनाया जा सकता है. इस लेख को पढ़ने से पहले, रिस्पॉन्सिव डिज़ाइन के बारे में ज़्यादा जानें. साथ ही, मीडिया क्वेरी के इस्तेमाल के कुछ बेहतरीन उदाहरण यहां देखें: mediaqueri.es.

ब्रैड फ़्रॉस्ट ने पिछले लेख में बताया है कि मोबाइल वेब के लिए वेबसाइट बनाते समय, सिर्फ़ लुक में बदलाव करने के अलावा और भी कई बातों का ध्यान रखना होता है. अगर आपने मोबाइल वेबसाइट बनाते समय, सिर्फ़ मीडिया क्वेरी की मदद से लेआउट को पसंद के मुताबिक बनाया है, तो ऐसी स्थिति में:

• सभी डिवाइसों को एक ही JavaScript, सीएसएस, और ऐसेट (इमेज, वीडियो) मिलती हैं. इस वजह से, पेज लोड होने में ज़रूरत से ज़्यादा समय लगता है.
• सभी डिवाइसों को एक ही शुरुआती डीओएम मिलता है. इससे डेवलपर को बहुत ज़्यादा जटिल सीएसएस लिखनी पड़ सकती है.
• हर डिवाइस के हिसाब से, कस्टम इंटरैक्शन तय करने की सुविधा कम होती है.

वेब ऐप्लिकेशन के लिए, मीडिया क्वेरी से ज़्यादा की ज़रूरत होती है

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

जैसे-जैसे आपके बनाए गए यूज़र इंटरफ़ेस (यूआई) ज़्यादा जटिल होते जाते हैं और आप सिंगल-पेज वेब ऐप्लिकेशन की ओर बढ़ते हैं, वैसे-वैसे आपको हर तरह के डिवाइस के लिए यूआई को ज़्यादा से ज़्यादा पसंद के मुताबिक बनाना होगा. इस लेख में, कम से कम मेहनत करके इन बदलावों को करने का तरीका बताया गया है. सामान्य तौर पर, इस तरीके में आपके विज़िटर के डिवाइस को सही डिवाइस क्लास में बांटा जाता है. इसके बाद, उस डिवाइस को सही वर्शन दिखाया जाता है. साथ ही, वर्शन के बीच कोड के दोबारा इस्तेमाल को ज़्यादा से ज़्यादा किया जाता है.

आपको किस तरह के डिवाइसों को टारगेट करना है?

इंटरनेट से कनेक्ट होने वाले डिवाइसों की संख्या बहुत ज़्यादा है. इनमें से लगभग सभी डिवाइसों में ब्राउज़र होता है. इनकी विविधता की वजह से, इन्हें कंट्रोल करना मुश्किल होता है: Mac लैपटॉप, Windows वर्कस्टेशन, iPhone, iPad, टच इनपुट वाले Android फ़ोन, स्क्रोल व्हील, कीबोर्ड, वॉइस इनपुट, प्रेशर सेंसिटिविटी वाले डिवाइस, स्मार्ट वॉच, टोस्टर, रेफ़्रिजरेटर, और ऐसे ही कई अन्य डिवाइस. इनमें से कुछ डिवाइस हर जगह उपलब्ध हैं, जबकि कुछ बहुत कम मिलते हैं.

अलग-अलग तरह के डिवाइस (सोर्स).

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

इस स्पेक्ट्रम के दो छोर हैं:

1. एक ऐसा वर्शन बनाएं जो सभी डिवाइसों पर काम करे. इस वजह से, यूज़र एक्सपीरियंस (यूएक्स) पर असर पड़ेगा, क्योंकि अलग-अलग डिवाइसों के लिए डिज़ाइन से जुड़ी अलग-अलग बातों को ध्यान में रखना ज़रूरी होता है.

2. हर उस डिवाइस के लिए एक वर्शन बनाएं जिस पर आपको ऐप्लिकेशन उपलब्ध कराना है. इसमें बहुत समय लगेगा, क्योंकि आपको अपने ऐप्लिकेशन के कई वर्शन बनाने होंगे. इसके अलावा, जब अगला नया स्मार्टफ़ोन आएगा (जो हर हफ़्ते आता है), तो आपको एक और वर्शन बनाना होगा.

यहां एक बुनियादी समझौता है: आपके पास जितनी ज़्यादा डिवाइस कैटगरी होंगी, उतना ही बेहतर उपयोगकर्ता अनुभव दिया जा सकेगा. हालांकि, उन्हें डिज़ाइन करने, लागू करने, और बनाए रखने में उतना ही ज़्यादा समय लगेगा.

हर डिवाइस क्लास के लिए अलग-अलग वर्शन बनाना, परफ़ॉर्मेंस के लिहाज़ से अच्छा हो सकता है. ऐसा तब भी किया जा सकता है, जब आपको अलग-अलग डिवाइस क्लास के लिए अलग-अलग वर्शन दिखाने हों. इसके अलावा, रिस्पॉन्सिव वेब डिज़ाइन का इस्तेमाल करना एक सही तरीका है.

समस्या का संभावित हल

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

1. छोटी स्क्रीन + टच (ज़्यादातर फ़ोन)
2. बड़ी स्क्रीन + टच (ज़्यादातर टैबलेट)
3. बड़ी स्क्रीन + कीबोर्ड/माउस (ज़्यादातर डेस्कटॉप/लैपटॉप)

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

ऑपरेटिंग सिस्टम के हिसाब से वेब ऐप्लिकेशन के उदाहरण

ऐसी कई वेब प्रॉपर्टी के उदाहरण मौजूद हैं जो अलग-अलग साइज़ या कॉन्फ़िगरेशन वाले डिवाइसों के लिए, पूरी तरह से अलग-अलग वर्शन दिखाती हैं. Google Search और Facebook ऐसा करते हैं. इसके लिए, परफ़ॉर्मेंस (ऐसेट फ़ेच करना, पेजों को रेंडर करना) और उपयोगकर्ता अनुभव, दोनों को ध्यान में रखा जाता है.

नेटिव ऐप्लिकेशन की दुनिया में, कई डेवलपर अपने ऐप्लिकेशन को डिवाइस क्लास के हिसाब से बनाते हैं. उदाहरण के लिए, iPad के लिए Flipboard का यूज़र इंटरफ़ेस (यूआई), iPhone पर Flipboard के यूज़र इंटरफ़ेस (यूआई) से काफ़ी अलग है. टैबलेट वर्शन को दोनों हाथों से इस्तेमाल करने और हॉरिज़ॉन्टल फ़्लिप करने के लिए ऑप्टिमाइज़ किया गया है. वहीं, फ़ोन वर्शन को एक हाथ से इस्तेमाल करने और वर्टिकल फ़्लिप करने के लिए बनाया गया है. कई अन्य iOS ऐप्लिकेशन भी फ़ोन और टैबलेट के लिए अलग-अलग वर्शन उपलब्ध कराते हैं. जैसे, Things (कामों की सूची) और Showyou (सोशल वीडियो). इनके बारे में यहां बताया गया है:

फ़ोन और टैबलेट के लिए, यूज़र इंटरफ़ेस (यूआई) को काफ़ी हद तक पसंद के मुताबिक बनाया जा सकता है.

पहला तरीका: सर्वर-साइड पर पहचान करना

सर्वर पर, हमें उस डिवाइस के बारे में बहुत कम जानकारी होती है जिसका हम इस्तेमाल कर रहे हैं. उपलब्ध सबसे काम की जानकारी शायद उपयोगकर्ता एजेंट स्ट्रिंग है. यह हर अनुरोध पर User-Agent हेडर के ज़रिए दी जाती है. इस वजह से, यहां भी UA स्निफ़िंग का वही तरीका काम करेगा. असल में, DeviceAtlas और WURFL प्रोजेक्ट पहले से ही ऐसा करते हैं. साथ ही, ये डिवाइस के बारे में कई तरह की अतिरिक्त जानकारी भी देते हैं.

हालांकि, इनमें से हर एक के साथ कुछ समस्याएं जुड़ी हुई हैं. WURFL बहुत बड़ा है. इसमें 20 एमबी का एक्सएमएल होता है. इससे हर अनुरोध के लिए, सर्वर-साइड ओवरहेड काफ़ी बढ़ सकता है. कुछ प्रोजेक्ट ऐसे होते हैं जो परफ़ॉर्मेंस को बेहतर बनाने के लिए, एक्सएमएल को अलग-अलग हिस्सों में बांट देते हैं. DeviceAtlas, ओपन सोर्स नहीं है. इसका इस्तेमाल करने के लिए, पैसे चुकाकर लाइसेंस लेना पड़ता है.

इसके अलावा, Detect Mobile Browsers प्रोजेक्ट जैसे आसान और मुफ़्त विकल्प भी उपलब्ध हैं. हालांकि, इसकी एक कमी यह है कि डिवाइस का पता लगाने की प्रोसेस पूरी तरह से काम नहीं करेगी. साथ ही, यह सिर्फ़ मोबाइल और नॉन-मोबाइल डिवाइसों के बीच अंतर करता है. यह टैबलेट के लिए सीमित सहायता उपलब्ध कराता है. इसके लिए, तदर्थ बदलावों का सेट इस्तेमाल किया जाता है.

दूसरा तरीका: क्लाइंट-साइड पर पहचान करना

हम सुविधा का पता लगाने की प्रोसेस का इस्तेमाल करके, उपयोगकर्ता के ब्राउज़र और डिवाइस के बारे में काफ़ी कुछ जान सकते हैं. हमें यह पता लगाना होता है कि डिवाइस में टच की सुविधा है या नहीं. साथ ही, यह भी पता लगाना होता है कि डिवाइस की स्क्रीन बड़ी है या छोटी.

हमें छोटे और बड़े टच डिवाइसों के बीच अंतर करने के लिए, किसी सीमा को तय करना होगा. क्या 5" Galaxy Note जैसे ऐज केस के लिए भी यही नियम लागू होता है? नीचे दिए गए ग्राफ़िक में, Android और iOS के कुछ लोकप्रिय डिवाइसों को ओवरले किया गया है. साथ ही, उनके स्क्रीन रिज़ॉल्यूशन भी दिखाए गए हैं. तारे के निशान से पता चलता है कि डिवाइस में डबल डेंसिटी वाला डिसप्ले है या ऐसा डिसप्ले लगाया जा सकता है. पिक्सल डेंसिटी दोगुनी होने के बावजूद, सीएसएस अब भी एक ही साइज़ रिपोर्ट करती है.

सीएसएस में पिक्सल के बारे में कुछ ज़रूरी बातें: मोबाइल वेब पर सीएसएस पिक्सल, स्क्रीन पिक्सल से अलग होते हैं. iOS रेटिना डिवाइसों में, पिक्सल डेंसिटी को दोगुना करने की सुविधा दी गई है. उदाहरण के लिए, iPhone 3GS बनाम 4, iPad 2 बनाम 3. रेटिना Mobile Safari UAs अब भी डिवाइस की चौड़ाई की जानकारी देते हैं, ताकि वेब को काम करने से रोका न जा सके. अन्य डिवाइसों के तौर पर (जैसे, Android) को ज़्यादा रिज़ॉल्यूशन वाले डिसप्ले मिलते हैं. इसके लिए, वे डिवाइस की चौड़ाई से जुड़ी एक ही तरकीब का इस्तेमाल करते हैं.

डिवाइस का रिज़ॉल्यूशन (पिक्सल में).

हालांकि, इस फ़ैसले को मुश्किल बनाने वाली बात यह है कि पोर्ट्रेट और लैंडस्केप, दोनों मोड को ध्यान में रखना ज़रूरी है. हम डिवाइस को घुमाने पर, पेज को फिर से लोड नहीं करना चाहते या हर बार अतिरिक्त स्क्रिप्ट लोड नहीं करना चाहते. हालांकि, हम पेज को अलग तरीके से रेंडर करना चाहते हैं.

यहां दिए गए डायग्राम में, स्क्वेयर हर डिवाइस के ज़्यादा से ज़्यादा डाइमेंशन को दिखाते हैं. ये पोर्ट्रेट और लैंडस्केप आउटलाइन को ओवरले करने (और स्क्वेयर को पूरा करने) के बाद मिलते हैं:

पोर्ट्रेट + लैंडस्केप रिज़ॉल्यूशन (पिक्सल में)

थ्रेशोल्ड को 650px पर सेट करके, हम iPhone और Galaxy Nexus को smalltouch के तौर पर और iPad और Galaxy Tab को "टैबलेट" के तौर पर कैटगरी में रखते हैं. इस मामले में, ऐंड्रोजेनस Galaxy Note को "फ़ोन" के तौर पर क्लासिफ़ाई किया गया है. इसलिए, इसे फ़ोन का लेआउट मिलेगा.

इसलिए, एक सही रणनीति कुछ ऐसी दिख सकती है:

if (hasTouch) {
  if (isSmall) {
    device = PHONE;
  } else {
    device = TABLET;
  }
} else {
  device = DESKTOP;
}

सुविधा का पता लगाने के तरीके का एक छोटा सा सैंपल देखें.

यहां वैकल्पिक तरीका यह है कि डिवाइस टाइप का पता लगाने के लिए, यूज़र एजेंट स्निफ़िंग का इस्तेमाल किया जाए. इसमें, अनुमान लगाने के लिए कुछ नियम बनाए जाते हैं और उन्हें उपयोगकर्ता के navigator.userAgent से मैच किया जाता है. स्यूडो कोड कुछ ऐसा दिखता है:

var ua = navigator.userAgent;
for (var re in RULES) {
  if (ua.match(re)) {
    device = RULES[re];
    return;
  }
}

यूज़र एजेंट का पता लगाने के तरीके का सैंपल देखें.

क्लाइंट-साइड लोडिंग के बारे में जानकारी

अगर आपके सर्वर पर यूज़र एजेंट का पता लगाया जा रहा है, तो आपके पास यह तय करने का विकल्प होता है कि नया अनुरोध मिलने पर, कौनसी सीएसएस, JavaScript, और DOM को दिखाया जाए. हालांकि, अगर क्लाइंट-साइड डिटेक्शन का इस्तेमाल किया जा रहा है, तो स्थिति ज़्यादा जटिल होती है. आपके पास कई विकल्प हैं:

1. डिवाइस टाइप के हिसाब से यूआरएल पर रीडायरेक्ट करें. इस यूआरएल में, डिवाइस टाइप के लिए वर्शन की जानकारी मौजूद होती है.
2. डिवाइस टाइप के हिसाब से ऐसेट को डाइनैमिक तरीके से लोड करता है.

पहला तरीका आसान है. इसके लिए, रीडायरेक्ट की ज़रूरत होती है. जैसे, window.location.href = '/tablet'. हालांकि, अब जगह की जानकारी के साथ डिवाइस के टाइप की जानकारी भी जुड़ जाएगी. इसलिए, हो सकता है कि आपको अपने यूआरएल को साफ़ करने के लिए, History API का इस्तेमाल करना पड़े. माफ़ करें, इस तरीके में रीडायरेक्ट शामिल है. इसमें समय लग सकता है, खास तौर पर मोबाइल डिवाइसों पर.

दूसरे तरीके को लागू करना काफ़ी मुश्किल है. आपको सीएसएस और JS को डाइनैमिक तरीके से लोड करने के लिए, एक मैकेनिज़्म की ज़रूरत होती है. साथ ही, (ब्राउज़र के हिसाब से), <meta viewport> को कस्टमाइज़ करने जैसे काम नहीं किए जा सकते. इसके अलावा, रीडायरेक्ट न होने की वजह से, आपको वही ओरिजनल एचटीएमएल मिलता है जो पहले मिला था. बेशक, JavaScript की मदद से इसमें बदलाव किया जा सकता है. हालांकि, आपके ऐप्लिकेशन के हिसाब से, यह प्रोसेस धीमी और/या मुश्किल हो सकती है.

क्लाइंट या सर्वर तय करना

इन तरीकों के बीच के अंतर यहां दिए गए हैं:

Pro client:

• यह UA के बजाय स्क्रीन साइज़/क्षमता पर आधारित है. इसलिए, यह आने वाले समय में ज़्यादा फ़ायदेमंद साबित होगा.
• UA की सूची को बार-बार अपडेट करने की ज़रूरत नहीं होती.

Pro सर्वर:

• यह तय करने का पूरा कंट्रोल कि किस डिवाइस पर कौनसा वर्शन उपलब्ध कराना है.
• बेहतर परफ़ॉर्मेंस: क्लाइंट रीडायरेक्ट या डाइनैमिक लोडिंग की ज़रूरत नहीं होती.

मेरी निजी राय यह है कि डिवाइस.js और क्लाइंट-साइड डिटेक्शन से शुरुआत करनी चाहिए. अगर आपको लगता है कि क्लाइंट-साइड रीडायरेक्ट की वजह से आपके ऐप्लिकेशन की परफ़ॉर्मेंस पर बुरा असर पड़ रहा है, तो device.js स्क्रिप्ट को आसानी से हटाया जा सकता है. साथ ही, सर्वर पर UA का पता लगाने की सुविधा लागू की जा सकती है.

पेश है device.js

Device.js, डिवाइस का पता लगाने के लिए एक शुरुआती पॉइंट है. यह सिमैंटिक और मीडिया क्वेरी पर आधारित है. इसके लिए, सर्वर-साइड के खास कॉन्फ़िगरेशन की ज़रूरत नहीं होती. इससे उपयोगकर्ता एजेंट स्ट्रिंग पार्स करने में लगने वाला समय और मेहनत बचती है.

इसका मतलब है कि आपको अपनी <head> के सबसे ऊपर, सर्च इंजन के हिसाब से सही मार्कअप (link rel=alternate) देना होगा. इससे यह पता चलेगा कि आपको अपनी साइट के कौनसे वर्शन उपलब्ध कराने हैं.

<link rel="alternate" href="http://foo.com" id="desktop"
    media="only screen and (touch-enabled: 0)">

इसके बाद, आपके पास दो विकल्प होते हैं. पहला, सर्वर-साइड पर यूए का पता लगाएं और वर्शन रीडायरेक्शन को खुद मैनेज करें. दूसरा, device.js स्क्रिप्ट का इस्तेमाल करके, सुविधा के आधार पर क्लाइंट-साइड रीडायरेक्शन करें.

ज़्यादा जानकारी के लिए, device.js प्रोजेक्ट पेज देखें. साथ ही, नकली ऐप्लिकेशन भी देखें, जो क्लाइंट-साइड रीडायरेक्शन के लिए device.js का इस्तेमाल करता है.

सुझाव: डिवाइस के हिसाब से व्यू दिखाने वाला एमवीसी

अब तक शायद आपको लग रहा होगा कि हम आपको तीन अलग-अलग ऐप्लिकेशन बनाने के लिए कह रहे हैं. इनमें से एक ऐप्लिकेशन हर डिवाइस टाइप के लिए होगा. नहीं! कोड शेयर करना ज़रूरी है.

हमें उम्मीद है कि आपने MVC जैसे फ़्रेमवर्क का इस्तेमाल किया होगा. जैसे, Backbone, Ember वगैरह. अगर आपने ऐसा किया है, तो आपको सेपरेशन ऑफ़ कंसर्न के सिद्धांत के बारे में पता होगा. खास तौर पर, यह कि आपका यूज़र इंटरफ़ेस (व्यू लेयर) आपके लॉजिक (मॉडल लेयर) से अलग होना चाहिए. अगर आपने पहली बार इस बारे में सुना है, तो एमवीसी के बारे में जानकारी देने वाले इन संसाधनों और JavaScript में एमवीसी के बारे में जानें.

क्रॉस-डिवाइस स्टोरी, आपके मौजूदा एमवीसी फ़्रेमवर्क में आसानी से फ़िट हो जाती है. अपने व्यू को अलग-अलग फ़ाइलों में आसानी से ले जाया जा सकता है. इससे हर डिवाइस टाइप के लिए, कस्टम व्यू बनाया जा सकता है. इसके बाद, व्यू लेयर को छोड़कर, सभी डिवाइसों पर एक ही कोड दिखाया जा सकता है.

क्रॉस-डिवाइस एमवीसी.

आपके प्रोजेक्ट का स्ट्रक्चर इस तरह का हो सकता है. हालांकि, आपके पास अपनी ज़रूरत के हिसाब से स्ट्रक्चर चुनने का विकल्प होता है:

models/ (shared models) item.js item-collection.js

controllers/ (shared controllers) item-controller.js

versions/ (device-specific stuff) tablet/ desktop/ phone/ (phone-specific code) style.css index.html views/ item.js item-list.js

इस तरह के स्ट्रक्चर की मदद से, यह कंट्रोल किया जा सकता है कि हर वर्शन कौनसी ऐसेट लोड करे. ऐसा इसलिए, क्योंकि आपके पास हर डिवाइस के लिए कस्टम एचटीएमएल, सीएसएस, और JavaScript होता है. यह बहुत असरदार है. इससे अलग-अलग डिवाइसों पर वेब ऐक्सेस करने के लिए, सबसे आसान और बेहतर तरीके से डेवलपमेंट किया जा सकता है. इसके लिए, अडैप्टिव इमेज जैसी तकनीकों पर निर्भर रहने की ज़रूरत नहीं होती.

अपने पसंदीदा बिल्ड टूल को चलाने के बाद, आपको अपनी सभी JavaScript और सीएसएस को एक ही फ़ाइल में जोड़ना होगा और उन्हें छोटा करना होगा, ताकि वे तेज़ी से लोड हो सकें. इसके बाद, आपका प्रोडक्शन एचटीएमएल कुछ इस तरह दिखेगा (फ़ोन के लिए, device.js का इस्तेमाल करके):

<!doctype html>
<head>
  <title>Mobile Web Rocks! (Phone Edition)</title>

  <!-- Every version of your webapp should include a list of all
        versions. -->
  <link rel="alternate" href="http://foo.com" id="desktop"
      media="only screen and (touch-enabled: 0)">
  <link rel="alternate" href="http://m.foo.com" id="phone"
      media="only screen and (max-device-width: 650px)">
  <link rel="alternate" href="http://tablet.foo.com" id="tablet"
      media="only screen and (min-device-width: 650px)">

  <!-- Viewport is very important, since it affects results of media
        query matching. -->
  <meta name="viewport" content="width=device-width">

  <!-- Include device.js in each version for redirection. -->
  <script src="device.js"></script>

  <link rel="style" href="phone.min.css">
</head>
<body>
  <script src="phone.min.js"></script>
</body>

ध्यान दें कि (touch-enabled: 0) मीडिया क्वेरी, स्टैंडर्ड नहीं है. इसे सिर्फ़ Firefox में moz वेंडर प्रीफ़िक्स के पीछे लागू किया गया है. हालांकि, device.js इसे सही तरीके से हैंडल करता है. इसके लिए, Modernizr.touch का इस्तेमाल किया जाता है.

वर्शन ओवरराइड करना

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

आम तौर पर, मोबाइल वर्शन से डेस्कटॉप वर्शन का लिंक दिया जाता है. इसे लागू करना आसान है. हालांकि, device.js इस सुविधा के साथ device GET पैरामीटर का इस्तेमाल करता है.

खत्म हो रहा है

क्रॉस-डिवाइस सिंगल-पेज यूज़र इंटरफ़ेस (यूआई) बनाते समय, जो रिस्पॉन्सिव डिज़ाइन के हिसाब से सही नहीं होते हैं, यह तरीका अपनाएं:

1. डिवाइस क्लास का कोई सेट चुनें, ताकि यह तय किया जा सके कि कौनसी डिवाइस क्लास काम करती हैं. साथ ही, डिवाइसों को क्लास में बांटने के लिए मानदंड चुनें.
2. अपने MVC ऐप्लिकेशन को इस तरह से बनाएं कि उसमें अलग-अलग कॉम्पोनेंट के काम अलग-अलग हों. इसके लिए, व्यू को बाकी कोडबेस से अलग करें.
3. क्लाइंट साइड पर डिवाइस क्लास का पता लगाने के लिए, device.js का इस्तेमाल करें.
4. जब आपकी स्क्रिप्ट और स्टाइलशीट तैयार हो जाएं, तब उन्हें डिवाइस क्लास के हिसाब से एक-एक पैकेज में बदलें.
5. अगर क्लाइंट-साइड रीडायरेक्शन की परफ़ॉर्मेंस से जुड़ी कोई समस्या आ रही है, तो device.js का इस्तेमाल बंद करें और सर्वर साइड पर यूए-डिटेक्शन पर स्विच करें.