1 pontos por GN⁺ 4 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • dickover é um incômodo em que um site ou app esconde o próprio conteúdo com um painel modal, popover ou interface em forma de cortina e força interações desnecessárias
  • Pedidos como aceitar cookies, assinar newsletter, instalar app ou concordar com termos de uso são exemplos típicos, por não terem relação direta com o conteúdo que a pessoa queria ler
  • Entre os principais exemplos estão a cortina em tela cheia da página inicial do Substack, a exigência de cadastro para SMS do Philadelphia Inquirer e o conflito de eixo Z no Tom’s Hardware
  • dickbar cobre apenas parte da página e exige menos ações obrigatórias, mas ainda prejudica a experiência ao encobrir texto e atrapalhar a rolagem com a barra de espaço
  • O login ou cadastro de um paywall não é dickover, porque faz parte do acesso ao conteúdo; o critério central é a desnecessidade e o bloqueio da atenção

Definição e problema do Dickover

  • dickover é um painel modal, popover ou interface em forma de cortina com que um site ou app encobre deliberadamente o próprio conteúdo
  • Ele atrapalha o acesso ao conteúdo ao forçar uma interação que o usuário não quer e de que não precisa
  • As exigências mais comuns são aceitar cookies, assinar newsletter, instalar um app mobile ou concordar com termos de serviço — coisas sem relação direta com o que a pessoa pretendia ler
  • Eles aparecem cada vez mais na web e em apps mobile e interrompem o fluxo de leitura de forma mais direta do que um popover comum

Tipos comuns e exemplos

  • Dickovers que exigem aceitar cookies são muito comuns, com o caso da Euronews e o caso da Gallup
  • Exigências para assinar newsletter seguem o mesmo padrão, incluindo o caso do Om Malik, um blog pessoal, e o caso da Field Notes, um site de marca
  • A página inicial de blogs hospedados no Substack mostra uma forma especialmente nociva de dickover
    • Uma cortina em tela cheia que nem parece um painel passa a forte impressão de que é preciso assinar a newsletter por email para ler o texto
    • O botão de fechar aparece como um pequeno link em texto que não parece um botão
    • Os casos de Paul Krugman e Matt Yglesias usam frases como “No thanks”
    • O caso do Volts usa uma frase açucarada demais, como “Just gimme that content!”
  • O caso do The Philadelphia Inquirer faz até assinantes de US$ 20 por mês, já conectados, se cadastrarem para receber SMS sobre Jersey Shore antes de poder ler a matéria
  • O caso do Tom’s Hardware mostra um conflito de eixo Z em JavaScript, no qual o dickover do site é novamente coberto pela própria publicidade

O que uma página web deveria fazer

  • Ao visitar um site, a pessoa deveria conseguir ver imediatamente o conteúdo do site
  • Mostrar antes um dickover de “assine a newsletter” ou “aceite os cookies” numa página de artigo contraria o objetivo básico de uma página web
  • Uma página web deve mostrar a página web, e um email deve mostrar o conteúdo do email
  • O interesse do usuário por um artigo, história ou página de produto é um privilégio conquistado pelo site, e interromper deliberadamente essa atenção é impróprio

O momento da exibição cria um incômodo ainda maior

  • Alguns sites exibem o dickover logo após o carregamento da página, e hoje os usuários já esperam até certo ponto esse tipo de obstáculo
  • Pior ainda é quando o site mostra de repente um dickover depois que a pessoa já começou a ler e rolou a página
  • Interromper no meio da leitura para pedir outra coisa além da atenção já concedida pelo usuário não é diferente de arrancar de suas mãos um livro ou revista de papel
  • Assim como alguém poderia levar um tapa na cara por arrancar uma publicação física das mãos de um leitor, interromper a experiência de leitura é um ato igualmente agressivo

Diferença em relação ao Dickbar

  • O Dickbar é relacionado ao dickover, mas é classificado como uma infração mais leve em termos de design e experiência do usuário
  • dickbar é um popover não modal que cobre apenas parte do conteúdo subjacente, e não a página inteira
  • O dickbar é relativamente menos ruim porque não encobre a página inteira e não exige uma ação obrigatória para ser fechado
  • Mesmo assim, ele prejudica a experiência do usuário ao cobrir conteúdo e desviar a atenção
  • Em especial, o dickbar horizontal mais comum cria um problema ao avançar a página com a barra de espaço
    • A página rola pela altura total da página web, sem descontar a altura do dickbar
    • Como resultado, a cada avanço de tela o dickbar cobre texto que a pessoa ainda não leu

