Was ist ein Dickover?

 (daringfireball.net)
1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • dickover ist ein Hindernis, bei dem eine Website oder App ihren eigenen Inhalt mit einem Modal-Panel, Popover oder einer vorhangartigen UI verdeckt und unnötige Interaktionen erzwingt
  • Typische Beispiele sind Aufforderungen, die nichts direkt mit dem Inhalt zu tun haben, den Nutzer eigentlich lesen wollten, etwa Cookie-Akzeptanz, Newsletter-Anmeldung, App-Installation oder Zustimmung zu Nutzungsbedingungen
  • Zu den wichtigsten Beispielen gehören der Vollbild-Vorhang auf der Substack-Startseite, die SMS-Anmeldepflicht des Philadelphia Inquirer und der Z-Achsen-Konflikt bei Tom’s Hardware
  • dickbar verdeckt nur einen Teil der Seite und verlangt weniger zwingende Aktionen, verschlechtert aber dennoch das Erlebnis, indem es Text überdeckt und das Scrollen mit der Leertaste stört
  • Anmelde- oder Login-Dialoge bei Paywalls unterscheiden sich von dickovern, weil sie für den Zugriff auf Inhalte erforderlich sind; das entscheidende Kriterium ist die Unnötigkeit und das Unterbrechen der Aufmerksamkeit

Definition und Problem von Dickover

  • dickover bezeichnet ein Modal-Panel, Popover oder eine vorhangartige UI, mit der eine Website oder App ihren eigenen Inhalt absichtlich verdeckt
  • Es behindert den Zugriff auf Inhalte, indem es Interaktionen erzwingt, die Nutzer weder wollen noch brauchen
  • Typische Forderungen sind Cookie-Akzeptanz, Newsletter-Abonnements, die Installation mobiler Apps oder die Zustimmung zu Nutzungsbedingungen — also Dinge, die nichts direkt mit dem Inhalt zu tun haben, den Nutzer eigentlich lesen wollten
  • Solche Elemente erscheinen im Web und in mobilen Apps immer häufiger und unterbrechen den Lesefluss direkter als gewöhnliche Popover

Häufige Typen und Beispiele

  • Dickover zur Aufforderung, Cookies zu erlauben, ist sehr verbreitet; Beispiele sind Euronews und Gallup
  • Auch Newsletter-Anmeldungen folgen diesem Muster, darunter das persönliche Blog-Beispiel von Om Malik und das Markenwebsite-Beispiel von Field Notes
  • Auf von Substack gehosteten Blog-Homepages erscheint eine besonders üble Form des dickover
    • Ein Vollbild-Vorhang, der nicht wie ein Panel wirkt, suggeriert stark, dass man sich für den E-Mail-Newsletter anmelden müsse, um den Text lesen zu können
    • Der Schließen-Button ist als kleiner Textlink platziert, der nicht wie ein Button aussieht
    • Die Beispiele von Paul Krugman und Matt Yglesias verwenden Formulierungen wie „No thanks“
    • Das Beispiel Volts nutzt übertrieben süßliche Formulierungen wie „Just gimme that content!“
  • Das Beispiel des Philadelphia Inquirer zwingt sogar 20-Dollar-Abonnenten im eingeloggten Zustand dazu, SMS zu Jersey-Shore-Themen zu abonnieren, bevor sie den Artikel lesen können
  • Das Beispiel von Tom’s Hardware zeigt einen JavaScript-Z-Achsen-Konflikt, bei dem das dickover der Website erneut von ihrer eigenen Werbung verdeckt wird

Was eine Webseite tun sollte

  • Beim Besuch einer Website sollten Nutzer den Inhalt der Website sofort sehen können
  • Auf einer Artikelseite zuerst ein Dickover für „Newsletter abonnieren“ oder „Cookies akzeptieren“ anzuzeigen, widerspricht dem grundlegenden Zweck einer Webseite
  • Eine Webseite sollte eine Webseite zeigen, und eine E-Mail sollte ihren E-Mail-Inhalt zeigen
  • Das Interesse, das Nutzer einem Artikel, einer Story oder Produktseite schenken, ist ein Privileg, das die Website erhalten hat — dieses Interesse absichtlich zu unterbrechen, ist unangebracht

