คิวรีสื่อนั้นยอดเยี่ยม แต่…
Media Query เป็นเครื่องมือที่ยอดเยี่ยมและมีประโยชน์อย่างยิ่งสำหรับนักพัฒนาเว็บไซต์ที่ต้องการปรับแต่งเล็กน้อยในสไตล์ชีตเพื่อให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่ดีขึ้นบนอุปกรณ์ขนาดต่างๆ หลักๆ แล้ว คิวรี่สื่อช่วยให้คุณปรับแต่ง CSS ของเว็บไซต์ตามขนาดหน้าจอได้ ก่อนอ่านบทความนี้ โปรดดูข้อมูลเพิ่มเติมเกี่ยวกับการออกแบบที่ปรับเปลี่ยนตามพื้นที่โฆษณาและดูตัวอย่างการใช้งานคิวรีสื่อที่ยอดเยี่ยมได้ที่ mediaqueri.es
ดังที่ Brad Frost ชี้ให้เห็นในบทความก่อนหน้านี้ การเปลี่ยนแปลงรูปลักษณ์เป็นเพียงสิ่งหนึ่งๆ ที่ต้องพิจารณาเมื่อสร้างเว็บสำหรับอุปกรณ์เคลื่อนที่ หากสิ่งที่คุณทําเมื่อสร้างเว็บไซต์เวอร์ชันอุปกรณ์เคลื่อนที่มีเพียงการปรับแต่งเลย์เอาต์ด้วย Media Query เท่านั้น สถานการณ์จะเป็นอย่างไร
- อุปกรณ์ทุกเครื่องจะได้รับ JavaScript, CSS และชิ้นงาน (รูปภาพ วิดีโอ) เดียวกัน ซึ่งส่งผลให้เวลาในการโหลดนานกว่าที่จำเป็น
- อุปกรณ์ทุกเครื่องจะได้รับ DOM เริ่มต้นเดียวกัน ซึ่งอาจบังคับให้นักพัฒนาซอฟต์แวร์เขียน CSS ที่ซับซ้อนเกินไป
- มีความยืดหยุ่นน้อยในการระบุการโต้ตอบที่กําหนดเองซึ่งปรับให้เหมาะกับอุปกรณ์แต่ละเครื่อง
เว็บแอปต้องใช้มากกว่า Media Query
อย่าเข้าใจผิด เราไม่ได้เกลียดการออกแบบที่ปรับเปลี่ยนได้ผ่าน Media Query และคิดว่าการออกแบบดังกล่าวมีบทบาทสำคัญในโลกนี้ นอกจากนี้ ปัญหาบางอย่างที่กล่าวถึงข้างต้นยังแก้ไขได้ด้วยวิธีการต่างๆ เช่น รูปภาพที่ปรับเปลี่ยนตามพื้นที่โฆษณา โหลดสคริปต์แบบไดนามิก ฯลฯ อย่างไรก็ตาม ในบางครั้ง คุณอาจพบว่าตัวเองทำการปรับเปลี่ยนมากเกินไป และอาจแสดงเวอร์ชันอื่นจะดีกว่า
เมื่อ UI ที่คุณสร้างมีความซับซ้อนมากขึ้นและคุณหันมาใช้เว็บแอปแบบหน้าเดียว คุณจะต้องปรับแต่ง UI สำหรับอุปกรณ์แต่ละประเภทมากขึ้น บทความนี้จะสอนวิธีทําการปรับแต่งเหล่านี้โดยใช้เวลาเพียงเล็กน้อย แนวทางทั่วไปคือการแยกประเภทอุปกรณ์ของผู้เข้าชมออกเป็นคลาสอุปกรณ์ที่เหมาะสม และแสดงเวอร์ชันที่เหมาะสมกับอุปกรณ์นั้น พร้อมกับเพิ่มการนําโค้ดมาใช้ซ้ำระหว่างเวอร์ชันต่างๆ ให้ได้มากที่สุด
คุณกําหนดเป้าหมายอุปกรณ์ระดับใด
อุปกรณ์ที่เชื่อมต่ออินเทอร์เน็ตมีมากมายและเกือบทั้งหมดมีเบราว์เซอร์ ความซับซ้อนอยู่ที่ความหลากหลายของอุปกรณ์ เช่น แล็ปท็อป Mac, เวิร์กสเตชัน Windows, iPhone, iPad, โทรศัพท์ Android ที่ใช้การป้อนข้อมูลด้วยการสัมผัส, ลูกล้อเลื่อน, แป้นพิมพ์, การป้อนข้อมูลด้วยเสียง, อุปกรณ์ที่ไวต่อแรงกด, สมาร์ทวอทช์, เครื่องปิ้งขนมปังและตู้เย็น และอื่นๆ อีกมากมาย อุปกรณ์เหล่านี้บางประเภทมีการใช้งานอย่างแพร่หลาย ขณะที่อุปกรณ์อื่นๆ นั้นหายากมาก
คุณต้องทราบว่าผู้ใช้เป็นใครและกำลังใช้อุปกรณ์ใดอยู่ จึงจะสร้างประสบการณ์การใช้งานที่ดีได้ หากคุณสร้างอินเทอร์เฟซผู้ใช้สำหรับผู้ใช้เดสก์ท็อปที่ใช้เมาส์และแป้นพิมพ์ แล้วนำไปให้ผู้ใช้สมาร์ทโฟน อินเทอร์เฟซจะใช้งานยากเนื่องจากออกแบบมาสำหรับหน้าจอขนาดอื่นและวิธีการป้อนข้อมูลอื่น
แนวทางมี 2 ลักษณะสุดขั้ว ได้แก่
สร้างเวอร์ชันเดียวที่ใช้งานได้กับทุกอุปกรณ์ ด้วยเหตุนี้ UX จึงได้รับผลกระทบ เนื่องจากอุปกรณ์แต่ละเครื่องมีการพิจารณาการออกแบบที่แตกต่างกัน
สร้างเวอร์ชันสำหรับอุปกรณ์แต่ละเครื่องที่ต้องการรองรับ ซึ่งจะใช้เวลานานมาก เนื่องจากคุณจะสร้างแอปพลิเคชันหลายเวอร์ชัน นอกจากนี้ เมื่อสมาร์ทโฟนรุ่นใหม่เปิดตัว (ซึ่งเกิดขึ้นทุกสัปดาห์โดยประมาณ) คุณจะต้องสร้างเวอร์ชันอื่นอีก
การเลือกหมวดหมู่อุปกรณ์มีหลักการพื้นฐานคือ ยิ่งคุณมีหมวดหมู่อุปกรณ์มากเท่าใด ประสบการณ์ของผู้ใช้ก็จะยิ่งดีขึ้นเท่านั้น แต่การออกแบบ ติดตั้งใช้งาน และบำรุงรักษาก็จะยิ่งยากขึ้น
การสร้างเวอร์ชันแยกต่างหากสำหรับอุปกรณ์แต่ละคลาสที่คุณเลือกอาจเป็นเรื่องที่ดีเนื่องจากเหตุผลด้านประสิทธิภาพ หรือในกรณีที่เวอร์ชันที่คุณต้องการแสดงในอุปกรณ์แต่ละคลาสแตกต่างกันมาก หรือจะใช้การออกแบบเว็บที่ตอบสนองตามอุปกรณ์ก็เหมาะเช่นกัน
แนวทางแก้ปัญหาที่เป็นไปได้
วิธีประนีประนอมคือจัดประเภทอุปกรณ์ออกเป็นหมวดหมู่ต่างๆ และออกแบบประสบการณ์การใช้งานที่ดีที่สุดสำหรับแต่ละหมวดหมู่ หมวดหมู่ที่คุณเลือกจะขึ้นอยู่กับผลิตภัณฑ์และผู้ใช้เป้าหมาย ต่อไปนี้เป็นตัวอย่างการจัดประเภทที่ครอบคลุมอุปกรณ์ที่ท่องเว็บได้ยอดนิยมในปัจจุบัน
- หน้าจอขนาดเล็ก + การสัมผัส (ส่วนใหญ่เป็นโทรศัพท์)
- หน้าจอขนาดใหญ่ + การสัมผัส (ส่วนใหญ่เป็นแท็บเล็ต)
- หน้าจอขนาดใหญ่ + แป้นพิมพ์/เมาส์ (ส่วนใหญ่เป็นเดสก์ท็อป/แล็ปท็อป)
นี่เป็นรายละเอียดเพียงส่วนหนึ่งจากหลายรายละเอียดที่เป็นไปได้ แต่เป็นสิ่งที่สมเหตุสมผลมาก ณ เวลาที่เขียน อุปกรณ์เคลื่อนที่ที่ไม่มีหน้าจอสัมผัส (เช่น โทรศัพท์รุ่นพื้นฐาน โปรแกรมอ่านอีบุ๊กบางรุ่น) จะไม่อยู่ในรายการข้างต้น อย่างไรก็ตาม อุปกรณ์เหล่านี้ส่วนใหญ่มีการติดตั้งซอฟต์แวร์การไปยังส่วนต่างๆ ด้วยแป้นพิมพ์หรือโปรแกรมอ่านหน้าจอ ซึ่งจะใช้งานได้ดีหากคุณสร้างเว็บไซต์โดยคำนึงถึงการช่วยเหลือพิเศษ
ตัวอย่างเว็บแอปที่เจาะจงรูปแบบ
มีตัวอย่างเว็บพร็อพเพอร์ตี้จำนวนมากที่แสดงเวอร์ชันที่แตกต่างกันโดยสิ้นเชิงสำหรับอุปกรณ์รูปแบบต่างๆ Google Search และ Facebook ก็ทำเช่นนั้น สิ่งที่ต้องพิจารณามีตั้งแต่ประสิทธิภาพ (การดึงข้อมูลชิ้นงาน การแสดงผลหน้าเว็บ) ไปจนถึงประสบการณ์การใช้งานทั่วไป
ในโลกของแอปที่มาพร้อมเครื่อง นักพัฒนาแอปจํานวนมากเลือกที่จะปรับแต่งประสบการณ์การใช้งานให้เหมาะกับคลาสอุปกรณ์ เช่น Flipboard สำหรับ iPad มี UI ที่แตกต่างจาก Flipboard ใน iPhone มาก เวอร์ชันแท็บเล็ตได้รับการเพิ่มประสิทธิภาพเพื่อการใช้งานด้วย 2 มือและการพลิกแนวนอน ส่วนเวอร์ชันโทรศัพท์มีไว้สำหรับการโต้ตอบด้วยมือเดียวและการพลิกแนวตั้ง แอปพลิเคชัน iOS อื่นๆ อีกมากมายยังมีเวอร์ชันสำหรับโทรศัพท์และแท็บเล็ตที่แตกต่างกันอย่างมาก เช่น Things (รายการสิ่งที่ต้องทำ) และ Showyou (วิดีโอโซเชียล) ที่แสดงอยู่ด้านล่าง
แนวทางที่ 1: การตรวจหาฝั่งเซิร์ฟเวอร์
ในเซิร์ฟเวอร์ เรามีความเข้าใจเกี่ยวกับอุปกรณ์ที่จัดการอยู่อย่างจำกัด เบาะแสที่มีประโยชน์ที่สุดที่มีอยู่อาจเป็นสตริง User Agent ซึ่งระบุผ่านส่วนหัว User-Agent ในคําขอทุกรายการ ด้วยเหตุนี้ วิธีการสํารวจ UA แบบเดียวกันจึงใช้ได้ อันที่จริงแล้ว โปรเจ็กต์ DeviceAtlas และ WURFL ดําเนินการนี้อยู่แล้ว (และระบุข้อมูลเพิ่มเติมมากมายเกี่ยวกับอุปกรณ์)
แต่ทั้ง 2 แนวทางนี้ต่างก็มีปัญหาของตัวเอง WURFL มีขนาดใหญ่มาก โดยมี XML ขนาด 20 MB ซึ่งอาจทำให้เกิดค่าใช้จ่ายเพิ่มเติมที่สำคัญฝั่งเซิร์ฟเวอร์สำหรับคำขอแต่ละรายการ มีโปรเจ็กต์ที่แยก XML เพื่อเหตุผลด้านประสิทธิภาพ DeviceAtlas ไม่ใช่โอเพนซอร์สและต้องใช้ใบอนุญาตแบบชำระเงิน
นอกจากนี้ยังมีทางเลือกอื่นๆ ที่ใช้งานง่ายและไม่มีค่าใช้จ่าย เช่น โปรเจ็กต์ตรวจหาเบราว์เซอร์ในอุปกรณ์เคลื่อนที่ ข้อเสียคือการตรวจหาอุปกรณ์จะครอบคลุมน้อยลง นอกจากนี้ ยังแยกความแตกต่างระหว่างอุปกรณ์เคลื่อนที่และอุปกรณ์ที่ไม่ใช่อุปกรณ์เคลื่อนที่เท่านั้น โดยให้การสนับสนุนแท็บเล็ตแบบจํากัดผ่านชุดการปรับเฉพาะกิจเท่านั้น
แนวทางที่ 2: การตรวจหาฝั่งไคลเอ็นต์
เราเรียนรู้ได้มากมายเกี่ยวกับเบราว์เซอร์และอุปกรณ์ของผู้ใช้โดยใช้การตรวจหาฟีเจอร์ สิ่งที่เราต้องพิจารณาหลักๆ คืออุปกรณ์มีความสามารถในการทัชสกรีนหรือไม่ และอุปกรณ์เป็นหน้าจอขนาดใหญ่หรือขนาดเล็ก
เราจำเป็นต้องกำหนดขีดจำกัดเพื่อแยกความแตกต่างระหว่างอุปกรณ์แบบสัมผัสขนาดเล็กและขนาดใหญ่ ในกรณีที่อุปกรณ์มีขนาดเล็กมาก เช่น Galaxy Note ขนาด 5 นิ้ว จะเป็นอย่างไร กราฟิกต่อไปนี้แสดงอุปกรณ์ Android และ iOS ยอดนิยมที่วางซ้อนกัน (พร้อมความละเอียดหน้าจอที่สอดคล้องกัน) เครื่องหมายดอกจันระบุว่าอุปกรณ์มีหรือสามารถมีความละเอียดเป็น 2 เท่า แม้ว่าความหนาแน่นของพิกเซลจะเพิ่มขึ้นเป็น 2 เท่า แต่ CSS จะยังคงรายงานขนาดเดิม
ข้อมูลสั้นๆ เกี่ยวกับพิกเซลใน CSS: พิกเซล CSS ในเว็บบนอุปกรณ์เคลื่อนที่ไม่เหมือนกันกับพิกเซลของหน้าจอ อุปกรณ์ Retina ของ iOS ได้นำแนวทางการเพิ่มความละเอียดของพิกเซลเป็น 2 เท่ามาใช้ (เช่น iPhone 3GS เทียบกับ 4, iPad 2 เทียบกับ 3) UA ของ Safari บนอุปกรณ์เคลื่อนที่ที่มีจอภาพ Retina จะยังคงรายงานความกว้างของอุปกรณ์เดิมเพื่อหลีกเลี่ยงการทำให้เว็บใช้งานไม่ได้ อุปกรณ์อื่นๆ (เช่น Android) มีจอแสดงผลที่มีความละเอียดสูงขึ้น อุปกรณ์เหล่านี้ก็ใช้กลอุบายเกี่ยวกับความกว้างของอุปกรณ์แบบเดียวกัน
อย่างไรก็ตาม สิ่งที่ทำให้การตัดสินใจนี้ซับซ้อนขึ้นคือความสำคัญของการพิจารณาทั้งโหมดแนวตั้งและแนวนอน เราไม่ต้องการเปลี่ยนหน้าเว็บใหม่หรือโหลดสคริปต์เพิ่มเติมทุกครั้งที่ปรับการวางแนวอุปกรณ์ใหม่ แม้ว่าเราอาจต้องการแสดงผลหน้าเว็บในลักษณะอื่น
ในแผนภาพต่อไปนี้ สี่เหลี่ยมจัตุรัสแสดงถึงขนาดสูงสุดของอุปกรณ์แต่ละเครื่อง ซึ่งเป็นผลมาจากการซ้อนทับรูปทรงของแนวตั้งและแนวนอน (และทำให้เป็นรูปสี่เหลี่ยมจัตุรัส)
เมื่อตั้งค่าเกณฑ์เป็น 650px เราจะจัดประเภท iPhone, Galaxy Nexus เป็น "อุปกรณ์แบบสัมผัสขนาดเล็ก" และ iPad, Galaxy Tab เป็น "แท็บเล็ต" ในกรณีนี้ Galaxy Note แบบ unisex จะจัดอยู่ในประเภท "โทรศัพท์" และจะได้รับเลย์เอาต์โทรศัพท์
กลยุทธ์ที่สมเหตุสมผลจึงอาจมีลักษณะดังนี้
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 ในเซิร์ฟเวอร์ คุณจะเลือก CSS, JavaScript และ DOM ที่แสดงได้เมื่อได้รับคําขอใหม่ อย่างไรก็ตาม หากใช้การตรวจหาฝั่งไคลเอ็นต์ สถานการณ์จะซับซ้อนมากขึ้น คุณมีตัวเลือกหลายอย่างดังนี้
- เปลี่ยนเส้นทางไปยัง URL สำหรับอุปกรณ์ประเภทนั้นๆ ซึ่งมีเวอร์ชันสำหรับอุปกรณ์ประเภทนี้
- โหลดชิ้นงานเฉพาะประเภทอุปกรณ์แบบไดนามิก
แนวทางแรกนั้นตรงไปตรงมา โดยต้องใช้การเปลี่ยนเส้นทาง เช่น
window.location.href = '/tablet' อย่างไรก็ตาม ตอนนี้ตำแหน่งจะมีข้อมูลประเภทอุปกรณ์นี้ต่อท้าย คุณจึงอาจต้องใช้ History API เพื่อล้าง URL ขออภัย วิธีการนี้เกี่ยวข้องกับการเปลี่ยนเส้นทาง ซึ่งอาจทําให้ช้าลง โดยเฉพาะอย่างยิ่งในอุปกรณ์เคลื่อนที่
แนวทางที่ 2 นั้นซับซ้อนกว่ามาก คุณต้องมีกลไกในการโหลด CSS และ JS แบบไดนามิก และคุณอาจทำสิ่งต่างๆ เช่น ปรับแต่ง <meta viewport> ไม่ได้ (ขึ้นอยู่กับเบราว์เซอร์) นอกจากนี้ เนื่องจากไม่มีการเปลี่ยนเส้นทาง คุณจึงต้องใช้ HTML ต้นฉบับที่แสดง แน่นอนว่าคุณจัดการข้อมูลด้วย JavaScript ได้ แต่อาจช้าและ/หรือไม่มีประสิทธิภาพ ทั้งนี้ขึ้นอยู่กับแอปพลิเคชันของคุณ
การเลือกไคลเอ็นต์หรือเซิร์ฟเวอร์
ข้อดีและข้อเสียระหว่างแนวทางต่างๆ มีดังนี้
ไคลเอ็นต์ Pro:
- ใช้ได้ในอนาคตมากขึ้นเนื่องจากอิงตามขนาด/ความสามารถของหน้าจอ ไม่ใช่ UA
- ไม่ต้องอัปเดตรายการ UA อยู่เสมอ
เซิร์ฟเวอร์ Pro:
- ควบคุมเวอร์ชันที่จะแสดงในอุปกรณ์แต่ละเครื่องอย่างเต็มรูปแบบ
- ประสิทธิภาพดีขึ้น: ไม่ต้องมีการเปลี่ยนเส้นทางไคลเอ็นต์หรือการโหลดแบบไดนามิก
เราขอแนะนำให้เริ่มต้นด้วย device.js และการตรวจหาฝั่งไคลเอ็นต์ เมื่อแอปพลิเคชันพัฒนาไปเรื่อยๆ หากพบว่าการเปลี่ยนเส้นทางฝั่งไคลเอ็นต์เป็นข้อเสียด้านประสิทธิภาพที่สำคัญ คุณสามารถนำสคริปต์ device.js ออกได้อย่างง่ายดาย และใช้การตรวจหา UA ในเซิร์ฟเวอร์
ขอแนะนํา device.js
Device.js เป็นจุดเริ่มต้นของการตรวจหาอุปกรณ์ตามความหมายและ Media Query โดยไม่จำเป็นต้องมีการกําหนดค่าฝั่งเซิร์ฟเวอร์เป็นพิเศษ ซึ่งจะช่วยประหยัดเวลาและความพยายามที่จําเป็นในการแยกวิเคราะห์สตริง User Agent
แนวคิดคือคุณระบุมาร์กอัปที่เหมาะสำหรับเครื่องมือค้นหา (link
rel=alternate) ที่ด้านบนของ <head> เพื่อระบุว่าคุณต้องการแสดงเว็บไซต์เวอร์ชันใด
<link rel="alternate" href="http://foo.com" id="desktop"
media="only screen and (touch-enabled: 0)">
ถัดไป คุณสามารถดําเนินการตรวจหา UA ฝั่งเซิร์ฟเวอร์และจัดการการเปลี่ยนเส้นทางเวอร์ชันด้วยตนเอง หรือจะใช้สคริปต์ device.js เพื่อทําการเปลี่ยนเส้นทางฝั่งไคลเอ็นต์ตามฟีเจอร์ก็ได้
ดูข้อมูลเพิ่มเติมได้ที่หน้าโปรเจ็กต์ device.js และแอปพลิเคชันแบบจําลองที่ใช้ device.js สําหรับการเปลี่ยนเส้นทางฝั่งไคลเอ็นต์
คําแนะนํา: MVC ที่มีมุมมองเฉพาะรูปแบบของอุปกรณ์
ตอนนี้คุณอาจคิดว่าเราบอกให้คุณสร้างแอป 3 แอปแยกกันโดยสิ้นเชิง โดยแต่ละแอปมีไว้สำหรับอุปกรณ์แต่ละประเภท ไม่เอาด้วยหรอก การแชร์รหัสเป็นกุญแจสำคัญ
เราหวังว่าคุณจะใช้เฟรมเวิร์กแบบ MVC เช่น Backbone, Ember ฯลฯ หากใช้อยู่ คุณก็น่าจะคุ้นเคยกับหลักการแยกความกังวล โดยเฉพาะการแยก UI (เลเยอร์มุมมอง) ออกจากตรรกะ (เลเยอร์โมเดล) หากเพิ่งเริ่มใช้ MVC ให้เริ่มต้นด้วยแหล่งข้อมูลเกี่ยวกับ MVC และ MVC ใน JavaScript
เรื่องราวข้ามอุปกรณ์จะพอดีกับเฟรมเวิร์ก MVC ที่มีอยู่ คุณย้ายมุมมองไปยังไฟล์แยกต่างหากได้อย่างง่ายดาย ซึ่งจะสร้างมุมมองที่กำหนดเองสำหรับอุปกรณ์แต่ละประเภท จากนั้นคุณจะแสดงโค้ดเดียวกันกับอุปกรณ์ทั้งหมดได้ ยกเว้นเลเยอร์มุมมอง
โปรเจ็กต์ของคุณอาจมีโครงสร้างดังต่อไปนี้ (แต่คุณเลือกโครงสร้างที่เหมาะกับการใช้งานมากที่สุดได้)
models/ (โมเดลที่แชร์) item.js item-collection.js
controllers/ (ตัวควบคุมที่แชร์) item-controller.js
versions/ (ข้อมูลเฉพาะอุปกรณ์) tablet/ desktop/ phone/ (โค้ดเฉพาะโทรศัพท์) style.css index.html views/ item.js item-list.js
โครงสร้างประเภทนี้ช่วยให้คุณควบคุมชิ้นงานที่แต่ละเวอร์ชันจะโหลดได้อย่างเต็มรูปแบบ เนื่องจากคุณมี HTML, CSS และ JavaScript ที่กําหนดเองสําหรับอุปกรณ์แต่ละเครื่อง ซึ่งมีประสิทธิภาพมากและสามารถนำไปสู่การพัฒนาเว็บข้ามอุปกรณ์ที่มีประสิทธิภาพและเรียบง่ายที่สุดโดยไม่ต้องใช้เทคนิคต่างๆ เช่น รูปภาพที่ปรับขนาด
เมื่อเรียกใช้เครื่องมือสร้างที่คุณชื่นชอบแล้ว คุณจะต้องต่อเชื่อมและลดขนาด JavaScript และ CSS ทั้งหมดเป็นไฟล์เดียวเพื่อให้โหลดได้เร็วขึ้น โดย HTML สำหรับเวอร์ชันที่ใช้งานจริงจะมีลักษณะดังต่อไปนี้ (สำหรับโทรศัพท์โดยใช้ 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
สรุป
โดยสรุปแล้ว เมื่อสร้าง UI แบบหน้าเดียวที่ใช้งานได้ในหลายอุปกรณ์ ซึ่งไม่เหมาะกับการออกแบบที่ตอบสนองตามอุปกรณ์ ให้ทําดังนี้
- เลือกชุดคลาสอุปกรณ์ที่จะรองรับ และเกณฑ์ที่ใช้จัดประเภทอุปกรณ์เป็นคลาส
- สร้างแอป MVC ด้วยการแยกข้อกังวลอย่างชัดเจน โดยแยกมุมมองออกจากโค้ดเบสส่วนที่เหลือ
- ใช้ device.js เพื่อตรวจหาคลาสอุปกรณ์ฝั่งไคลเอ็นต์
- เมื่อพร้อมแล้ว ให้จัดแพ็กเกจสคริปต์และสไตล์ชีตเป็นไฟล์ 1 ไฟล์สำหรับแต่ละคลาสอุปกรณ์
- หากประสิทธิภาพการเปลี่ยนเส้นทางฝั่งไคลเอ็นต์เป็นปัญหา ให้เลิกใช้ device.js และเปลี่ยนไปใช้การตรวจหา UA ฝั่งเซิร์ฟเวอร์