▲

Dickover란 무엇인가?

 (daringfireball.net)
1P by GN⁺ | ★ favorite | 댓글 1개
  • dickover는 웹사이트나 앱이 모달 패널·팝오버·커튼형 UI로 자기 콘텐츠를 가리고, 불필요한 상호작용을 강요하는 방해물임
  • 쿠키 수락, 뉴스레터 가입, 앱 설치, 약관 동의처럼 사용자가 읽으려던 콘텐츠와 직접 관련 없는 요구가 대표적임
  • Substack 홈의 전체 화면 커튼, Philadelphia Inquirer의 SMS 가입 요구, Tom’s Hardware의 Z축 충돌이 주요 사례임
  • dickbar는 페이지 일부만 가리고 필수 행동을 덜 요구하지만, 텍스트를 덮고 스페이스바 스크롤을 방해해 경험을 해침
  • 페이월의 가입·로그인은 콘텐츠 접근에 필요한 절차라 dickover와 다르며, 핵심 기준은 불필요성과 관심 차단 여부임

Dickover의 정의와 문제

  • dickover는 웹사이트나 앱이 자기 콘텐츠를 의도적으로 가리는 모달 패널, 팝오버, 커튼형 UI를 뜻함
  • 사용자가 원하지 않고 필요하지도 않은 상호작용을 강요해 콘텐츠 접근을 방해함
  • 대표적인 요구는 쿠키 수락, 뉴스레터 구독, 모바일 앱 설치, 서비스 약관 동의처럼 사용자가 읽으려던 콘텐츠와 직접 관련 없는 것들임
  • 웹과 모바일 앱에서 점점 더 자주 보이며, 일반 팝오버보다 더 직접적으로 사용자의 읽기 흐름을 끊음

흔한 유형과 사례

  • 쿠키 허용을 요구하는 dickover는 매우 흔하며, Euronews 사례와 Gallup 사례가 있음
  • 뉴스레터 가입 요구도 같은 패턴으로 쓰이며, 개인 블로그인 Om Malik 사례와 브랜드 사이트인 Field Notes 사례가 포함됨
  • Substack이 호스팅하는 블로그 홈페이지에는 특히 악질적인 형태의 dickover가 표시됨
    • 패널처럼 보이지 않는 전체 화면 커튼으로 글을 읽으려면 이메일 뉴스레터에 가입해야 하는 것처럼 강하게 암시함
    • 닫기 버튼은 버튼처럼 보이지 않는 작은 텍스트 링크로 배치됨
    • Paul Krugman과 Matt Yglesias 사례는 “No thanks” 같은 문구를 사용함
    • Volts 사례는 “Just gimme that content!”처럼 지나치게 달콤한 문구를 씀
  • The Philadelphia Inquirer 사례는 월 20달러 구독자가 로그인한 상태에서도 Jersey shore 관련 SMS 수신에 가입해야 기사를 볼 수 있게 함
  • Tom’s Hardware 사례는 사이트의 dickover가 자체 광고에 다시 가려지는 JavaScript Z축 충돌을 보여줌

웹페이지가 해야 할 일

  • 웹사이트에 방문하면 사용자는 웹사이트 콘텐츠를 바로 볼 수 있어야 함
  • 기사 페이지에서 “뉴스레터 구독”이나 “쿠키 수락” dickover를 먼저 보여주는 것은 웹페이지의 기본 목적과 어긋남
  • 웹페이지는 웹페이지를 보여줘야 하고, 이메일은 이메일 내용을 보여줘야 함
  • 기사, 스토리, 제품 페이지에 주어진 사용자의 관심은 사이트가 얻은 특권이며, 그 관심을 의도적으로 끊는 행위는 부적절함

표시 타이밍이 만드는 더 큰 방해

  • 일부 사이트는 페이지 로드 직후 dickover를 띄우며, 사용자는 오늘날 웹페이지 로딩 때 이런 장애물을 어느 정도 예상함
  • 더 나쁜 경우는 사용자가 이미 읽기 시작하고 스크롤을 내린 뒤에 갑자기 dickover를 띄우는 방식임
  • 읽는 도중의 방해는 사용자가 이미 부여한 관심 외의 다른 것을 요구하려고 실제 책이나 잡지를 손에서 빼앗는 행위와 다르지 않음
  • 물리적 출판물을 독자의 손에서 빼앗는다면 얼굴을 맞을 수 있다는 비유처럼, 읽기 경험을 끊는 행위는 그만큼 공격적임

