มาฟื้นคืนการออกแบบแบบอิงธรรมเนียมกันเถอะ

 (essays.johnloeber.com)
1 คะแนน โดย GN⁺ 17 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ธรรมเนียมการออกแบบ ที่ผู้ใช้เข้าใจได้ทันทีช่วยลดภาระในการเรียนรู้และทำให้เกิดปฏิสัมพันธ์ที่สม่ำเสมอ
  • ในอดีต ยุคของซอฟต์แวร์เดสก์ท็อปมีอินเทอร์เฟซที่เป็นหนึ่งเดียวกัน ทั้งโครงสร้างเมนูและคีย์ลัด อาศัยระบบปฏิบัติการและแนวทางกำกับ
  • ตรงกันข้าม ในยุคของซอฟต์แวร์บนเบราว์เซอร์ ความสม่ำเสมอของอินเทอร์เฟซได้พังทลายลงจากการแพร่หลายของเฟรมเวิร์กและการพัฒนาคัสตอม
  • Apple และ Substack แสดงให้เห็นถึงกรณีความสำเร็จของธรรมเนียมสมัยใหม่ผ่านการปรับแต่งที่จำกัดและระบบดีไซน์ที่เป็นหนึ่งเดียว
  • นักออกแบบผลิตภัณฑ์ควรยึดตามธรรมเนียมที่มีอยู่เดิม และให้ความสำคัญกับความชัดเจนและความสม่ำเสมอเพื่อมุ่งไปสู่ประสบการณ์ผู้ใช้แบบมาตรฐานทั่วทั้งเว็บ

ธรรมเนียมการออกแบบ

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

อินเทอร์เฟซที่เป็นเนื้อเดียวกัน

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

ยุคซอฟต์แวร์เดสก์ท็อป

  • ซอฟต์แวร์เดสก์ท็อปในช่วงWindows 95~7รักษาความสม่ำเสมอของอินเทอร์เฟซในระดับสูงไว้ได้
    • โครงสร้างเมนูอย่าง “File, Edit, View” มีเหมือนกันในทุกโปรแกรม
    • ตัวอักษรที่ขีดเส้นใต้ในรายการเมนูหมายถึงคีย์ลัดบนแป้นพิมพ์ และสามารถใช้งานได้ด้วย ALT+F, N เป็นต้น
    • แถบสถานะ (status bar) ด้านล่างแสดงสถานะปัจจุบันอย่างชัดเจน เช่น หน้า จำนวนคำ หรือโหมด
    • เน้นเมนูแบบข้อความเป็นหลัก และใช้ไอคอนเฉพาะเมื่อมีความหมายชัดเจนเท่านั้น
  • ธรรมเนียมเหล่านี้ไม่ได้มีแค่ใน Microsoft Word แต่ถูกทำให้เป็นหนึ่งเดียวกันทั่วทั้งระบบนิเวศของ Windows
    • แม้แต่หน้าจอออกจากระบบของ Windows XP ก็ยังแสดงให้เห็นชัดเจนว่าทุกองค์ประกอบเป็นปุ่ม และมีการแสดงคีย์ลัดไว้
  • ความสม่ำเสมอนี้เป็นไปได้ด้วยข้อจำกัดของระบบปฏิบัติการและไลบรารี GUI และ Microsoft ก็เผยแพร่แนวทางการออกแบบยาวนับร้อยหน้าเพื่อชี้นำให้นักพัฒนาปฏิบัติตาม