Warum der Anzeigezeitpunkt noch stärker stört

  • Manche Websites zeigen ein dickover direkt nach dem Laden der Seite; Nutzer erwarten heute beim Laden von Webseiten bis zu einem gewissen Grad solche Hindernisse
  • Noch schlimmer ist es, wenn ein plötzliches dickover erst erscheint, nachdem Nutzer schon mit dem Lesen begonnen und nach unten gescrollt haben
  • Eine Unterbrechung mitten im Lesen unterscheidet sich kaum davon, jemandem ein echtes Buch oder Magazin aus der Hand zu reißen, nur um etwas anderes als die bereits geschenkte Aufmerksamkeit zu verlangen
  • So wie man im übertragenen Sinn einen Schlag ins Gesicht riskieren würde, wenn man jemandem eine physische Publikation aus der Hand nimmt, ist auch die Unterbrechung des Leseerlebnisses entsprechend aggressiv

Unterschied zu Dickbar

  • Dickbar ist mit dickover verwandt, gilt aber in Bezug auf Design und Nutzererlebnis als leichtere Verfehlung
  • dickbar ist ein nicht-modales Popover, das nicht den gesamten zugrunde liegenden Inhalt, sondern nur einen Teil davon verdeckt
  • Dickbar ist relativ gesehen weniger schlimm, weil es nicht die ganze Seite verdeckt und keine zwingende Aktion zum Schließen verlangt
  • Trotzdem verschlechtert dickbar die Nutzererfahrung, weil es Inhalte verdeckt und Aufmerksamkeit ablenkt
  • Besonders die häufigste horizontale Form des dickbar verursacht Probleme beim seitenweisen Scrollen mit der Leertaste
    • Die Seite scrollt um die volle Webseitenhöhe, ohne die Höhe des dickbar abzuziehen
    • Dadurch verdeckt das dickbar bei jedem Wechsel zur nächsten Ansicht Text, der noch nicht gelesen wurde

Die Grenze zwischen Modal-Blockern und Dickover

  • Jedes dickover ist ein modaler Blocker, aber nicht jeder modale Blocker ist ein dickover
  • Anmelde- oder Login-Panels für kostenpflichtige Inhalte sind kein dickover
  • Paywalls können zwar manchmal lästig sein, aber eines der Kernkriterien von dickover ist Unnötigkeit
  • Cookie-Berechtigungsanfragen und Aufforderungen zur Anmeldung für E-Mail-Newsletter sind nicht erforderlich, um Inhalte zu lesen
  • Bei Paywall-Inhalten dagegen sind Anmeldung oder Login notwendig, weshalb sie von dickovern zu unterscheiden sind

