ผลกระทบเชิงลบของดีไซน์เว็บแบบ Mobile-first ต่อเดสก์ท็อป
(nngroup.com)- หากนำเลย์เอาต์ที่ออกแบบให้เหมาะกับมือถือไปขยายใช้บนเดสก์ท็อปแบบเดิม ๆ รูปภาพ ตัวอักษร และระยะเว้นว่างจะใหญ่เกินไป และทำให้การใช้งานแย่ลงจาก การกระจายตัวของคอนเทนต์ ที่ข้อมูลกระจัดกระจายไปตามหน้าที่ยาว
- เมื่อทราฟฟิกเว็บทั่วโลกมากกว่า 55% มาจากมือถือ แนวทาง Mobile-first จึงถูกใช้อย่างแพร่หลาย แต่เมื่อผสานกับดีไซน์แบบมินิมัลและการออกแบบที่เน้นรูปภาพขนาดใหญ่ ความหนาแน่นของข้อมูลบนเดสก์ท็อปจะลดลงอย่างมาก
- จากการเปรียบเทียบเลย์เอาต์แบบกระจายกับแบบอัดแน่นในการ ทดสอบการใช้งานเชิงคุณภาพ 13 ครั้ง พบว่าหน้าแบบกระจายทำให้การค้นหาและทำความเข้าใจข้อมูลยากขึ้น
- คอนเทนต์ที่กระจายตัวเพิ่มการเลื่อนและการคลิก ทำให้ ต้นทุนการโต้ตอบ สูงขึ้น และบังคับให้ต้องจดจำข้อมูลที่เกี่ยวข้องกันข้ามหลายหน้าจอ ซึ่งอาจนำไปสู่ภาระทางความคิด ความหงุดหงิด และความเชื่อมั่นที่ลดลง
- บนเดสก์ท็อป ควรจัดกลุ่มข้อมูลสำคัญที่เกี่ยวข้องกันไว้ใน viewport เดียวกัน และควรใช้แพตเทิร์นสำหรับมือถือโดยเฉพาะอย่าง accordion อย่างจำกัด
การกระจายตัวของคอนเทนต์คืออะไร
- การกระจายตัวของคอนเทนต์ คือปรากฏการณ์ที่คอนเทนต์ของเว็บเพจแบบ responsive ดูใหญ่เกินไปและยืดยาวเกินควรบนหน้าจอแล็ปท็อปขนาดใหญ่หรือเดสก์ท็อป
- เมื่อหน้าแบบ Mobile-first ถูกเรนเดอร์บนเดสก์ท็อป รูปภาพที่กินเต็มหน้าจอ ตัวอักษรขนาดใหญ่ที่ถูกขยาย และ negative space ที่มากเกินไปจะสร้างหน้าที่ยาวและต้องเลื่อนมากขึ้น
- หากการกระจายตัวเกิดขึ้นเฉพาะบางส่วน อาจไม่ใช่ปัญหาการใช้งานใหญ่ แต่หากเกิดกับหน้าส่วนใหญ่ ผลกระทบสะสมโดยทั่วไปจะเป็นลบ
- บนอุปกรณ์จอใหญ่ การกระจายตัวของคอนเทนต์เพิ่ม ภาระทางความคิด, ต้นทุนการโต้ตอบ, ความยากในการเข้าใจคอนเทนต์ และความหงุดหงิดของผู้ใช้
แนวโน้มการออกแบบที่ทำให้คอนเทนต์กระจายตัว
- แนวทาง Mobile-first คือการออกแบบสำหรับมือถือก่อน แล้วจึงปรับให้เหมาะกับแท็บเล็ตและเดสก์ท็อป
- เมื่อทราฟฟิกเว็บทั่วโลกมากกว่า 55% เกิดจากอุปกรณ์มือถือ แนวทางนี้จึงถูกใช้อย่างแพร่หลาย
- มินิมัลลิสม์ ตัดองค์ประกอบการออกแบบที่ไม่จำเป็นต่อฟังก์ชันหลักหรือสารหลักของเว็บไซต์ออก
- ใช้ negative space จำนวนมากเพื่อหลีกเลี่ยงภาพลักษณ์ที่ดูซับซ้อน
- ปริมาณคอนเทนต์ที่แสดงใน viewport หนึ่งหน้าจอลดลง จนอาจกลายเป็นหน้าที่ยาวและมีความหนาแน่นของข้อมูลต่ำ
- ดีไซน์ที่เน้น รูปภาพขนาดใหญ่ เชื่อมโยงกับกระแสการใช้ภาพความละเอียดสูงในขนาดใหญ่บนเว็บสมัยใหม่
- รูปขนาดใหญ่ดึงดูดสายตาได้ แต่ก็อาจทำให้คอนเทนต์ข้อความกระจัดกระจายมากเกินไป
- การมีรูปใหญ่ไม่กี่รูปในหน้าเดสก์ท็อปอาจทำงานได้ดี
- แต่หากมีรูปใหญ่มากเกินไป คอนเทนต์ที่เป็นข้อความระหว่างรูปเหล่านั้นจะแตกเป็นชิ้น ๆ ทั่วทั้งหน้า
วิธีการทดสอบการใช้งาน 13 ครั้ง
- การทดสอบดำเนินด้วยการผสาน การทดสอบการใช้งานเชิงคุณภาพ 13 ครั้ง กับการสัมภาษณ์แบบกึ่งมีโครงสร้าง
- สิ่งที่นำมาเปรียบเทียบคือชุดผสมของเลย์เอาต์สองแบบและประเภทหน้าสองประเภท
- เลย์เอาต์: แบบอัดแน่น, แบบกระจาย
- ประเภทหน้า: โฮมเพจ, หน้าผลิตภัณฑ์
- ใช้ prototype ทั้งหมด 4 แบบ
- prototype แบบกระจายถูกสร้างขึ้นใหม่จากการหาเว็บเพจเดสก์ท็อปจริงที่มีความหนาแน่นของคอนเทนต์ต่ำ มี negative space กว้าง และตัวอักษรใหญ่
- เวอร์ชันแบบอัดแน่นถูกสร้างแยกต่างหากโดยใช้คอนเทนต์เดียวกับหน้าเดิม
- ผู้ใช้ทำกิจกรรมปลายเปิดบน prototype ทั้ง 4 แบบ และเข้าร่วมการอภิปรายต่อเนื่องเพื่อเปรียบเทียบเวอร์ชันทั้งสองของแต่ละประเภทหน้า
- วิธีวิจัยทั้งหมดอยู่ใน หน้าวิธีวิจัยแยกต่างหาก
ปัญหาการใช้งานที่เกิดจากคอนเทนต์กระจายตัว
- หากการกระจายตัวปรากฏในบริเวณกว้างของหน้า อาจส่งผลอย่างมากต่อประสบการณ์ผู้ใช้โดยรวม
- ปัญหาหลักมีดังนี้
- ความยาวหน้าและ ต้นทุนการโต้ตอบ เพิ่มขึ้น
- ภาระทางความคิด เพิ่มขึ้น
- สร้าง conceptual model ของหน้าได้ยาก
- ความหงุดหงิดเพิ่มขึ้น
- ความเชื่อมั่นลดลง
-
การเลื่อนและการคลิกเพิ่มขึ้น
- การกระจายตัวของคอนเทนต์ทำให้เกิดหน้าที่ยาวซึ่งต้องเลื่อนมากขึ้น และองค์ประกอบดีไซน์สำหรับมือถือโดยเฉพาะอย่าง accordion ต้องใช้การคลิกมากขึ้นเพื่อเข้าถึงคอนเทนต์
- เมื่อเว็บไซต์แบบ Mobile-first ถูกเรนเดอร์บนจอใหญ่ คอนเทนต์จะกระจายตัวจนกลายเป็นหน้าที่ยาว และผลนี้จะยิ่งเด่นขึ้นเมื่อผสานกับดีไซน์แบบมินิมัลและเน้นรูปภาพ
- เมื่อคอนเทนต์กระจัดกระจายอยู่ในหลาย viewport การหาข้อมูลเฉพาะภายในหน้าจะยากขึ้น
- ผู้เข้าร่วมทดสอบพบว่าการหาข้อมูลในหน้าผลิตภัณฑ์แบบกระจายยากกว่าเวอร์ชันแบบอัดแน่น
-
ปัญหาของแพตเทิร์นสำหรับมือถือบนเดสก์ท็อป
- accordion ช่วยพับข้อมูลจำนวนมากไว้ในพื้นที่แคบบนมือถือ ทำให้หน้าสั้นลง และช่วยให้ผู้ใช้เข้าถึงส่วนที่สนใจได้โดยตรง
- บนจอใหญ่ ปัญหาหน้าที่ยาวมีความสำคัญน้อยกว่าโดยเปรียบเทียบ ดังนั้น accordion อาจทำให้คอนเทนต์แตกเป็นชิ้น ๆ และเพิ่ม ต้นทุนการโต้ตอบ ในการหาข้อมูลสำคัญอย่างมาก
- ผู้เข้าร่วมคนหนึ่งตอบว่าต้องเปิดและปิดแต่ละรายการใน accordion ข้อมูลผลิตภัณฑ์ของ prototype แบบกระจายเพื่ออ่านข้อมูล
- ผู้เข้าร่วมอีกคนประเมินว่าหน้าแบบอัดแน่นดีกว่า เพราะคลิกน้อยกว่าและข้อมูลอยู่ตรงหน้า
-
ภาระทางความคิดเพิ่มขึ้น
- ยิ่งรูปภาพใหญ่ขึ้นและ negative space กว้างขึ้น คอนเทนต์ที่เป็นข้อความก็ยิ่งแตกเป็นชิ้น ๆ ข้ามหลาย viewport
- เมื่อคอนเทนต์ที่เกี่ยวข้องกันถูกตัดแบ่งตามหน้าจอ ผู้ใช้จะมองมันเป็นหน่วยเดียวกันได้ยาก
- เพื่อใช้วิจารณญาณหรือตัดสินใจ ผู้ใช้ต้องจดจำข้อมูลจาก viewport ต่าง ๆ หรือเลื่อนไปมา และความจุของความจำระยะสั้นอาจถูกกดดันจนล้นได้ง่าย
- เลย์เอาต์แบบอัดแน่นแสดงข้อมูลได้มากกว่าใน viewport เดียวกัน จึงลดภาระทางความคิดและมอบประสบการณ์การสำรวจที่ราบรื่นกว่า
- ลักษณะของรูปภาพก็ส่งผลต่อความรู้สึกว่าคอนเทนต์แตกเป็นชิ้น ๆ เช่นกัน
- รูปภาพเชิงข้อมูล อาจเพิ่มภาระไม่มากแม้จะแสดงใหญ่บนจอใหญ่ เพราะผู้ใช้ใช้เวลาดูเพื่อดึงข้อมูลที่เป็นประโยชน์
- รูปภาพตกแต่ง ไม่มีคุณค่าทางข้อมูล ผู้ใช้จึงมักเลื่อนผ่านโดยไม่ดู และต้องเลื่อนผ่านภาพประกอบขนาดใหญ่เพื่อไปถึงคอนเทนต์ที่มีประโยชน์ ทำให้รู้สึกว่าคอนเทนต์แตกกระจายแย่ลง
ผลกระทบต่อ conceptual model และความเชื่อมั่น
- หน้าแบบกระจายทำให้ประเมินแนวคิดที่เว็บไซต์สื่อสารและสร้าง conceptual model ได้ยากขึ้น เพราะหน้ายาวขึ้นและเพิ่มภาระต่อ working memory
- ใน prototype โฮมเพจ ผู้เข้าร่วมตอบว่าแทนที่จะเห็นข้อเสนอ 4–5 อย่างพร้อมกันและเข้าใจขอบเขตได้ พวกเขาต้องจดจำสิ่งเหล่านั้นไปพร้อมกับทำความเข้าใจ จึงยากกว่า
- ในหน้าผลิตภัณฑ์ เมื่อปัจจัยประกอบการตัดสินใจซื้อ เช่น ราคา รายละเอียดผลิตภัณฑ์ และรีวิว กระจัดกระจายไปตามหลาย viewport ผู้ใช้ต้องเสพและจดจำข้อมูลแยกกัน
- หากข้อมูลสำคัญอยู่ร่วมกันหรือจัดวางในจำนวน viewport ที่น้อยลง จะสร้างความเข้าใจเชิงแนวคิดเกี่ยวกับผลิตภัณฑ์หรือคุณค่าที่นำเสนอได้ง่ายขึ้น
- ภาพลวงตาว่าจบแล้ว อาจเด่นชัดมากขึ้นในเว็บไซต์แบบกระจาย
- บล็อกสีอาจสร้างเส้นแนวนอนที่เด่นใน viewport หรือ negative space ที่กว้างอาจทำให้ดูเหมือนว่าหน้าจบแล้ว
- หากไม่มีสัญญาณบอกการเลื่อนว่ามีคอนเทนต์เพิ่มเติม ผู้ใช้อาจพลาดคอนเทนต์ได้
- เมื่อปัญหาการใช้งานสะสม เว็บไซต์แบบกระจายอาจดูเหมือนมีคอนเทนต์น้อยและเข้าถึงยาก
- ผู้ใช้บางคนอาจรู้สึกว่าบริษัทกำลังซ่อนข้อมูล ซึ่งในกรณีนี้ ความเชื่อมั่น อาจลดลง
- ผู้ใช้ชอบเลย์เอาต์แบบอัดแน่นมากกว่า โดยเฉพาะเมื่อมีเป้าหมายในการสำรวจเว็บไซต์และทำความเข้าใจโดยรวมเกี่ยวกับสิ่งที่เว็บไซต์นำเสนอ
กรณีที่การกระจายตัวของคอนเทนต์ช่วยได้
- หากทั้งหน้ากระจายตัว ผลกระทบสะสมต่อการใช้งานโดยทั่วไปจะเป็นลบ แต่ในบางสถานการณ์ก็อาจส่งผลดีต่อประสบการณ์ได้
- เมื่อปริมาณคอนเทนต์ที่แสดงใน viewport หนึ่งลดลง ผู้ใช้จะโฟกัสคอนเทนต์ที่ถูกเน้นได้ทีละอย่าง และอาจรู้สึกว่าข้อมูลล้นน้อยลง
- วิธีลดความหนาแน่นของคอนเทนต์ใน viewport เพื่อเน้นข้อมูลอาจมีประโยชน์ในกรณีต่อไปนี้
- ต้องทำความเข้าใจ คอนเทนต์ที่ซับซ้อน ทีละชิ้น
- ผู้ใช้ต้องคุ้นเคยกับคอนเทนต์ที่แสดง และอาจรู้สึกท่วมท้นหากมีข้อมูลมากเกินไป
- แสดง รูปภาพมูลค่าสูง
- รูปผลิตภัณฑ์ขนาดใหญ่ช่วยเพิ่มคุณค่าโดยทำให้ผู้ใช้ตรวจดูรายละเอียดของผลิตภัณฑ์ได้ง่ายขึ้น
- รูปภาพที่มีคุณค่าทางข้อมูลสูงอาจทำให้การกระจายตัวสมเหตุสมผล แต่รูปที่ใช้เติมพื้นที่หรือมีไว้เพื่อความน่าสนใจทางสายตาอย่างเดียวจะก่อให้เกิดการกระจายตัวโดยไม่มีประโยชน์เพิ่มเติม
- ใน prototype โฮมเพจ คุณค่าของรูปภาพต่ำกว่า จึงสังเกตเห็นผลเชิงบวกของการกระจายตัวของคอนเทนต์ได้น้อยกว่า
คำแนะนำสำหรับการออกแบบเดสก์ท็อป
- ควรประเมิน การเรนเดอร์บนเดสก์ท็อป แยกต่างหาก
- หากส่วนใหญ่ของหน้าบนเดสก์ท็อปยืดขยายเกินไป ควรพิจารณาออกแบบใหม่ให้กวาดตาดูคอนเทนต์สำคัญได้ง่ายขึ้น
- ควรพิจารณา คุณค่า ที่รูปภาพเพิ่มเข้ามา
- ควรให้ความสำคัญกับรูปภาพขนาดใหญ่ที่ช่วยให้เข้าใจบริบทของผลิตภัณฑ์หรือบริการ
- ควรตัดสินว่ารูปภาพขนาดใหญ่นั้นมีคุณค่าพอให้ยอมรับการกระจายตัวที่เกิดบนเดสก์ท็อปหรือไม่
- ควรจัดกลุ่มคอนเทนต์สำคัญที่เกี่ยวข้องกันไว้ใน viewport เดียวกัน
- ควรพิจารณาว่าข้อมูลใดเกี่ยวข้องที่สุดต่อการทำความเข้าใจสิ่งที่นำเสนอ และเลือกดีไซน์ที่ลดการเลื่อนไปมา
- ควรจำกัดการโต้ตอบและองค์ประกอบดีไซน์สำหรับมือถือโดยเฉพาะ
- ควรลดการใช้ accordion บนเดสก์ท็อป
- ควรพิจารณา adaptive design ที่แสดงคอนเทนต์เดียวกันในรูปแบบที่เป็นมิตรกับเดสก์ท็อป
- การกระจายตัวเหมาะที่จะใช้แบบจำกัดในฐานะกลยุทธ์เพื่อดึงความสนใจไปยังประเด็นหลักหรือคอนเทนต์ที่ซับซ้อน
สรุป
- คอนเทนต์ที่กระจายตัวในหน้าเดสก์ท็อปแบบมินิมัลสามารถลดสิ่งรบกวนและดึงความสนใจไปยังประเด็นหลักหรือข้อมูลที่ซับซ้อนได้
- แต่หากทั้งหน้าถูกจัดตามแนวทาง Mobile-first, มินิมัลลิสม์ และดีไซน์เน้นรูปภาพ ปัญหาการใช้งานบนเดสก์ท็อปจะเพิ่มขึ้น
- เมื่อคอนเทนต์ยืดยาวและแตกเป็นชิ้น ๆ ข้ามหลาย viewport ผู้ใช้จะเสพและทำความเข้าใจข้อมูลได้ยากขึ้น
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
Danny O'Brien เคยดูแลบล็อกเก่าแก่ชื่อ Oblomovka และราวปี 2007 ได้บัญญัติคำว่า hinternet
ตอนนั้นเป็นช่วงที่อินเทอร์เน็ต ซึ่งเดิมเป็นพื้นที่ที่ชนชั้นนำด้านเทคโนโลยีดูแลกันเอง เริ่มมีคนทั่วไปเข้ามาใช้ และ hinternet คือแนวคิดที่ว่าอินเทอร์เน็ตที่มีเทคโนโลยีประณีตและมีคุณค่า กับอินเทอร์เน็ตของสแปม Viagra และแบนเนอร์ป็อปอัปนั้นแยกจากกัน
ในอดีต ชนชั้นนำด้านเทคโนโลยีแทบจะหลีกเลี่ยง hinternet ได้ เหมือนเลี่ยงการเข้าไปในย่านอันตราย แต่คนทั่วไปไม่มีเครื่องมือแยกแยะเช่นนั้น จึงได้รับประสบการณ์ใช้อินเทอร์เน็ตที่ด้อยกว่ามาก
ตอนนี้อินเทอร์เน็ตส่วนใหญ่กลายเป็น hinternet ไปแล้ว และแม้แต่ระบบจำเป็นอย่างธนาคาร สินเชื่อบ้าน การผ่อนรถ และค่าสาธารณูปโภค ก็ถูกออกแบบแบบ mobile-first พร้อมใช้เทคนิคมืดที่พังบนแพลตฟอร์มเปิด โดยอ้างว่าเป็น “การยืนยันตัวตนผู้ใช้จริง”
หาก hinternet ในอดีตเป็นตรอกมืด ๆ ที่ขายนาฬิกาเลียนแบบ ทุกวันนี้มันใกล้เคียงกับดิสโทเปียของการบูรณาการข้อมูลแนวดิ่งที่มีหน่วยงานกึ่งรัฐดำเนินการอยู่เบื้องหลัง และถ้าจะล็อกอินเข้า IRS ก็ต้องใช้แพลตฟอร์มจัดการตัวตน id.me ที่ขายของด้วย
มีความพยายามจะปลูกสวนเล็ก ๆ ที่ประณีตอยู่บ้าง แต่ความสำเร็จก็ขึ้น ๆ ลง ๆ และในมุมของปัจเจก แทบไม่มีแรงจูงใจให้มีส่วนร่วมกับ hinternet นอกจากเรื่องจำเป็นจริง ๆ
หากมองจากมุมนี้ “การออกแบบเว็บแบบ mobile-first” ก็เป็นเพียงอาการที่ถูกตัดออกมาจากบริบทที่ใหญ่กว่าเท่านั้น
โครงเรื่องคือด้านหนึ่งมีชนชั้นนำผู้มีการศึกษาจากแวดวงวิชาการ กองทัพ และรัฐบาล ในฐานะผู้ก่อตั้งโดยชอบธรรม ส่วนอีกด้านหนึ่งคือมวลชนที่หลั่งไหลเข้ามาหลัง Eternal September
ท้ายที่สุดก็เป็นเรื่องทำนองว่าผู้มาใหม่อย่างพ่อค้า นักเก็งกำไร และนักต้มตุ๋น แปลงสัญชาติกลายเป็นบริษัทและธนาคารของโลกใหม่ หากมองยุคดอตคอมเป็นเรื่องราวการล่าอาณานิคม ชนชั้นนำก็กลายเป็นชนพื้นเมืองที่ถูกผลักออกจากผืนดินของตนเอง และยังเข้ากับเรื่องเล่าแบบปัจจุบันได้ดี
แต่สิ่งที่ขาดไปจากนิทานเรื่องนี้คือคนธรรมดาจริง ๆ
ตั้งแต่ปี 1997 ถึงราวปี 2010 เหตุการณ์ดอตคอม, Web 2.0 และการสร้างจักรวรรดิ ยังคงเป็นเหตุการณ์ชายขอบที่เงินและอำนาจเดิมย้ายเข้าสู่อินเทอร์เน็ต พร้อมมี “ผู้ประกอบการ” สายลุยส่วนน้อยเข้ามาเกาะ ส่วนคน 99% ยังเป็นผู้ชม จนตอนนี้เหมือนถูกต้อนเข้าไปในคอก
ความเป็นไปได้ของ อินเทอร์เน็ตของผู้คน ยังมีอยู่ แต่แทบยังแก้ปัญหาคลาสสิกอย่างการกินแรงผู้อื่นและโศกนาฏกรรมของทรัพยากรส่วนรวมไม่ได้ และ ณ จุดนี้ “Web 3.0 และเว็บบล็อกเชน” ดูเหมือนตายไปแล้ว
หากจะกลับไปสู่อินเทอร์เน็ตที่เป็นสาธารณะ มีคุณภาพ และยิ่งใหญ่อีกครั้ง ต้องพิจารณาประวัติศาสตร์และเรื่องเล่าของอินเทอร์เน็ต รวมถึงว่าใครคือผู้มีส่วนได้ส่วนเสียที่แท้จริง ให้ละเอียดกว่านี้
ไม่แน่ใจว่าหมายถึงอินเทอร์เน็ตยุค 90 ที่ใช้ยากและมี IRC กับ Usenet เป็นศูนย์กลาง หรือหมายถึงอินเทอร์เน็ตด้านมืดยุค 90 ที่มีเนื้อหาผิดกฎหมายบนโฮสติงฟรี
มองไม่ค่อยออกว่าอินเทอร์เน็ตยุค 90 ที่มีฟอรัม, IRC, สแปม Viagra และ goatse คล้ายกับอินเทอร์เน็ตปลอดเชื้อในปัจจุบันที่เต็มไปด้วย dark pattern และถูกบริษัทเมกะคอร์ปไม่กี่รายครอบงำอย่างไร
การใช้งานมือถือไม่ได้ทำให้ คนไม่รู้หนังสือคอมพิวเตอร์ ลดลง แต่กลับเพิ่มขึ้นด้วยซ้ำ เป็นแบบกดลิงก์ผิด ติดตั้งแถบเครื่องมือเบราว์เซอร์ แล้วค่อย ๆ ติดเชื้อ dark pattern มากขึ้น
เวลาญาติ ๆ ติดต่อมาเรื่องปัญหาคอมพิวเตอร์ ผมเห็นสภาพแบบนี้ค่อนข้างบ่อย
ทุกครั้งที่ใช้คำอย่าง “phonish” หรือ “phonishness” มักถูกโหวตลบเสมอ แต่สมาร์ตโฟนทำให้ชีวิตแย่ลงมากกว่าดีขึ้น และรู้สึกเหมือนทำให้มนุษย์ต้องรับใช้คอมพิวเตอร์
ตั้งตารอแพลตฟอร์มถัดไป
นอกจากโฟลเดอร์เมลขยะ ก็แทบไม่ได้สัมผัสเลย ส่วนที่เหลือถูกคัดกรองทั้งหมดให้เป็นพื้นที่ที่ “โอเค” หรือถูกปรับให้ใกล้เคียงกับถิ่นอาศัยบนอินเทอร์เน็ตของผู้มีอภิสิทธิ์
แม้ไม่มีเงิน แต่ในแง่ความรู้ก็ถือว่าร่ำรวย และดูเหมือนเป็นโครงสร้างแบบโศกนาฏกรรมของทรัพยากรส่วนรวม ที่กลุ่มคนไม่รู้เท่าทันเทคโนโลยีกลายเป็น โล่มนุษย์ ให้กับโฆษณาและบริการแบบจ่ายเงินอย่าง YouTube
เมื่อเวลาผ่านไป ก็ยิ่งชัดเจนว่า ฟรอนต์เอนด์ น่าจะเป็นส่วนที่ยากที่สุดของสแต็ก
ผู้คนคิดว่าการปั๊มแอป Bootstrap React แบบลวก ๆ ออกมาก็สมบูรณ์แบบแล้ว แต่การเขียน UI ที่ซับซ้อนให้ทำงานได้บนทุกเบราว์เซอร์ อุปกรณ์ เทคโนโลยีช่วยเหลือ และภาษา เป็นเรื่องยากอย่างยิ่ง
ต้องมีความรู้ลึกเกี่ยวกับ HTML, CSS และ Web API ที่เกี่ยวข้อง และวิศวกรฟรอนต์เอนด์ที่ดีนั้นหายากมากแม้แต่ในบริษัทเทคยักษ์ใหญ่
UX designer ที่คิดไปถึงเรื่องพวกนี้ยิ่งหายากกว่า และคนแบบนั้นมีมูลค่าระดับล้านดอลลาร์
สุดท้ายจึงย้ายไปเป็น designer เพราะถ้าจะไม่ได้รับความเคารพ อย่างน้อยก็ไม่ต้องวิ่งอยู่บนลู่วิ่งของเทคโนโลยีใหม่ ๆ ตลอดเวลา
เคยทำแบ็กเอนด์ด้วย และมันก็ยากในแบบของมันเอง แต่ถ้าดูเรื่องเงินแล้ว จะเลือกแบ็กเอนด์มากกว่าฟรอนต์เอนด์
หลังจากได้ทำทั้ง design, backend และ frontend ก็เกิดแกนสองแกนในหัวคือ การยอมรับ กับ การถูกแทรกแซง
งาน design ได้รับการยอมรับมากเพราะผลลัพธ์มองเห็นได้ แต่ใคร ๆ ก็ออกความเห็นได้ง่ายว่า “ทำให้ดีกว่านี้ได้อย่างไร” และเข้ามายุ่งได้ง่าย
แบ็กเอนด์ไม่มีใครเข้ามาแทรกแซงนอกจากวิศวกรคนอื่น แต่ต่อให้ทำได้ดี มันก็ทำงานเหมือนเป็นเรื่องที่ควรเป็นอยู่แล้ว จึงยากที่จะได้รับเครดิต
ฟรอนต์เอนด์อยู่ตรงกลาง ถ้าดูดีและทำงานดี ก็ได้รับการยอมรับในระดับหนึ่ง แต่ถึงแอปจะเร็วและตอบสนองดี เครดิตราวครึ่งหนึ่งก็อาจตกไปที่ designer
ในขณะเดียวกัน ผู้คนก็จะอ้างอิงจากแอปอื่นแล้วบอกว่า “มันควรทำงานแบบนี้” และนักพัฒนาฟรอนต์เอนด์ต้องทำให้มันใช้งานได้ให้ได้ ระหว่างสิ่งที่ designer อนุมัติกับสิ่งที่แบ็กเอนด์รองรับ
พวกเขาเหนื่อยกับการต้องเถียงทั้งวันกับเพื่อนร่วมงานที่เขียนโค้ดได้แต่ไม่มีเซนส์ด้าน design และคุณสมบัติที่ทำให้เป็นวิศวกรฟรอนต์เอนด์ที่ดี ก็ยังช่วยให้ย้ายไปทำบทบาทที่มีต้นทุนทางจิตใจต่ำกว่าได้ด้วย
นักพัฒนาฟรอนต์เอนด์ไม่ได้รับมือกับเครื่องจักรที่เป็นกลาง แต่ต้องรับมือกับมนุษย์ที่มีความเห็นเชิงอัตวิสัย อีกทั้งยังต้องรับมือกับ designer และ product manager รวมถึงถูกจำกัดโดยวิศวกรแบ็กเอนด์และโครงสร้างพื้นฐาน
ต้องทำให้ใช้งานได้บนอุปกรณ์และเบราว์เซอร์ต่าง ๆ ใช้เฟรมเวิร์กที่คนอื่นเลือกไว้ และต้องไม่ทำอะไรพัง
ขอคารวะนักพัฒนาฟรอนต์เอนด์ทุกคน
ทุกอย่างมี padding ข้อความก็มี padding กล่องที่ครอบข้อความก็มี padding และแถวตารางที่บรรจุกล่องนั้นก็มี padding ใหญ่ยิ่งกว่า
ผลคือหน้าจอ 1080p ทั่วไปแสดงแถวตารางได้แค่ประมาณ 4 แถว และแต่ละแถวก็แทบไม่มีข้อมูลจริง
แถมไม่รู้ด้วยเหตุผลอะไร ขนาดตัวอักษรถูกกำหนดด้วย ความกว้างของ viewport จนแทบใช้งานไม่ได้บนจอ 4:3 รุ่นเก่า
ลองนึกถึงระบบที่ต้องประมวลผลระดับหลายพันล้านรายการต่อวัน ต่อสัปดาห์ หรือต่อเดือน ต้องจัดการ data caching และ data warehouse, การแจ้งเตือนแบบเรียลไทม์, ปริมาณงานในคิว, คำขอ API หลากหลายแบบ, การซิงก์ระหว่างระบบแบ็กเอนด์, data store หลายตัว, การขยายหลายรีเจียน, redundancy และการรับมือเมื่อแบ็กเอนด์ล่ม
ในซอฟต์แวร์เว็บที่ซับซ้อน ปัญหาแบ็กเอนด์แบบนี้เป็นเรื่องปกติ
ฟรอนต์เอนด์ที่เชื่อมกับแบ็กเอนด์นั้นโดยทั่วไปมีโอกาสน้อยกว่าที่จะเกิดปัญหากลางดึกเพราะโปรเซสอัตโนมัติของแบ็กเอนด์ หรือกังวลเรื่องจำนวนผู้ใช้และขนาดข้อมูล
ไม่ว่าการพัฒนาฟรอนต์เอนด์ช่วงแรกหรือการบำรุงรักษาตามการเปลี่ยนแปลงของเบราว์เซอร์จะยากเพียงใด เมื่อพัฒนาเสร็จแล้ว มันคือโค้ดแบบ static ที่อินเทอร์เฟซกับระบบชั้นล่างที่ซับซ้อนกว่ามาก และระบบชั้นล่างนั้นต้องการความใส่ใจอย่างต่อเนื่องทุกครั้งที่ข้อมูลและความต้องการทางธุรกิจเปลี่ยนไป
ปัญหาไม่ใช่ mobile-first เทียบกับเดสก์ท็อป แต่คือ designer ที่ยังไม่เข้าใจว่าเว็บคือ เนื้อหาแบบไดนามิก ที่ต้องไหลไปตามขนาดและรูปทรงของหน้าจอผู้ใช้
เว็บไม่ใช่สื่อ static แบบกระดาษ และไม่ได้ถูกผูกกับขนาดหรือรูปทรงเฉพาะ จึงไม่ควรถูกปฏิบัติแบบนั้น
“designer” เว็บไม่ควรพยายามยัดเนื้อหาให้พอดีกับขนาดหรือความละเอียดพิกเซลเฉพาะ และเพราะความละเอียดหน้าจอกับอัตราส่วนกว้างยาวมีความหลากหลายมาก เนื้อหาจึงต้องไหลตามสิ่งเหล่านั้นได้
สำหรับผู้ใช้ที่มีความบกพร่องทางการมองเห็นซึ่งต้องขยายฟอนต์ หากเนื้อหาแตกเละเมื่อขยายฟอนต์ การเข้าถึงก็จะแย่ลงอย่างมาก
หน้าแบบนี้ก็ต้องทำงานได้ทั้งบนมือถือและเบราว์เซอร์เดสก์ท็อป และต้องดูดีทั้งหมด ซึ่งก็ไม่ได้ยากขนาดนั้น
แค่ใช้เวลาเพิ่มขึ้นเล็กน้อย และ media query กับ JavaScript นิดหน่อยก็ทำให้เป็นไปได้
ในขณะเดียวกัน ต่อให้เป็นคนที่ทำงานนี้มานาน พื้นที่นี้ก็ยังเละเทะอยู่ดี
ช่วงนี้จึงใช้พื้นฐานด้าน design เข้าไปมีส่วนร่วมในขั้นตอนออกแบบให้มากที่สุด จากนั้นหลัง implement และ deploy แล้ว ก็รับฟีดแบ็กในทำนองว่า “บอกทุกจุดที่พังบน viewport แปลก ๆ ที่มีผู้ใช้แค่ 1% ให้หมด” แล้วแก้ในขั้น review หรือระหว่างใช้งานจริงด้วย CSS patch และ media query แยกตาม viewport
มีเหตุผลที่ความยาวบรรทัดของข้อความในหนังสือสิ่งพิมพ์ทุกเล่มโดยรวมใกล้เคียงกัน และ ความกว้างสำหรับการอ่าน ควรถูกจำกัดเสมอ
ความกว้างอาจเป็น 300px หรือ 1920px ก็ได้ อาจใช้เมาส์ อาจใช้แค่การแตะ อาจใช้ทั้งคู่ หรืออาจไม่ได้ใช้ทั้งสองอย่างเลย
เมนูแฮมเบอร์เกอร์กับไอคอนภาพสัญลักษณ์ เนี่ยนะ
เข้าใจว่าทำไมถึงใช้บนมือถือ
ถ้ามีพื้นที่แค่สำหรับคอนเทนต์ ก็สมเหตุสมผลที่จะเอาฟังก์ชันส่วนน้อยไว้เป็นไอคอนเล็ก ๆ แล้วซ่อนการทำงานที่เหลือไว้ในเมนูแฮมเบอร์เกอร์
แต่ถ้ามีพื้นที่อยู่แล้ว การใช้แบบนั้นแย่มาก
อย่างดีก็ทำให้ขั้นตอนเพิ่มขึ้น อย่างแย่ก็คือทำให้เกิดอุบัติเหตุจากการลองผิดลองถูกเพื่อหาว่าไอคอนนั้นทำอะไร
ถ้า undo ทำงานดี ๆ ก็ยังพอไหว แต่ดูเหมือนพวกเขาจะตัดสินใจแล้วว่าแม้แต่อันนั้นจะพังก็ไม่เป็นไร
บนเดสก์ท็อปควรเอาการทำงานที่ใช้บ่อยออกมานอกเมนู แล้ววางไว้ใน ปุ่มที่มีป้ายกำกับ เพื่อให้ผู้ใช้ตอบคำถาม “ทำอะไรได้บ้าง?” ได้โดยไม่ต้องเล่นซ่อนหา เหมือน Apple HIG สมัยก่อน
undo เป็นสิ่งที่มาเติมทีหลังได้ยาก จึงควรวางไว้ตั้งแต่ต้นเพื่อลดต้นทุนของการทดลอง
น่าเสียดายที่ดีไซน์มือถือครอบงำอย่างสมบูรณ์เกินไป จนแม้แอปนั้นแทบทั้งหมดจะถูกใช้บนเดสก์ท็อป และในทีมมีคนที่สนับสนุนดีไซน์เดสก์ท็อปอยู่ นักออกแบบ UI ก็ยังเลือกแฮมเบอร์เกอร์ ภาพสัญลักษณ์ และ undo ที่พัง
แถม modal ก็กลับมาอย่างดุเดือดด้วย แต่เพื่อความดันโลหิต ขอหยุดไว้แค่นี้
แม้แต่มือถือราคาถูกอายุ 5 ปีอย่าง moto e4 ก็มีหน้าจอ 1280x720 และมีพิกเซลพอให้ใส่ป้ายกำกับไอคอน
ไอคอนภาพสัญลักษณ์แทบจะเป็นดีไซน์แบบ “เราเกลียดผู้ใช้ และอยากให้ผู้ใช้รู้เรื่องนั้น”
เมนูแฮมเบอร์เกอร์เองก็มักเอาออกได้เมื่อดูจากจำนวนตัวเลือก
แอป Gmail ก็สามารถเอาไอคอนไปใส่ในแถบแนวนอนได้ แต่กลับใช้แฮมเบอร์เกอร์ และถ้าจะอ้างว่าพื้นที่สำคัญ ก็ยังใส่แถบล่างสำหรับแชต วิดีโอ และ Spaces ไว้อีก
ผมกังวลอยู่นิดหน่อยว่าผู้ใช้อาจไม่สังเกตว่ามีตัวเลือกให้เลื่อนต่อ แต่ก็ยังชอบมากกว่าเมนูแฮมเบอร์เกอร์ที่เปิดขึ้นมาแล้วทับคอนเทนต์
เพราะผู้ใช้มองเห็นตัวเลือกทั้งหมดพร้อมคำกำกับของมัน
บนเดสก์ท็อปไม่จำเป็นต้องจัดการแบบนี้
แต่ผมคิดว่าสาเหตุที่ดีไซเนอร์ชอบ เพราะมันทำให้รักษาดีไซน์ให้สอดคล้องกันข้ามหลายภาษาได้ง่าย
ตัวอย่างเช่น การแปลเป็นภาษาเยอรมันอาจจัดให้ลงตัวได้ยาก
ผมอยากเพิ่ม ตัวเลือกที่ขึ้นกับบริบทแบบซ่อนอยู่ เข้าไปด้วย
ตัวเลือกที่ปิดใช้งานเมื่อใช้ไม่ได้ หรือก็คือแสดงเป็นสีเทา อย่างน้อยก็ยังดีเพราะมันบอกความเป็นไปได้ว่าเมื่อเงื่อนไขเหมาะสมจะทำอะไรบางอย่างได้
แต่ดีไซน์สมัยใหม่กลับซ่อนตัวเลือกพวกนั้นไปเลย และถ้าไม่รู้เงื่อนไขวิเศษที่ทำให้มันปรากฏ ก็จะไม่มีวันเห็น
Unifi ของ Ubiquiti เป็นตัวอย่าง
ในหน้าจัดการพอร์ตของสวิตช์ไม่มีตัวเลือก “Select All” และต้องเลือกพอร์ตอย่างน้อยหนึ่งพอร์ตก่อน ตัวเลือกนั้นจึงจะปรากฏขึ้นมาเหมือนเวทมนตร์
ไม่เพียงแค่ถูกซ่อน แต่บริบทก็ยังผิดด้วย
ถ้ามันเป็นช่องทำเครื่องหมายที่ปิดใช้งานอยู่ ทุกคนคงสังเกตได้ทันทีว่าการให้ช่อง “Select All” ปิดใช้งานเมื่อยังไม่ได้เลือกพอร์ตใดเลยนั้นโง่อย่างเห็นได้ชัด
ถ้าบนหน้าจอมีของเยอะเกินไป พวกเขาจะตกใจได้ง่าย และคนกลุ่มนี้แหละที่ครอบงำ focus group
เลยดูเหมือนว่านักออกแบบถูกผูกมัดไว้กับกฎอันเลวร้ายข้อนี้เพียงข้อเดียว
งานวิจัยนี้ในเชิงปฏิบัติไม่สมเหตุสมผล
หน้าเหล่านั้นไม่ได้ถูกออกแบบมาเพื่อส่งข้อมูลให้ได้มากที่สุดในพื้นที่น้อยที่สุด แต่ถูกออกแบบมา เพื่อขายสินค้า
หากจะอ้างว่ามีผลเสียจากการกระจายคอนเทนต์ ต้องวัดตามวัตถุประสงค์ที่หน้านั้นถูกออกแบบมา
ในที่นี้ศึกษาหน้าอีคอมเมิร์ซ/หน้าสินค้าอย่างชัดเจน ดังนั้นตัวชี้วัดที่เกี่ยวข้องคือ หน้าใดทำให้ผู้ใช้รับรู้มูลค่าสินค้าสูงกว่า มี conversion rate สูงกว่า มี NPS สูงกว่า หรือสร้างความชอบต่อแบรนด์ได้ดีกว่า
ลำโพงพกพาไม่ได้ขายด้วยสเปก แต่ขายด้วยภาพฝันอันน่าใฝ่ฝันของการใช้งานที่ชายหาด
ถ้ากาง accordion รายละเอียดสินค้าไว้แล้วถามว่า “คุณรู้สึกว่าเข้าใจข้อเสนอที่หน้านี้สื่อได้ดีแค่ไหน?” คะแนนแบบสอบถามย่อมสูงกว่าอยู่แล้ว
ถ้าหน้าที่อัดข้อมูลแน่นกว่ากลับขายได้ดีกว่า นั่นต่างหากที่น่าประหลาดใจ
นี่เหมือนกับการออกแบบงานวิจัยว่าที่นั่งแข็ง ๆ ของรถแข่ง F1 นั้นไม่ดี แล้วติดโฟมเข้าไปเต็มที่ จากนั้นทดสอบว่าฝั่งไหนนั่งสบายกว่า ทั้งที่ตัวชี้วัดเดิมมีแค่เวลา lap time แต่กลับประกาศว่าดีกว่าเพราะคะแนนความสบายสูงกว่า
ตัวเลือกด้านดีไซน์ที่บทความวิจารณ์ไม่ได้เป็นผลจาก mobile-first design
จริง ๆ แล้วเว็บไซต์ช่วงปลายยุค 2000 ก่อน responsive design จะแพร่หลาย ก็หน้าตาเป็นแบบนั้นอยู่แล้ว
เช่น Apple: https://www.versionmuseum.com/history-of/apple-website
โดยพื้นฐานแล้วมันกำลังเปรียบเทียบความหนาแน่นของข้อมูลของใบปลิวการตลาดหรือป้ายโฆษณา แล้วบอกว่ามันสื่อทุกอย่างไม่ได้ ซึ่งนั่นแหละคือจุดประสงค์
โฆษณาไม่ใช่ตารางสเปก แต่มีไว้กระตุ้นให้ผู้ชมอยากได้สินค้า
แต่สำหรับผม มันกลับอาจเป็นสัญญาณแรง ๆ ของ คำโฆษณาไร้สาระคุณภาพต่ำ
เว็บไซต์จำนวนมากเปลี่ยน UI ไปโดยสิ้นเชิงเมื่อปรับขนาดหน้าต่าง
บางครั้งผมอยากให้เบราว์เซอร์กินพื้นที่แค่ครึ่งจอ แล้ววางอย่างอื่นไว้ข้าง ๆ แต่ในเว็บไซต์สมัยใหม่ เมื่อย่อขนาดหน้าต่าง UI มักใช้การไม่ได้ จึงล้มเหลวบ่อย ๆ
ถ้าทำดี ๆ ก็ยอดเยี่ยม แต่ก็จริงที่หลายเว็บไซต์ทำงานก้าวร้าวเกินไป ราวกับทดสอบจริงแค่สองช่วงขนาด
หมายความว่าเมื่อย่อมุมมองแล้วจะเข้าถึงฟังก์ชันและคอนเทนต์ไม่ได้อีกหรือเปล่า
ผมเกลียดเว็บไซต์ที่เอาคอนเทนต์ที่มีประโยชน์ไปใส่ไว้ในคอลัมน์แคบ ๆ ตรงกลาง
ที่แย่กว่านั้นคือเว็บไซต์ที่เมื่อก่อนปกติดีก็ค่อย ๆ พังลง
โดยปกติมักเกิดขึ้นเมื่อมีผู้จัดการคนใหม่เข้ามา แล้วบอกว่าจะ “จินตนาการใหม่” ผลิตภัณฑ์ด้วยวิสัยทัศน์ “mobile-first”
Patreon เมื่อไม่นานนี้เป็นตัวอย่างที่ดี
และในบางกรณี เว็บไซต์ที่ปกติดีก็หายไปเลย แล้วถูกแทนที่ด้วย crapp อย่าง Venmo, Amazon Alexa, Chamberlain
สิ่งที่รู้สึกขัดจริง ๆ คือไม่มีทางเลือกแบบสัมผัสที่ดีพอสำหรับ hover
มันเป็นองค์ประกอบ UX ที่มีประโยชน์เกินกว่าจะทิ้งไปเมื่อย้ายไปสู่ mobile-first
นอกเหนือจากนั้นก็ใกล้เคียงกับฝั่งที่ว่า “ไม่ได้ยากขนาดนั้น”
ในบรรดาปัญหาที่ต้องแก้ การทำให้มันดูเข้าท่าในหลายขนาดหน้าจอถือว่าอยู่ค่อนข้างท้าย ๆ ทั้งในแง่เวลาและความซับซ้อน
อย่างน้อยผมก็ใช้แบบนั้นตอนดูข้อความแทนรูปภาพใน Firefox บนมือถือ
การตรวจจับ hover จริง ๆ คงทำได้ แต่ถ้าไม่ได้ใช้สไตลัส UX น่าจะไม่ค่อยดี
ในฐานะเว็บดีไซเนอร์ ผมไม่ค่อยเห็นด้วยอยู่บ้าง
ตัวอย่างที่ยกมาในบทความทำงานได้ดีกว่ากับคอนเทนต์ที่เรียบง่ายต่อหนึ่งหน้าจอ
มองภาพรวมได้ง่ายกว่า และเวอร์ชันแบบอัดแน่นมีเลย์เอาต์หลายคอลัมน์จำนวนมาก ซึ่งส่วนตัวผมไม่ชอบ
ความหนาแน่นของคอนเทนต์สูงเหมาะกับแอปพลิเคชันเดสก์ท็อป แต่ไม่เหมาะกับเว็บไซต์ที่โดยพื้นฐานแล้วเป็น เว็บไซต์โบรชัวร์
ดีตรงที่ไม่ใช่แค่ความรู้สึกของใครบางคน
ยากที่จะเชื่อว่าหน้า marketing ที่ผ่านวิวัฒนาการและการทดสอบมาหลายสิบปี จะยังไปไม่ถึงสิ่งที่ผู้ใช้ต้องการจริง ๆ ไม่ใช่สิ่งที่ผู้ใช้บอกว่าต้องการ
สำหรับคนที่เติบโตมากับอินเทอร์เน็ต การสกรอลล์เป็นพฤติกรรมที่เป็นธรรมชาติมาก
การใช้จอใหญ่เพื่อเปรียบเทียบด้วยสายตาก็มีประโยชน์ แต่ตัวอย่างในบทความไม่ดี
เขาบอกว่า “จัดข้อมูลเดียวกันเป็นกริด 2x2 เพื่อให้เปรียบเทียบบริการหลายอย่างพร้อมกันได้” แต่ผมไม่รู้ว่ามีอะไรให้เปรียบเทียบ
มันเป็นบริการคนละแบบกัน
ผมชอบตัวอย่างสเปกผลิตภัณฑ์ แต่นั่นใกล้เคียงกับ ปัญหาการใช้งานเชิงวัตถุวิสัย ที่บังคับให้ต้องคลิกมากขึ้นเพื่อดูข้อมูลมากขึ้น
ต้องสังเกตว่าสกรีนช็อตถูก “ย่อขนาด” จึงทำให้การจัดหลายคอลัมน์ดูมีเนื้อหาแน่นและดึงดูดทางสายตามากกว่า
ผมเห็นด้วยเต็มที่กับการใช้พื้นที่แนวนอน แต่สิ่งที่เราเรียนรู้เกี่ยวกับ ปุ่มกระตุ้นให้ทำการกระทำ นำไปสู่การออกแบบแบบองค์ประกอบเดี่ยว
สิ่งที่น่าหงุดหงิดกว่าเว็บไซต์โบรชัวร์หรือเว็บไซต์อีคอมเมิร์ซ คือ ดีไซน์แบบ mobile-first ของไซต์ด้าน productivity และอินเทอร์เฟซเครื่องมือ
ปกติแล้วใครกันที่เข้าใช้เครื่องมือพวกนี้จากโทรศัพท์มือถือ
แค่ต้องพิมพ์ชื่อและที่อยู่ของนายจ้างเก่าและที่พักอาศัยเก่าด้วยคีย์บอร์ดมือถือก็ทรมานแล้ว แต่การกรอกวันที่ยิ่งแย่กว่า
date picker เริ่มจากเดือนและปีปัจจุบัน แล้วเลื่อนได้ทีละเดือนเท่านั้น ดังนั้นถ้าจะกรอกวันเกิดต้องแตะประมาณ 550 ครั้ง
ผมก็อยากร้องเรียนต่อ EEOC เพราะมันส่งผลกระทบอย่างไม่สมส่วนต่อแรงงานสูงอายุซึ่งเป็นกลุ่มที่ได้รับการคุ้มครอง แต่คงไม่ใช่วิธีที่ดีในการแนะนำตัวกับ HR ของนายจ้างใหม่
ในทางปฏิบัติมันจะเหมือนมุมมองหน้าจอเล็ก และนี่เป็น ข้อกำหนดของ WCAG