ยุคซอฟต์แวร์บนเบราว์เซอร์

  • ยุคของเว็บแอปพลิเคชันในปัจจุบันถูกอธิบายว่าเป็นยุคของอินเทอร์เฟซที่หลากหลายจนไม่เป็นเนื้อเดียวกัน
    • แม้แต่เว็บแอปคุณภาพสูงอย่าง Figma และ Linear ก็ยังไม่มีไอคอนหรือคีย์ลัดร่วมกัน
    • แต่ละแอปได้รับการออกแบบมาอย่างดีในแบบของตนเอง ทว่ามีรูปแบบปฏิสัมพันธ์ที่แตกต่างกัน
    • แม้อยู่ในบริษัทเดียวกัน ประสบการณ์ของ Gmail, GSuite และ Google Docs ก็ยังแตกต่างกัน
    • ผลลัพธ์คือผู้ใช้ต้องเสียเวลาไปกับการหาว่าจะกดตรงไหนแทนที่จะได้อยู่ในกระแสการทำงานที่ลื่นไหล (flow)

  • ผลกระทบจากการเปลี่ยนผ่านสู่มือถือ

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

  • การขาดแคลนธรรมเนียมนอกเหนือจาก HTML

    • ในยุคแรกของเว็บเคยมีธรรมเนียมที่ชัดเจน เช่น ลิงก์สีน้ำเงินขีดเส้นใต้ แต่ปัจจุบันแต่ละเว็บกลับมีสไตล์แตกต่างกันหมด
    • แม้มาตรฐาน HTML/CSS จะเข้มงวด แต่ในทางปฏิบัติส่วนใหญ่กลับใช้ระบบบิลด์ที่อิง React·TypeScript
    • ผลคือมีการใช้การพัฒนาคัสตอมแทนองค์ประกอบ HTML มาตรฐานอย่างแพร่หลาย และยังก่อปัญหาด้านการเข้าถึงอีกด้วย
    • ตัวอย่างเช่น การใช้ <span> ที่มี onclick แทน <a> ทำให้ฟังก์ชันของสกรีนรีดเดอร์พัง
    • ยังมีแอปอย่าง Figma ที่อาศัยWebAssemblyจนหลุดออกจาก HTML ไปโดยสิ้นเชิง
    • ฟังก์ชันพื้นฐานของเบราว์เซอร์อย่างปุ่มย้อนกลับและคีย์ลัดถูกเพิกเฉย และเกิดการรื้อสร้างกระบวนทัศน์ใหม่ของปฏิสัมพันธ์ระหว่างมนุษย์กับคอมพิวเตอร์
    • เมื่อการพัฒนาฟรอนต์เอนด์เติบโตโดยเน้นความเร็วและความเป็นไปได้ จึงทำให้การสร้างธรรมเนียมที่สม่ำเสมอทำได้ยาก
    • ด้วยการมีอยู่ของเฟรมเวิร์กและรูปแบบปฏิสัมพันธ์นับไม่ถ้วน จึงเป็นสภาพแวดล้อมที่ยากต่อการสร้างมาตรฐานเดียวในเชิงโครงสร้าง

กรณีสำเร็จของการออกแบบแบบอิงธรรมเนียม

  • Apple ถูกยกให้เป็นตัวอย่างเด่นในยุคปัจจุบันที่ยังรักษาธรรมเนียมการออกแบบที่แข็งแรงไว้ได้
    • ฟอนต์ ปุ่ม สี และระบบดีไซน์โดยรวมถูกทำให้เป็นหนึ่งเดียวกัน พร้อมมอบประสบการณ์ปฏิสัมพันธ์ที่สม่ำเสมอตลอดทั้ง iOS
    • ความสม่ำเสมอนี้สร้างความเชื่อมั่นในแบบ “it just works”
  • Substack ก็เช่นกัน มอบประสบการณ์ผู้ใช้ที่มั่นคงผ่านการปรับแต่งที่จำกัดและค่าเริ่มต้นด้านสุนทรียะที่กำหนดไว้ล่วงหน้า
    • หลักการออกแบบของ Apple และ Substack ได้แพร่กระจายเป็นมาตรฐานของอุตสาหกรรมผ่านความสำเร็จ และท้ายที่สุดก็กลายเป็นธรรมเนียมใหม่

