การค้นหาสื่อนั้นดีเยี่ยม แต่...
คิวรี่สื่อเป็นสิ่งที่ยอดเยี่ยม เป็นประโยชน์ต่อนักพัฒนาเว็บไซต์ที่อยากปรับแต่งสไตล์ชีตเล็กๆ น้อยๆ เพื่อมอบประสบการณ์การใช้งานที่ดีขึ้นสำหรับผู้ใช้อุปกรณ์ขนาดต่างๆ คำค้นหาสื่อช่วยให้คุณปรับแต่ง CSS ของเว็บไซต์ตามขนาดหน้าจอได้เป็นหลัก ก่อนที่จะเจาะลึกลงในบทความนี้ โปรดดูข้อมูลเพิ่มเติมเกี่ยวกับการออกแบบที่ปรับเปลี่ยนตามอุปกรณ์และดูตัวอย่างอย่างละเอียดของการใช้คำค้นหาสื่อที่ mediaqueri.es
ตามที่ Brad Frost ได้อธิบายไว้ในบทความก่อนหน้านี้ การเปลี่ยนรูปลักษณ์เป็นเพียงหนึ่งในหลายสิ่งที่ต้องพิจารณาเมื่อสร้างเว็บบนอุปกรณ์เคลื่อนที่ หากสิ่งเดียวที่คุณทำเมื่อสร้างเว็บไซต์บนอุปกรณ์เคลื่อนที่คือการปรับแต่งเลย์เอาต์ด้วยคำค้นหาสื่อ แสดงว่าเรามีสถานการณ์ต่อไปนี้
- อุปกรณ์ทั้งหมดจะได้รับ JavaScript, CSS และเนื้อหา (รูปภาพ วิดีโอ) เดียวกัน ทำให้ใช้เวลาโหลดนานกว่าที่จำเป็น
- อุปกรณ์ทั้งหมดจะได้รับ DOM เริ่มต้นชุดเดียวกัน ซึ่งอาจบังคับให้นักพัฒนาซอฟต์แวร์เขียน CSS ที่ซับซ้อนเกินไป
- มีความยืดหยุ่นเล็กน้อยในการระบุการโต้ตอบแบบกำหนดเองที่ปรับให้เหมาะกับแต่ละอุปกรณ์
เว็บแอปต้องการมากกว่าแค่คิวรี่สื่อ
ตอบผิดนะ ผมไม่ชอบการออกแบบที่ตอบสนองตามอุปกรณ์ผ่านคำค้นหาตามสื่อ และผมคิดว่าวิธีนี้มีที่หนึ่งในโลก นอกจากนี้ ปัญหาบางอย่างที่กล่าวถึงข้างต้นยังแก้ไขได้ด้วยวิธีต่างๆ เช่น รูปภาพที่ปรับเปลี่ยนตามอุปกรณ์ การโหลดสคริปต์แบบไดนามิก ฯลฯ อย่างไรก็ตาม ณ จุดใดจุดหนึ่ง คุณอาจพบว่าตนเองกำลังปรับแต่งเพิ่มขึ้นมากเกินไป และอาจดีกว่าการแสดงผลเวอร์ชันอื่นๆ
เนื่องจาก UI ที่สร้างมีความซับซ้อนมากขึ้น และคุณโน้มเอียงไปที่เว็บแอปในหน้าเดียว คุณอาจต้องปรับแต่ง UI สำหรับอุปกรณ์แต่ละประเภทมากขึ้น บทความนี้จะสอนวิธีปรับแต่งเหล่านี้โดยใช้ความพยายามเพียงเล็กน้อย วิธีการทั่วไปนี้จะจำแนกประเภทอุปกรณ์ของผู้เข้าชมให้อยู่ในกลุ่มอุปกรณ์ที่เหมาะสม และแสดงเวอร์ชันที่เหมาะสมแก่อุปกรณ์นั้น ขณะเดียวกันก็ทำให้การนำโค้ดกลับมาใช้ซ้ำได้สูงสุดระหว่างเวอร์ชันต่างๆ
คุณกำหนดเป้าหมายอุปกรณ์ประเภทใด
ปัจจุบันมีอุปกรณ์ที่เชื่อมต่ออินเทอร์เน็ตอยู่มากมาย และแทบทุกอุปกรณ์มีเบราว์เซอร์ ข้อมูลแทรกซ้อนอยู่ในความหลากหลาย ได้แก่ แล็ปท็อป Mac, เวิร์กสเตชัน Windows, iPhone, iPad, โทรศัพท์ Android ที่มีการป้อนข้อมูลด้วยการสัมผัส, ล้อเลื่อน, แป้นพิมพ์, การป้อนข้อมูลด้วยเสียง, อุปกรณ์ที่มีความไวต่อแรงกด, สมาร์ทวอทช์, เครื่องปิ้งขนมปัง และตู้เย็น และอีกมากมาย อุปกรณ์บางชนิดมีอยู่ทั่วไป และบางอุปกรณ์ก็หายากมาก
ในการสร้างประสบการณ์ของผู้ใช้ที่ดี คุณต้องทราบว่าผู้ใช้ของคุณเป็นใครและใช้อุปกรณ์ใด หากคุณสร้างอินเทอร์เฟซผู้ใช้สำหรับ ผู้ใช้เดสก์ท็อปด้วยเมาส์และแป้นพิมพ์ แล้วสร้างให้กับผู้ใช้สมาร์ทโฟน อินเทอร์เฟซของคุณจะน่าหงุดหงิดเพราะอินเทอร์เฟซนี้ออกแบบมาสำหรับหน้าจอขนาดอื่นและมีรูปแบบการป้อนข้อมูลอีกรูปแบบหนึ่ง
วิธีการมีขอบเขตสุดโต่งอยู่ 2 แบบด้วยกัน ดังนี้
สร้างเวอร์ชันเดียวที่ใช้งานได้ในอุปกรณ์ทุกเครื่อง ผลที่ตามมาคืออุปกรณ์แต่ละอย่างมีการพิจารณาการออกแบบต่างกัน
สร้างเวอร์ชันสำหรับอุปกรณ์แต่ละเครื่องที่ต้องการรองรับ การดำเนินการนี้อาจใช้เวลานานเกินไป เนื่องจากคุณจะสร้างแอปพลิเคชันหลายเวอร์ชันเกินไป นอกจากนี้ เมื่อสมาร์ทโฟนเครื่องใหม่รุ่นใหม่มาถึง (ซึ่งจะเกิดขึ้นประมาณทุกสัปดาห์) คุณก็จะถูกบังคับให้สร้างอีกเวอร์ชันหนึ่ง
แต่เงื่อนไขพื้นฐานก็คือ ยิ่งมีหมวดหมู่อุปกรณ์มากเท่าใด ประสบการณ์ของผู้ใช้ก็ยิ่งดีขึ้นเท่านั้น แต่การออกแบบ ติดตั้งใช้งาน และดูแลรักษาก็ยิ่งต้องทำงานหนักมากขึ้นเท่านั้น
การสร้างเวอร์ชันแยกต่างหากสำหรับแต่ละคลาสของอุปกรณ์ที่คุณเลือกอาจเป็นความคิดที่ดีด้วยเหตุผลด้านประสิทธิภาพ หรือในกรณีที่เวอร์ชันที่คุณต้องการแสดงในแต่ละคลาสของอุปกรณ์แตกต่างกันอย่างมาก แต่หากไม่เป็นเช่นนั้น การออกแบบเว็บที่ตอบสนองตามอุปกรณ์จะเป็นวิธีที่สมเหตุสมผลที่สุด
โซลูชันที่เป็นไปได้
ข้อดีอีกอย่างหนึ่งคือ แยกอุปกรณ์ออกเป็นหมวดหมู่ต่างๆ และออกแบบประสบการณ์การใช้งานที่ดีที่สุดสำหรับแต่ละหมวดหมู่ หมวดหมู่ที่คุณเลือก ขึ้นอยู่กับผลิตภัณฑ์และผู้ใช้เป้าหมายของคุณ ต่อไปนี้เป็นตัวอย่างการจำแนกประเภทที่ครอบคลุมอุปกรณ์ ที่สามารถใช้งานเว็บได้ซึ่งเป็นที่นิยมอย่างที่มีอยู่ในปัจจุบัน
- หน้าจอขนาดเล็ก + หน้าจอสัมผัส (ส่วนใหญ่เป็นโทรศัพท์)
- หน้าจอขนาดใหญ่ + หน้าจอสัมผัส (ส่วนใหญ่เป็นแท็บเล็ต)
- หน้าจอขนาดใหญ่ + แป้นพิมพ์/เมาส์ (ส่วนใหญ่เป็นเดสก์ท็อป/แล็ปท็อป)
นี่เป็นเพียงรายละเอียดหนึ่งที่เป็นไปได้มากมาย แต่เป็นรายละเอียดที่มีเหตุผลมากในขณะที่เขียน สิ่งที่หายไปจากรายการข้างต้นคืออุปกรณ์เคลื่อนที่ที่ไม่มีหน้าจอสัมผัส (เช่น ฟีเจอร์โฟน โปรแกรมอ่าน eBook โดยเฉพาะ) อย่างไรก็ตาม แอปเหล่านี้ส่วนใหญ่จะมีซอฟต์แวร์การนําทางด้วยแป้นพิมพ์หรือโปรแกรมอ่านหน้าจอติดตั้งอยู่ ซึ่งก็ทํางานได้ด้วยเช่นกัน หากคุณสร้างเว็บไซต์โดยคํานึงถึงการช่วยเหลือพิเศษ
ตัวอย่างเว็บแอปเฉพาะรูปแบบของอุปกรณ์
มีตัวอย่างจำนวนมากของผลิตภัณฑ์และบริการบนอินเทอร์เน็ตที่แสดงเวอร์ชัน ที่แตกต่างกันโดยสิ้นเชิงสำหรับอุปกรณ์รูปแบบต่างๆ 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: การตรวจหาฝั่งไคลเอ็นต์
เราสามารถเรียนรู้มากมายเกี่ยวกับเบราว์เซอร์และอุปกรณ์ของผู้ใช้โดยใช้การตรวจหาฟีเจอร์ สิ่งสำคัญที่เราต้องพิจารณาคืออุปกรณ์มีความสามารถในการสัมผัสหรือไม่ และเป็นหน้าจอขนาดใหญ่หรือเล็ก
เราต้องลากเส้นแบ่งเพื่อแยกแยะอุปกรณ์ระบบสัมผัสขนาดเล็กและใหญ่ แล้วเคส Edge อย่าง Galaxy Note ขนาด 5" ล่ะ กราฟิกต่อไปนี้แสดงอุปกรณ์ Android และ iOS ยอดนิยมจำนวนหนึ่งที่วางซ้อนกัน (ที่มีความละเอียดหน้าจอสอดคล้องกัน) เครื่องหมายดอกจันแสดงว่าอุปกรณ์มาถึงหรืออาจมีความหนาแน่นเพิ่มขึ้นเป็น 2 เท่า แม้ว่าความหนาแน่นของพิกเซลอาจเป็น 2 เท่า CSS ก็ยังคงรายงานขนาดเดียวกัน
ข้อมูลสั้นๆ เกี่ยวกับพิกเซลใน CSS: พิกเซล CSS ในเว็บบนอุปกรณ์เคลื่อนที่ไม่เหมือนกับพิกเซลหน้าจอ อุปกรณ์ iOS Retina นำ ความหนาแน่นของพิกเซลเป็น 2 เท่า (เช่น iPhone 3GS เทียบกับ 4, iPad 2 เทียบกับ 3) UA สำหรับ Safari ในอุปกรณ์เคลื่อนที่แบบเรตินายังคงรายงานความกว้างของอุปกรณ์เท่าเดิมเพื่อหลีกเลี่ยงการทำลายเว็บ เช่นเดียวกับอุปกรณ์อื่นๆ (เช่น Android) จะได้รับจอแสดงผลที่มีความละเอียดสูงขึ้น แต่จะใช้วิธีการเดียวกันกับความกว้างของอุปกรณ์
อย่างไรก็ตาม สิ่งที่ทำให้เกิดความสับสนคือความสำคัญของการพิจารณาทั้งโหมดแนวตั้งและแนวนอน เราไม่ต้องการโหลดหน้านี้ซ้ำหรือโหลดสคริปต์เพิ่มเติมทุกครั้งที่ปรับการวางแนวอุปกรณ์ แต่อาจต้องการแสดงผลหน้าเว็บให้แตกต่างออกไป
ในแผนภาพต่อไปนี้ สี่เหลี่ยมจัตุรัสจะแสดงขนาดสูงสุดของอุปกรณ์แต่ละเครื่อง ซึ่งเป็นผลมาจากการซ้อนทับเส้นแนวตั้งและแนวนอน (และเติมสี่เหลี่ยมจัตุรัส)
เมื่อตั้งค่าเกณฑ์เป็น 650px
เราจะจัดประเภท iPhone, Galaxy Nexus เป็น
smalltouch และ iPad, Galaxy Tab เป็น "แท็บเล็ต" Galaxy Note ของ Google+ ในตัวอย่างนี้ได้รับการจัดประเภทเป็น "phone" และจะมีเลย์เอาต์ของโทรศัพท์
กลยุทธ์ที่สมเหตุสมผลอาจมีลักษณะดังนี้
if (hasTouch) {
if (isSmall) {
device = PHONE;
} else {
device = TABLET;
}
} else {
device = DESKTOP;
}
ดูตัวอย่างเล็กๆ น้อยๆ ของวิธีการตรวจหาฟีเจอร์ในการใช้งานจริง
อีกวิธีหนึ่งคือการใช้การดักจับของ UA เพื่อตรวจหาประเภทอุปกรณ์ โดยพื้นฐานแล้ว คุณสร้างชุดการเรียนรู้และจับคู่กับ navigator.userAgent
ของผู้ใช้ได้ โค้ด Pseudo มีลักษณะดังต่อไปนี้
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 ได้ แต่อาจทำงานช้าและ/หรือไม่สุภาพ ทั้งนี้ขึ้นอยู่กับแอปพลิเคชันของคุณ
การตัดสินใจเกี่ยวกับไคลเอ็นต์หรือเซิร์ฟเวอร์
ข้อดีและข้อเสียระหว่าง 2 วิธีนี้มีดังนี้
ลูกค้า Pro:
- พิสูจน์ให้เห็นว่าอนาคตจะเป็นอย่างไรเมื่อพิจารณาขนาด/ความสามารถของหน้าจอมากกว่า UA
- ไม่จำเป็นต้องอัปเดตรายการ UA อย่างสม่ำเสมอ
Pro Server:
- ควบคุมเวอร์ชันที่จะแสดงในอุปกรณ์ได้โดยสมบูรณ์
- ประสิทธิภาพที่ดีขึ้น: ไม่จำเป็นต้องเปลี่ยนเส้นทางไคลเอ็นต์หรือการโหลดแบบไดนามิก
ความต้องการส่วนตัวของผมคือเริ่มต้นด้วย device.js และการตรวจหาฝั่งไคลเอ็นต์ เมื่อแอปพลิเคชันมีการพัฒนามากขึ้น หากพบว่าการเปลี่ยนเส้นทางฝั่งไคลเอ็นต์มีข้อเสียด้านประสิทธิภาพอย่างมาก คุณอาจนำสคริปต์ device.js ออกและใช้การตรวจจับ UA บนเซิร์ฟเวอร์ได้อย่างง่ายดาย
ขอแนะนำ device.js
Device.js คือจุดเริ่มต้นของการตรวจหาอุปกรณ์เชิงความหมายโดยใช้คำค้นหาสื่อ โดยไม่จำเป็นต้องกำหนดค่าพิเศษฝั่งเซิร์ฟเวอร์ ซึ่งช่วยประหยัดแรงและเวลาที่ต้องใช้ในการแยกวิเคราะห์สตริง 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 แอปแยกจากกัน โดยใช้ 1 แอปสำหรับอุปกรณ์แต่ละประเภท ไม่เอาด้วยหรอก การแชร์โค้ดคือ กุญแจสำคัญ
หวังว่าคุณจะเคยใช้เฟรมเวิร์กที่เหมือน MVC อย่างเช่น Backbone, Ember เป็นต้น หากเคยใช้แล้ว คุณคุ้นเคยกับหลักการแยกข้อกังวล โดยเฉพาะอย่างยิ่งต้องแยก UI (Viewเลเยอร์) ออกจากตรรกะของคุณ (โมเดลเลเยอร์) หากคุณยังไม่คุ้นเคยกับการสตรีม ให้เริ่มต้นใช้งานด้วยแหล่งข้อมูลเกี่ยวกับ MVC และ MVC ใน JavaScript เหล่านี้
เรื่องราวจากหลายอุปกรณ์นี้เข้ากับเฟรมเวิร์ก MVC ที่คุณมีอยู่อย่างลงตัว คุณสามารถย้ายมุมมองไปที่ไฟล์แยกต่างหากได้อย่างง่ายดาย ซึ่งเป็นการสร้างมุมมองที่กำหนดเองสำหรับอุปกรณ์แต่ละประเภท จากนั้นคุณสามารถแสดงโค้ดเดียวกันสำหรับทุกอุปกรณ์ ยกเว้นเลเยอร์มุมมอง
โปรเจ็กต์ของคุณอาจมีโครงสร้างต่อไปนี้ (แน่นอนว่าคุณเลือกโครงสร้างที่เหมาะสมที่สุดตามแอปพลิเคชันของคุณได้)
โมเดล/ (โมเดลที่ใช้ร่วมกัน) item.js item-collection.js
Controller/ (ตัวควบคุมที่ใช้ร่วมกัน) item-controller.js
เวอร์ชัน/ (ข้อมูลเฉพาะอุปกรณ์) แท็บเล็ต/ เดสก์ท็อป/ โทรศัพท์/ (โค้ดเฉพาะโทรศัพท์) style.css index.html view/ 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
เท่านั้น) แต่ได้รับการจัดการอย่างถูกต้อง (ต้องขอบคุณ Modernizr.touch) โดย device.js
การลบล้างเวอร์ชัน
บางครั้งการตรวจหาอุปกรณ์อาจผิดพลาด และในบางกรณี ผู้ใช้อาจต้องการดูการจัดวางของแท็บเล็ตบนโทรศัพท์ (อาจใช้ Galaxy Note) คุณจึงต้องให้ผู้ใช้เลือกได้ว่าจะใช้เว็บไซต์เวอร์ชันใดหากต้องการลบล้างด้วยตนเอง
วิธีทั่วไปคือให้ลิงก์ไปยังเวอร์ชันเดสก์ท็อปจากเวอร์ชันอุปกรณ์เคลื่อนที่ วิธีการนี้ใช้งานง่ายพอ แต่ device.js รองรับฟังก์ชันนี้ด้วยพารามิเตอร์ device
GET
สรุป
กล่าวโดยสรุปคือ เมื่อสร้าง UI แบบหน้าเดียวแบบหลายอุปกรณ์ที่ไม่เข้ากับโลกแห่งการออกแบบที่ปรับเปลี่ยนตามอุปกรณ์เลย ให้ทำดังนี้
- เลือกชุดคลาสอุปกรณ์ที่จะสนับสนุนและเกณฑ์ที่จะใช้ในการจัดประเภทอุปกรณ์เป็นคลาส
- สร้างแอป MVC ด้วยการแยกข้อกังวลใจอย่างชัดเจน โดยแยกมุมมองออกจากฐานของโค้ดที่เหลือ
- ใช้ device.js เพื่อตรวจจับคลาสอุปกรณ์ฝั่งไคลเอ็นต์
- เมื่อคุณพร้อมแล้ว ให้แพ็กเกจสคริปต์และสไตล์ชีตเป็นคลาสใดคลาสหนึ่งสำหรับอุปกรณ์แต่ละคลาส
- หากประสบปัญหาเกี่ยวกับประสิทธิภาพการเปลี่ยนเส้นทางฝั่งไคลเอ็นต์ ให้เลิกใช้ device.js แล้วเปลี่ยนไปใช้การตรวจหา UA ฝั่งเซิร์ฟเวอร์