คู่มือที่เป็นมิตรสำหรับตัวเลือกวันที่บนฟรอนต์เอนด์

 (pikaday.dbushell.com)
1 คะแนน โดย GN⁺ 2025-11-13 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แนะนำแนวทางการป้อนข้อมูลที่เรียบง่ายและเข้าถึงได้มากกว่า แทนการใช้ ตัวเลือกวันที่ JavaScript ที่ซับซ้อน
  • การใช้ องค์ประกอบ input พื้นฐานของเบราว์เซอร์ (date, time, datetime-local) ช่วยให้ได้ทั้งการเข้าถึง ประสิทธิภาพ และการรองรับการทำงานหลายภาษาโดยอัตโนมัติ
  • สามารถทำให้ UI ที่ซับซ้อนเรียบง่ายลงได้ด้วย ช่องกรอกแยกส่วน, masked input หรือ กลุ่มปุ่มตัวเลือก radio
  • แม้ใน เฟรมเวิร์กอย่าง React ก็ยังสามารถใช้องค์ประกอบ input มาตรฐานของ HTML ได้โดยตรง และแม้การปรับสไตล์จะมีข้อจำกัด แต่ก็ยังคง UI ของระบบที่ผู้ใช้คุ้นเคยไว้ได้
  • ตัวเลือกวันที่ทุกแบบมีปัญหาด้านการเข้าถึง ดังนั้น โครงสร้างการป้อนข้อมูลที่เรียบง่ายและการทดสอบกับผู้ใช้จริง คือหัวใจสำคัญของการออกแบบฟอร์มที่ประสบความสำเร็จ

จำเป็นต้องใช้ตัวเลือกวันที่ JavaScript จริงหรือ

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

การป้อนวันที่และเวลาแบบพื้นฐานของเบราว์เซอร์

  • เบราว์เซอร์สมัยใหม่ทั้งหมดรองรับ ชนิด input แบบ date, time, datetime-local เป็นพื้นฐาน
    • date ใช้เลือกวันที่, time ใช้ป้อนชั่วโมงและนาที, datetime-local ใช้รวมทั้งสองอย่างเข้าด้วยกัน
  • input พื้นฐานสามารถใช้งานได้ด้วยโค้ดเพียงบรรทัดเดียว และเบราว์เซอร์จะจัดการเรื่อง การเข้าถึง·ประสิทธิภาพ·การรองรับหลายภาษา ให้
    • รองรับการป้อนด้วยคีย์บอร์ด และมี UI ปฏิทินพื้นฐานให้
    • แม้จะไม่สมบูรณ์แบบ แต่โดยมากก็เสถียรกว่าไลบรารี JavaScript ส่วนใหญ่
  • อย่างไรก็ตาม ยังมี ปัญหาด้านการเข้าถึง บางส่วนอยู่

ช่องกรอกแยกส่วนและองค์ประกอบเลือกค่า

  • แทนที่จะใช้ตัวเลือกวันที่เพียงตัวเดียว การ แยกช่องกรอกปี·เดือน·วัน ช่วยเพิ่มการใช้งานได้ดีกว่า
    • มีการยกตัวอย่างคอมโพเนนต์ date input ของ GOV.UK
  • หากค่าข้อมูลที่ถูกต้องมีจำนวนจำกัด การใช้ องค์ประกอบ select จะเหมาะสมกว่า
    • ช่วยป้องกันข้อผิดพลาดในการป้อน และลดจำนวนการโต้ตอบ
    • ควรระวังการที่โปรแกรมอ่านหน้าจออ่านค่าผิดเมื่อแสดงเดือนเป็นตัวเลข
  • ในกรณีอย่าง การจองการเดินทางที่มีช่วงเวลาคงที่ (เช่น ทุก 15 นาที) การแสดงวันที่แบบสัมพันธ์ เช่น วันนี้, พรุ่งนี้ มีประโยชน์

masked input และการตรวจสอบความถูกต้อง

  • ช่องกรอกแบบ masked input เป็นทางเลือกที่ช่วยชี้นำรูปแบบวันที่โดยไม่ต้องใช้ปฏิทิน
    • สามารถใช้ JavaScript เพื่อตรวจสอบและจัดรูปแบบข้อมูลฝั่งไคลเอนต์ได้
    • ตัวอย่าง: ข้อความผิดพลาด “กรุณาป้อนวันที่ที่ถูกต้องของเดือนกุมภาพันธ์ (1~28)”
    • ใช้ Intl API เพื่อจัดรูปแบบวันที่โดยอัตโนมัติ
  • อย่างไรก็ตาม หากใช้ JavaScript อัปเดตค่าที่ป้อน ฟังก์ชัน undo/redo อาจเสียได้
  • สามารถใช้ CSS รวมหลายช่องกรอกให้ดูเหมือนเป็นช่องเดียวกันในเชิงภาพได้