Wie der Begriff entstanden ist

  • 2022 begann man, solche UI-Elemente dickpanel zu nennen, später setzte sich jedoch dickover als passendere Bezeichnung durch
  • Der neue Begriff kam bei dem Versuch auf, über das Drag-and-drop-„Shelf“-Utility Dropover für den Mac zu schreiben
  • Kurz zuvor gab es einen Beschwerdeeintrag über den besonders lächerlichen Cookie-Modal-Blocker von Euronews, bei dem der bestehende Ausdruck dickpanel nicht ganz passend wirkte
  • In einer Mastodon-Umfrage wurde gefragt, wie man „einen gefälschten Dialog in einem Fenster nennen sollte, mit dem Websites und einige Apps Inhalte überdecken“; unter 1.130 Antworten gewann dickover knapp mit 51 zu 49
  • Ob sich ein Neologismus durchsetzt, entscheidet weniger seine Beschreibungsstärke oder Klarheit als sein tatsächlicher Gebrauch, und dickover wirkt wie ein scharfer Ausdruck, der Spaß macht zu benutzen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Hacker-News-Kommentare

  • Meine Erfahrung war wahrscheinlich genau so, wie es beabsichtigt war. Ich klickte auf den Link „What is a dickover?“ und fragte mich, was das wohl ist, und kaum war die Seite geladen und nach einem ganz kurzen Stillstand, schlug mir ein großes, nerviges Popup mit „This is a Dickover“ ins Gesicht, und ich verstand sofort.
    Jetzt weiß ich immerhin, wie ich das nennen kann, wenn ich das nächste Mal auf Substack gehe

  • Ich habe die Hypothese, dass ungefähr 97 % der Entwickler und Administratoren so etwas wie die Cookie-Einwilligung ihres eigenen Produkts schon vor fünf Jahren einmal weggeklickt haben und es danach nie wieder sehen, weshalb sie nicht wissen, wie schlecht die Erfahrung für Neukunden tatsächlich ist.
    Entwickler und ihre Vorgesetzten glauben, sie machen großartige Arbeit und hätten die Homepage schön ausgefeilt, aber normale Nutzer bekommen nacheinander ein Cloudflare-Captcha, ein Cookie-Modal, ein Newsletter-Modal und ein App-Installations-Modal ab, und all das versperrt den Zugang zum Button „Produkt kaufen“.

    • Am besten sind die, die auf der nächsten Seite wieder fragen, nachdem man abgelehnt hat.
      Vermutlich wissen sie nicht, was funktionale Cookies sind. Vielleicht kennt das Marketing-Vokabular nur YES.
    • Wenn es „nie wieder angezeigt“ wird, klingt das schon nach einer besseren Implementierung als 99,9 % der dickover, denen ich begegne.
      Die meisten tauchen später wieder auf, selbst wenn man sie schließt, und manche gefühlt bei jedem Besuch der Website.
    • Es gibt auch die Hypothese, dass es ihnen schlicht egal ist, was Kunden denken.
    • Entwickler sind nicht besonders gut darin zu beurteilen, was für die User Experience das Beste ist. Wie sollte man sonst die Hunderttausende Stunden Branchenforschung rechtfertigen, die Designer und PMs in dieses schöne, performante First-Screen-Design und die automatisch nachladenden Modals dahinter gesteckt haben?
      Man soll es bitte den Experten überlassen.
    • Websites sollte man immer im Inkognito-Fenster testen.

  • Eines der Kriterien für die Aufnahme ins Kagi Small Web ist, dass es keinen dickover gibt. Danke, John, dass du dem Ding einen richtigen Namen gegeben hast.
    [1] https://kagi.com/smallweb

    • Es wäre schön, wenn man den Originallink des Small-Web-Artikels leichter teilen könnte. Im Moment ist das so schwierig, dass es fast so wirkt, als wolle man die Leute dazu zwingen, die Kagi-URL-Version zu teilen.
    • Für genau diese Seite sollte man vielleicht eine Ausnahme machen.
    • Zur Info: Nachdem ich dreimal auf „next“ geklickt hatte, kam eine Seite mit einem Cookie-dickover. Da müsste man den Filter wohl etwas nachjustieren.
    • Der echte dickover-Moment ist, wenn man den Dienst zu nutzen beginnt und merkt, dass sie mit Yandex Geschäfte machen.

  • Wenn man eine Browser-Erweiterung einrichtet, mit der sich JavaScript ein- und ausschalten lässt, kann man die meisten Popups, Nagscreens und Cookie-Abfragen blockieren. Solche Erweiterungen gibt es einige.
    Alternativ kann man auch einen anderen Browser mit dauerhaft deaktiviertem JavaScript minimiert im Tray oder im Hintergrund bereithalten.
    Viele Websites, die ein Abo verlangen, einen Nagscreen anzeigen oder andere Sperren verwenden, lassen sich lesen, sobald man nur JavaScript deaktiviert.
    Das JavaScript von Websites ist zu einem Mittel geworden, mit dem Unternehmen uns manipulieren und kontrollieren, Nagscreens anzeigen oder Abos verlangen.
    Wenn ich auf eine Seite stoße, die vor dem Laden JavaScript verlangt, lasse ich sie einfach fallen und schaue sie mir nie wieder an.

  • Ich unterstütze diesen Namen. Wenn das der Standardbegriff für diese Technik wird, müssen Leute in Meetings dieses Wort benutzen, wenn sie sie ernsthaft vorschlagen, und dann wird es schwieriger, sie mit ernstem Gesicht vorzuschlagen.
    „Das ist unser Dickover-Design.“
    „Leute, ich glaube nicht, dass wir unseren Kunden einen Dickover verpassen sollten.“
    „Wenn man es so ausdrückt, klingt es schon etwas komisch …“
    Epilog: Sechs Monate später konvertiert der Newsletter überhaupt nicht, und die Website geht unter.

    • Wer sind solche Leute überhaupt? Also diejenigen, die nicht im Geringsten wütend werden, wenn ihnen ein dickover ins Gesicht geklatscht wird, fröhlich weitermachen und ernsthaft darüber nachdenken, ihre E-Mail-Adresse in diesen dickover einzutragen?

  • Dieses Bookmarklet ist sehr praktisch, wenn man es zur Hand hat.

    javascript:(function()%7B let i%2C elements %3D document.querySelectorAll('body *')%3B for (i %3D 0%3B i < elements.length%3B i%2B%2B) %7B if(getComputedStyle(elements%5Bi%5D).position %3D%3D%3D 'fixed' %7C%7C getComputedStyle(elements%5Bi%5D).position %3D%3D%3D 'sticky')%7B elements%5Bi%5D.parentNode.removeChild(elements%5Bi%5D)%3B %7D %7D %7D)()

    Manchmal braucht man danach noch dieses zweite, um das Scrollen wieder zu reparieren.

    javascript:var r="html,body{overflow:auto !important;}"; var s=document.createElement("style"); s.type="text/css"; s.appendChild(document.createTextNode(r)); document.body.appendChild(s); void 0;

  • Auf Substack werden diese Dinger an meine Beiträge angehängt, selbst wenn ich sie ausdrücklich deaktiviere. Ob das ein Bug ist oder so beabsichtigt funktioniert, weiß ich nicht, aber es reicht aus, damit ich Substack nicht mehr benutze.
    Ich will meinen Lesern so etwas nicht antun.

  • Für Leute wie mich, die Websites zum Lesen vergrößern, sind diese Dinger besonders nervig.
    Um den Schließen-Button zu finden, muss ich wieder herauszoomen. Jedes Mal ist es eine Verfolgungsjagd, und manchmal gebe ich einfach auf.
    Es gibt die EU Web Accessibility Directive, und ich verstehe nicht, wie so etwas erlaubt sein kann.

    • Selbst HN ist furchtbar, wenn der UI-Zoom größer als 1,0 ist.
      Man muss ständig horizontal scrollen, um den Text lesen zu können.

  • Ich frage mich, ob noch jemand dachte, das sei ein cleveres keming-Wortspiel.
    Zum Glück ist es selbst auf Websites, bei denen der Inhalt JavaScript braucht oder bei denen man JavaScript braucht, um einen dickover zu entfernen, nicht besonders schwer und ziemlich befriedigend, solche und andere störende Elemente mit dem Elementinspektor des Browsers zu löschen.

    • Die Funktion Hide Distracting Items in Safari ist ein großer Grund, warum ich kein Chrome benutze.
    • Als ich zum ersten Mal die kleingeschriebene Version von dickover sah, las ich sie als clickover.

  • Für mich ist schon die bloße Tatsache, dass ein dickover möglich ist, ein Bug in jedem JavaScript-Interpreter.
    Ein richtiger Browser sollte meiner Meinung nach nicht nur dickover unmöglich machen, sondern auch verwandtes feindseliges Verhalten wie das Verändern des Rechtsklick-Menüs oder das Blockieren der Textauswahl durch Webseiten.
    Leider ist das vollständige Deaktivieren von Skripten keine praktikable Lösung, weil viele Seiten dann gar nicht mehr funktionieren, aber die oben genannten Verhaltensweisen haben für den Nutzer keinerlei sinnvollen Zweck und sollten daher wirkungslos sein, und es sollte für feindselige Seiten auch keine Möglichkeit geben festzustellen, ob diese Aktionen greifen oder nicht.
    Modalfenster können in Anwendungen, die ich selbst kontrolliere, manchmal nützlich sein, aber in Anwendungen, die von anderen kontrolliert werden, etwa beim Surfen auf Internetseiten, sollte man sie immer ignorieren oder umgehen können.

    • Ich frage mich wirklich, ob man auf Ebene der JavaScript-Implementierung, des DOM oder des Browsers irgendetwas tun könnte, um somehow nur dickover zu blockieren, während gewünschte modale Popover-Inhalte wie Dropdown-Menüs, Tooltips und schwebende Navigationsleisten weiterhin erlaubt bleiben?