Dickbar와의 차이

  • Dickbar는 dickover와 관련 있지만 디자인과 사용자 경험 측면에서는 더 가벼운 위반으로 분류됨
  • dickbar는 비모달 팝오버로, underlying content 전체가 아니라 일부만 가림
  • dickbar가 상대적으로 덜 나쁜 이유는 페이지 전체를 가리지 않고, 닫기 위한 필수 행동을 요구하지 않기 때문임
  • 그래도 dickbar는 콘텐츠를 가리고 주의를 분산시켜 사용자 경험을 해침
  • 특히 가장 흔한 가로형 dickbar는 스페이스바로 한 화면씩 넘길 때 문제를 만듦
    • 페이지는 dickbar 높이를 제외하지 않고 전체 웹페이지 높이만큼 스크롤됨
    • 그 결과 다음 화면으로 이동할 때마다 dickbar가 아직 읽지 않은 텍스트를 가림

모달 차단기와 Dickover의 경계

  • 모든 dickover는 모달 차단기지만, 모든 모달 차단기가 dickover는 아님
  • 유료 콘텐츠의 가입 또는 로그인 패널은 dickover가 아님
  • 페이월은 때로 성가실 수 있지만, dickover의 핵심 조건 중 하나는 불필요성임
  • 쿠키 권한 요청과 이메일 뉴스레터 가입 요청은 콘텐츠를 읽기 위해 필요하지 않음
  • 반면 페이월 콘텐츠에서는 가입이나 로그인이 필요하므로 dickover와 구분됨

용어가 만들어진 배경

  • 2022년에는 이런 UI를 dickpanel이라고 부르기 시작했지만, 이후 dickover가 더 적합한 표현으로 자리 잡음
  • 새 용어는 Mac용 드래그앤드롭 “선반” 유틸리티 Dropover에 대해 쓰려던 과정에서 떠오름
  • 그 직전 Euronews의 특히 우스운 쿠키 모달 차단기에 대해 불평한 항목이 있었고, 기존 dickpanel이라는 표현이 잘 붙지 않는다고 느끼게 됨
  • Mastodon 설문에서는 “웹사이트와 일부 앱이 콘텐츠를 덮는 창 안의 가짜 대화상자”를 무엇이라 부르는 게 나은지 물었고, 1,130개 응답에서 dickover가 51대 49로 근소하게 이김
  • 신조어가 자리 잡는 기준은 설명성이나 명확성보다 사용 여부이며, dickover는 날카롭고 쓰기 재미있는 표현으로 보임

함께 보면 좋은 글 β