การเลือกช่วงและตัวเลือกที่จำกัด

  • ตัวเลือกวันที่แบบเลือกช่วง ที่ใช้ปฏิทินสองตัวนั้นใช้งานยาก และไม่สะดวกหากใช้งานโดยไม่มีอุปกรณ์ชี้ตำแหน่ง
    • ทางเลือกคือทำให้ง่ายขึ้นด้วย ช่องกรอกสองช่อง
  • หากต้องการให้เลือกได้เฉพาะวันที่ที่กำหนดไว้ สามารถแทนที่ด้วย กลุ่ม input แบบ radio ได้
    • เปลี่ยนจาก UI ที่ซับซ้อนเป็นขั้นตอนการทำงานที่เรียบง่ายและเป็นลำดับ
    • ฟอร์มหลายขั้นตอนสามารถขยายเป็นอินเทอร์แอ็กชันหน้าเดียวด้วย JavaScript ได้

การป้อนแบบอิสระและฟังก์ชันคำแนะนำ

  • เมื่อไม่จำเป็นต้องระบุวันที่·เวลาอย่างแม่นยำ ช่องกรอกข้อความพื้นฐาน ก็มีประโยชน์
  • หากใช้ datalist ก็สามารถแสดงคำแนะนำระหว่างพิมพ์ได้
    • ใช้งานร่วมกับชนิด input แบบ date, time ได้ด้วย

คำถามที่พบบ่อย

เมื่อใช้ JavaScript framework

  • เฟรมเวิร์กหลักทั้งหมดสามารถใช้งาน องค์ประกอบ HTML พื้นฐาน ได้
    • ไม่จำเป็นต้องสร้างเป็นคอมโพเนนต์แบบกำหนดเอง
    • สามารถทำ two-way state binding ผ่านพร็อพเพอร์ตี value ได้

การปรับสไตล์ตัวเลือกวันที่พื้นฐาน

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

การรับมือกับผู้มีส่วนได้ส่วนเสียที่ต้องการตัวเลือกวันที่ JavaScript

  • เป้าหมายคือ การส่งฟอร์มสำเร็จ และ UI ที่ซับซ้อนจะเพิ่มข้อผิดพลาด
    • ตัวเลือกวันที่ทุกแบบมีปัญหาด้านการเข้าถึง
    • การผสมใช้ input พื้นฐานเป็นมิตรกับผู้ใช้มากกว่า
    • UI JavaScript ที่ยังไม่ผ่านการพิสูจน์อาจขัดต่อข้อกำหนดอย่าง European Accessibility Act (EAA)
    • ความเรียบง่ายคือกุญแจสู่ความสำเร็จ

การทดสอบและการรับประกันด้านการเข้าถึง

  • จำเป็นต้องเข้าใจ แนวทางด้านการเข้าถึงอย่าง WCAG
    • ใช้มาตรฐานเว็บเพื่อหลีกเลี่ยงข้อผิดพลาดของ UI แบบกำหนดเอง
  • สามารถตรวจหาข้อผิดพลาดได้ด้วยฟีเจอร์ด้านการเข้าถึงในเครื่องมือสำหรับนักพัฒนาของเบราว์เซอร์
    • ไม่มีเครื่องมือใดสมบูรณ์แบบ และ การทดสอบกับผู้ใช้จริง คือวิธีตรวจสอบเพียงวิธีเดียว
  • ไม่แนะนำอย่างยิ่งให้ใช้ accessibility overlay เพราะอาจทำให้ปัญหาแย่ลง

แหล่งข้อมูลอ้างอิงด้านการเข้าถึง

  • Collecting dates in an accessible way — Graham Armfield
  • What makes an accessible date picker? — Russ Weakley
  • Maybe You Don’t Need a Date Picker — Adrian Roselli
  • Date Picker Dialog Example — ARIA Authoring Practices Guide
  • Designing The Perfect Date And Time Picker — Vitaly Friedman

คำตอบต่อคำขอแนะนำตัวเลือกวันที่ JavaScript

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

