สำหรับคนที่ติดตามเรื่อง Responsive Web Design กับโค้ชพลมาตั้งแต่ 2-3 ปีที่แล้ว คงดีใจกันสุดๆ เมื่อ HTML5 Element ใหม่ที่ชื่อว่า <picture> ใกล้ออกมาให้ใช้งานกันได้แล้ว
น่าจะแก้ปัญหาเรื่องรูปภาพบนเว็บไซต์ยุคอุปกรณ์พกพา (ได้ซะที)
วันนี้ผมกำลังสรุปวิธีใช้งานเจ้า <picture> element ที่น่าจะมาแก้ปัญหาให้พวกเราได้เร็วๆ นี้อยู่ ก็คิดได้ว่า ยังไม่ได้คุยเรื่องแนวคิดในการใช้รูปภาพบน เว็บไซต์แบบ Responsive ที่ดีเลย มาดูกันครับ
ปัญหาที่ติดมากับความสวยงาม
รูปภาพ แทนคำพูดได้นับล้าน
และแน่นอน นักออกแบบเว็บไซต์ใช้รูปภาพในการสื่อสารข้อความ และเนื้อหาถึงผู้เข้าเว็บ รวมไปถึงการใช้ในระบบ e-commerce ต่างๆ ด้วย
ทีนี้รูปภาพมันมาพร้อมกับ “ขนาดของไฟล์” ที่ต้องถูกดาวน์โหลดมาที่เครื่องผู้เข้าชมเว็บ
เมื่อยุค internet เข้าเมืองไทยใหม่ๆ คนที่ได้ใช้โมเด็มความเร็ว 28k และ 56k คงจำกันได้ดี บางเว็บภาพเยอะมา รอกันเป็นชั่วโมงก็มี
ยุคนี้คงไม่พ้น 3G ที่จำกัดปริมาณการใช้งาน ต้นเดือนก็โหลดเร็วปรู๊ดปร๊าด พอหมดแพคเกจเท่านั้นล่ะ หึหึหึ
ซึ่งปัจจุบันจอ Retina Display กับ HD ความละเอียดสูงกำลังมาแรง รูปเว็บไหนละเอียดไม่พอ ก็ไม่สวย ดูไม่ไฮโซทันที คนที่ใช้อุปกรณ์หน้าจอความละเอียดโคตรชัดพวกนี้แหละ รู้ไหมหนอว่าถ้าดูผ่าน 3G เนี่ย ตัวกระซวกแบนด์วิธ (bandwidth) ชัดๆ
ดังนั้นปัจจุบัน ถึงแม้ว่าจะมีการนำรูปภาพความละเอียดสูงมาใช้ในเว็บไซต์แบบ Responsive Layout ทำขนาดการแสดงผลยืดหยุ่นได้ แต่ขนาดของภาพที่ต้องโหลดผ่านเครือข่ายยังเท่าเดิม (ใครเรียนกับผมไป จะรู้จักในชื่อของ “ศาสตร์มืด”)
สรุปง่ายๆ ว่า มือถือต้องโหลดภาพผ่านเครือข่าย 3G แบบเดียวกับที่ PC ทำได้สบายๆ บนเครือข่าย Wifi
เป็นโจทย์ใหญ่ที่นักสร้างเว็บไซต์ในปัจจุบันต้องผ่านไปให้ได้
แนวคิดของการใช้รูปภาพใน Responsive Web ที่สมบูรณ์
ดังนั้นในปัจจุบัน เรามีการสร้างแนวคิดขึ้นมาครับ ว่าการใช้รูปภาพบนเว็บไซต์ที่ต้องรองรับการแสดงผลบนทุกๆ อุปกรณ์ที่ดี ควรจะมีลักษณะยังไงบ้าง
1. ขนาดเหมาะกับหน้าจอ
ปฏิเสธไม่ได้ว่าตอนนี้พวกเราส่วนใหญ่ถนัดการออกแบบสำหรับหน้าจอ PC หรือ Desktop ก่อนแล้วค่อยลดความต้องการลงมาในหน้าจอที่เล็กกว่า (ถึงแม้หลักการ mobile-first ที่ผมเคยแนะนำที่นี่ จะดูเป็นหนทางที่ดีที่สุด แต่ก็ต้องอาศัยประสบการณ์พอสมควร)
ทำให้รูปภาพที่นำไปพิจารณาใช้งานในตอนต้น จะมีขนาดใหญ่มาก ภาพขนาดใหญ่ที่เอามาโชว์ในหน้าจอขนาดเล็กอย่างสมาร์ทโฟนมักจะดูพิลึกพิลั่นเสมอ จึงมีการนำวิธีต่างๆ ตั้งแต่ CSS ไปจนถึง Javascript framework มาช่วย
2. รักษาแบนด์วิธ (Bandwidth)
ภาพความละเอียดสูงเป็นที่ต้องการเสมอในปัจจุบัน
แต่การโหลดภาพความละเอียดสูงในเว็บไซต์ผ่านเครือข่าย 3G หรือ Edge เป็นอีกเรื่องหนึง
รูปภาพในเว็บจะโหลดมาแสดงผลได้ช้า นั่นหมายความว่าเว็บคุณจะโหลดช้า โหลดช้า ทำให้ผู้ใช้รอ ไม่เป็นการดีเลย
เว็บที่ดีต้องสามารถกำหนดความละเอียดรูปภาพที่เหมาะสมต่อการใช้งานได้ เช่นการส่งภาพความละเอียดสูงสำหรับการดูผ่านหน้าจอคอมพิวเตอร์ และภาพความละเอียดกลางถึงต่ำในสมาร์ทโฟน
โจทย์นี้น่าสนใจใช่ไหมล่ะ? 🙂
ดังนั้นบางคนก็เลือกใช้ Adaptive Web Design แทน Responsive Web Design เลย แต่ก็ยังยุ่งยาก และใช้เวลานานกว่าจะได้เว็บออกมาสักเว็บ
บางคนก็ใช้ CSS
และตอนนี้หลายๆ คนก็หวังกับการมาของ <picture> element
3. สื่อความหมายได้เหมือนเดิม
ในข้อแรกเราคุยถึงความเหมาะสมของขนาดภาพ กับขนาดหน้าจอที่ต้องแสดงผล
แต่รูปภาพใหญ่ๆ อย่างพวกเต็มจอ เวลามาย่อเหลือขนาดเล็กๆ มันน่าเกลียด
ถึงแม้เราจะเถียงว่ามันเป็นเพราะ Responsive Layout แต่อย่าลืมว่าภาพใช้บนเว็บ คือการสื่อสารข้อความ หากมันดูไม่รู้เรื่องเพราะขนาดมันย่อซะเล็กมาก มันก็ไม่มีประโยชน์อะไรที่จะมีภาพนั้นอยู่
โจทย์ปัจจุบันคือเราจะทำอย่างไร ให้การแสดงภาพเดียวกันในหลายๆ ขนาดหน้าจอ สามารถสื่อสารความหมายเดียวกันไปสู่ผู้เข้าชมได้
แนวทางที่มีปัจจุบันคือหลายๆ คน และผม เลือกให้ภาพถูก “ครอบ” (Crop) บางส่วนที่ไม่สำคัญออกไป ให้เหลือส่วนที่เป็นใจความสำคัญของภาพครับ
ตัวอย่างด้านล่างจะแสดงให้เห็นถึงการ crop ภาพที่ไม่ใส่ใจเนื้อหา กับใส่ใจเนื้อหาได้เป็นอย่างดี
ปิดท้าย
เรื่องของ Responsive Web Design เป็นเรื่องของแนวคิดล้วนๆ เหมือนการนั่งคิดว่าจะวาดภาพยังไง ก่อนที่จะใช้พู่กันเขียนลงบนผืนผ้า
เราเผชิญตั้งแต่เรื่องของการแสดงผลเนื้อหา (Content on Responsive Web Design) เรื่องของโครงสร้างเพจ (Responsive Web Layout) จนไปถึงแนวคิดปฏิวัติอย่าง mobile-first และเราก็ผ่านมาได้
โชกโชนกันทีเดียว
เรื่องของรูปภาพเป็นโจทย์ล่าสุดที่เรากำลังจะผ่านไปได้ น่าตื่นเต้นจริงๆ ที่เราอยู่ในยุคใหม่ หลังจากที่โลกของเว็บได้หยุดนิ่งมาหลายปี
ลองติดตามเรื่องของ Responsive Web Image ได้ใน tag ของบทความผมนะครับ
ศึกษาเพิ่มเติมได้จาก: Thank you photo from:
- “Multi-device design” by Jeffrey Zeldman
- “Going nowhere fast” – by Nathan