4 Punkte von GN⁺ 2023-10-15 | 3 Kommentare | Auf WhatsApp teilen
  • Relative Datumsangaben in Web-UIs wirken wie natürliche Sprache, stimmen aber oft nicht damit überein, wie Nutzer sich tatsächlich an Daten orientieren
  • Für Menschen bedeutet „yesterday“ den Vortag von 0:00 bis 23:59 Uhr und nicht einfach „weniger als 24 Stunden her“
  • Wenn sich die zugrunde liegende Logik je nach Implementierung unterscheidet, schwankt selbst innerhalb desselben Dienstes die Anzeige von „yesterday“, wodurch die Verlässlichkeit der Datumsanzeige sinkt
  • Formulierungen wie „vor 12 Tagen“, die vergangene Zeit nur als längere Zahl ausdrücken, passen nur bedingt zum natürlichen menschlichen Zeitgefühl
  • Auch „last week/month/year“ ist wegen des großen Bereichs mehrdeutig; bei Einträgen, die älter als gestern sind, ist ein konkretes Datum klarer

Warum relative Datumsangaben verwirrend sind

  • Ausdrücke wie „yesterday“, „2 days ago“ oder „a week ago“ wirken zwar wie menschliche Zeitangaben, sind für die tatsächliche Einordnung eines Datums aber nicht präzise genug
  • Gerade bei „yesterday“ ist die erwartete Bedeutung für Nutzer eindeutig
    • Es bedeutet den Vortag
    • Es bezeichnet den Zeitraum von 0:00 bis 23:59 Uhr des vorherigen Tages
    • Es ist nicht dasselbe wie die Rechenregel „weniger als 24 Stunden her“
  • Computer-Implementierungen können „yesterday“ unterschiedlich berechnen, und wenn die Anzeige selbst innerhalb desselben Dienstes abweicht, vertrauen Nutzer den Datumsangaben weniger

Bei älteren Einträgen ist ein Datum besser

  • Formulierungen wie „vor 12 Tagen“ passen nicht besonders gut zu den Zeiteinheiten, in denen Menschen üblicherweise denken
  • Auch „last week“, „last month“ und „last year“ lassen wegen ihres großen Umfangs Mehrdeutigkeit zurück
  • Bei Einträgen, die älter als gestern sind, ist es lesbarer und vertrauenswürdiger, statt relativer Angaben ein konkretes Datum anzuzeigen

3 Kommentare

 
cosine20 2024-12-02

Echt, bei GitHub genauso wie bei YouTube, hasse ich diese Angaben wie „vor ein paar Monaten“ oder „vor ein paar Jahren“. Wie auch in den HN-Kommentaren unten erwähnt wurde: „vor 1 Jahr“ ist in Wirklichkeit manchmal schon 1,5 Jahre her, das ist viel zu ungenau.

 
budlebee 2023-10-17