▲
GN⁺   [-]
Hacker News 의견들

  • 내 경험은 아마 의도한 그대로였던 것 같음. “What is a dickover?” 링크를 누르며 이게 뭘까 상상하고 있었는데, 페이지가 뜬 뒤 아주 짧은 멈춤이 지나자마자 “This is a Dickover”라는 크고 짜증 나는 팝업이 얼굴을 때렸고 바로 이해됨
    이제 다음에 Substack에 갈 때 이걸 뭐라고 부르면 되는지는 알게 됨

  • 개발자와 관리자 중 97% 쯤은 5년 전에 자기 제품의 쿠키 동의 같은 걸 한 번 완료해버려서 다시는 보지 않고, 그래서 신규 고객 경험이 실제로 얼마나 나쁜지 모른다는 가설이 있음
    개발자와 상사들은 자신들이 훌륭히 하고 있고 홈페이지도 잘 다듬었다고 생각하지만, 일반 사용자는 Cloudflare 캡차, 쿠키 모달, 뉴스레터 모달, 앱 설치 모달을 차례로 맞고, 전부가 ‘제품 구매’ 버튼 접근을 막고 있음

    • 거절하면 다음 페이지에서 다시 묻는 것들이 최고임
      아마 기능성 쿠키가 뭔지 모르는 듯함. 마케팅 어휘에는 YES밖에 없을지도 모름
    • “다시는 보지 않는다”면 내가 마주치는 dickover의 99.9%보다 나은 구현처럼 들림
      대부분은 닫아도 나중에 또 보이고, 어떤 건 사이트 방문할 때마다 나오는 느낌임
    • 고객이 어떻게 생각하는지 신경 쓰지 않는다는 가설도 있음
    • 개발자는 사용자 경험에 뭐가 최선인지 판단하는 데 능숙하지 않음. 디자이너와 PM이 그 아름답고 성능 좋은 첫 화면 디자인과 이어지는 자동 로드 모달에 쏟아부은 업계 연구 수십만 시간을 어떻게 정당화하겠나
      제발 전문가에게 맡기라는 말임
    • 웹사이트는 항상 시크릿 창에서 테스트해야 함

  • Kagi Small Web에 포함되는 기준 중 하나가 dickover가 없는 것임. 이름을 제대로 붙여줘서 고마움, John
    [1] https://kagi.com/smallweb

    • Small Web 글의 원본 링크를 더 쉽게 공유할 수 있게 해주면 좋겠음. 지금은 너무 어려워서 Kagi 버전 URL을 공유하도록 강제하려는 것처럼 느껴질 정도임
    • 이 특정 페이지에는 예외를 두면 좋겠음
    • 참고로 “next”를 세 번 누르자 쿠키 dickover가 있는 페이지가 나왔음. 필터를 좀 조정해야 할 듯함
    • 진짜 dickover 순간은 서비스를 쓰기 시작한 뒤 그들이 Yandex와 거래한다는 걸 깨닫는 때임

  • 자바스크립트를 켜고 끌 수 있는 브라우저 확장 기능을 설정해두면 대부분의 팝업, 잔소리 화면, 쿠키 요구를 막을 수 있음. 그런 확장은 여러 개 있음
    대안으로 자바스크립트를 영구적으로 끈 다른 브라우저를 트레이나 백그라운드에 최소화해 두는 방법도 있음
    구독을 요구하거나 잔소리 화면을 띄우거나 다른 차단을 쓰는 많은 웹사이트는 자바스크립트만 끄면 읽을 수 있음
    웹사이트의 자바스크립트는 기업이 우리를 조작·통제하고 잔소리 화면을 띄우거나 구독을 요구하는 수단이 되어버림
    로드 전에 자바스크립트를 요구하는 사이트를 만나면 그냥 버리고 영원히 보지 않음

  • 이 이름을 지지함. 이 기법의 표준 이름이 되면 회의에서 진지하게 제안할 때 사람들이 그 단어를 써야 하고, 그러면 진지하게 제안하기가 더 어려워짐
    “이게 우리 Dickover 디자인입니다”
    “여러분, 고객에게 Dickover를 씌우는 건 좀 아닌 것 같습니다”
    “그렇게 말하니까 좀 그렇네요…”
    에필로그: 6개월 뒤, 뉴스레터 전환이 전혀 안 돼서 사이트는 망함

    • 대체 그런 사람들은 누구임? dickover가 얼굴에 붙어도 전혀 분노하지 않고 계속 즐거워하며, 그 dickover에 이메일 주소를 입력하는 걸 진지하게 고려하는 사람들 말임

  • 이 북마클릿은 가지고 있으면 아주 좋음

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

    가끔은 위걸 쓴 뒤 스크롤을 고치려고 이 두 번째 것도 필요함

    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;

  • Substack에서 이것들을 명시적으로 꺼도 내 글에 어쨌든 붙음. 버그인지 의도대로 동작하는 건지는 모르겠지만, 그걸로 충분히 Substack 사용을 그만두게 됨
    독자들에게 그런 짓을 하고 싶지 않음

  • 나처럼 웹사이트를 읽으려고 확대해서 보는 사람에게는 이런 것들이 특히 짜증 남
    닫기 버튼을 찾으려면 다시 축소해야 함. 매번 추격전이고, 때로는 그냥 포기하게 됨
    EU Web Accessibility Directive가 있는데 이런 게 어떻게 허용되는지 모르겠음

    • HN 자체도 UI 배율이 1.0보다 크면 형편없음
      텍스트를 읽으려고 계속 가로 스크롤을 하게 됨

  • 이게 영리한 keming 말장난이라고 생각한 사람이 또 있었는지 궁금함
    다행히 콘텐츠에 자바스크립트가 필요하거나 dickover를 제거하는 데 자바스크립트가 필요한 사이트에서도, 브라우저의 요소 검사 도구로 이런 것들과 다른 성가신 요소를 삭제하는 건 그리 어렵지 않고 꽤 후련함

    • Safari의 Hide Distracting Items 기능은 내가 Chrome을 쓰지 않는 큰 이유임
    • dickover의 소문자 버전을 처음 봤을 때는 clickover라고 읽었음

  • 나에게는 dickover가 가능하다는 사실 자체가 모든 자바스크립트 인터프리터의 버그임
    제대로 된 브라우저라면 dickover뿐 아니라 웹페이지가 우클릭 메뉴를 바꾸거나 텍스트 선택을 막는 것 같은 관련 적대적 동작도 불가능하게 만들어야 한다고 봄
    안타깝게도 스크립트를 완전히 끄는 건 많은 사이트가 아예 동작하지 않아서 해결책이 되기 어렵지만, 위에서 말한 행동들은 사용자에게 유용한 목적이 전혀 없으므로 효과가 없어야 하고, 적대적 사이트가 그 동작이 먹히는지 아닌지 알아낼 방법도 없어야 함
    모달 창은 내가 제어하는 애플리케이션에서는 가끔 유용할 수 있지만, 인터넷 사이트를 탐색할 때처럼 외부가 제어하는 애플리케이션에서는 항상 무시하거나 우회할 수 있어야 함

    • 진짜 궁금한데, 원하는 모달 팝오버 콘텐츠인 드롭다운 메뉴, 툴팁, 떠 있는 내비게이션 바는 허용하면서 somehow dickover만 막기 위해 자바스크립트 구현이나 DOM, 브라우저 쪽에서 뭘 할 수 있을까?
답변달기