Limite entre bloqueadores modais e Dickover

  • Todo dickover é um bloqueador modal, mas nem todo bloqueador modal é um dickover
  • Painéis de cadastro ou login para conteúdo pago não são dickover
  • O paywall pode ser irritante às vezes, mas uma das condições centrais do dickover é a desnecessidade
  • Pedidos de permissão para cookies e cadastro em newsletter por email não são necessários para ler o conteúdo
  • Já no conteúdo com paywall, cadastro ou login são necessários, por isso ficam numa categoria diferente de dickover

Como o termo surgiu

  • Em 2022, esse tipo de interface começou a ser chamado de dickpanel, mas depois dickover se consolidou como a expressão mais adequada
  • O novo termo surgiu durante um processo de escrita sobre o utilitário de “prateleira” de arrastar e soltar para Mac Dropover
  • Pouco antes disso, houve uma reclamação sobre um bloqueador modal de cookies especialmente ridículo da Euronews, e a expressão dickpanel já não parecia se encaixar bem
  • Numa enquete no Mastodon, perguntou-se qual seria o melhor nome para “caixas de diálogo falsas dentro de janelas que cobrem o conteúdo em sites e alguns apps”, e em 1.130 respostas dickover venceu por pouco, 51 a 49
  • O que define se um neologismo pega não é sua capacidade de explicar ou sua clareza, mas seu uso; e dickover parece uma expressão afiada e divertida de usar