Dem kann ich wirklich zustimmen. Aus Sicht derjenigen, die so etwas entwickeln, ist es zwar praktisch, wenn man es als „vor xx Tagen“ anzeigt, weil man sich dann nicht um die je nach Land unterschiedlichen Datumsformate wie YY.MM.DD oder MMDDYYYY kümmern muss, aber ich finde eine Datumsangabe besser als „vor xx Tagen“.

 
GN⁺ 2023-10-15
Hacker-News-Kommentare
  • Insbesondere relative Zeitangaben werden viel zu ungenau.
    Bei YouTube kann „vor 1 Jahr“ alles von vor 365 Tagen bis vor 729 Tagen bedeuten.
    Um herauszufinden, welches von zwei Videos mit der Anzeige „vor 1 Jahr“ aktueller ist, muss man das Video tatsächlich öffnen und bis zur Beschreibung gehen, um das Datum zu sehen.

    • Es fühlt sich an, als hätten UI-Designer einen Wettbewerb für GUI-Mikroaggressionen veranstaltet, um Nutzer zu quälen, und der Trend „vor N Tagen“ hätte gewonnen und sich überall verbreitet.
      Ich will im Kopf keine Datumsrechnungen anstellen; zeigt mir einfach einen exakten Timestamp.
      Man sollte nicht Informationen über große Zeitspannen wie „vor 1 Jahr“ wegwerfen, sondern die tatsächliche Zeit anzeigen.
    • Noch interessanter ist, dass jede Website andere Rundungsregeln hat.
      YouTubes „vor 1 Jahr“ kann 365 bis 729 Tage zurückliegen, aber auf manchen Websites bedeutet es das nächstliegende Jahr, also 183 bis 548 Tage, und wieder andere runden bis 11 Monate auf Monate und behandeln dann 350 bis 548 Tage zurück als „vor 1 Jahr“.
      Anderswo gibt es auch Kriterien wie „innerhalb des letzten Kalenderjahres“, wodurch alles von vor 1 bis 365 Tagen bis hin zu vor 364 bis 729 Tagen möglich wird.
    • Jetzt ist Oktober 2023; wenn ein im November 2021 hochgeladenes Video als „vor 1 Jahr“ angezeigt wird, ist das falsch, es sollte „vor fast 2 Jahren“ heißen.
    • Selbst beim gleichen Datum wird abgerundetet, wenn die Uhrzeit später liegt.
      Auch wenn ein Video vom 14. Oktober 2021 zwei Jahre alt ist, kann es noch als vor 1 Jahr angezeigt werden, wenn es an diesem Tag zu einer späteren Uhrzeit hochgeladen wurde.
    • Man kann die Ungenauigkeit verringern, indem man vermeidet, dass die erste Zahl 1 ist, und auf kleinere Einheiten wechselt.
      Also zum Beispiel bis vor 120 Sekunden, bis vor 120 Minuten, bis vor 48 Stunden, bis etwa vor 61 Tagen und danach bis vor 24 Monaten anzeigen.
      Relative Datumsangaben in Listen sind meistens noch erträglich, aber das Problem, dass sie nicht aktualisiert werden, ist viel nerviger und wird nicht gelöst, indem man sie nur bis „gestern“ zulässt.
  • Das würde ich noch nachdrücklicher empfehlen.
    Zum Glück wird der Timestamp oft als Tooltip angezeigt.
    Wenn man sich zum Beispiel eine npm-Paketversion ansieht, steht dort so etwas wie „version 5.3.27 was released ‘about a year ago’“ — da fragt man sich wirklich, ob das ernst gemeint ist.
    Ich versuche, die Release-Reihenfolge alter Pakete zu verstehen, um eine kompatible Kombination festgepinntener Pakete zusammenzustellen, aber 20 aufeinanderfolgende Pakete werden alle als „vor etwa 1 Jahr“ angezeigt, sodass ich für jedes einzelne den Tooltip öffnen muss, um zu prüfen, ob es die neuere Version ist.
    Ein solches Design überschreitet eine Grenze und wirkt wie dieselbe Sorte Leute, die ORMs bauen, die unregelmäßige Tabellenamen im Singular und Plural mappen.

    • Tatsächlich gab es auch bei YouTube Tooltips.
      Ich weiß nicht, warum mir das nicht bewusst war; es ist ziemlich nützlich.
    • Es ist nicht verrückt, sondern einfach dumm — oder, wohlwollend formuliert, ignorant bis zur Inkompetenz.
    • Leute, die so etwas in Tools für Entwickler machen, sind auf kriminellem Niveau inkompetent.
      Erstaunlich ist nicht nur, dass solche Leute noch beschäftigt sind, sondern auch, dass sich diese dumme Praxis von npm über GitHub bis CircleCI überall verbreitet hat.
  • Darüber hinaus würde ich solche gerundeten relativen Timestamps am liebsten ganz abschaffen.
    Die iOS-Mail-App nervt besonders.
    Wenn man sie öffnet, steht dort „gerade aktualisiert“, aber wenn man zum Aktualisieren nach unten zieht, erscheint plötzlich eine ungelesene Mail, die vor 2 Stunden eingegangen ist.
    Zeigt einfach die genaue Uhrzeit an, zu der aktualisiert wurde.

    • Die dummen Timestamps von Benachrichtigungen sind noch schlimmer.
      Wenn man sie nicht innerhalb einer Stunde sieht, werden sie sofort ungenau, sodass man nur noch „vor 1 Stunde“ oder „vor 2 Stunden“ sieht.
      Manchmal muss man vielleicht unbedingt wissen, wann genau eine bestimmte Benachrichtigung eingegangen ist, aber es gibt keinerlei Möglichkeit, das zu prüfen.
      Zeigt einfach die Uhrzeit an; ich kann Uhrzeiten lesen.
    • Einer der Vorteile von Thunderbird ist, dass es noch das genaue Datum und die genaue Uhrzeit anzeigt.
      Wenn es heute ist, wird nur die Uhrzeit angezeigt, sonst das vollständige Datum samt Uhrzeit.
  • Wenn man absolute Zeiten verwendet, kann der Browser sie gemäß den Nutzerpräferenzen anzeigen.
    https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ti...

    • Der Traum des Webs, dass der Server nur Daten sendet und der Client die Darstellungsweise wählt, ist komplett tot.
      Webdesigner wollen, dass eine Website bis auf den Pixel genau eine bestimmte Form hat, und clientseitige Kontrolle über die Darstellung steht dem im Weg.
      Es ist zwar immer noch möglich, aber Websites werden nicht für diesen Zweck entworfen oder ihn aktiv unterstützen.
    • Ich weiß nicht, wie es für durchschnittliche Nutzer tatsächlich aussieht.
      Im Beispiel sieht die Ausgabe unter iOS/Safari so aus, als gäbe es das Tag gar nicht.
  • Besonders unpraktisch an unscharfen Datumsangaben ist es, wenn der Wochentag die wichtigste Information ist
    Wenn man sich zum Beispiel den GitLab-Verlauf ansieht, ist es viel nützlicher zu wissen, ob etwas an einem Freitag gemergt wurde, als „letzte Woche“ oder „vor 2 Tagen“ zu lesen
    Auch bei Chatverläufen kann es nahe einer Monatsgrenze wichtig sein, ob eine Unterhaltung vor oder nach dem Monatsanfang stattfand
    Auch sonst finde ich persönlich ein genaues Datum besser als die Angabe, ob es vor 4 Wochen oder vor 2 Monaten war, und durch ein genaues Datum geht auch keine Information verloren
    Ich kann mir kaum eine Situation vorstellen, in der ein unscharfes Datum nützlicher wäre als ein genaues Datum

    • Ich bin Mitglied des GitLab-Teams
      In GitLab kann man per Einstellung statt relativer Zeiten absolute Zeiten verwenden
      Beispiel: October 14, 2023 11:51AM
      https://docs.gitlab.com/ee/user/profile/preferences.html#sho...
    • Ich habe ein Greasemonkey-Skript geschrieben, das die nutzlosen Zeitlabels in Jira durch vollständige Datumsangaben mit Wochentag ersetzt
      Für häufig genutzte browserbasierte Software kann ich sehr empfehlen, so etwas einzusetzen
    • In sehr speziellen Fällen können unscharfe Datumsangaben nützlich sein
      Es gibt eine Anwendung, die Informationen aus einer anderen Datenbank holt, neu formatiert und den Nutzern anzeigt; die Aktualisierung ist teuer und dauert lange, daher muss sie bei Bedarf manuell vom Nutzer gestartet werden
      In diesem Fall ist der genaue Zeitpunkt der letzten Aktualisierung nicht besonders wichtig, sondern wie alt die Daten sind, also wie wahrscheinlich sie bereits von der Quelle abweichen
      Manche Informationen müssen schon nach wenigen Stunden aktualisiert werden, andere können auch noch okay sein, wenn sie 4 bis 5 Tage oder älter sind, sodass man keine Aktualisierung anstoßen muss, die bis zu 10 Minuten dauern kann
      Für diesen Zweck ist es nützlicher, das ungefähre Alter anzuzeigen als den Zeitpunkt der letzten Aktualisierung, und der Nutzer muss nicht mit der aktuellen Uhrzeit vergleichen und rechnen
      Das ist allerdings ein seltener Fall; meistens sind relative, unscharfe Datumsangaben weniger nützlich
    • Wenn man Menschen in mehreren Zeitzonen Zeiten in naher Zukunft mitteilt, sind relative Zeiten nützlich
      Etwa: „endet ungefähr 4–5 Stunden nach diesem Kommentar“ oder „ist behoben und startet den nächsten Lauf etwa 15 Stunden nach diesem Kommentar“
  • Die schlechteste App, die ich nutze und die Zeitstempel falsch anzeigt, ist gitg
    Man muss sich nur diesen Screenshot ansehen
    https://ubunlog.com/wp-content/uploads/2018/06/git-gui-gitg....
    Mehrere Commits werden als „vor 3 Tagen“ angezeigt; das ist nur ein bisschen besser als gar keine Information
    Man erfährt nicht, ob es vormittags oder nachmittags war, ob sie innerhalb einer Stunde gebündelt waren oder über den ganzen Tag verteilt
    Wenn ich Arbeitszeiten für Kunden nicht erfasst habe und sie eine Woche später schätzen muss, sind solche Informationen wichtig; dann muss ich jeden Commit einzeln anklicken und den Zeitstempel auf der anderen Seite des Bildschirms prüfen

    • Der Screenshot zeigt einen der wichtigen Gründe, warum vollständige Datumsangaben immer nötig sind
    • Outlook Webmail ist ebenfalls ziemlich schlecht
      Es zeigt nicht nur „vor ein paar Tagen“ an, sondern versucht auch, die Einträge, die es selbst für wichtig hält, ganz oben anzuzeigen
      Dadurch werden zwei Listen mit teilweisen Überschneidungen durcheinandergeworfen, was das Grauen verdoppelt
    • Git-Zeitstempel richten sich nach der lokalen Zeitzone der jeweiligen Entwickler und werden nicht validiert, was die Sache bei weltweiter Entwicklung noch schwieriger machen kann
      https://alesnosek.com/blog/2017/01/02/git-getting-the-timing...
    • Es ist erstaunlich, dass es in gitg offenbar keine Einstellung gibt, um immer vollständiges Datum und Uhrzeit anzuzeigen
    • Die Darstellungsweise im Screenshot wäre, gäbe es eine Branchenaufsicht, ein Kandidat für berufliches Fehlverhalten
  • Man kann einfach beides anzeigen
    „vor 1 Stunde (15:47)“
    „letzte Woche (MON 12 SEP 9:20)“
    „vor 2 Jahren (WED 14 APR 2021 11:47)“
    Das Datumsformat kann man nach Geschmack wählen

    • Im Frontend hat sich bewährt, auf der Seite relative Zeiten zu rendern und den echten Zeitstempel oder das Datumsformat in einen Tooltip zu legen
      Wer mehr Details sehen möchte, kann mit der Maus über das relative Datum fahren
    • Früher habe ich genaue Zeit- und Datumsinformationen in Tooltips gepackt, weil ich dachte: „Nutzer, die sie brauchen, können sie finden, ohne die UI zu überladen“
      Einige Jahre später zeigte sich in Nutzerinterviews, dass eine hyperlinkartige Unterstreichung allein Nutzer nicht dazu bringt, zu denken: „Hier sollte ich mit der Maus drüberfahren“; daher habe ich vieles davon wieder zurückgenommen
      Jetzt, wo Emojis und hochauflösende Displays verbreitet sind, frage ich mich, ob ein dezenter Tooltip-Hinweis per Fragezeichen- oder Lupen-Icon für ältere oder weniger geübte Nutzer ausreichen würde
    • Warum nicht einfach nur das Datum anzeigen?
  • Das Jahr sollte ebenfalls enthalten sein
    Es ist mir zu oft passiert, dass ein Webforum Kommentardaten nur als „5 Jul“ angezeigt hat und ich erst später gemerkt habe, dass der Kommentar schon mehrere Jahre alt war
    Inzwischen vertraue ich Datumsangaben ohne Jahr nicht mehr; wenn ich das Jahr nicht sofort sehe, suche ich es mir irgendwie heraus

    • Das Jahr sollte vierstellig sein
      Es gibt ein Forum, das ich ein paarmal pro Woche besuche und das 20–30 Jahre alt ist; dort stehen Daten wie 08/11/02 oder 09/03/04, was sehr verwirrend ist
  • „vor 1 Jahr“ ist möglicherweise nicht genau genug, aber „vor 11 Monaten“ reicht meistens aus
    Wenn ich solche Funktionen implementiere, vermeide ich eher die Zahl 1
    Also etwa „vor 6 Tagen“ statt „vor 1 Woche“

  • Wenn etwas bei Google oder web.archive.org archiviert wird, kann das Label, sofern es nicht clientseitig berechnet wird, zu einer relativen Zeit bezogen auf das Indexierungsdatum werden
    In Archiven ist außerdem gut möglich, dass JavaScript nicht richtig funktioniert
    Um Datumsangaben zugänglicher darzustellen, lohnt es sich außerdem, das time-Tag und das datetime-Attribut in Betracht zu ziehen
    https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ti...
    In Browsern unterscheidet es sich derzeit zwar kaum von einem span-Tag, aber es schadet nicht, Webseiten zukunftskompatibel zu machen