บทสรุป

  • การทดสอบกับผู้ใช้จริงและการเก็บ feedback เป็นสิ่งจำเป็น
  • คู่มือนี้ยังอยู่ระหว่างพัฒนา และยินดีรับ feedback

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

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

 
GN⁺ 2025-11-13
ความคิดเห็นจาก Hacker News
  • เมื่อหลายปีก่อนเคยทำแอปมือถือสำหรับผู้ป่วยของโรงพยาบาลท้องถิ่น ผู้ใช้จำนวนมากเป็นผู้สูงอายุ และมีคำบ่นถาโถมเข้ามาว่าตัวเลือกวันที่พื้นฐานของ OS ใช้งานยากเกินไป
    มีเรื่องอย่าง “ตั้งปีเกิดไม่ได้”, “ถ้าจะเลื่อนไปถึงวันเกิดของฉันต้องกดลูกศรเดือนก่อนหน้า 720 ครั้ง” เกิดขึ้นจริง
    ทั้ง iOS และ Android ในตอนนั้นแสดงปีเหมือนเป็นแค่หัวข้อ เลยไม่ถูกมองว่าเป็นองค์ประกอบที่คลิกได้
    รู้สึกว่า Flat Design ที่เน้นความสวยงามกำลังทำลาย UX ปัญหาคือความจริงที่ว่า UI ของ OS ถูกตัดสินโดยนักออกแบบเป็นหลัก ไม่ใช่ผู้เชี่ยวชาญ UX อย่าง Don Norman
    สุดท้ายพอเปลี่ยนเป็นรูปแบบกล่องข้อความ-ดรอปดาวน์-กล่องข้อความ (วัน-เดือน-ปี) เสียงบ่นก็หายไป
    • งานวิจัยของ ทีมออกแบบ Gov.uk ก็สรุปแบบเดียวกัน
      โดยบอกว่ากล่องข้อความสามช่อง (วัน เดือน ปี) ให้ประสบการณ์ที่ดีที่สุด
      และยังมี คู่มือแพตเทิร์น สำหรับการนำไปใช้ด้วย
    • ฉันเองก็จำได้ว่าตอนใช้ช่องกรอกนั้นครั้งแรก ต้องแตะเกิน 100 ครั้งแล้วคิดว่า ‘นี่มันแปลกนะ’ จนต้องไปค้นหา มันเป็น ฝันร้ายด้าน UX จริงๆ
    • มันไม่เป็นธรรมชาติเลยถึงขั้นที่เผลออุทานว่า “ปีมันกดได้ด้วยเหรอ??”
    • ฉันก็เคยงมหาวิธีเลื่อนปีในปฏิทินนั้นอยู่นานเหมือนกัน
    • แต่ก็สงสัยว่าทำไมตอนกรอกวันเดือนปีเกิดถึงต้องใช้ calendar picker ด้วย
  • ในกรณีที่กำหนดวันแน่นอนอยู่แล้ว เช่น การจองท่องเที่ยว การใช้วันที่แบบสัมพัทธ์อย่าง “วันนี้”, “พรุ่งนี้” อาจสะดวก
    แต่ถ้าจองเที่ยวบินแถวๆ เที่ยงคืน ก็จะสับสนว่า “วันนี้” อ้างอิงตามเขตเวลาของฉัน ของเซิร์ฟเวอร์ หรือ GMT
    • วันที่แบบสัมพัทธ์อย่าง “วันนี้”, “พรุ่งนี้” ฟังดูเป็นไอเดียที่ดี แต่การทำจริงคือ นรก
      มีข้อยกเว้นเยอะมาก ทั้งเขตเวลา เวลาออมแสง สิ้นเดือน (31 มกราคม → เดือนถัดไป?) หลังเที่ยงคืนทันที ฯลฯ
      ต้องคิดให้รอบคอบจริงๆ ก่อนใส่ฟีเจอร์แบบนี้
    • ระบบขนส่งสาธารณะของมอนทรีออลเคยใช้นาฬิกาแบบ 28 ชั่วโมง รถบัสหลังเที่ยงคืนจะแสดงเวลาอย่าง 27:30 ซึ่งชวนสับสนมาก
    • ฉันไม่ชอบที่คอมพิวเตอร์นิยามคำว่า ‘วันนี้’ โดยยึดเที่ยงคืนเป็นเกณฑ์
      เวลาทำงานเลยเที่ยงคืนไปแล้ว คำว่า “พรุ่งนี้” มันขัดกับความรู้สึกของความเป็นจริง
      ทั้งที่จริงๆ หมายถึง “หลังเช้าวันนี้” แต่ระบบกลับมองว่าเป็นวันถัดไป
    • แต่ไม่ว่าจะเป็น “วันนี้” หรือ “12 พฤศจิกายน” ถ้าเขตเวลาไม่ตรงกัน ปัญหาเดียวกัน ก็ยังเกิดขึ้น
  • จากประสบการณ์ทำงานกับ datepicker มานานกว่า 20 ปี ทางที่ดีที่สุดคือใช้ input type="text" แล้วใส่คำใบ้รูปแบบเอาไว้
    จะได้ไม่ต้องปวดหัวกับเรื่องเบราว์เซอร์ การเข้าถึง และ locale
    คอมโพเนนต์แบบคัสตอมคือ ประตูนรก ของจริง เผลอทำเท่แล้วตกลงไปในโพรงกระต่าย 10 ชั้น
    • ถ้าเป็นวันที่ผู้ใช้รู้อยู่แล้ว เช่น วันเกิด ก็โอเค แต่ถ้าหาเที่ยวบินแบบ “ประมาณวันศุกร์ต้นเดือนเมษายน” ก็ต้องมีปฏิทิน
      เพราะต้อง สำรวจวันที่ด้วยสายตา
    • ไม่ว่าจะใส่คำใบ้รูปแบบแบบไหน “3-9-1980” ก็ เชื่อถือไม่ได้ ว่าสำหรับผู้ใช้หมายถึง 9 มีนาคม หรือ 3 กันยายน
    • นี่เป็นคำแนะนำที่ไม่ดี ISO 8601 ใช้ได้กับวันที่ในอดีต แต่ไม่เหมาะกับการจองล่วงหน้าหรือตารางข้ามพรมแดน
      ปัญหาเรื่องวันที่ซับซ้อนมาก จนต้อง เลือกแนวทางตาม use case
    • ถึงอย่างนั้นก็ยังดีกว่าปฏิทินบนมือถือที่เลือกปีไม่ได้มาก
  • ตลกดีที่พูดเรื่อง internationalization แต่รองรับแค่รูปแบบวันที่แบบตะวันตก
    ถ้าจะสร้างระบบโรงพยาบาลในเนปาล ต้องรองรับทั้งปฏิทินเนปาลและปฏิทินสากล ปฏิทินเนปาลซับซ้อนมาก
    เอธิโอเปียใช้ปฏิทิน 13 เดือน โดยเดือนสุดท้ายมีแค่ 5~6 วัน
    ถ้าใครมีแหล่งอ้างอิงสำหรับ date picker ที่รองรับ internationalization อย่างจริงจัง ก็อยากรู้
  • บริบทของการกรอกวันที่ควรเป็นตัวตัดสินว่าจะใช้ picker แบบไหน
    ตัวอย่างเช่น การจองมื้อเย็น ปฏิทินมีประโยชน์เพราะช่วยดูความพร้อมของวันหยุดสุดสัปดาห์ แต่การกรอกวันเกิด การพิมพ์ตัวเลขเร็วๆ จะมีประสิทธิภาพกว่า
  • ในกรณีที่การไหลของการกรอกตัวเลขสำคัญ เช่น ตอนกรอกข้อมูลบัตรเครดิต
    ขั้นตอนแบบ “เลือกชื่อเดือน → ดรอปดาวน์ → เลือกปี” จะทำลายจังหวะ
    การกรอกเป็นตัวเลขล้วนดูเป็นธรรมชาติกว่ามาก บนมือถือยิ่งแย่เพราะคีย์บอร์ดเดี๋ยวเปิดเดี๋ยวปิด
  • การได้เห็น date picker ที่พิมพ์ด้วยคีย์บอร์ดได้โดยตรงทำให้รู้สึกสดใหม่
    การบังคับใช้คัสตอม picker แทน UI พื้นฐานดูแปลก
    โดยเฉพาะการเลียนแบบ ตัวเลือกเวลาแบบวงล้อหมุน สไตล์ iOS บนเว็บใน Android นี่แย่ที่สุด
  • ในฐานะคนเดนมาร์ก ฉันว่าชื่อ “Pikaday” ฟังดูขำ เพราะ “pik” ในภาษาเดนมาร์กเป็นคำสแลงเรียกอวัยวะเพศชาย
    • ถึงขั้นมีมุกว่า “งั้น Pokémon ก็ยังดังในเดนมาร์กเหรอ?”
  • แค่ Date, Time, DateTime picker ยังไม่พอ
    ยังต้องมีตัวเลือกแบบรายเดือน รายสัปดาห์ และช่วงกำหนดเองด้วย องค์ประกอบฟอร์มแบบเนทีฟยังจำกัดเกินไป
    • อยากรู้ว่านอกจาก Firefox ยังมีอะไรขาดอีกไหมสำหรับ <input type="week"> หรือ <input type="month">
    • ฉันอยากมี AI time picker ที่ยืมพลังจากโครนอส เทพเจ้ากรีก
  • อ้างอิงไว้ก่อนว่าบริบทของการถกเถียงนี้มาจาก บทความเกี่ยวกับ Pikaday
    • จำได้ว่าเมื่อก่อนก็เคยใช้ไลบรารี datepicker ชื่อ Pikaday เหมือนกัน