कल से पुराने आइटमों में वास्तविक तारीख दिखानी चाहिए

• वेब UI के relative date labels देखने में इंसानी भाषा जैसे लगते हैं, लेकिन वे अक्सर इस बात से मेल नहीं खाते कि उपयोगकर्ता वास्तव में तारीखों को कैसे याद करते हैं
• लोगों के लिए “yesterday” का मतलब आज से पिछला दिन, 0:00 से 23:59 तक होता है, सिर्फ “24 घंटे से कम” नहीं
• अगर हर implementation में आधार अलग हो, तो एक ही service के भीतर भी “yesterday” का दिखना बदलता रहता है और date display पर भरोसा कम हो जाता है
• “12 days ago” की तरह सिर्फ संख्या के साथ कई दिन पहले दिखाने का तरीका, समय को महसूस करने के इंसानी और स्वाभाविक तरीके से दूर है
• “last week/month/year” भी दायरे में बड़े और अस्पष्ट होते हैं, इसलिए कल से पुराने आइटमों को ठोस तारीख के साथ दिखाना ज्यादा स्पष्ट है

---

relative date labels उलझन क्यों पैदा करते हैं

• “yesterday”, “2 days ago”, “a week ago” जैसे भाव मानवीय समय अभिव्यक्ति जैसे लगते हैं, लेकिन वास्तविक तारीख समझने के लिए पर्याप्त रूप से सटीक नहीं होते
• खास तौर पर “yesterday” का मतलब वह है जिसकी उपयोगकर्ता स्पष्ट अपेक्षा करते हैं
  • इसका अर्थ आज से पिछला दिन है
  • यह पिछले दिन के 0:00 से 23:59 तक के समय को दर्शाता है
  • यह “24 घंटे से कम” जैसी गणना से अलग है
• कंप्यूटर implementations “yesterday” की गणना अलग-अलग तरह से कर सकती हैं, और अगर एक ही service में भी इसका प्रदर्शन बदलता रहे, तो उपयोगकर्ता तारीख संबंधी जानकारी पर कम भरोसा करते हैं

पुराने आइटमों को तारीख के रूप में दिखाना बेहतर है

• “12 days ago” जैसे भाव उस समय इकाई से अच्छी तरह मेल नहीं खाते, जिसमें लोग आम तौर पर समय के बारे में सोचते हैं
• “last week”, “last month”, “last year” भी दायरे में बड़े होते हैं, इसलिए अस्पष्टता बनी रहती है
• कल से पुराने आइटमों के लिए relative expressions की जगह विशिष्ट तारीख दिखाना पढ़ने और भरोसा करने, दोनों के लिए आसान है

[cosine20]

सच में, GitHub हो या YouTube, कुछ महीने पहले, कुछ साल पहले जैसी दिखावट बहुत नापसंद है। नीचे HN की राय में भी है, लेकिन 1 साल पहले का मतलब असल में 1.5 साल पहले भी हो सकता है, इसलिए यह बहुत अस्पष्ट है।

[budlebee]

यह बात सच में बहुत relatable लगती है। बनाने वाले के नज़रिए से देखें तो, xx दिन पहले दिखाने पर YY.MM.DD या mmddyyyy जैसी अलग-अलग देशों की date format की चिंता नहीं करनी पड़ती, लेकिन मुझे xx दिन पहले से बेहतर सीधे तारीख दिखाना लगता है।

[GN⁺]

Hacker News टिप्पणियाँ

