ควรแสดงวันที่จริงสำหรับรายการที่เก่ากว่าเมื่อวาน
(grumpy.website)- ป้ายวันที่แบบสัมพัทธ์ ในเว็บ UI ดูเหมือนภาษาที่มนุษย์ใช้ แต่บ่อยครั้งไม่ตรงกับวิธีที่ผู้ใช้คิดถึงวันที่จริง
- สำหรับคนทั่วไป “yesterday” หมายถึง ช่วง 00:00–23:59 ของวันก่อนวันนี้ ไม่ใช่แค่ “น้อยกว่า 24 ชั่วโมง”
- หากแต่ละ implementation ใช้เกณฑ์ต่างกัน แม้จะอยู่ในบริการเดียวกัน การแสดง “yesterday” ก็อาจไม่นิ่ง ทำให้ ความน่าเชื่อถือของการแสดงวันที่ ลดลง
- วิธีแสดงว่า “12 days ago” โดยใช้ตัวเลขบอกว่าเป็นกี่วันก่อนแบบยาว ๆ เพียงอย่างเดียว ห่างไกลจากความรู้สึกเรื่องเวลาที่คนใช้กันตามธรรมชาติ
- “last week/month/year” ก็มีช่วงกว้างและกำกวม ดังนั้นรายการที่เก่ากว่าเมื่อวานควรแสดงเป็น วันที่ที่ชัดเจน จะเข้าใจได้ชัดกว่า
ทำไมป้ายวันที่แบบสัมพัทธ์จึงทำให้งง
- คำอย่าง “yesterday”, “2 days ago”, “a week ago” ดูเหมือนเป็น การบอกเวลาแบบมนุษย์ แต่ในทางปฏิบัติยังไม่แม่นพอสำหรับการตัดสินว่าเป็นวันไหน
- โดยเฉพาะ “yesterday” มีความหมายที่ผู้ใช้คาดหวังไว้อย่างชัดเจน
- หมายถึงวันก่อนวันนี้
- ชี้ไปที่ช่วง 00:00 ถึง 23:59 ของวันก่อน
- ไม่เหมือนกับสูตรคำนวณแบบ “น้อยกว่า 24 ชั่วโมง”
- ระบบคอมพิวเตอร์อาจคำนวณ “yesterday” ไม่เหมือนกัน และถ้าแม้แต่ภายในบริการเดียวกันยังแสดงต่างกัน ผู้ใช้ก็จะเชื่อถือข้อมูลวันที่น้อยลง
รายการที่เก่ากว่าควรแสดงเป็นวันที่จะดีกว่า
- คำอย่าง “12 days ago” ไม่ค่อยสอดคล้องกับหน่วยเวลาที่คนทั่วไปใช้คิดตามธรรมชาติ
- “last week”, “last month”, “last year” ก็ยังมี ความกำกวม เพราะช่วงเวลากว้าง
- สำหรับรายการที่เก่ากว่าเมื่อวาน การแสดงเป็น วันที่ที่ระบุชัดเจน แทนคำแบบสัมพัทธ์ จะอ่านง่ายกว่าและน่าเชื่อถือกว่า
3 ความคิดเห็น
GitHub เองก็จริง YouTube เองก็จริง ผมเกลียดการแสดงผลแบบหลายเดือนก่อน หลายปีก่อนมาก ด้านล่างในความเห็นของ HN ก็มีพูดไว้เหมือนกันว่า 1 ปีก่อน ทั้งที่จริง ๆ แล้วอาจเป็น 1 ปีครึ่งก่อนก็ได้ มันกำกวมเกินไปครับ
อันนี้เห็นด้วยมากเลยนะครับ ในมุมคนทำ ถ้าแสดงเป็น "เมื่อ 〇〇 วันที่แล้ว" ก็ไม่ต้องกังวลเรื่องรูปแบบวันที่ที่ต่างกันในแต่ละประเทศ เช่น จะใช้ YY.MM.DD หรือ mmddyyyy อะไรทำนองนั้น แต่สำหรับผม ชอบแสดงเป็นวันที่มากกว่าแสดงว่า 〇〇 วันที่แล้ว
ความคิดเห็นจาก Hacker News
โดยเฉพาะ การแสดงเวลาแบบสัมพัทธ์ จะคลาดเคลื่อนเกินไป
บน YouTube คำว่า “1 ปีที่แล้ว” อาจหมายถึงได้ตั้งแต่ 365 วันก่อนจนถึง 729 วันก่อน
ถ้าจะรู้ว่าวิดีโอสองรายการที่แสดงว่า “1 ปีที่แล้ว” อันไหนใหม่กว่า ก็ต้องเปิดวิดีโอจริง ๆ แล้วไปดูวันที่ในช่องคำอธิบาย
ไม่อยากคำนวณวันที่ในหัว ก็แค่แสดง timestamp ที่แม่นยำมาก็พอ
ไม่ควรทิ้งข้อมูลเป็นช่วงกว้าง ๆ แบบ “1 ปีที่แล้ว” แต่ควรแสดงเวลาจริง
“1 ปีที่แล้ว” ของ YouTube อาจเป็น 365~729 วันก่อน แต่บางไซต์หมายถึง 183~548 วันก่อนโดยปัดเป็นหน่วยปีที่ใกล้ที่สุด และบางไซต์ก็ปัดเป็นหน่วยเดือนจนถึง 11 เดือน แล้วนับ 350~548 วันก่อนเป็น “1 ปีที่แล้ว”
ส่วนบางแห่งใช้เกณฑ์อย่าง “ภายในปีปฏิทินที่ผ่านมา” ทำให้เป็นไปได้ตั้งแต่ 1~365 วันก่อน ไปจนถึง 364~729 วันก่อน
วิดีโอที่อัปโหลดวันที่ 14 ตุลาคม 2021 แม้จะเป็น 2 ปีที่แล้ว แต่ถ้าอัปโหลดในเวลาที่ช้ากว่าในวันนั้น ก็อาจยังแสดงว่า 1 ปีที่แล้วได้
เช่น แสดงจนถึง 120 วินาทีก่อน, จนถึง 120 นาทีก่อน, จนถึง 48 ชั่วโมงก่อน, จนถึงประมาณ 61 วันก่อน แล้วหลังจากนั้นแสดงจนถึง 24 เดือนก่อน
วันที่แบบสัมพัทธ์ในรายการโดยรวมยังพอทนได้ แต่ ปัญหาที่มันไม่อัปเดต น่าหงุดหงิดกว่ามาก และการจำกัดไว้แค่ “เมื่อวาน” ก็ไม่ได้แก้ปัญหา
อยากสนับสนุนเรื่องนี้ให้แรงกว่านี้อีก
โชคดีที่หลายกรณี timestamp จะแสดงเป็น tooltip
เช่นตอนดูเวอร์ชันแพ็กเกจ npm มันขึ้นประมาณว่า “version 5.3.27 was released ‘about a year ago’” นี่เสียสติไปแล้วหรือไง
กำลังพยายามดูว่าบรรดาแพ็กเกจเก่า ๆ ออกตามลำดับไหน เพื่อจัดชุดการ pin แพ็กเกจที่เข้ากันได้ แต่แพ็กเกจ 20 ตัวติดกันทั้งหมดแสดงว่า “ประมาณ 1 ปีที่แล้ว” เลยต้องเปิด tooltip ทีละอันเพื่อดูว่าเป็นเวอร์ชันใหม่หรือไม่
การออกแบบแบบนี้ล้ำเส้นไปแล้ว และดูเป็นพวกเดียวกับคนที่ทำ ORM ที่คอยแมปชื่อตารางเอกพจน์·พหูพจน์แบบไม่สม่ำเสมอ
ไม่รู้เหมือนกันว่าทำไมถึงไม่เคยรู้ และมันค่อนข้างมีประโยชน์
ที่น่าทึ่งคือคนพวกนั้นไม่เพียงยังมีงานทำอยู่ แต่แนวทางโง่ ๆ นี้ยังแพร่ไปทั่วทุกที่ ตั้งแต่ npm ไปจนถึง GitHub และ CircleCI
ยิ่งไปกว่านั้น อยากให้เลิกใช้ timestamp แบบสัมพัทธ์ที่ถูกปัดเศษ พวกนี้ไปเลย
แอป iOS Mail น่าหงุดหงิดเป็นพิเศษ
เปิดขึ้นมาก็ขึ้นว่า “อัปเดตเมื่อครู่นี้” แต่พอดึงเพื่อรีเฟรช อีเมลที่ยังไม่ได้อ่านซึ่งได้รับมาเมื่อ 2 ชั่วโมงก่อนกลับโผล่มาเฉย
แค่แสดงเวลาที่อัปเดตอย่างแม่นยำมาก็พอ
ถ้าไม่ได้ดูภายในหนึ่งชั่วโมง มันก็คลาดเคลื่อนทันที เหลือให้เห็นแค่ว่า “1 ชั่วโมงที่แล้ว” หรือ “2 ชั่วโมงที่แล้ว”
บางครั้งเราอาจจำเป็นต้องรู้แน่ชัดว่าการแจ้งเตือนหนึ่งเข้ามาเมื่อไหร่ แต่ไม่มีทางตรวจสอบเลย
แค่แสดงเวลาก็พอ และเวลาฉันอ่านเองได้
ถ้าเป็นวันนี้จะแสดงแค่เวลา ส่วนวันอื่น ๆ จะแสดงวันที่และเวลาเต็ม
ถ้าใช้เวลาแบบ absolute เบราว์เซอร์ก็สามารถแสดงตามรูปแบบที่ผู้ใช้ต้องการ ได้
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ti...
นักออกแบบเว็บต้องการให้ไซต์มีหน้าตาเฉพาะเจาะจงถึงระดับพิกเซล และการควบคุมการแสดงผลฝั่งไคลเอนต์ก็ขัดขวางสิ่งนั้น
มันยังทำได้อยู่ก็จริง แต่เว็บไซต์คงไม่ได้ออกแบบมาโดยคำนึงถึงการใช้งานแบบนั้น หรือช่วยสนับสนุนอย่างจริงจัง
ในตัวอย่าง output ของ iOS/Safari ดูเหมือนไม่มีแท็กเลย
สิ่งที่ไม่สะดวกเป็นพิเศษในการแสดงวันที่แบบคลุมเครือคือเมื่อ วันในสัปดาห์เป็นข้อมูลที่สำคัญที่สุด
เช่น เวลาดูประวัติใน GitLab การรู้ว่าถูก merge ในวันศุกร์หรือไม่นั้นมีประโยชน์กว่าคำว่า “สัปดาห์ที่แล้ว” หรือ “2 วันที่แล้ว” มาก
ประวัติแชตก็เช่นกัน ถ้าอยู่ใกล้ช่วงรอยต่อของเดือน การรู้ว่าบทสนทนาเกิดก่อนหรือหลังต้นเดือนอาจสำคัญ
ในกรณีอื่น ๆ โดยส่วนตัวแล้ว วันที่ที่แม่นยำก็ดีกว่าการบอกว่า 4 สัปดาห์ก่อนหรือ 2 เดือนก่อน และการให้วันที่ที่แม่นยำก็ไม่ได้ทำให้ข้อมูลลดลง
นึกภาพสถานการณ์ที่วันที่แบบคลุมเครือมีประโยชน์กว่าวันที่ที่แม่นยำได้ยาก
ใน GitLab ถ้าเปลี่ยนการตั้งค่า จะใช้ เวลาแบบสัมบูรณ์ แทนเวลาแบบสัมพัทธ์ได้
ตัวอย่าง: October 14, 2023 11:51AM
https://docs.gitlab.com/ee/user/profile/preferences.html#sho...
ขอแนะนำอย่างยิ่งให้ทำแบบนี้กับซอฟต์แวร์บนเบราว์เซอร์ที่ใช้บ่อย
มีแอปพลิเคชันที่ดึงข้อมูลจากฐานข้อมูลอื่นมาจัดรูปแบบใหม่แล้วแสดงให้ผู้ใช้ดู แต่การอัปเดตมีต้นทุนสูงและใช้เวลานาน จึงต้องให้ผู้ใช้สั่งรันเองเมื่อจำเป็น
ในกรณีนี้ เวลาที่แน่นอนของการอัปเดตล่าสุดไม่ค่อยสำคัญเท่าไร สิ่งที่สำคัญคือข้อมูลเก่าแค่ไหน หรือมีโอกาสคลาดเคลื่อนจากต้นทางมากเพียงใด
ข้อมูลบางอย่างต้องรีเฟรชแม้ผ่านไปเพียงไม่กี่ชั่วโมง แต่ข้อมูลบางอย่างแม้จะเก่า 4–5 วันขึ้นไปก็ยังใช้ได้ จึงไม่จำเป็นต้องอัปเดตซึ่งอาจใช้เวลาถึง 10 นาที
สำหรับจุดประสงค์นี้ การแสดง ความเก่าโดยประมาณ มีประโยชน์กว่าการแสดงเวลาอัปเดตล่าสุด และผู้ใช้ก็ไม่ต้องคำนวณเทียบกับเวลาปัจจุบันเอง
อย่างไรก็ตาม นี่เป็นกรณีที่พบไม่บ่อย และส่วนใหญ่วันที่แบบคลุมเครือเชิงสัมพัทธ์จะมีประโยชน์น้อยกว่า
เช่น “จะจบประมาณ 4–5 ชั่วโมงหลังคอมเมนต์นี้”, “แก้แล้ว และจะเริ่มรอบถัดไปประมาณ 15 ชั่วโมงหลังคอมเมนต์นี้”
แอปที่แสดง timestamp แย่ที่สุดในบรรดาที่ผมใช้คือ gitg
ดูสกรีนช็อตนี้ได้
https://ubunlog.com/wp-content/uploads/2018/06/git-gui-gitg....
มีหลาย commit ที่แสดงว่า “3 วันที่แล้ว” ซึ่งดีกว่าไม่มีข้อมูลเลยแค่นิดเดียว
ไม่รู้ว่าเป็นช่วงเช้าหรือบ่าย กระจุกอยู่ในช่วงหนึ่งชั่วโมงหรือกระจายตลอดทั้งวัน
เวลาบันทึกเวลาทำงานให้ลูกค้าไม่ทันและต้องมาประเมินย้อนหลังหนึ่งสัปดาห์ ข้อมูลแบบนี้สำคัญมาก จึงต้องคลิก commit ทีละรายการแล้วดู timestamp ที่อีกฝั่งของหน้าจอ
ไม่ใช่แค่แสดงว่า “หลายวันที่แล้ว” เท่านั้น แต่ยังพยายามเอารายการที่มันตัดสินว่าสำคัญมาไว้ด้านบน
ทำให้รายการสองชุดที่ซ้ำกันบางส่วนถูกปนกันออกมา และความแย่ก็เพิ่มเป็นสองเท่า
https://alesnosek.com/blog/2017/01/02/git-getting-the-timing...
ก็แสดงทั้งสองอย่างไปเลย
“1 ชั่วโมงก่อน (15:47)”
“สัปดาห์ที่แล้ว (MON 12 SEP 9:20)”
“2 ปีก่อน (WED 14 APR 2021 11:47)”
รูปแบบวันที่ก็แล้วแต่ความชอบ
คนที่อยากดูรายละเอียดเพิ่มก็เอาเมาส์ไปชี้เหนือวันที่แบบสัมพัทธ์ได้
หลายปีต่อมา การสัมภาษณ์ผู้ใช้เผยว่า แค่ขีดเส้นใต้แบบลิงก์ไม่ทำให้ผู้ใช้คิดว่า “ควรเอาเมาส์ไปชี้ตรงนี้” จึงต้องย้อนกลับแก้ไปมาก
ตอนนี้ที่อีโมจิและจอความละเอียดสูงเป็นเรื่องปกติแล้ว ก็สงสัยว่าการให้ สัญญาณว่ามี tooltip ด้วยรูปเครื่องหมายคำถามหรือแว่นขยายที่ไม่รบกวนสายตา จะเพียงพอสำหรับผู้ใช้ที่อายุมากกว่าหรือไม่ค่อยชำนาญหรือเปล่า
ควรรวมปีด้วย
เคยเจอบ่อยมากที่เว็บฟอรัมแสดงวันที่คอมเมนต์แค่แบบ “5 Jul” แล้วมารู้ทีหลังว่าคอมเมนต์นั้นเป็นโพสต์เมื่อหลายปีก่อน
ตอนนี้ผม ไม่เชื่อวันที่ที่ไม่มีปี อีกต่อไป และถ้าไม่เห็นปีตั้งแต่แรกก็จะพยายามหาปีให้ได้
มีฟอรัมหนึ่งที่เข้าไปหลายครั้งต่อสัปดาห์ เป็นเว็บอายุ 20–30 ปีแล้ว วันที่ถูกพิมพ์แบบ 08/11/02, 09/03/04 ทำให้สับสนมาก
“1 ปีก่อน” อาจไม่แม่นยำพอ แต่ “11 เดือนก่อน” โดยทั่วไปก็เพียงพอ
เวลาเขียนฟังก์ชันแบบนี้ ผมมักหลีกเลี่ยง ตัวเลข 1
เช่น แสดงว่า “6 วันที่แล้ว” แทน “1 สัปดาห์ก่อน”
ถ้าถูกเก็บไว้ในที่อย่าง Google หรือ web.archive.org ป้ายเวลาอาจกลายเป็นเวลาแบบสัมพัทธ์ที่อิงจาก วันที่ถูกจัดทำดัชนี เว้นแต่ว่าป้ายนั้นคำนวณฝั่งไคลเอนต์
ใน archive เอง JavaScript ก็มีโอกาสทำงานไม่ถูกต้องด้วย
นอกจากนี้ หากต้องการแสดงวันที่ให้เข้าถึงได้มากขึ้น ก็ควรพิจารณาใช้แท็ก
timeกับแอตทริบิวต์datetimehttps://developer.mozilla.org/en-US/docs/Web/HTML/Element/ti...
ตอนนี้ในเบราว์เซอร์ยังไม่ต่างจากแท็ก
spanมากนัก แต่การทำให้เว็บเพจรองรับอนาคตไว้ก็ไม่เสียหาย