หลักการที่นักออกแบบผลิตภัณฑ์ควรยึดถือ

  • นักพัฒนาผลิตภัณฑ์ควรยึดตามธรรมเนียมการออกแบบที่มีอยู่เดิมให้มากที่สุด เพราะเป็นหนทางที่จะเพิ่มทั้งการใช้งานได้จริงและความเข้ากันได้
    • ปฏิบัติตามธรรมเนียมพื้นฐานของ HTML/CSS: ลิงก์ควรมีขีดเส้นใต้ สี เคอร์เซอร์แบบตัวชี้ และสร้างด้วยแท็ก <a>
    • อย่านำองค์ประกอบ HTML พื้นฐานไปสร้างใหม่ด้วย JavaScript เช่น ใช้ <button> แทน React Button
    • ปฏิบัติตามธรรมเนียมของเบราว์เซอร์: ปุ่มย้อนกลับต้องทำงานได้, คัดลอก URL แล้วเข้าถึงอินเทอร์เฟซเดิมได้, CTRL+คลิกแล้วเปิดแท็บใหม่ได้
    • หากต้องออกนอกเหนือจากธรรมเนียมทั่วไป อย่างน้อยก็ควรรักษากฎที่สม่ำเสมอภายในองค์กร
    • ให้ข้อความมาก่อนไอคอน และใช้ไอคอนให้น้อยที่สุด โดยใช้เฉพาะเมื่อคนทั่วไปเข้าใจได้
    • องค์ประกอบทางภาพควรให้ความชัดเจนมาก่อนความงามเชิงสุนทรียะ
    • หากตัดสินใจได้ยาก ให้ดูตัวอย่างจากเว็บไซต์ที่ยอดเยี่ยมและหนังสือออกแบบอินเทอร์เฟซในอดีต
  • ท้ายที่สุดแล้ว บทความนี้มุ่งสู่อนาคตที่ตัวเลือกวันที่หรือฟอร์มกรอกบัตรบนทุกเว็บไซต์ทำงานเหมือนกัน โดยตั้งเป้าไปยังสภาพแวดล้อมเว็บที่หลอมรวมสู่ธรรมเนียมที่เหมาะสมที่สุดผ่านการทำซ้ำและปรับปรุงต่อเนื่องนานหลายทศวรรษ

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

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

 
GN⁺ 17 일 전
ความเห็นจาก Hacker News

  • บางแอปใช้ Enter เพื่อส่งข้อความ และ Ctrl+Enter เพื่อขึ้นบรรทัดใหม่ (เช่น Slack) ขณะที่บางที่กลับตรงกันข้าม (เช่น GitHub)
    ความไม่สอดคล้องกันแบบนี้ทำให้ผู้ใช้สับสนมาก คำว่า “ฟื้นคืนการออกแบบตามธรรมเนียม” ฟังดูดี แต่ปัญหาคือจริง ๆ แล้วเราแทบไม่มีธรรมเนียมร่วมกันให้ยึดแล้ว

    • เมื่อก่อน Return กับ Enter เป็นคนละปุ่มกัน Return ใช้ขึ้นบรรทัดใหม่ ส่วน Enter ใช้ส่งข้อมูล
      ตอนนี้ปุ่มถูกรวมเป็นปุ่มเดียวกัน โดยทั่วไปในช่องกรอกหลายบรรทัด Enter จะขึ้นบรรทัดใหม่ และ Ctrl+Enter จะเป็นการส่ง
      แต่แอปแชตมักเน้นข้อความสั้น จึงทำงานกลับกัน แอปที่ดีจะเปิดให้ตั้งค่าสิ่งนี้ได้
    • Teams มีสองโหมด ค่าเริ่มต้นคือ Enter เพื่อส่ง และ Shift+Enter เพื่อขึ้นบรรทัดใหม่ แต่ถ้าเปิดเครื่องมือจัดรูปแบบ มันจะสลับกลับกัน
      ถึงจะมีการบอกว่าใช้คีย์อะไรขึ้นบรรทัดใหม่ ก็ยังชวนสับสนอยู่ดี
    • Slack ซับซ้อนยิ่งกว่า ถ้าเปิด Markdown, Shift+Enter จะขึ้นบรรทัดใหม่ แต่ภายในโค้ดบล็อก (``` ) กลับเป็น Enter ที่ขึ้นบรรทัดใหม่ และ Shift+Enter ที่ส่งข้อความ
      เข้าใจเจตนาได้ แต่ในแง่การใช้งานถือว่าแย่มาก
    • วิธีแก้ที่เหมาะที่สุดน่าจะเป็น Ctrl+Enter = ส่งเสมอ, Shift+Enter = ขึ้นบรรทัดใหม่เสมอ, ส่วน Enter ให้ทำตามค่าเริ่มต้นของบริบท
    • ฉันเองก็คิดว่า Shift+Enter คือขึ้นบรรทัดใหม่เหมือนกัน ซึ่งยิ่งแสดงให้เห็นว่าUX ที่แตกกระจัดกระจายคือปัญหา

  • ซอฟต์แวร์สมัยนี้ไม่ได้ถูกสร้างโดยผู้ออกแบบที่รอบคอบแบบในอดีตอีกแล้ว
    แต่กลับถูกขับเคลื่อนโดย PM หรือคนฝั่ง Product ที่เพิ่งได้เลื่อนตำแหน่งอย่างเร่งรีบ และยังส่งเสริมdark patternเพื่อหารายได้อีกด้วย

    • ในฐานะวิศวกรมือถือ เวลาบอกผู้มีส่วนได้ส่วนเสียว่า “ทำตามไอเดียอย่างเดียวไม่ได้” มักจะได้สีหน้างง ๆ กลับมา
      ต้องย้ำความสำคัญของความสม่ำเสมอด้าน UX และโครงสร้างสารสนเทศ (IA) และอย่าลืมว่านักออกแบบก็เป็นคนแก้ปัญหาเช่นกัน
    • คำวิจารณ์แบบนี้ก็มองแคบเกินไปเหมือนกัน แค่จะทำฟอร์มออนไลน์สักอันก็เหมือนตกนรกแล้ว
      เช่น เวลาทำฟอร์มบัตรเครดิต ต้องคิดทั้งเรื่องอนุญาตให้คัดลอก/วางหรือไม่ การรองรับเบราว์เซอร์เก่า การหาสมดุลระหว่างการเข้าถึงได้กับความปลอดภัย และตัวแปรอีกมากมาย
      อ้างอิง บทความเรื่องแพลตฟอร์มของ Steve Yegge ก็อธิบายความซับซ้อนแบบนี้ได้ดี
    • ในช่วงทศวรรษ 2010 นักออกแบบ UX ที่มีทักษะสูงค่อย ๆ หายไป และถูกแทนที่ด้วยนักออกแบบที่ไม่ใช่มืออาชีพจากสายงานสิ่งพิมพ์หรือกราฟิกจำนวนมาก ทำให้คุณภาพตกลง
    • แน่นอนว่ามีทั้งแรงจูงใจที่ผิดและกำหนดการที่เร่งรีบ แต่ก็คงอธิบายด้วยความไร้ความสามารถหรือเจตนาร้ายอย่างเดียวไม่ได้ เพราะตัวระบบเองเปลี่ยนไปแล้ว
    • ทุกวันนี้พอเห็น PM พยายามออกแบบแม้กระทั่งสถาปัตยกรรมโดยรวมและโรดแมปการปล่อยเวอร์ชันด้วยตัวเอง ก็ยิ่งรู้สึกว่าคำพูดนี้ไม่ผิด

  • เฟรมเวิร์กระบบเคยเป็นรากฐานที่ทำให้เกิดUI ตามธรรมเนียม
    Win32, AppKit และ UIKit ดูแลรายละเอียดเล็ก ๆ น้อย ๆ ไว้ให้ จนนักพัฒนาทำ UX ที่สอดคล้องกันได้โดยธรรมชาติ
    แต่บนเว็บไม่มีสิ่งนั้น ทุกอย่างต้องทำเองหมด ผลลัพธ์จึงมักเป็นUI ที่เหมือนทำไม่เสร็จครึ่งหนึ่ง

    • แต่ผู้เขียนก็ชี้ปัญหาความไม่สอดคล้องของเว็บผิดจุดอยู่เหมือนกัน “ยุคเดสก์ท็อป” จริง ๆ ก็คือยุคของ Windows และทุกคนก็แค่ทำตาม Win32 ที่เป็นค่ามาตรฐาน
      เว็บตั้งแต่แรกเป็นโลกที่เน้นเอกสาร จึงไม่มีแนวทางมาตรฐานแบบนั้น และภายหลังจึงค่อยมีมาตรฐานชั่วคราวอย่าง Bootstrap โผล่ขึ้นมา
    • เรามี HTML และ CSS อยู่แล้ว แต่ทุกวันนี้หลายคนกลับอ้อมไปใช้ WebAssembly แทน
      ที่จริงแล้วตัวเลือกวันที่หรือการกรอกข้อมูลบัตรควรใช้คอนโทรล HTML พื้นฐาน
      แบบนั้นเบราว์เซอร์จึงจะมอบความปลอดภัยและความสะดวกในระดับ OS ได้ (เช่น Safari เชื่อมกับ Apple Wallet, Android เชื่อมกับ Google Pay)
    • นักพัฒนาที่คุ้นกับพฤติกรรมสม่ำเสมอของ OS มักพยายามเลียนแบบสิ่งนั้นโดยธรรมชาติ
      แต่เว็บกับมือถือเป็นสภาพแวดล้อมแบบปิดเป็นกล่องที่ต่างออกไปโดยสิ้นเชิง จึงทำให้ความสอดคล้องแบบนั้นพังลง
      ตัวอย่างเช่น เดิมทีเคยมีโอกาสทำให้การคลิกขวาบนเดสก์ท็อปเทียบเท่ากับการกดค้างบนมือถืออย่างเป็นมาตรฐาน แต่ก็ไม่ได้ผลักดันให้สม่ำเสมอ
    • ปัญหารากฐานของเว็บคือมันยังติดอยู่กับกระบวนทัศน์ที่มีเอกสารเป็นศูนย์กลาง
      เวลาจะสร้าง UI แบบแอปก็ต้องเอาไปครอบทับบน UI แบบเอกสาร จึงเกิดการชนกัน
      เบราว์เซอร์ช่วยบรรเทาได้บ้าง แต่ไม่ใช่การแก้ที่ต้นเหตุ
    • อนึ่ง ใน AppKit ก็เปลี่ยนความสูงของปุ่มได้เหมือนกัน เพียงแต่ไม่ได้ชัดเจนนัก

  • ตัวเลือกวันที่เป็นฝันร้ายด้าน UXจริง ๆ
    หลายที่พอผู้ใช้อยากพิมพ์วันที่เองก็กลับห้าม แล้วบังคับให้คลิกอย่างเดียว
    ทั้งที่แค่ช่วยจับการกรอกผิดก็พอแล้ว แต่กลับทำให้ใช้งานลำบากโดยไม่จำเป็น

    • เวลาจะกรอกวันเกิดแล้วต้องเลื่อนปฏิทินย้อนหลังหลายสิบปี ก็ทำให้รู้สึกถึงความไม่เที่ยงของชีวิตขึ้นมาทันที
    • ตัวเลือกเวลาบนมือถือก็ไม่เหมือนกันสักที่ บางอันเลื่อนครั้งเดียวจาก 12:00 ไป 11:50 ได้ บางอันก็ไม่ได้
      ตัวเลือกแบบหน้าปัดนาฬิกาอนาล็อกดูเข้าใจง่ายกว่า อยากให้สิ่งนี้กลายเป็นมาตรฐาน
    • รูปแบบวันที่ก็เป็นปัญหา 03/04/2026 อาจหมายถึง 4 มีนาคม หรือ 3 เมษายน ก็ได้
      ถ้ามีผู้ใช้ต่างประเทศ YYYY-MM-DD คือรูปแบบที่ปลอดภัยกว่า
    • เว็บไซต์ที่ใช้ตัวเลือกวันที่แบบเดียวกับการนัดหมายในอนาคตมาให้กรอกวันเกิดนี่แย่ที่สุด
      ต้องเลื่อนกลับไป 50 ปีก่อน แถมยิ่งทำให้รู้สึกแก่ขึ้นอีก
    • การทำให้เรารับรู้อายุของตัวเองผ่านการเลื่อนทุกครั้งที่กรอกวันเกิด มันเหมือนการทรมานมากกว่า

  • ทุกวันนี้คุณภาพ UX ที่ถดถอยหนักมาก โดยเฉพาะบนเว็บไซต์ธนาคาร
    ทั้งการซ่อนแถบเลื่อน พื้นที่ว่างที่เปลือง ปุ่มแบน และไอคอนชวนงง ทำให้ใช้งานยากกว่า UI เดสก์ท็อปสมัยก่อนมาก

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

  • หนึ่งในแนวคิดจาก Mac รุ่นเก่าคือ ถ้าข้อความบนปุ่มลงท้ายด้วยจุดไข่ปลา (…) แปลว่ายังต้องมีการกรอกข้อมูลเพิ่มเติม
    ตรงกันข้าม ปุ่มที่ไม่มีจุดไข่ปลาคือกดแล้วการกระทำจะเสร็จทันที

  • เห็นด้วยกับแนวคิดที่ว่า “ควรใช้คำมากกว่าไอคอน”
    คนส่วนใหญ่รับรู้คำได้เร็วกว่าไอคอน

    • แน่นอนว่าไอคอนที่วาดเป็นวัตถุจริงยังใช้ได้ดี แต่ทุกวันนี้มีไอคอนแบบนามธรรมและเส้นเรียบมากเกินไป
      ถ้าไม่มีคำอธิบายกำกับ ก็เหมือนต้องคลิกเสี่ยงดวงเพื่อเดาว่ามันหมายถึงอะไร
    • แม้แต่กรณีอย่าง “unvote/undown” ของ HN ก็ยังสับสนเพราะขึ้นต้นเหมือนกัน ต้องเช็กใหม่ทุกครั้งก่อนกด
    • ถ้าไอคอนเล็กหรือเปลี่ยนตำแหน่งบ่อย คำจะดีกว่า แต่ในสภาพแวดล้อมที่ตำแหน่งคงที่ ไอคอนอาจเร็วกว่า

  • เมื่อไม่นานมานี้ฉันค้นพบเทคโนโลยีใหม่ชื่อ CSS ซึ่งทำให้กำหนดเลย์เอาต์แบบประกาศเจตนาได้ และใช้สไตล์แบบลำดับชั้นบน DOM ได้
    มันช่วยลดภาระทั้งฝั่งไคลเอนต์และเซิร์ฟเวอร์ แชร์สไตล์ชีตกันได้ และยังทำธีมเฉพาะผู้ใช้ได้ง่ายด้วย
    ฉันอยากเรียกสิ่งนี้ว่ากระบวนทัศน์ UI แบบ “no-framework”
    ภาพตัวอย่าง

    • เคยลองใช้แล้ว เป็นฝันร้ายเต็ม ๆ ไม่รู้เลยว่าสไตล์ไหนถูกใช้ตรงไหน และถ้าโครงสร้าง DOM เปลี่ยน สไตล์ก็พังหมด
      แถมเรื่อง “ลดภาระฝั่งไคลเอนต์ให้ต่ำสุด” ก็เป็นแค่มายาคติเท่านั้น จริง ๆ แล้วช้ากว่าอีก
    • ไอเดียนี้น่าลองเสนอให้ทีมเฟรมเวิร์ก vanilla-js ดู

  • ฟีเจอร์ร่วมที่พวกเราสูญเสียไป:
    Undo/Redo, Help (F1), คำใบ้เมื่อเอาเมาส์ชี้, การปรับแต่งคีย์ลัด, เมนูหลัก, ไฟล์/ไดเรกทอรี, ปิดด้วย ESC, drag-and-drop ฯลฯ
    สิ่งที่เคยเป็นนวัตกรรมเหล่านี้ ตอนนี้แทบหายไปจากทั้งมือถือและเว็บแล้ว

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