• खासकर relative time display बहुत ज्यादा inaccurate हो जाता है
  YouTube पर “1 साल पहले” का मतलब 365 दिन पहले से लेकर 729 दिन पहले तक कुछ भी हो सकता है
  “1 साल पहले” दिखने वाले दो videos में कौन-सा ज्यादा हाल का है, यह जानने के लिए सच में video खोलकर description तक जाकर तारीख देखनी पड़ती है

  • ऐसा लगता है जैसे UI designers ने मिलकर users को परेशान करने वाली GUI microaggression competition रखी हो, और “N दिन पहले” trend जीतकर everywhere फैल गया हो
    दिमाग में date calculate नहीं करनी, बस exact timestamp दिखा दो
    “1 साल पहले” जैसे बड़े range की information फेंकने के बजाय real time दिखाना चाहिए
  • और मजेदार बात यह है कि हर site का rounding criterion अलग होता है
    YouTube का “1 साल पहले” 365~729 दिन पहले हो सकता है, लेकिन कोई site nearest year unit में 183~548 दिन पहले का मतलब लेती है, और कोई दूसरी site 11 महीने तक month unit में round करती है और फिर 350~548 दिन पहले को “1 साल पहले” मानती है
    कुछ और जगहों पर “पिछले calendar year के भीतर” जैसे criteria से 1~365 दिन पहले से लेकर 364~729 दिन पहले तक भी संभव हो जाता है
  • अभी अक्टूबर 2023 है, तो नवंबर 2021 में upload हुआ video “1 साल पहले” नहीं दिखना चाहिए, “लगभग 2 साल पहले” होना चाहिए
  • तारीख same हो, तब भी time देर का हो तो floor कर दिया जाता है
    14 अक्टूबर 2021 को upload हुआ video 2 साल पुराना हो सकता है, लेकिन अगर उसी दिन बाद के time पर upload हुआ था, तो अभी भी 1 साल पहले दिख सकता है
  • पहले number को 1 न आने दें और छोटी unit में बदल दें, तो inaccuracy कम हो सकती है
    उदाहरण के लिए 120 seconds पहले तक, 120 minutes पहले तक, 48 hours पहले तक, करीब 61 days पहले तक, और फिर 24 months पहले तक दिखाने जैसा
    lists में relative dates आम तौर पर tolerate हो जाती हैं, लेकिन update न होने की problem कहीं ज्यादा irritating है, और इसे सिर्फ “कल” तक limit करने से solve नहीं होगी

• मैं इसे और भी strongly recommend करना चाहूँगा
  अच्छी बात है कि कई बार timestamp tooltip में दिख जाता है
  जैसे npm package version देखते समय “version 5.3.27 was released ‘about a year ago’” जैसा दिखता है; यह देखकर लगता है, क्या ये लोग होश में हैं?
  पुराने packages के release order को समझकर compatible pinned package combination बनाना है, लेकिन लगातार 20 packages सब “लगभग 1 साल पहले” दिख रहे हैं, इसलिए हर एक का tooltip खोलकर confirm करना पड़ता है कि कौन-सा recent version है
  इस तरह का design हद पार कर चुका है, और यह उन लोगों जैसा लगता है जो irregular singular/plural table names map करने वाला ORM बनाते हैं

  • सच में YouTube में भी tooltip था
    पता नहीं मुझे क्यों नहीं पता था, और यह काफी useful है
  • यह होश में न होने की बात नहीं, बस बेवकूफी है, या ज्यादा अच्छा मानें तो incompetence के level तक की ignorance है
  • developer tools में ऐसा करने वाले लोग criminal level तक incompetent हैं
    हैरानी की बात यह है कि ऐसे लोग अभी भी employed हैं ही, साथ ही यह मूर्खतापूर्ण तरीका npm से लेकर GitHub और CircleCI तक everywhere फैल चुका है

• और आगे बढ़कर, मैं ऐसे rounded relative timestamps को पूरी तरह हटाना चाहूँगा
  iOS Mail app खास तौर पर irritating है
  खोलने पर “अभी-अभी updated” दिखाता है, लेकिन pull-to-refresh करने पर 2 घंटे पहले आया unread mail अचानक दिख जाता है
  बस यह exact time दिखा दो कि update कब किया था

  • notifications के stupid timestamps और भी खराब हैं
    एक घंटे के भीतर न देखो तो तुरंत inaccurate हो जाते हैं, और सिर्फ “1 घंटे पहले” या “2 घंटे पहले” ही दिखता है
    किसी notification के exactly कब आने की जानकारी जरूरी हो सकती है, लेकिन पता करने का कोई तरीका नहीं है
    बस time दिखाओ, और time मैं पढ़ सकता हूँ
  • Thunderbird की एक अच्छी बात यह है कि यह अभी भी exact date और time दिखाता है
    अगर आज है तो सिर्फ time दिखाता है, वरना पूरी date और time दिखाता है

