แถบเลื่อนกำลังกลายเป็นปัญหา

 (artemis.sh)
2 คะแนน โดย GN⁺ 2023-10-14 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แถบเลื่อนค่อย ๆ เล็กลงหรือถูกซ่อนไว้ จนกลายเป็นปัญหาด้านการใช้งานจริง ไม่เฉพาะกับผู้ใช้ที่ใช้ล้อเลื่อนหรือท่าทางสัมผัสได้ยากเท่านั้น แต่รวมถึงผู้ใช้ที่ต้องการย้ายตำแหน่งอย่างรวดเร็วภายในเอกสารด้วย
  • ผู้ใช้ที่ควบคุมการเคลื่อนไหวละเอียดได้ยาก หรือใช้เครื่องมือชี้ตำแหน่งที่มีความแม่นยำจำกัดอย่าง eye tracker มักเล็งแถบเลื่อนกว้าง 8 พิกเซลได้ยาก และผู้ใช้ที่ควบคุมด้วยเสียงก็อาจอยากคลิกไปยังตำแหน่งที่ต้องการโดยตรง แทนการเลื่อนซ้ำ ๆ
  • แม้ใน GTK, Qt, Firefox, Chrome และ Electron จะพอปรับความกว้างหรือรูปแบบการแสดงแถบเลื่อนได้ แต่ก็ต้องพึ่งวิธีที่ผู้ใช้ทั่วไปเข้าถึงยาก เช่น แก้ CSS, gsettings, about:config, คอมไพล์ธีมใหม่ หรือการตั้งค่าแยกเป็นรายแอป
  • ในอดีตเคยมี ปุ่มเลื่อน ที่กดค้างแล้วค่อย ๆ ขยับได้ แต่ค่อย ๆ หายไปอย่างเงียบ ๆ ส่วนปุ่มลูกศรบนคีย์บอร์ดแม้จะทดแทนได้บางส่วน แต่การทำงานก็เปลี่ยนไปตามสถานะโฟกัส
  • UI อย่างมินิแมปของเอกสาร ที่ให้เห็นเนื้อหาและย้ายตำแหน่งได้ด้วยพื้นที่คลิกขนาดใหญ่ อาจเป็น วิธีนำทางทางเลือก ที่มีประโยชน์กับผู้ใช้ eye tracker และปากกาแท็บเล็ตด้วย

แถบเลื่อนที่เล็กลงและถูกซ่อน

  • แถบเลื่อนเป็น UI พื้นฐานสำหรับคลิกและลากเพื่อเปลี่ยนตำแหน่งปัจจุบันภายในพื้นที่ที่เลื่อนได้
  • ช่วงหลังแถบเลื่อนมีขนาดเล็กลงมากจนแทบจับภาพหน้าจอให้เห็นยังยาก และแนวโน้มที่จะทำให้เล็กลงหรือซ่อนมันยิ่งทำลายการใช้งาน
  • แนวคิดแบบ “ใช้ล้อเลื่อนก็ได้” ตั้งอยู่บนสมมติฐานว่าผู้ใช้ทุกคนใช้ล้อเลื่อนหรือปัดหน้าจอสัมผัสได้
  • แม้แต่ผู้ใช้ที่ใช้ล้อเลื่อนได้คล่อง บางครั้งก็อาจอยาก กระโดดไปยังตำแหน่งหนึ่งอย่างรวดเร็ว

ผลกระทบต่อการเข้าถึง

  • ผู้ใช้ที่มีปัญหาในการควบคุมการเคลื่อนไหวละเอียด มักจับแถบเลื่อนที่บางมากได้ไม่แม่น
  • อุปกรณ์ชี้ตำแหน่งอย่าง eye tracker แม้น่าประทับใจ แต่ก็ยังไม่พอสำหรับการเล็งแถบเลื่อนกว้าง 8 พิกเซลอย่างเสถียร
  • ผู้ใช้ที่ควบคุมคอมพิวเตอร์ด้วยเสียงหรือเสียงพูด แม้จะใช้เครื่องมืออย่าง Talon Voice ก็อาจชอบการมองแถบเลื่อนแล้วคลิกไปยังจุดที่ต้องการ มากกว่าการพูด scroll down ซ้ำ ๆ หรือใช้การเลื่อนอัตโนมัติ
  • ย้อนกลับไปในปี 2015 ก็มีการพูดถึง ปัญหาความกว้างของแถบเลื่อนใน GTK3 แล้ว โดยแถบเลื่อนที่บางสร้างภาระให้ทั้งผู้ใช้ที่ไม่เชี่ยวชาญเทคนิค และผู้ใช้ที่มีปัญหาด้านการใช้มือหรือการมองเห็น

วิธีที่ทำให้แถบเลื่อนใช้งานยากลง

  • ในบางกรณี ความกว้างของแถบเลื่อนยังเท่าเดิมเมื่อวัดเป็นพิกเซล แต่เมื่อความละเอียดหน้าจอสูงขึ้น เป้าหมายในการคลิกจริงกลับเล็กลง
  • ในกรณีอื่น แถบเลื่อนเองก็เล็กลงจริง ๆ
  • ยังมีการยกตัวอย่างแถบเลื่อนที่บางมากที่ Ubuntu เคยทดลองใช้ในอดีต
  • ระหว่างที่แถบเลื่อนเล็กลง ปุ่มเลื่อน ที่กดค้างเพื่อขยับทีละน้อยก็หายไปด้วย
    • ปุ่มลูกศรบนคีย์บอร์ดทดแทนได้บางส่วน แต่ขึ้นอยู่กับว่าขณะนั้นโฟกัสอยู่ที่เนื้อหาใด
    • ส่วนปุ่มเลื่อนใช้งานได้โดยไม่ขึ้นกับสถานะโฟกัส
  • โดยรวมแล้วแถบเลื่อนใช้งานได้น้อยลง และการตั้งค่าสำหรับแก้ไขปัญหานี้ก็มักไม่มี หรือถูกซ่อนไว้ในสแตกเทคนิคที่ผู้ใช้ทั่วไปหาไม่เจอ

