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

बोरिस स्मस

Twitter होम पेज

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

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

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

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

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

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

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

डिवाइस की कौनसी क्लास टारगेट की जा रही हैं?

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

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

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

अलग-अलग तरीकों के दो चरम अंत होते हैं:

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

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

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

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

एक संभावित हल

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

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

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

डिवाइस के नाप या आकार के हिसाब से, वेब ऐप्लिकेशन के उदाहरण

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

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

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

तरीका #1: सर्वर साइड की पहचान

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

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

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

तरीका #2: क्लाइंट-साइड डिटेक्शन

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

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

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

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

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

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

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

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

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

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

सुविधा की पहचान करने के तरीके का कम से कम नमूना देखें.

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

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

UA की पहचान करने के तरीके का सैंपल देखें.

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

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

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

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

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

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

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

प्रो क्लाइंट:

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

प्रो सर्वर:

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

मेरी पसंद device.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)">

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

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

सुझाव: फ़ॉर्म-फ़ैक्टर के हिसाब से व्यू के साथ एमवीसी

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

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

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

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

आपके प्रोजेक्ट का स्ट्रक्चर इस तरह का हो सकता है (बेशक, आपके पास वह स्ट्रक्चर चुनने का विकल्प होता है जो आपके ऐप्लिकेशन के हिसाब से सबसे सही हो):

मॉडल/ (शेयर किए गए मॉडल) item.js item-collection.js

कंट्रोलर/ (शेयर किए गए कंट्रोलर) item-controller.js

वर्शन/ (डिवाइस से जुड़ी खास चीज़ें) टैबलेट/ डेस्कटॉप/ फ़ोन/ (फ़ोन के लिए खास कोड) style.css index.html व्यू/ 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) मीडिया क्वेरी नॉन-स्टैंडर्ड है (सिर्फ़ moz वेंडर प्रीफ़िक्स के पीछे Firefox में लागू की जाती है), लेकिन device.js को सही तरीके से हैंडल करता है (Modernizr.touch की वजह से).

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

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

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

निष्कर्ष

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

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