1 comentários

 
GN⁺ 4 시간 전
Comentários do Hacker News
  • Minha experiência foi provavelmente exatamente a pretendida. Cliquei no link “What is a dickover?” imaginando o que seria, e, assim que a página carregou e passou uma pausa bem curta, um pop-up grande e irritante com “This is a Dickover” bateu na minha cara, e eu entendi na hora
    Agora pelo menos já sei como chamar isso da próxima vez que eu entrar no Substack

  • Tenho a hipótese de que uns 97% dos desenvolvedores e administradores já concluíram uma vez, há 5 anos, algo como o consentimento de cookies do próprio produto e nunca mais viram isso, então não fazem ideia de quão ruim é de fato a experiência de novos clientes
    Desenvolvedores e chefes acham que estão fazendo um ótimo trabalho e que a homepage está bem polida, mas o usuário comum toma uma sequência de captcha da Cloudflare, modal de cookies, modal de newsletter e modal para instalar o app, e tudo isso bloqueia o acesso ao botão de “comprar o produto”

    • O melhor é quando você recusa e na página seguinte perguntam de novo
      Acho que eles não sabem o que é cookie funcional. Talvez no vocabulário do marketing só exista YES
    • Se é para “nunca mais ver”, isso já parece uma implementação melhor do que 99,9% dos dickovers que eu encontro
      Na maioria das vezes, mesmo fechando, eles aparecem de novo depois, e alguns parecem surgir toda vez que você visita o site
    • Também existe a hipótese de que eles simplesmente não se importam com o que os clientes pensam
    • Desenvolvedores não são muito bons em julgar o que é melhor para a experiência do usuário. Como é que vão justificar as centenas de milhares de horas de pesquisa da indústria que designers e PMs despejaram naquele lindo e performático design da primeira tela e no modal que carrega automaticamente logo em seguida?
      A ideia é: por favor, deixem isso com os especialistas
    • Site sempre tem que ser testado em janela anônima
  • Um dos critérios para entrar no Kagi Small Web é não ter dickover. Obrigado por dar o nome certo a isso, John
    [1] https://kagi.com/smallweb

    • Seria bom se facilitassem compartilhar o link original dos posts do Small Web. Hoje é tão difícil que parece até que estão tentando forçar você a compartilhar a URL da versão da Kagi
    • Seria bom abrir uma exceção para esta página específica
    • Só para constar: apertei “next” três vezes e apareceu uma página com cookie dickover. Parece que precisam ajustar um pouco o filtro
    • O verdadeiro momento dickover é quando você começa a usar o serviço e percebe que eles fazem negócio com a Yandex
  • Se você configurar uma extensão de navegador que permita ligar e desligar o JavaScript, dá para bloquear a maioria dos pop-ups, telas de bronca e pedidos de cookies. Existem várias extensões assim
    Como alternativa, também dá para deixar minimizado na bandeja ou em segundo plano outro navegador com JavaScript permanentemente desligado
    Muitos sites que exigem assinatura, mostram telas de bronca ou usam outros bloqueios podem ser lidos só desligando o JavaScript
    O JavaScript dos sites virou um meio de empresas nos manipularem e controlarem, exibirem telas de bronca ou exigirem assinatura
    Se eu encontro um site que exige JavaScript antes de carregar, simplesmente abandono e nunca mais volto

  • Apoio esse nome. Se ele virar o nome padrão dessa técnica, as pessoas vão ter que usar essa palavra quando a propuserem seriamente em reuniões, e isso vai tornar bem mais difícil propô-la com cara séria
    “Este é o nosso design de Dickover”
    “Pessoal, acho meio complicado enfiar um Dickover nos clientes”
    “Falando assim, realmente soa mal...”
    Epílogo: 6 meses depois, a conversão da newsletter continua zerada e o site quebra

    • Quem são essas pessoas, afinal? As que não sentem absolutamente nenhuma raiva quando um dickover gruda na cara delas, continuam felizes e ainda consideram seriamente digitar o endereço de e-mail naquele negócio
  • Este bookmarklet é ótimo de ter à mão

    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)()  
    

    Às vezes, depois de usar o de cima, você também precisa deste segundo para consertar o scroll

    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;  
    
  • Mesmo desativando isso explicitamente no Substack, continua sendo adicionado aos meus textos de qualquer jeito. Não sei se é bug ou se está funcionando como planejado, mas isso já basta para me fazer parar de usar o Substack
    Não quero fazer isso com meus leitores

  • Para quem, como eu, lê sites com zoom para conseguir enxergar, essas coisas são especialmente irritantes
    Para achar o botão de fechar, preciso reduzir o zoom de novo. É uma perseguição toda vez, e às vezes eu simplesmente desisto
    Existe a EU Web Accessibility Directive, então não sei como isso é permitido

    • O próprio HN fica horrível quando a escala da UI está acima de 1.0
      Você acaba tendo que fazer rolagem horizontal o tempo todo só para ler o texto
  • Queria saber se mais alguém achou que isso era um trocadilho esperto de keming
    Felizmente, mesmo em sites em que o conteúdo exige JavaScript ou em que remover o dickover exige JavaScript, não é tão difícil apagar essas coisas e outros elementos irritantes com a ferramenta de inspecionar elementos do navegador, e isso é bastante satisfatório

    • O recurso Hide Distracting Items do Safari é um dos grandes motivos de eu não usar Chrome
    • Quando vi a versão em minúsculas de dickover pela primeira vez, li como clickover
  • Para mim, o simples fato de dickover ser possível já é um bug em todos os interpretadores de JavaScript
    Um navegador decente deveria tornar impossível não só dickovers, mas também comportamentos hostis relacionados, como páginas alterarem o menu de clique direito ou impedirem a seleção de texto
    Infelizmente, desligar scripts por completo não é uma solução viável, porque muitos sites simplesmente deixam de funcionar, mas os comportamentos mencionados acima não têm utilidade nenhuma para o usuário, então deveriam simplesmente não surtir efeito, e sites hostis também não deveriam ter como descobrir se esses comportamentos funcionam ou não
    Janelas modais às vezes podem ser úteis em aplicativos que eu controlo, mas em aplicativos controlados por terceiros, como ao navegar em sites na internet, eu deveria sempre poder ignorá-las ou contorná-las

    • Fico genuinamente curioso se haveria algo que desse para fazer na implementação de JavaScript, no DOM ou no navegador para bloquear especificamente dickovers de algum jeito, ao mesmo tempo em que se permite conteúdo modal legítimo, como menus suspensos, tooltips e barras de navegação flutuantes