อุปสรรคของการตั้งค่า GTK

  • ใน GTK2 สามารถเปลี่ยนความกว้างของแถบเลื่อนได้โดยตรงใน gtkrc และยังมีโปรแกรม GUI สำหรับเรื่องนี้ด้วย
  • ใน GTK3 ต้องปรับผ่าน CSS และหากไม่เข้าใจธีมก็แทบไม่มีวิธีตั้งค่าที่เป็นมิตรกับผู้ใช้
  • ในเธรด Reddit มีการแนะนำสคริปต์ที่เพิ่ม slider { min-width: ...; min-height: ...; } ลงใน gtk.css ของ GTK3·GTK4 พร้อมจัดการทั้ง Flatpak override และการตั้งค่า overlay scrolling
  • แอป Flatpak ต้องมี override แยกต่างหาก ทำให้ธีมของระบบอาจไม่ถูกนำไปใช้ตรง ๆ
  • GTK ยังใช้วิธีซ่อนแถบเลื่อนตามค่าเริ่มต้น แล้วจะแสดงเมื่อเอาเมาส์ไปวางที่ตำแหน่งนั้น
    • ใน GTK3 สามารถตั้งให้แสดงตลอดได้ด้วยคำสั่งต่อไปนี้ gsettings set org.gnome.desktop.interface overlay-scrolling false
    • ค้นหาได้ใน Dconf Editor เช่นกัน แต่ต้องรู้ตำแหน่งของค่าดังกล่าว
  • มีการอ้างถึง เธรดใน GNOME Bugzilla ที่ระบุว่าใน GTK4 ไม่สามารถตั้งค่านี้แบบทั้งระบบได้
    • ในการอภิปราย มีการชี้ว่าการต้องไปร้องขอตัวเลือก non-overlay scrollbar เป็นรายแอปนั้นเป็นปัญหา

อุปสรรคของการตั้งค่า Qt

  • ความกว้างของแถบเลื่อนใน Qt ถูกกำหนดโดย ปลั๊กอินสไตล์วิดเจ็ตของ Qt ที่ใช้งานอยู่
  • /u/cfeck_kde อธิบายใน คำตอบบน r/kde ว่าตามที่ทราบ มีเพียงสไตล์ Skulpture ที่ยอมให้ตั้งค่าขนาดได้ ส่วนสไตล์อื่นอย่าง Breeze ต้องแก้ซอร์สโค้ด C++ แล้วคอมไพล์ใหม่
  • ปลั๊กอินสไตล์ของ Qt เป็นโค้ดจริง จึงควบคุมได้ทรงพลัง แต่ผู้ใช้ก็ต้องไปหาให้เจอว่าปลั๊กอินใดมีตัวเลือกที่ต้องการ
  • Kvantum แม้จะหาการตั้งค่าความกว้างของแถบเลื่อนได้ยาก แต่สามารถปิดฟังก์ชันทำให้แถบเลื่อนหายไปอย่าง “Transient scrollbars” ได้
  • Skulpture ดูเป็นตัวเลือกที่น่าลอง แต่ยังยืนยันไม่ได้ว่าจะตั้งค่าผ่าน GUI ได้อย่างไรหากไม่มี KDE Plasma
  • หากต้องพึ่งเอนจินธีมเพียงตัวเดียว ก็ยังมีความกังวลว่าจะถูกรักษาต่อเนื่องหรือไม่ระหว่างที่การพัฒนา Qt ดำเนินต่อไป

สถานการณ์ของ Firefox, Chrome และ Electron

  • Firefox เองก็ใช้แถบเลื่อนที่เล็กมาก แต่ตอนนี้ยังปรับได้ผ่าน about:config
    • พิมพ์ about:config ในแถบที่อยู่
    • แก้ widget.non-native-theme.scrollbar.size.override เป็นตัวเลขที่ต้องการ
    • ปรับ widget.non-native-theme.scrollbar.style เพื่อเปลี่ยนรูปลักษณ์ได้
    • ค่า 4 จะตั้งเป็นรูปทรงสี่เหลี่ยมหนา
    • ในหน้าตั้งค่าทั่วไป about:preferences สามารถเปิด “Always show scrollbars” ได้
  • ตัวอย่างเช่น สามารถตั้งขนาดแถบเลื่อนของ Firefox เป็น 50 ได้ และถึงแม้จะไม่ได้อยากใช้ใหญ่ขนาดนั้นจริง ๆ แต่ข้อดีก็คือมันทำให้ใหญ่ได้
  • บทความ การตั้งค่าแถบเลื่อนของ Firefox เพิ่มเติม โดย Athena Lilith Martin ยังพูดถึงการปรับปรุงเพิ่มเติม เช่น ปิดการ override CSS ของหน้าเว็บ
  • Chrome ถูกมองว่าไม่น่าหวังว่าจะมีตัวเลือกที่มีประโยชน์
  • แอป Electron ก็ปรับตั้งค่าได้ยาก และแม้อาจแก้ด้วยการฉีด custom CSS ได้ ก็ยังไม่มีคำตอบที่ชัดเจน