• absolute time इस्तेमाल करें तो browser user preference format के हिसाब से display कर सकता है
  https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ti...

  • server सिर्फ data भेजे और client display method चुने—web का यह सपना पूरी तरह मर चुका है
    web designers चाहते हैं कि site pixel level तक एक खास shape में दिखे, और client-side display control उसमें बाधा डालता है
    अभी भी किया जा सकता है, लेकिन website ऐसी use case को ध्यान में रखकर design नहीं होगी या actively मदद नहीं करेगी
  • पता नहीं average user को असल में कैसा दिखेगा
    example में iOS/Safari output ऐसा दिखता है जैसे tag है ही नहीं

• धुंधली तारीख दिखाने में खास तौर पर दिक्कत तब होती है जब सप्ताह का दिन सबसे महत्वपूर्ण जानकारी हो
  उदाहरण के लिए GitLab इतिहास देखते समय यह जानना कि merge शुक्रवार को हुआ था, “पिछले हफ्ते” या “2 दिन पहले” से कहीं ज़्यादा उपयोगी होता है
  chat history में भी अगर तारीख महीने की सीमा के आसपास हो, तो यह महत्वपूर्ण हो सकता है कि बातचीत महीने की शुरुआत से पहले हुई थी या बाद में
  बाकी मामलों में भी, निजी तौर पर मुझे 4 हफ्ते पहले या 2 महीने पहले से ज़्यादा सटीक तारीख बेहतर लगती है, और सटीक तारीख देने से जानकारी कम भी नहीं होती
  यह कल्पना करना मुश्किल है कि धुंधली तारीख सटीक तारीख से ज़्यादा उपयोगी कब होगी

  • GitLab टीम का सदस्य हूँ
    GitLab में setting बदलने पर relative time के बजाय absolute time इस्तेमाल किया जा सकता है
    उदाहरण: October 14, 2023 11:51AM
    https://docs.gitlab.com/ee/user/profile/preferences.html#sho...
  • मैंने Jira के बेकार time labels को सप्ताह के दिन सहित पूरी तारीख में बदलने के लिए एक Greasemonkey script बनाई थी
    browser-आधारित software जिसे आप अक्सर इस्तेमाल करते हैं, उस पर ऐसी चीज़ें लागू करने की मैं जोरदार सिफारिश करता हूँ
  • बहुत खास मामलों में धुंधली तारीख उपयोगी हो सकती है
    एक application है जो दूसरे database से जानकारी लाकर उसे reformat करके users को दिखाती है, लेकिन update की लागत ज़्यादा है और इसमें समय लगता है, इसलिए ज़रूरत पड़ने पर user को इसे manually चलाना पड़ता है
    ऐसे में आखिरी update का सटीक समय बहुत महत्वपूर्ण नहीं होता; महत्वपूर्ण यह होता है कि data कितना पुराना है, यानी original से उसके अलग हो जाने की संभावना कितनी है
    कुछ जानकारी कुछ घंटे बीतते ही refresh करनी पड़ती है, लेकिन कुछ जानकारी 4–5 दिन से ज़्यादा पुरानी होने पर भी ठीक रहती है, इसलिए अधिकतम 10 मिनट लगने वाला update करने की ज़रूरत नहीं होती
    इस उद्देश्य के लिए आखिरी update time के बजाय लगभग कितनी पुरानी है यह दिखाना ज़्यादा उपयोगी है, और user को current time से तुलना करके हिसाब नहीं लगाना पड़ता
    हालांकि यह दुर्लभ मामला है और ज्यादातर स्थितियों में relative धुंधली तारीख कम उपयोगी होती है
  • अलग-अलग time zones में मौजूद लोगों को निकट भविष्य का समय बताने के लिए relative time उपयोगी होता है
    जैसे “इस comment के करीब 4–5 घंटे बाद खत्म होगा”, “ठीक हो गया है और इस comment के लगभग 15 घंटे बाद अगला run शुरू करेगा”