วิธีนำทางที่ดีกว่า: มินิแมป

  • มินิแมปช่วยให้มองเห็นเนื้อหา คลิกที่เนื้อหา และย้ายไปยังตำแหน่งของเนื้อหาที่คลิกได้
  • เป้าหมายในการคลิกมีขนาดใหญ่มาก จึงมีประโยชน์กับผู้ใช้ eye tracker และผู้ใช้ปากกาแท็บเล็ตด้วย
  • “หลักการออกแบบสมัยใหม่” แบบทั่วไปกำลังส่งผลเสียต่อทั้งแถบเลื่อนและผู้คนที่ใช้งานคอมพิวเตอร์ในวิธีที่หลากหลาย

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-10-14
ความคิดเห็นใน Hacker News

  • ไม่ใช่ปัญหาเฉพาะแถบเลื่อนเท่านั้น เพราะการ เอาขอบหน้าต่างออก ทำให้แยกไม่ออกจากหน้าต่างพื้นหลังที่มีสีคล้ายกัน และแทบเป็นไปไม่ได้ที่จะจับขอบเพื่อปรับขนาดหน้าต่าง
    แถบชื่อหน้าต่างถูกยัดทั้งช่องค้นหาและปุ่มไม่จำเป็นเต็มไปหมด จนแทบไม่มีที่ให้จับเพื่อย้ายหน้าต่าง และการกด Tab ย้ายระหว่างกล่องข้อความก็ไม่ทำงานอย่างที่คาด หรือไม่ทำงานเลย
    tooltip ขัดขวางและทำให้อินเทอร์เฟซรก หลายครั้งยังบังสิ่งที่อยากดู และ 95% เป็นข้อมูลซ้ำซ้อนหรือไร้ประโยชน์
    ตลอด 10 ปีที่ผ่านมา UI/UX แบบ cargo cult ได้ทิ้งหลักการด้านการใช้งานที่สั่งสมมาหลายทศวรรษ แล้วสร้างผลลัพธ์ที่ดูดีอย่างเดียว แต่ใช้งานไม่ได้จริงสำหรับคนจำนวนมาก
    แอปอย่าง Postman, Teams, แอป Microsoft ส่วนใหญ่ในปัจจุบัน, Chrome, Insomnia ควรถูกใช้เป็นตัวอย่างว่าไม่ควรทำ UI ของซอฟต์แวร์เดสก์ท็อปอย่างไร
    ความผิดที่ใหญ่กว่านั้นคือ ถ้าองค์ประกอบเหล่านี้ถูกตั้งค่าได้ในระดับระบบหน้าต่าง และนักพัฒนาแอปไม่สามารถ override ได้ ก็คงไม่เป็นปัญหา แต่ Windows และ Gnome/GTK กลับกำลังเดินไปในทางลบตัวเลือกเดิม ๆ ออก

    • ผมคิดว่าคำว่า “คนโง่” นั้นเหมาะแล้ว ไม่ได้อยากด่าคนทำงานโดยไม่จำเป็น แต่ตอนนี้ถ้าจะย้ายหน้าต่าง ก็ต้องคลิกมั่วไปทั่วเหมือนคนโง่เพื่อดูว่าตรงไหนคือแถบชื่อหน้าต่าง ตรงไหนคือปุ่ม
      ทุกครั้งที่เริ่ม “New Teams” มันจะถามว่าจะกลับไปใช้ Old Teams ไหม และถ้าเปิด PDF ด้วย New Teams จาก File Explorer ก็ไม่ชัดเจนว่าจะปิด PDF อย่างไรโดยไม่เสียตำแหน่งในระบบไฟล์
      แถมทุกอย่างยังช้าอย่างน่ากลัว มีคนจำนวนไม่น้อยที่ทำงานใน Microsoft/Apple/Google ที่ทำงานของตัวเองไม่เป็น และควรรู้สึกอับอายกับเรื่องนั้น
    • รู้สึกว่า Windows XP คือจุดสูงสุดของอินเทอร์เฟซที่ใช้งานได้ และควรหยุดอยู่ตรงนั้น แน่นอน อาจเป็นแค่เพราะผมแก่แล้วและกำลังตะโกนไล่เด็ก ๆ ออกจากสนามหญ้าก็ได้
      สำหรับ Windows ผมมั่นใจว่าเป็นแบบนั้น และมองว่า Windows ทุกรุ่นหลังจากนั้นทำให้ประสบการณ์ผู้ใช้แย่ลง
    • ผมคิดว่าไม่จำเป็นต้องใช้คำดูหมิ่น เหตุผลที่ชอบ HN ก็เพราะเป็นหนึ่งในไม่กี่ที่ที่ การถกเถียงอย่างสุภาพ มาก่อนน้ำเสียงเกลียดชังแบบแพลตฟอร์มอื่น
      โดยพื้นฐานแล้วผมเห็นด้วยว่าการใช้งานสำคัญกว่าสุนทรียะ แต่ไม่แน่ใจว่า “คนโง่ UI/UX แบบ cargo cult” หมายถึงใครกันแน่
      จากมุมมองคนที่ทำงานเป็นผู้นำด้าน UX/UI มากว่า 20 ปี ตัวการหลักที่ทำลายการใช้งานมักเป็น ผู้นำธุรกิจและนักการตลาด มากกว่านักออกแบบ
      แน่นอนว่ามีนักออกแบบที่คิดว่ารูปลักษณ์สำคัญกว่าฟังก์ชันและผลักดันแถบเลื่อนขนาดเล็ก แต่เมื่ออธิบายปัญหาให้ฟัง พวกเขามักยอมถอยและทำดีไซน์ที่ใช้งานได้
      ระดับ C-level ผู้นำการตลาด และผู้จัดการนั้นอันตรายกว่า เพราะไม่รู้เรื่อง UI แต่มีความเห็นแรง เช่น “แถบเลื่อนเว็บนี้ดี”, “ดีไซน์ดูไม่ทันสมัย”
      การต่อสู้เพื่อรักษาการใช้งานและการเข้าถึงเป็นเรื่องเจ็บปวดมาก และบางตำแหน่งควรทำตัวเป็นมืออาชีพกว่านี้และเชื่อใจผู้เชี่ยวชาญ ส่วนดีไซเนอร์เองก็ควรคิดถึงการใช้งานก่อนเช่นกัน
    • ปัญหาที่ใหญ่กว่าคือ ตอนนี้แทบไม่มีความพยายามจะทำ การจัดโครงสร้างข้อมูล เลย
      เมนูตั้งค่าเป็นฝันร้ายที่มีรายการซ้อนทับรายการ โครงสร้างเมนูของแต่ละแอปสุ่มไปหมด และบ่อยครั้งแม้แต่สิ่งที่ควรตั้งค่าได้ในเครื่องก็ยังส่งไปเป็นลิงก์เว็บภายนอก
      มันยากมากที่จะเข้าใจเจตนาของนักออกแบบ และแยกไม่ออกว่าผมหาการตั้งค่าไม่เจอเอง หรือมันถูกทำให้ไม่มีอยู่ในเมนูนี้ตั้งแต่แรก
      มีหลายครั้งเกินไปที่ต้องค้น Google เพียงเพื่อเปลี่ยนค่าพื้นฐาน และแม้แต่ในเกมที่ประสบการณ์เป็นครึ่งหนึ่งของมูลค่าผลิตภัณฑ์ก็ยังเป็นแบบเดียวกัน
      เมนูตั้งค่าของ CS2 มีปุ่มข้อความด้านบนที่ดูเหมือนแท็บ แต่จริง ๆ แล้วแค่เลื่อนไปยังจุดสุ่มในรายการตั้งค่ายาว ๆ ทำให้แยกในหัวได้ยากว่าแต่ละปุ่มหมายถึงอะไร
      ความหมายของแนวคิดต่าง ๆ ไม่ได้เชื่อมโยงกัน และไม่ได้ถูกจัดโครงสร้าง ทำให้การสำรวจคอมพิวติ้งยากเกินจำเป็นมาก
      ผมคิดถึง UI ของ Macromedia Flash แม้จะไม่ได้ใช้เยอะ แต่มันเรียบง่ายและใช้งานง่ายจริง ๆ
      หนึ่งในแรงจูงใจใหญ่ที่ทำให้หันไปหาความเป็นส่วนตัวและโซลูชันที่ทำเอง ก็เพราะอยากหนีจาก การปนเปื้อนของประสบการณ์และความรู้ ที่เห็นในทุกวันนี้
    • นั่นแหละคือเหตุผลที่เคยมี กล่องปรับขนาด อยู่ จริง ๆ แล้วขอบที่ลากได้ซึ่งไม่มีเนื้อที่ชัดเจน ทำให้เราเอาหน้าที่มากเกินไปไปวางบนองค์ประกอบ 1 พิกเซล จนเกิดการชนกันของบทบาท
      กล่องปรับขนาดแบบเก่าเคยเป็นมือจับเฉพาะสำหรับปรับขนาดหน้าต่าง อยู่ที่ด้านล่างสุดของแถบเลื่อนแนวตั้ง ใต้ปุ่มลูกศรลงพอดี
      มันอยู่ใกล้ปุ่มเลื่อนสำหรับดูเนื้อหาที่ไม่ปรากฏในหน้าจอแรก จึงเป็นเหมือนจุดเริ่มต้นและจุดอ้างอิงที่เป็นธรรมชาติสำหรับการโต้ตอบกับ viewport
      น่าขันที่ใน UI ของแอปส่วนใหญ่สิ่งนี้หายไปแล้ว แต่เว็บเบราว์เซอร์ยัง render มันในองค์ประกอบอย่าง textarea ที่เปิดทั้งแถบเลื่อนและ resize อยู่บ้าง เพียงแต่ UI ส่วนใหญ่ไม่มีปุ่มเลื่อนที่เกี่ยวข้องอีกต่อไป

  • เมื่อเร็ว ๆ นี้มีเรื่องตลกที่เพิ่งตระหนักได้ ไม่ใช่ว่าสายตาฉันแย่ลง แต่เป็นเพราะ UI แย่ลงต่างหาก
    สกรอลล์บาร์ tiny ที่คอนทราสต์ต่ำจนน่าขันนั้นไม่สามารถเข้าถึงได้สำหรับใครเลย
    ช่วงนี้เริ่มใช้ KDE กับธีม Oxygen แล้วรู้สึกดีใจ เพราะใช้งานได้สบายตาไม่เมื่อยล้า
    สกรอลล์บาร์แบบนี้เป็นของน่าสมเพชที่แทบไม่มีช่องให้ปรับแต่ง และถ้าจะใส่ธีมให้แอปที่ถูกล็อกไว้ก็ต้องขอให้โชคดี
    มันชัดเจนเกินไปว่า UI designer ไม่สนใจความต้องการของผู้ใช้ และในโลก FOSS ก็ไม่ได้เป็นข้อยกเว้น
    เป็นเรื่องน่าเศร้าที่เราถอยหลังจากยุคที่มีซอฟต์แวร์ที่ดูดี ใช้งานได้จริง เข้าถึงได้ และรวดเร็ว ไปสู่ ขยะ Electron ที่ถูกล็อกและใส่ธีมไม่ได้
    ถ้า UI มีคอนทราสต์และความอ่านง่ายเพียงพอ สิ่งอย่าง “dark mode” ก็คงไม่จำเป็นด้วยซ้ำ

    • ไม่ได้ใช้ dark mode เพราะเรื่องคอนทราสต์ แต่เพราะ light mode ของซอฟต์แวร์จำนวนมากมันเป็นสีขาวล้วนเฉย ๆ หน้าจอก็สว่างขึ้นและแรงขึ้นเรื่อย ๆ
      เวลาใช้ซอฟต์แวร์ที่ไม่มี white mode บ่อยครั้งมันสว่างจนผนังใกล้ ๆ เหมือนเปิดไฟฉายส่อง
      พอลดความสว่างหน้าจอลง สีและคอนทราสต์ก็เละเทะจนยังมองอะไรไม่เห็นอยู่ดี
      คิดถึงอินเทอร์เฟซสีเทายุค Win 9x ถึงมันจะไม่สวย แต่จริง ๆ แล้วมองเห็นได้
    • คอนทราสต์ก็เป็นปัจจัยหนึ่ง แต่ กระแส flat UI ได้ขับสีเทากลางและเทาอ่อนออกไป แล้วดันสีขาวจั๊วะกับสีเกือบขาวเข้ามา ทำให้ light mode แสบตากว่าเดิมมาก
      หลังจาก flat UI ที่แสบตาครองโลก ก็ไม่แปลกเลยที่ผู้คนจะเรียกร้อง dark mode
    • อยากให้โลกดิจิทัลมี การควบคุมแบบแอนะล็อก มากขึ้น อยากให้มีปุ่มหมุนแทนปุ่มขึ้น/ลง 10 ระดับ
      การควบคุมด้วยมือแบบดิจิทัลที่ออกจากเมนูได้ง่าย แล้วพอจะกลับเข้าไปกลับไปปรับอย่างอื่นแทน แบบนี้มันดิจิทัลเกินไปและยุ่งยากเกินไปแล้ว
      เมื่อก่อนเราปรับคอนทราสต์และความสว่างของจอ, โวลุ่มแอมป์, ทีวีแอนะล็อก, เทอร์โมสตัท, วิทยุรถยนต์ ฯลฯ ได้ง่าย
      ตอนนี้ยังไม่ได้มีกระแสเอาการควบคุมแอนะล็อกจำนวนมากกลับมา แต่สุดท้ายแล้วโลกของเราก็เป็นแอนะล็อก อินพุตเป็นแอนะล็อก เช่น คำพูด การเคลื่อนไหวของกล้ามเนื้อ และเอาต์พุตก็เป็นแอนะล็อกที่สัมผัสประสาทสัมผัส เช่น แสงและการสั่น
      ไม่รู้เหมือนกันว่าทำไมการควบคุมถึงไม่เป็นแอนะล็อกมากกว่านี้ อาจเป็นเพราะต้นทุน
      ถ้ามีจอหรือแล็ปท็อปที่มีคอนโทรลแบบแอนะล็อก ฉันคงซื้อทันที ต่อให้จริง ๆ เป็นไดอัล 16 ล้านระดับก็พอแล้ว ถ้าตอบสนองทันทีและรู้สึกเหมือนตัวต้านทานปรับค่าได้จริง
      อยากให้มีปุ่มหมุนที่ช่วยเปลี่ยนความเข้มได้เร็วตามสถานการณ์ หรือวนอ่านตัวเลือกให้ดูง่ายฟังง่ายขึ้น
      ทุกวันนี้ 90% ของงานที่ทำเกิดขึ้นในเบราว์เซอร์ ดังนั้นถ้าเบราว์เซอร์มี accessibility API ให้ควบคุมด้วยปุ่มหมุน ไม่ว่าจะผ่าน Bluetooth หรืออะไรก็ตาม ก็คงดี เหมือนเป็นเวอร์ชันเสริมพลังของล้อเลื่อนเมาส์
    • โดยเฉพาะกระแส “don’t theme my app” ที่เพิ่งออกมาใหม่นั้นน่าเสียดาย ปัญหา CSS stylesheet ของ GTK ควรแก้ด้วยการแทนที่ CSS ด้วยวิธีเขียนสไตล์ที่ดีกว่า ไม่ใช่โยนทิ้งทั้งหมดแล้วห้ามผู้ใช้ใช้ธีมของตัวเอง
    • ผมมองว่าประมาณ 20 ปีก่อน ใน ยุค Windows 2000 usability ไปถึงจุดสูงสุดแล้ว ภาพหน้าจอในบทความก็ดูเหมือน OS X 10.x รุ่นแรก ๆ แถว ๆ ยุคนั้น น่าจะราว 10.3

  • มักเจอเว็บไซต์ที่มี popover แบบเลื่อนได้หรือเฟรมภายในแปลก ๆ อยู่บ่อย ๆ แต่สกรอลล์บาร์ของเฟรมภายในขนาดเล็กถูกซ่อนไว้ ทำให้ไม่รู้ว่ามีเนื้อหาเพิ่มหรือเปล่า และทำให้คิดว่าไซต์พังไปหมดแล้ว
    มันน่าโมโหมาก และก็อดโทษ iOS กับ macOS ที่ส่งเสริมและทำให้ความบ้าคลั่งนี้ฮิตขึ้นมาไม่ได้ ฝ่ายที่ผลักดันกระแส UI “flat” ซึ่งทำให้เดายากว่าอะไรเป็นอะไรก็มีส่วนรับผิดชอบทางอ้อมด้วย
    UI คือการสื่อสาร แต่ UI designer กลับตัดสินใจว่าการพูดงึมงำนั้นเท่

    • ในบริบทของ iPhone ดั้งเดิม การซ่อนสกรอลล์บาร์ตอนที่ไม่ได้กำลังเลื่อนอยู่ยังพอมีเหตุผลอยู่บ้าง หน้าจอมีขนาด 3.5 นิ้ว และถ้าตั้งเป้าจะแสดงเนื้อหาระดับเดสก์ท็อป ก็ไม่มีพื้นที่ให้สกรอลล์บาร์มากนัก อีกทั้งคนส่วนใหญ่คงไม่โต้ตอบกับตัวสกรอลล์บาร์เอง
      ในทางกลับกัน บนระบบปฏิบัติการเดสก์ท็อป แม้แต่หน้าจอที่เล็กที่สุดที่ใช้งานกันก็ยังใหญ่กว่ามาก จึงแทบไม่มีเหตุผลดี ๆ ที่จะซ่อนสกรอลล์บาร์
    • หากจะเสี่ยงพากระทู้บ่นนี้ออกนอกเรื่องไปในทางที่ยิ่งจุดไฟเพิ่มขึ้น ก็อาจเป็นการเลียนแบบ ภาพยนตร์และทีวี สมัยนี้
      ต่อให้เด็ก ๆ เงียบ หลับ หรือไปโรงเรียนอยู่แล้ว หนังและซีรีส์จำนวนมากในยุคนี้ก็ดูยากถ้าไม่มีซับไตเติล
    • ผมไม่เข้าใจด้วยซ้ำว่า flat UI แบบนี้กลายเป็นกระแสได้อย่างไร

  • ต้องชม Firefox อีกครั้งที่ให้เครื่องมือปิดสิ่งแบบนี้ได้ใน about:config ถ้ามองในแง่ดีก็เป็นแค่ของตกแต่งน่ารัก ๆ แต่ถ้ามองแย่ก็ทั้งน่ารำคาญและชวนให้ถูกใช้ในทางที่ผิด
    UI ของเบราว์เซอร์ควรถูกกันออกจากพื้นที่ที่เว็บไซต์เปลี่ยนแปลงได้แทบทั้งหมด และ สกรอลล์บาร์ ก็ควรรวมอยู่ในนั้นด้วย

    • ในทางกลับกัน Chrome ทำให้หัวเราะลั่นตรงจุดที่ว่า “ลองจินตนาการดูว่า Chrome จะให้ตั้งค่าสิ่งที่มีประโยชน์ได้”
      บทความทั้งหมดเขียนได้ดีมาก และขอชื่นชมผู้เขียน
      ผมเองก็ย้ายกลับไปใช้ Firefox เพราะ Edge เอาแต่ยัดเยียดการค้นหา Bing กับฟีเจอร์อื่น ๆ แถม prompt กู้คืนแท็บก็ชวนรำคาญเกินไป อยากให้มันหุบปากแล้วหยุดเสียที
    • ยังจำได้ชัดมากว่าตอนต้นยุค 2000 เคยยืนกรานปกป้องฟีเจอร์ การตกแต่งสกรอลล์บาร์ของ IE6 ในเว็บบอร์ด ตอนนั้นฝั่ง Mozilla เรียกมันว่าเป็นสิ่งน่ารังเกียจ
      ตอนนี้อายุมากขึ้น มีทั้งแรงจะมองย้อนกลับไปและจุดอ่อนจากสายตาที่แย่ลง ผมยอมรับได้ว่าตัวเองผิด มันถูกใช้ในทางที่ผิดได้ง่ายเกินไป
    • smooth scrolling ก็ควรถูกใส่ไว้ในรายการนั้นด้วย ไม่ว่าจะเลื่อนด้วยล้อเมาส์ หรือย้ายไปมาระหว่างคำที่พบด้วย Ctrl-F ก็ตาม
      โชคดีที่สามารถ override ได้ด้วย uBlock Origin
    • ecosystem อันกว้างขวางของผู้เขียนส่วนขยายก็ควรได้รับคำชมเช่นกัน ตอนท้ายผู้เขียนชม minimap sidebar ว่าเป็นการอัปเกรดจากสกรอลล์บาร์เดิม และของแบบนั้นมีอยู่จริง
      https://addons.mozilla.org/en-US/firefox/addon/minimap-scrol...
    • บนมือถือก็ทำงานได้ แต่ต้องไปค้นคาถาที่ถูกต้องสำหรับ override สิ่งนี้
      คิดว่าน่าจะเป็นอันนี้
      <https://www.makeuseof.com/change-firefox-scrollbar-style/>

  • ผู้เขียนเห็นปัญหาไปแล้วครึ่งหนึ่ง แต่กลับเสนอครึ่งที่แย่ของวิธีแก้
    แถบเลื่อนไม่ได้เป็นแค่อุปกรณ์ควบคุม แต่ยังเป็น ตัวบอกตำแหน่ง ด้วย มันแสดงให้เห็นว่า viewport ปัจจุบันอยู่ตรงไหนภายในมุมมองที่ใหญ่กว่า เช่น รายการยาว ๆ
    การซ่อนแถบเลื่อนเหมือนกับ GUI บางตัวอย่าง macOS นั้นเสียมารยาทมาก พอ ๆ กับการทำให้ปุ่มแยกไม่ออกจากข้อความ หรือวางตัวอักษรสีเทาอ่อนบนพื้นหลังสีเทาอ่อน
    วิธีแก้มีอยู่แล้วและถูกใช้งานแทบจะเป็นสากล นั่นคือ scroll wheel ของเมาส์และ gesture เลื่อนของ trackpad
    มุมมองที่เลื่อนด้วยแถบเลื่อนได้ แต่เลื่อนด้วย gesture มาตรฐานของ trackpad หรือ wheel ของเมาส์ไม่ได้ นั้นหาได้ยากมาก เมาส์ของผมยังเลื่อนแนวนอนได้ด้วย wheel และตัวควบคุม TrackPoint ก็เช่นกัน
    การเลื่อนแบบนี้ไม่จำเป็นต้องให้ pointer อยู่บนแถบเลื่อน แค่อยู่เหนือมุมมอง/คอนโทรล/widget ที่ต้องการก็พอ
    ทำได้ง่ายมากแม้ใช้อุปกรณ์ป้อนข้อมูลที่ไม่แม่นยำ มือสั่น หรือสายตาไม่ดี
    แต่เมื่อมีวิธีเลื่อนที่เป็นธรรมชาติและง่ายแบบนี้ ก็ยิ่งทำให้คิดถึงแถบเลื่อนมากขึ้นเมื่อมันทำหน้าที่เป็น ตัวบอกสถานะ
    minimap บางครั้งก็มีประโยชน์ แต่บ่อยครั้งก็ไม่ และโดยส่วนตัวรู้สึกว่าในการแก้ไขข้อความมันใหญ่เทอะทะและไม่ช่วยอะไร แน่นอนว่าผมเห็นด้วยถ้ามันเป็นตัวเลือกสำหรับคนที่ชอบ

    • scroll wheel และ gesture เป็นอุปกรณ์สำหรับเลื่อนหน้า และแถบเลื่อนก็ทำหน้าที่นั้นด้วย แต่ในขณะเดียวกันมันยังเป็นคอนโทรลที่สั่งว่า “พาฉันไปกลางเอกสาร” ได้ด้วย
      ถ้ามีสมมติฐานว่าเอกสารตอบสนองได้ถูกต้อง โดยเฉพาะในเอกสารขนาดใหญ่ แถบเลื่อนช่วยให้ย้ายข้ามช่วงใหญ่ ๆ ได้ง่าย แต่บนเว็บสมัยนี้เชื่อสมมติฐานนั้นได้ยาก
      ผมเคยใช้แถบเลื่อนทำ binary search แทบจะจริง ๆ นับครั้งไม่ถ้วน เพื่อหาหน้าที่ยากจะเจอใน PDF ขนาดใหญ่เก่า ๆ ที่ไม่มีลิงก์และใช้หมายเลขหน้าของ section อย่าง “B-29”
      แน่นอนว่าเว็บสมัยใหม่แทบทำลายความเป็นไปได้ในการใช้แถบเลื่อนเป็นตัวบอกสถานะไปแล้ว ด้วยการใช้ lazy loading และ infinite scroll อย่างพร่ำเพรื่อ
      บน Mac ผมเคยกด Cmd-ลูกศรลงเพื่อกระโดดไปท้ายเอกสารอยู่บ่อย ๆ หวังว่าจะมีจุดจบ และหวังว่า embed ทั้งหลายที่ทำลายรูปแบบจะโหลดครบ
      แต่สุดท้ายกลับเหมือนขึ้นไปอยู่บนรถไฟที่ไม่เห็นปลายทาง ไม่รู้ว่ามาไกลแค่ไหนแล้วและเหลืออีกเท่าไร
      ดังนั้นเพราะแถบเลื่อนแทบไร้ประโยชน์ไปแล้ว ผมจึงใช้ mouse wheel แบบมีลูกปืนและมีน้ำหนัก ที่ออกแบบมาเพื่อ doom scrolling ความเร็วสูง
    • ดูเหมือนคุณไม่ได้อ่านบทความ ตั้งแต่ย่อหน้าแรกก็พูดว่า “คุณอาจบอกว่านั่นคือหน้าที่ของ scroll wheel แต่ไม่ใช่ทุกคนจะใช้ scroll wheel หรือการปัดบนหน้าจอสัมผัสได้”
      ย่อหน้าถัดมาก็พูดถึงความยากที่แถบเลื่อนขนาดเล็ก/ถูกซ่อนสร้างให้กับวิธีป้อนข้อมูลอื่น ๆ อย่าง eye tracker
    • ใช่เลย ในที่สุดก็มีคนเข้าใจแล้วว่าแถบเลื่อนมีไว้เพื่ออะไร
      บทบาทหลักของแถบเลื่อนคือแสดงให้ผู้ใช้เห็นว่าเอกสารใหญ่กว่าหน้าต่าง และบทบาทรองคือแสดงให้เห็นว่าส่วนไหนของเอกสารถูกมองเห็นอยู่ การทำให้ผู้ใช้เลื่อนได้นั้นไม่ใช่หน้าที่หลัก
      ผมตกใจจริง ๆ ตอนที่ Apple เริ่มซ่อนแถบเลื่อนโดยค่าเริ่มต้นใน macOS ดูเหมือนนักออกแบบ UI ของ Apple จะไม่รู้ว่าคอนโทรลพื้นฐานของ UI ทำหน้าที่อะไรจริง ๆ
    • อุปกรณ์ป้อนข้อมูลสำหรับการเลื่อนไม่ได้มีให้ใช้อย่างแพร่หลายเสมอไป
      สำหรับ ผู้ใช้ Wacom/ปากกา ไม่มี scroll wheel
      trackball จำนวนมากก็ไม่มี scroll wheel และบางรุ่นมี scroll ring รอบลูกบอล
      ผมถอด scroll wheel ออกจากเมาส์เพราะเกิดอาการบาดเจ็บจากการใช้งานซ้ำที่นิ้วที่ใช้เลื่อน เคยมีช่วงหนึ่งที่ยืดแขนข้างที่ใช้เมาส์มากเกินไปจนต้องใช้ trackball ด้วยมืออีกข้างอยู่หลายสัปดาห์ด้วย
    • ถ้าต้องเลื่อนเป็นระยะทางไกลมาก ๆ mouse wheel ก็ไปไม่รอด

  • ควรพูดถึง ขอบหน้าต่าง ด้วย ผมเปิดหน้าต่าง VS Code หลายอันทับกัน โดยเป็นพื้นหลังสีดำกับขอบสีดำ และไม่มีเงา
    มองไม่เห็นเลยว่า frame/ขอบของหน้าต่างหนึ่งอยู่ตรงไหนบนอีกหน้าต่างหนึ่ง เรื่องนี้ควรเป็นปัญหาระดับระบบปฏิบัติการ แต่ apparently กลับเป็นปัญหาของแอป
    แถม VS Code ยัง “ถอน” การรองรับการตั้งค่าขอบออกไปด้วย: https://github.com/microsoft/vscode/issues/160159

    • มีเนื้อหาเพิ่มเติมเกี่ยวกับขอบและ title bar อยู่ที่นี่
      https://news.ycombinator.com/item?id=37865824
      ตามทฤษฎีของผม นักออกแบบดูเหมือนจะตั้งเป้าไปที่ผู้ใช้ที่ดูหน้าต่างเต็มหน้าจอเพียงหน้าต่างเดียวในแต่ละครั้ง
      ผู้ใช้ต้นแบบของพวกเขานั่งอยู่หน้าหน้าจอแล็ปท็อป 13 นิ้ว ในห้องที่มีแสงสมบูรณ์แบบและไม่มีแสงสะท้อน ไม่ย้ายหรือปรับขนาดหน้าต่าง และไม่เปิดแท็บ/เอกสารเกิน 3 อันต่อวัน

  • ทุกครั้งที่อ่านบทความแบบนี้หรือบล็อก UX ก็เห็นชัดเกินไปว่าเราไม่ใส่ใจ การเข้าถึงสำหรับทุกคน มากแค่ไหน
    ดีไซน์ที่ “ดี” และเข้าถึงได้มักค่อนข้างน่าเบื่อและไม่รก เมื่อเทียบกับสิ่งที่คาดหวังจากเว็บแอปสมัยใหม่
    ผมอ่านหนังสือของ Adam Silver เกี่ยวกับฟอร์มแล้วตระหนักว่าในมุมของ accessibility เรากำลังทำผิดไปหมด แต่ accessibility ไม่ใช่ลำดับความสำคัญ

    • น่าขันที่ถ้าความเห็นจะเข้าถึงได้ ผู้อ่านต้องไปค้นเองว่า a11y หมายถึง “accessibility”
    • จากมุมธุรกิจ มันไม่ได้ผิดเสมอไป ถ้าบริษัททำสิ่งที่ทำไม่ได้เมื่อสร้างเว็บไซต์ที่เข้าถึงได้ บ่อยครั้งคำนวณออกมาแล้วกลับได้ผลดีกว่า
      โดยเฉพาะ dark pattern นั้นตรงข้ามกับ accessibility อย่างมาก
      ดังนั้นจึงจำเป็นต้องมีกฎหมายที่ทำให้ accessibility เป็นข้อบังคับ

  • รู้ไหมว่าอะไรที่เป็นปัญหาด้านการเข้าถึงสำหรับคนจำนวนมากที่อายุ 40 ปีขึ้นไป? ก็คือ ตัวอักษรสีขาวบนพื้นหลังสีเข้ม
    ผมคงฟังเรื่องที่เรียกร้องให้ทำหน้าเว็บให้อ่านได้สำหรับคนวัยเดียวกับผมได้ไม่รู้เบื่อ
    ถ้าเปิด Developer Tools แล้วแก้ CSS ของผู้เขียนก็พออ่านได้ แต่กลับทำให้อ่านเชลล์สคริปต์ไม่ได้

    • แม้จะอายุต่ำกว่า 40 ปี ชุดสีนี้ก็ทำให้ตาล้ามาก อ่านไปไม่กี่ย่อหน้าแล้วมองกำแพง จะยังเห็น ตัวอักษรติดตา อยู่ในสายตานานกว่า 30 วินาที
      มันไม่สบายตามากจนถ้าเลือกข้อความทั้งหมดแล้วยังลดคอนทราสต์พื้นหลังมืด/ตัวอักษรขาวไม่ได้ ผมก็จะไม่อ่านหน้านั้นเลย
    • น่าเสียดายที่ข้อกำหนดด้านการเข้าถึงมักขัดแย้งกันเอง และคนทำเว็บเพจก็ไม่ได้มีเวลามหาศาลพอจะรับประกันตัวเลือกสำหรับทุกคน
      อาจพิจารณาปิด CSS ไปเลยก็ได้
    • ผมยังไม่ถึง 40 แต่กรณีของผมกลับตรงกันข้าม ผมมี วุ้นตาเสื่อม รุนแรง พื้นหลังสีขาวทำให้สิ่งเหล่านั้นเด่นชัดขึ้น
      สิ่งที่ดีจริง ๆ ในช่วง 5 ปีที่ผ่านมาคือ ตอนนี้อินเทอร์เฟซผู้ใช้หลัก ๆ ส่วนใหญ่มีทั้งโหมดมืดและโหมดสว่างให้ใช้แล้ว
    • ในเบราว์เซอร์ ลองปรับส่วนขยาย Dark Reader ดูก็น่าจะดี ปกติมักใช้เป็นโหมดมืดแบบทั่วทั้งระบบ แต่ก็สามารถตั้งค่าโหมดขาวแบบรายเว็บไซต์หรือทั่วทั้งระบบได้ด้วย
    • ไม่ใช่ปัญหาเดียวกันเป๊ะ แต่ผมมักเห็นกรณีที่มีตัวอักษรสีเข้มหรือสีเทากลางบนพื้นหลังสีสว่างหรือสีเทากลาง
      วิธีแก้ของผมคืออันนี้
      https://addons.mozilla.org/en-US/firefox/addon/font-contrast...
      อย่างน้อยมันบังคับให้ข้อความเป็นสีดำ ค่อนข้างเสถียร และตั้งข้อยกเว้นที่จำเป็นเป็นบางครั้งได้ง่ายด้วย

  • เห็นด้วยว่าสโครลบาร์กำลังตายและใช้งานไม่ได้ สโครลบาร์ควรกว้าง มองเห็นชัด และเล็งได้ง่าย
    ควรมีขนาดตามสัดส่วนเพื่อแสดงสัดส่วนของเอกสารที่กำลังมองเห็นอยู่ และส่วนที่ขยับได้ควรมีลักษณะที่สื่อถึง แรงเสียดทาน ไม่ใช่ความลื่น
    ปุ่มลูกศรควรถูกวางไว้ด้วยกัน ไม่ใช่อยู่ปลายตรงข้ามกัน และควรใช้สีบอกสถานะ hover กับสถานะกดเมาส์
    ในบรรดาสโครลบาร์คลาสสิกที่ยกมานี้ https://scrollbars.matoseb.com/ ผมว่า Nextstep ใกล้เคียงเงื่อนไขที่สุด และ Mac OS 8 สวยที่สุดโดยรวม

    • นอกจากนี้ ถ้าเอกสารรองรับ ก็ควรมีตัวเลือกให้แพนได้สองทิศทางจากวิดเจ็ตบนทูลบาร์เพียงอันเดียวด้วย ผมเคยเห็นการใช้งานแบบนั้น แต่ไม่เคยเห็นแบบที่ปุ่มลูกศรอยู่ด้วยกันแทนที่จะอยู่คนละปลาย
      เมื่อก่อนเคยมีสาขาวิจัยที่เรียกว่า ปฏิสัมพันธ์ระหว่างมนุษย์กับคอมพิวเตอร์ ซึ่งทำให้เราได้เรียนรู้เรื่องกฎของ Fitts หรือข้อเท็จจริงที่ว่าขอบหน้าจอมีขนาดเสมือนอนันต์ จึงมีคุณค่าเป็นพิเศษ
      ผมเปิด MS Teams ไว้ใน OS X เหมือนเป็นการลงโทษ หน้าต่างชิดขวาของหน้าจอพอดี และมีสโครลบาร์อยู่ที่ขอบขวา
      พอเลื่อนเมาส์ไปทางขวา แล้วคลิกเพื่อจับสโครลบาร์ที่ขยายขึ้นเมื่อเอาเมาส์ไปวางและแตะไปถึงพิกเซลขอบสุด กลับกลายเป็นว่าลากทั้งหน้าต่างไปแทน
      ไม่รู้ว่าเรามาถึงจุดนี้ได้อย่างไร เคยมีช่วงเวลาที่มีการศึกษากันอย่างจริงจังว่าอินเทอร์เฟซผู้ใช้ที่ดีคืออะไร งานวิจัยนั้นสะท้อนออกมาในประสบการณ์ผู้ใช้จริง และเห็นผลลัพธ์ชัดเจน
    • ผมไม่เคยคิดมาก่อนว่าปุ่มลูกศรควรถูก วางเรียงข้างกัน แทนที่จะอยู่ปลายตรงข้ามกัน แต่มันก็สมเหตุสมผล
      นอกจากเหตุผลว่า “ก็ทำกันมาแบบนี้ตลอด” แล้ว ผมสงสัยว่าทำไมมันถึงหายากขนาดนั้น

  • มีคนบอกว่า “นักออกแบบไม่ได้ทดสอบการใช้งานกับผู้ใช้ที่ไม่ใช่สายเทคนิค” แต่ต่อให้ทำก็คงไม่ต่างมาก
    ผมทำงานเป็นนักพัฒนาเว็บมาเกือบ 25 ปี และร่วมงานกับนักออกแบบมามาก สิ่งที่พวกเขาใส่ใจคือ เลย์เอาต์แบบ pixel-perfect ที่ตรงกับ “วิสัยทัศน์” ของตัวเอง UX แทบไม่เคยเป็นแม้แต่ความคิดแวบผ่าน

    • ไม่ใช่นักออกแบบทุกคนจะเป็นแบบนั้น แต่ก็มีจำนวนมากที่เป็น ผมเคยเห็นนักออกแบบที่หลังจากงานวิจัย UX กับผู้ใช้จริงแล้วพูดว่า “นี่เป็นแค่ข้อมูลหนึ่งจุด และเรามองว่าผู้ใช้เหล่านั้นคิดผิด”
      กรณีแบบนี้โน้มน้าวไปก็ไม่สำเร็จ