• timestamp गलत दिखाने वाली apps में, जिनका मैं इस्तेमाल करता हूँ, सबसे खराब gitg है
  यह screenshot देखिए
  https://ubunlog.com/wp-content/uploads/2018/06/git-gui-gitg....
  कई commits “3 दिन पहले” के रूप में दिखते हैं, जो जानकारी बिल्कुल न होने से बस थोड़ा बेहतर है
  यह पता नहीं चलता कि सुबह था या दोपहर, वे एक घंटे के अंदर clustered थे या पूरे दिन में फैले हुए थे
  जब client के काम का समय record नहीं हो पाया हो और एक हफ्ते बाद estimate करना पड़े, तो ऐसी जानकारी महत्वपूर्ण होती है, इसलिए हर commit पर अलग-अलग click करके screen के दूसरी तरफ timestamp देखना पड़ता है

  • screenshot उन महत्वपूर्ण कारणों में से एक है कि पूरी तारीख दिखाना हमेशा क्यों ज़रूरी है
  • Outlook webmail भी काफी खराब है
    वह सिर्फ “कुछ दिन पहले” नहीं दिखाता, बल्कि जिन items को वह महत्वपूर्ण समझता है उन्हें ऊपर दिखाने की कोशिश भी करता है
    इसलिए दो lists, जिनमें कुछ items duplicate होते हैं, आपस में मिल जाती हैं और भयानकपन दोगुना हो जाता है
  • git timestamps हर developer के local time zone के मुताबिक होते हैं और verified नहीं होते, इसलिए global development में यह और मुश्किल हो सकता है
    https://alesnosek.com/blog/2017/01/02/git-getting-the-timing...
  • हैरानी की बात है कि gitg में हमेशा पूरी तारीख·समय दिखाने की कोई setting दिखती नहीं
  • screenshot में दिखाया गया तरीका, अगर industry regulator होता, तो professional misconduct का उम्मीदवार होता

• दोनों दिखा दीजिए
  “1 घंटे पहले (15:47)”
  “पिछले हफ्ते (MON 12 SEP 9:20)”
  “2 साल पहले (WED 14 APR 2021 11:47)”
  date format पसंद के हिसाब से रख सकते हैं

  • frontend में page पर relative time render करना और tooltip में असली timestamp या date format डालना उपयोगी रहा
    जिसे ज्यादा detail देखनी हो वह relative date पर mouse hover कर ले
  • पहले मैं exact time/date जानकारी tooltip में डालता था, यह सोचकर कि “जिन users को ज़रूरत है वे UI को overload किए बिना इसे ढूंढ सकते हैं”
    कुछ साल बाद user interviews में पता चला कि सिर्फ hyperlink-style underline से users यह नहीं सोचते कि “मुझे यहाँ mouse hover करना चाहिए”, इसलिए मैंने काफी कुछ वापस बदला
    अब जब emojis और high-resolution displays आम हैं, तो सोचता हूँ कि क्या परेशान करने वाले question mark या magnifying glass image से tooltip hint देना उम्रदराज़ या कम skilled users के लिए काफी होगा
  • सिर्फ तारीख ही क्यों नहीं दिखा देते?

• साल भी शामिल होना चाहिए
  web forums में comment date सिर्फ “5 Jul” जैसी दिखती है, और बहुत बार बाद में ही पता चला कि वह comment कई साल पुराना था
  अब मैं बिना साल वाली तारीखों पर भरोसा नहीं करता, और अगर शुरू से साल न दिखे तो किसी तरह उसे ढूंढता हूँ

  • साल 4 अंकों में होना चाहिए
    एक forum है जहाँ मैं हफ्ते में कुछ बार जाता हूँ, और वह 20–30 साल पुराना है; वहाँ dates 08/11/02, 09/03/04 जैसी दिखती हैं, जिससे बहुत confusion होता है

• “1 साल पहले” पर्याप्त सटीक नहीं हो सकता, लेकिन “11 महीने पहले” आम तौर पर पर्याप्त होता है
  ऐसी function implement करते समय मैं 1 संख्या से बचता हूँ
  जैसे “1 हफ्ते पहले” के बजाय “6 दिन पहले” दिखाना

• अगर Google या web.archive.org जैसी जगहों पर archive हो जाए, तो label, जब तक client side पर calculate न हो, indexing date के आधार पर relative time बन सकता है
  archives में JavaScript भी शायद ठीक से काम न करे
  तारीख को ज्यादा accessible दिखाने के लिए time tag और datetime attribute इस्तेमाल करने पर भी विचार किया जा सकता है
  https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ti...
  अभी browsers में यह span tag से बहुत अलग नहीं है, लेकिन webpage को future-compatible बनाने में कोई नुकसान नहीं है